Back to blog
Data Migration

Reconciling the Trial Balance After a Finance Migration

24 September 2026
Reconciling the Trial Balance After a Finance Migration

If the trial balance does not reconcile after a finance migration, nothing else you say about go-live quality matters much. Controllers know this. Auditors know this. Programmes that treat trial balance proof as a final courtesy, after the weekend, after the speeches, discover it the hard way at first close.

Trial balance reconciliation migration is the control spine of finance data movement. It is how you prove that mapped openings in the target represent the source financial position at the cut date, and that differences are explained, approved, and owned. This article shows a practical mid-market method. For broader finance scope (COA design, subledgers, period control), see finance system data migration. For the general reconciliation stack, see full-population reconciliation.

What “TB reconciled” must mean

A defensible definition:

At cut date T, for the in-scope entity set, the source trial balance, after applying the approved COA/dimension mapping, matches the target opening trial balance within agreed tolerances (default zero at account/control level unless a documented exception exists), and every difference is classified as a mapping rule effect, an accepted exclusion, or a blocking defect.

It is not:

  • “Total assets look similar”
  • “We checked a few major accounts”
  • “The system generated openings”
  • “Differences are timing; we’ll fix in the first close” (unless that path is explicitly designed and controlled)

Prerequisites (do not skip)

Before a meaningful TB reconcile, you need:

  1. Frozen cut date/time and entity scope
  2. Approved, versioned COA/dimension mapping register
  3. Source TB extract integrity (postings cut off, extract reproducible)
  4. Clear treatment of P&L vs balance sheet at cut (YTD close/roll policies)
  5. Known source issues documented (accounts that already do not make sense)
  6. Target opening load design (how openings are posted/imported)

If mapping is still fluid, you are not reconciling. You are negotiating.

Also reconcile source subledgers to source controls before migration. Migrating an unexplained source break simply relocates the argument.

The TB reconciliation stack

Work in layers. Stop calling the TB “green” until all applicable layers pass.

Layer 1, Extract control

Prove you are reconciling the right source numbers.

  • Extract timestamp and period status recorded
  • Entity/company filter confirmed
  • TB type defined (adjusted, unadjusted, management, statutory)
  • Hash/total control: total debits = total credits in source extract
  • Re-extract produces the same result (reproducibility)

Layer 2, Mapping completeness

  • Every source account with a non-zero balance or required open residual has a map
  • Every map points to a valid target account/dimension combination
  • Blocked/deprecated target accounts are not receiving openings accidentally
  • Mapping version ID stamped on the reconcile pack

Unmapped non-zero accounts are blocking by default.

Layer 3, Mapped source TB (simulations)

Apply mapping to the source extract to create a mapped source trial balance in target-shaped accounts.

This is the intellectual centre of the method. You should be able to show:

  • Source account → target account/dimensions → mapped amount
  • Many-to-one collapses summed correctly
  • Sign/normal balance treatments handled explicitly

If you only compare unmapped source TB to target, every COA redesign looks like a migration defect.

Layer 4, Target opening TB

  • Target openings generated from the approved load only (no silent manual journals unless listed)
  • Opening entry references/migration batch IDs retained
  • Target TB extracted with the same entity and dimension granularity as the mapped source

Layer 5, Account-level comparison

Compare mapped source vs target openings:

CheckPass rule (typical)
Per account/dimension balanceExact match (zero tolerance) unless approved
Total debits / total creditsExact match
Balance sheet net assetsExact match to source policy
P&L treatment at cutMatches agreed roll/close design

Produce variance lists sorted by absolute value. Materiality thresholds can guide review order; they do not automatically approve variances.

Layer 6, Dimension integrity

If cost centres, projects, tracking categories, or locations are in the COA model:

  • Dimension combinations valid in target
  • No unintended dumping into a default cost centre without report
  • Subtotals by dimension hierarchy reviewed for management-pack sanity

Layer 7, Subledger bridge

TB proof is incomplete if subledgers that feed controls are wrong.

  • AR subledger total = AR control
  • AP subledger total = AP control
  • Other material subledgers (stock control, fixed assets) tied
  • Open-item identity samples explain the control residual

