Platform · trust

The document that makes a migration defensible

Ask any vendor how you will know a migration was complete and correct. The good answer is a per-period, per-account variance report that ties the loaded balances to the source system and that you keep. Most projects produce a sign-off email instead, which proves somebody was satisfied rather than that the numbers agree.

Their QuickBooksas filed
1000 · Cash412,880.14
1200 · Accounts receivable286,401.00
2010 · Accounts payable(94,220.55)
4000 · Revenue(1,842,110.00)
6000 · Operating expense1,237,049.41
Trial balance0.00
erp.io shadow ledgercomputed
1000 · Cash412,880.14
1200 · Accounts receivable286,401.00
2010 · Accounts payable(94,220.55)
4000 · Revenue(1,842,110.00)
6000 · Operating expense1,237,049.41
Trial balance0.00

184 consecutive days tied · variance $0.00

Per period, per accountVariance resolved to transactionYours to keep

What it does

Six things, specifically.

Trial balance agreement

Total debits and credits agree with the source, and net to zero, for every period in scope. This is the top-level check and the least interesting one.

Account-level agreement

Every account balance matched period by period, so a difference is located rather than known to exist somewhere in the aggregate.

Subledger to control

AR and AP detail ties to its control account on both sides. An aggregate that agrees while the detail does not is the failure mode this catches.

Variance to the transaction

Any difference resolves to the specific source transaction causing it, with a reason — unmapped account, timing difference, classification disagreement, or genuine error.

Every period, not a sample

Each period in the migration scope, not a spot check on the most recent one. A conversion that ties in December and not in March is not converted.

Exportable and retained

Yours in an open format, retained independently of us. It is the document you hand an auditor who asks how you know the conversion was complete.

Variances early are the process working

The first runs of a reconciliation proof almost always show differences, and customers occasionally read that as a bad sign. It is the opposite. Timing differences, unmapped accounts, and classification disagreements are exactly what a migration has to surface, and finding them in week one costs a fortnight of adjustment.

The same differences discovered at a cutover weekend cost the cutover. Every one of them exists whether or not anybody looks; the only variable is when.

A migration whose first reconciliation is clean has usually not reconciled properly. The differences are there either way.

Why it gates rather than reports

A reconciliation that produces a report somebody reviews under deadline pressure is a formality. Ours gates: the migration does not advance past a period that does not agree, and a variance sends the work back to mapping rather than being waived.

That is enforced on our side as much as yours — we will not sell a ledger cutover until three consecutive closed months have tied at zero variance. It applies to our revenue, which is the only version of a gate that means anything.

What it is not

It is not an audit and it is not an opinion on whether your source data was right. If your QuickBooks file contains an error, a correct migration reproduces that error faithfully and the proof will show agreement. Agreement means the conversion was faithful, not that the underlying books were correct.

Where we notice something that looks wrong in the source — an accumulated depreciation balance that does not tie to the register, a suspense account with years of activity — we raise it separately as a finding rather than folding it into the migration.

For customers who came through Connect

If a shadow ledger has been running against your books for months, the proof already exists as a historical record rather than being produced for the cutover. That is the strongest version of this: months of daily agreement rather than a reconciliation performed once, under pressure, by the party being paid for the conversion.

Limits

Where this does not help.

It does not validate your source data

Faithful conversion of an incorrect balance produces agreement. The proof shows the migration was accurate, not that the original books were right.

Not an auditor’s opinion

It is evidence your auditor can use and not a substitute for their procedures. We produce the artefact; they form the view.

Full history is a different scope

Standard scope is opening balances plus one to two years. Where you migrate more, the proof covers what was migrated and we state the boundary explicitly.

Questions

What people ask.

What if the first reconciliation does not tie?
It usually does not, and that is the process working. Timing differences and unmapped accounts surface in week one and cost a fortnight; the same differences at cutover cost the cutover.
Do we keep the proof?
Yes, in an open format, retained independently of us. It is what you hand an auditor who asks how you know the conversion was complete.
Does it prove our books were correct?
No. It proves the conversion was faithful. If the source contained an error, a correct migration reproduces it and the proof will show agreement — we raise source issues separately as findings.
How many periods does it cover?
Every period in the migration scope, not a sample. A conversion that ties in one month and not another is not converted.
Can we see one before committing?
Yes — request an anonymised sample from a live conversion. We would rather you evaluate the artefact than take our description of it.

Ask any vendor for this document.

A per-period, per-account variance report you keep. We will send an anonymised sample so you know what to ask for.