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:
- Frozen cut date/time and entity scope
- Approved, versioned COA/dimension mapping register
- Source TB extract integrity (postings cut off, extract reproducible)
- Clear treatment of P&L vs balance sheet at cut (YTD close/roll policies)
- Known source issues documented (accounts that already do not make sense)
- 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:
| Check | Pass rule (typical) |
|---|---|
| Per account/dimension balance | Exact match (zero tolerance) unless approved |
| Total debits / total credits | Exact match |
| Balance sheet net assets | Exact match to source policy |
| P&L treatment at cut | Matches 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 type | Example | Treatment |
|---|---|---|
| Approved many-to-one map | 3 source expense accounts → 1 target | Expect mapped match, not source-line match |
| Policy change at go-live | New netting approach | Separate conversion journal, documented |
| Out-of-scope account | Local statutory-only account excluded | Accepted exclusion with residual plan |
| Rounding in currency conversion | Minor FX residual | Pre-agreed tolerance + write-off path |
| Source error discovered late | Historical mispost | Fix 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
| Phase | TB activity |
|---|---|
| Mapping design | Simulate mapped TB on recent source extracts |
| Early test loads | Stand up automated comparison pack |
| Dress rehearsals | Full cut-date simulation; burn down variances |
| Cutover | Final extract → load → immediate TB pack |
| First close | Bridge 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
- Entity scope and cut timestamp
- Mapping version identifier
- Source extract controls
- Mapped source TB
- Target opening TB
- Variance list with classifications and owners
- Subledger bridge summaries
- List of conversion journals
- Open defects and accepted exclusions
- Controller sign-off and date
- 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
| Pattern | Why it is dangerous |
|---|---|
| Totals-only comparison | Account-level errors cancel out |
| Unmapped source vs target | COA redesign looks like load failure |
| Post-load manual “fix journals” undocumented | Audit trail breaks; next month worse |
| Ignoring dimensions | Cost centre reporting fails later |
| TB green, subledger red | Collections/payments chaos |
| Tolerance used as a blanket | Material 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


