Trial Balance Cross-Check

How VersionForge reconciles source totals against target totals after every sync to catch discrepancies before they reach your planning models.

Why Cross-Check Exists

A sync that completes without errors is not the same as a sync that is correct. Rows can be silently dropped, transforms can misfire, and rounding can accumulate. The trial balance cross-check is VersionForge's final verification gate -- it proves that the numbers in your planning target actually tie back to the source.

How It Works

After every load completes, VersionForge runs a three-step reconciliation automatically:

Aggregate source totals -- Sum the GL amounts from the extracted snapshot, grouped by the dimensions you configure (typically account, period, and entity).
Aggregate target totals -- Query the target system for the same grouping and sum the loaded values.
Compare with tolerance -- Calculate the absolute variance between source and target for each group. If every variance falls within the configured tolerance, the check returns PASS. If any variance exceeds tolerance, the check returns FAIL.

The result is attached to the sync run and visible on the Verification tab.

A Real Example

Suppose your sync loads general ledger data for March 2026 into Adaptive Planning. After the load:

| Metric | Value | |--------|-------| | Source total (NetSuite GL extract) | $4,892,341.00 | | Target total (Adaptive sheet sum) | $4,892,341.00 | | Variance | $0.00 | | Tolerance | $1.00 | | Result | PASS |

The cross-check confirms that every dollar extracted from NetSuite arrived in Adaptive. No rows were dropped, no transforms introduced rounding drift, and no data was lost in transit.

What Happens on FAIL

When the variance exceeds tolerance, VersionForge takes immediate action:

The sync run is flagged with a red verification status visible on the dashboard.
Notifications fire to the configured alert channels (email, Slack, or webhook) with the variance amount and affected dimensions.
Subsequent scheduled syncs pause for that profile until the discrepancy is reviewed and resolved.

A FAIL result does not roll back the load -- the data is already in the target. The flag ensures your team investigates before the next cycle runs and before downstream consumers trust the numbers.

Configuring Tolerance

Tolerance is set per connector and per version in your sync profile settings:

verification:
  crossCheck:
    enabled: true
    tolerance: 1.00        # absolute dollar amount
    groupBy:
      - account
      - period
      - entity

You can configure different tolerances for different sync profiles. A high-volume revenue sync from Stripe might use a $5.00 tolerance to account for in-flight transactions, while a headcount sync from Workday might use $0.00 because the numbers must be exact.

Tolerance is applied per group, not as a grand total. If you group by account and period, each account-period combination must independently pass the tolerance check.

Audit Trail

Every cross-check result is persisted and queryable:

Run ID, timestamp, and operator who triggered the sync
Source and target totals for each dimension group
Variance per group with PASS/FAIL status
Tolerance that was in effect at the time of the check