Move your QuickBooks file over. Most of it maps itself.

Upload the export and most accounts map automatically — you're mainly reviewing suggestions, not building a mapping from scratch. Then two reports prove the move before you rely on it: a completeness report that accounts for everything the file contained, and a reconciliation report that checks every number against your old file. Migration is free on every plan, including the trial. What follows is the actual procedure: what comes across, what doesn't, and what it takes on your end. Not a pitch — a walkthrough.

Try the migration demo Talk to us first

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 refuses to commit while that activity has nowhere to post — 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 completeness report

Before anything commits, one row per kind of thing the file contained — accounts, customers, vendors, transactions, and the constructs the importer doesn't carry yet, like memorized transactions or budgets — with what was found, what migrated, the mapping applied, and a stated reason for anything that didn't make it. Nothing found in the file is left off this report. Here it is, computed by the real importer on the same "messy books" sample the migration demo uses:

1 row needs a decision

In the file	Found	Migrated	What happened to it
Accounts	7	6	3 mapped to an existing account, 3 created as a new account; "Estimates" has no destination mapping
Transactions	3	3	3 posted through the ledger

That one gap is the point of the report: seven accounts found, six migrated, and the seventh named with its reason rather than folded into a rounder number.

The confidence gate

A migration is never marked complete with an unexplained gap. Two rules do the work. First, commit is refused while any account with activity still has no destination — the dry run lists them, and the button does nothing until the list is empty. Second, the completeness report above is frozen on the migration record at commit, so the reasons for anything that didn't migrate travel with the books instead of living in someone's memory. What comes out the other side is either fully accounted for, or still waiting on a decision. There is no third state.

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's activity still has nowhere to post. 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:

Discrepancy found

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: give that $500 a real destination — a deposit reserve or a liability, most commonly. The migration demo lets you make exactly that remap and watch the discrepancy resolve to zero; on a real migration today, that reclassification happens in QuickBooks before you re-export, since the mapping screen flags a non-posting account rather than offering to remap it in place. Either way, nothing commits until the gap is gone, and the reconciliation report you actually get shows everything already balanced. There's a full page on the reconciliation report — what it checks, where discrepancies come from, and how each one resolves.

What you actually do

1Export your company file to IIF.

Ask your bookkeeper or IT contact for an IIF export of your company file, including transaction history — the exact steps vary by QuickBooks Desktop version. A CSV of transaction history works as a fallback.

2Upload it and review the account mapping.

Nummio reads your accounts and proposes a match against your Nummio chart — confirm or change each one. A non-posting account with real activity, like Estimates, is flagged instead, and nothing commits while its activity has nowhere to post.

3Check the dry run.

A trial balance built from the proposed mapping, before anything commits, so the shape of the result — and any account still needing a decision — is visible first.

4Commit once every account is mapped, then read the reconciliation report.

Commit is refused while any account, non-posting types included, is still unmapped. Once it commits, history posts through the same posting engine every other transaction uses, and the reconciliation report lists every account — with nothing unmapped or unbalanced ever allowed through, it comes back showing everything reconciled.

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 account's activity has somewhere to post.
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.

What it costs

Nothing. Migration is free on every plan, portfolio batch migration included, and it works during the trial — you can move a real file in and read both reports before you've paid for anything. The wedge is never a paid add-on. What running the books costs after the move, against staying, is on the calculator.

Have a messy file? That's the normal case.

Send it over and we'll walk through the mapping and the reconciliation report together.

Talk to us