A clean TB with untied subledgers is a temporary illusion.

Layer 8, Narrative and sign-off

  • Variance narrative for every non-zero difference
  • Classification: mapping effect / accepted exclusion / defect
  • Controller (or CFO delegate) signature on the pack
  • Pack archived with mapping version and extract IDs

Handling legitimate differences without hand-waving

Legitimate differences exist. They need rules.

Difference typeExampleTreatment
Approved many-to-one map3 source expense accounts → 1 targetExpect mapped match, not source-line match
Policy change at go-liveNew netting approachSeparate conversion journal, documented
Out-of-scope accountLocal statutory-only account excludedAccepted exclusion with residual plan
Rounding in currency conversionMinor FX residualPre-agreed tolerance + write-off path
Source error discovered lateHistorical mispostFix in source before cut or documented opening adjustment

Conversion journals should be visible, approved, and reconciling items, not buried inside opaque load logic.

Multi-entity and consolidation notes

For multi-entity cuts:

  • Reconcile per entity before consolidation views
  • Prove intercompany pair symmetry where both sides are in scope
  • Separate local statutory COA maps from group reporting maps if both exist
  • Do not declare group green while one entity remains amber

Consolidation layers can hide entity-level disasters behind a net number. Do not let them.

Multi-currency notes

Define which TB you are reconciling:

  • Transaction currency views
  • Functional currency TB
  • Reporting currency TB

State rate sources and whether openings are migrated pre-translated or translated in load. Mixed approaches without documentation create irreproducible packs. Agree FX residual policy before dress rehearsals.

Operating cadence: when to run TB packs

PhaseTB activity
Mapping designSimulate mapped TB on recent source extracts
Early test loadsStand up automated comparison pack
Dress rehearsalsFull cut-date simulation; burn down variances
CutoverFinal extract → load → immediate TB pack
First closeBridge pack old vs new reporting; residual watch

If the first real TB pack is on cutover night, you scheduled a control failure.

Automate as much as possible. Manual Excel heroics do not scale to exhausted cutover teams and are hard to audit later.

What the sign-off pack should contain

  1. Entity scope and cut timestamp
  2. Mapping version identifier
  3. Source extract controls
  4. Mapped source TB
  5. Target opening TB
  6. Variance list with classifications and owners
  7. Subledger bridge summaries
  8. List of conversion journals
  9. Open defects and accepted exclusions
  10. Controller sign-off and date
  11. Link to detailed open-item packs where material

This pack is a core delivery artefact for migration services, not optional PMO wallpaper.

Failure patterns that create false greens

PatternWhy it is dangerous
Totals-only comparisonAccount-level errors cancel out
Unmapped source vs targetCOA redesign looks like load failure
Post-load manual “fix journals” undocumentedAudit trail breaks; next month worse
Ignoring dimensionsCost centre reporting fails later
TB green, subledger redCollections/payments chaos
Tolerance used as a blanketMaterial local misstatements hidden

How this ties to readiness and methodology

A Data Migration Readiness Assessment should tell you whether source TBs and subledgers currently tie, how complex COA mapping will be, and whether period/cut design is coherent, before you price delivery.

In methodology terms, TB reconciliation is the finance expression of stage-four proof in our migration methodology. It is also one of the main reasons post-go-live failures show up at month-end rather than cutover.

The trial balance is the truth test

Trial balance reconciliation after a finance migration is not a technical formality. It is the moment the organisation decides whether the new system holds the financial truth. Do it with mapped simulations, account-level comparison, subledger bridges, and signed exception handling. Do it every rehearsal. Do it again on the final extract.

If your go-live criteria do not include a controller-signed TB pack, add them before you add more software features.

Next step: Read the finance migration guide, book a readiness assessment, or talk to Cyber Samurai about controlled finance migration delivery.


Questions

Frequently asked

  • The controlled comparison of source financial positions to target openings after applying approved account mapping, ensuring differences are explained and accepted before sign-off.

Keep reading

Recommended articles