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.

Create your account

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 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.

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 it through