Trial Balance Validation
How VersionForge validates extracted GL data against NetSuite trial balance reports at each fiscal period checkpoint.
Why Validate at Each Period
A GL history load can contain hundreds of thousands of transactions across dozens of periods. If you load everything and discover a discrepancy afterward, isolating the problem -- which period, which account, which subsidiary -- becomes a painful forensic exercise. VersionForge prevents this by validating every period individually before it leaves the staging area.
How Trial Balance Validation Works
After each period is extracted and staged, VersionForge runs a three-step validation:
Sum extracted debits and credits
VersionForge totals all debit and credit amounts from the extracted transaction detail for the period. These sums represent what VersionForge pulled from the GL.
Fetch the NetSuite trial balance
VersionForge queries NetSuite's native Trial Balance report for the same period and subsidiary scope. This gives you the authoritative totals that NetSuite considers correct.
Compare within tolerance
The extracted totals are compared against the NetSuite trial balance. If the absolute difference is within your configured tolerance (default: $1.00), the period passes. If it exceeds tolerance, the period is flagged as Failed Validation.
You configure the tolerance threshold in GL History Loader > Settings > Validation. For high-volume subsidiaries with rounding across currencies, you may need to increase tolerance to $5.00 or $10.00.
What Happens When a Period Fails
A failed period does not stop the entire load. The loader continues processing remaining periods and flags the failed one for your attention. On the Period Progress Grid, the failed period shows a red badge with a link to the validation detail.
The validation detail report shows:
- Expected totals (from NetSuite trial balance)
- Extracted totals (from VersionForge's extraction)
- Variance amount and variance percentage
- Account-level breakdown -- which accounts contribute most to the variance
You fix the issue, then re-run extraction for only that period. The loader does not re-process periods that already passed.
Never override a failed validation without investigating. A trial balance discrepancy usually means missing transactions, duplicates, or a fiscal calendar mismatch. Loading incorrect actuals into your planning tool creates downstream variance analysis errors that are difficult to trace.
Reconciliation Report
After all periods are processed, VersionForge generates a Reconciliation Report accessible from the GL History Loader dashboard. The report includes:
- Period-by-period summary -- Status (passed/failed), extracted total, expected total, variance.
- Account-level detail -- For each period, a breakdown by account showing extracted vs. expected amounts.
- Subsidiary rollup -- If you loaded multiple subsidiaries, totals are broken out by subsidiary with elimination entries shown separately.
- Export options -- Download the report as CSV or PDF for auditor review.
Common Discrepancy Causes
| Symptom | Likely Cause | Fix | |---------|-------------|-----| | Small variance ($0.01-$1.00) across many accounts | Currency rounding during multi-currency consolidation | Increase tolerance to $1.00-$5.00 | | Large variance in a single account | Eliminated intercompany transactions included/excluded | Check your subsidiary scope and elimination settings | | Entire period off by a round number | Journal entries posted after the trial balance snapshot | Re-run the extraction for the affected period | | Variance only in the first or last period | Fiscal calendar start/end date mismatch | Verify your fiscal calendar configuration matches NetSuite |
The reconciliation report is retained for every GL History Loader run, even after the data is loaded. You can pull it up months later for audit support or restatement reference.