Every migration produces discrepancies. The difference is whether you get to see them.
A migration report only means something if it's allowed to say something didn't land. This page shows the report Nummio produces when QuickBooks history moves over — what a discrepancy looks like, what causes one, and how each gets resolved. Including the part where the number isn't zero.
What the report actually checks
For every account with activity in your QuickBooks file, one row with three figures: what the file's own transactions sum to for that account, what actually posted in Nummio, and the difference. Every such account gets a row — the ones that match to the penny and the ones that don't. Above the rows, a count of transactions posted — and, if anything was skipped, a count of that too, never a silence.
Both figures in a row come from the same source — your file. The left number is what your QuickBooks export says the account's activity totals; the right is what the posting engine actually recorded against its Nummio target. So this report isn't a second opinion on your books. It's a completeness check on the move itself: everything the file contains either posted, or shows up here as a difference with a reason.
Where a discrepancy comes from
There are two real causes, and both are properties of the file, not accidents of the import:
The common pattern elsewhere is to make these disappear: a plug entry to an equity account to soak up whatever didn't balance, or activity that simply doesn't come across, with nothing telling you it's gone. The books look clean on day one and disagree with the old system in ways nobody can trace by the time anyone notices. Nummio's report does the opposite job — it exists to put the difference in front of you while it's still explainable.
A real one, traced
This is what the real pipeline computes for the "messy books" sample from the migration demo — a small file with three transactions, one of them a journal entry reserving a deposit against a pending estimate — while Estimates still has nowhere to post. In the demo you watch this table land live; in the product itself, the same gap surfaces before commit as a flagged account and a refused commit, so the report you read after a real migration shows every row already reconciled:
| QuickBooks account | Nummio account | QuickBooks total | Posted total | Discrepancy |
|---|---|---|---|---|
| Checking | Checking | −$1,200.00 | −$1,200.00 | — |
| Estimates | Not mapped (no Nummio equivalent) | $500.00 | $0.00 | $500.00 |
| Fixed Assets:Vehicles | Vehicles (new) | $1,200.00 | $1,200.00 | — |
| Sales Income | Sales Income | −$500.00 | −$500.00 | — |
The $500.00 sits against Estimates, a non-posting QuickBooks account type with real activity recorded against it. The file says $500.00 of activity; nothing has anywhere to post; the report shows exactly that difference rather than plugging it. Every other account in the same file reconciles to the penny — the discrepancy is precise, not a general fog over the migration.
How a discrepancy resolves
A discrepancy is resolved by giving the money a real destination, never by a workaround — and the migration refuses to commit until that's done:
Ask every vendor this question
If you're evaluating migration tools, ask each one to run its reconciliation report on your messiest client file and show you the result, account by account. A vendor whose report can't show a non-zero number isn't running a cleaner migration — it's running a quieter one.
Nummio's answer is above, non-zero number included. You can reproduce it yourself in the migration demo — pick the messy sample, watch the discrepancy land, remap the account, and watch it resolve to zero. It runs entirely in your browser: no upload, no account, under twenty seconds.
Want this run against your real file?
Send it over and we'll walk the report together, row by row — the non-zero ones especially.