Move your QuickBooks file over, then check the numbers before you trust them.
This is the actual procedure: what comes across, what doesn't, how account mapping catches the gaps before anything commits, and what it takes on your end. Not a pitch — a walkthrough.
What comes across
| From QuickBooks | What lands in Nummio |
|---|---|
| Chart of accounts | Every account, mapped to a matching account in your Nummio chart or created fresh if nothing matches. |
| Customers and vendors | Every name on your lists, active and inactive. |
| Transaction history | Checks, deposits, invoices, credit memos, bills, bill payments, customer payments, general journal entries, and credit card charges and credits — the full transaction file, not a recent window. |
| Inactive and hidden accounts | Included and marked inactive, not left out. |
The migration reads your company file's IIF export — the one QuickBooks format that carries the full chart of accounts, customer and vendor lists, and transaction history in one plain-text file. A generic CSV of transaction history works too, as a fallback.
What doesn't
| Doesn't come across | Why, and what happens instead |
|---|---|
| .QBO and .QBX files | QuickBooks' bank-download format (.QBO) carries only downloaded bank transactions, no chart of accounts or customer list. .QBX is an encrypted accountant's-copy format with no public spec. Only .IIF and CSV actually parse — a .QBO or .QBX upload surfaces as a parse issue, not silent data loss. |
| Non-posting accounts | QuickBooks' Estimates, Purchase Orders, and Sales Orders accounts are a non-posting type with no Nummio equivalent. If real activity is posted against one anyway, the account mapping step flags it and won't let the migration commit until you decide where that activity actually belongs — see the example below. |
| Journal entries that don't balance | A transaction whose lines don't sum to zero is excluded from posting and listed as a parse issue for you to review, not silently dropped or force-balanced. |
Full history once, then a 180-day feed going forward
The migration itself has no date limit — every transaction in your QuickBooks file posts, whether that's four months of history or twelve years. That's a one-time import, not an ongoing feed.
Once you connect a bank account for live reconciliation, that connection (through Stripe Financial Connections) only returns the trailing 180 days of transactions — a limit set by the bank data provider, not by Nummio. For anything older than that on a connected account, or for institutions that don't support a live connection, CSV statement upload stays available. Your migrated history and your live bank feed are two different mechanisms, and neither one gets clipped by the other.
The reconciliation report
Migrating history means moving money between two systems, so nothing posts on faith. Every QuickBooks account needs a mapping decision — matched to an existing Nummio account, created fresh, or flagged as non-posting — and the migration refuses to commit while any account is still undecided. Only once every account has a decision does history actually post, through the same posting engine every other transaction uses. The reconciliation report then compares what your QuickBooks file says an account's activity totals to what actually posted to its Nummio target — account by account, every account getting a row. Because nothing unmapped or unbalanced is ever allowed to reach commit, that report comes back clean: everything reconciled to the penny.
Here's what the mapping step catches before you ever get near commit — the same "messy books" sample used in the migration demo, a small file with three transactions, one of them a journal entry reserving a deposit against a pending estimate:
| 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 | — |
Estimates is a non-posting QuickBooks account type, so it has no Nummio equivalent — the $500 recorded against it in QuickBooks, shown in the discrepancy column above, has nowhere to post. This is what the mapping screen catches, before you're ever allowed to commit — not something that slips through to a post-commit report. The fix is a decision, not a bug fix: remap Estimates to a real account — a deposit reserve or a liability, most commonly — and that $500 posts there instead. Only once every account, Estimates included, has a resolved mapping does the migration commit, and the reconciliation report you actually get shows everything already balanced. You can run this exact example yourself, remap included, at the migration demo.
What you actually do
A realistic timeline
| Step | Typical timing |
|---|---|
| Export from QuickBooks | Minutes, once you know where the export lives in your version of QuickBooks. |
| Upload and review the account mapping | Same day if it's a name or two to remap; add a business day or two if your file has several non-posting accounts, like Estimates, or old sub-accounts to sort through. Most accounts map automatically, so you're mainly reviewing, not building a mapping from scratch — but commit stays blocked until every one has a decision. |
| Dry run | Minutes — no waiting, since nothing has posted yet. |
| Commit and read the reconciliation report | Same day for a small file, and only once every account is mapped. History posts through the ordinary posting engine, so size and transaction count drive the time, not anything special about migration. |
These are estimates based on how the migration itself works, not a guaranteed timeline. A large or heavily customized file takes longer mainly because there's more for a person to review, not because the import is slower.
Have a messy file? That's the normal case.
Send it over and we'll walk through the mapping and the reconciliation report together.