You're six weeks into your new platform and your accountant asks: where did the custom invoice field go? Why do multi-currency transactions show different totals? Why is the audit trail broken for Q3? A QuickBooks Online migration that looks clean on the surface often orphans critical data mid-handoff. Not because the migration tool is broken, but because QBO's data model and your destination platform's schema don't align—and nobody documented the gaps before you switched. This is the map that should have existed before you clicked migrate. What transfers clean (and you can trust) These core ledger elements move without corruption: Chart of accounts. Account names, numbers, and type (asset, liability, equity, revenue, expense) port reliably. Account balances reconcile. No surprises here. Historical transactions (invoices, bills, payments). Line-item amounts, dates, tax codes, and payee mappings transfer. The ledger footprint stays intact. This is the one thing QBO exports cleanly. Customer and vendor names. Master data ports without corruption. Phone, email, address fields move if your destination platform has those fields. Bank and credit card transactions. Opening balances and matched transactions reconcile if your destination platform supports bank feeds. If it doesn't, you lose the match history and have to re-reconcile. Basic tax mappings. If your destination platform uses the same tax authority codes (US sales tax, VAT, GST), the mapping usually survives. If it doesn't, you're remapping 300+ transactions. The ledger itself is portable. The context around it is not. What orphans (and where to audit before migrating) Custom fields on transactions. QBO lets you add custom fields to invoices, bills, and expenses. Most export tools ignore them. You lose the data. If you use custom fields to track project codes, customer segments, or internal notes, they vanish. Workaround: export custom field data to a CSV before migration, then decide whether to re-import as notes or rebuild in the destination platform. Multi-currency rounding differences. QBO rounds at the transaction level. Most destination platforms round at the line item. A £100 invoice + 20% VAT in QBO nets to £120.00. In Xero, the rounding rule might shift to £120.01 depending on how line items are calculated. Your ledger drifts by pence. This is especially painful if you have monthly currency reconciliations. Test a sample of multi-currency invoices before you commit to the migration. Tax agency mappings for indirect taxes. QBO's tax setup for Malaysia (SST), Indonesia (e-Faktur), or Singapore (GST) doesn't port to Xero or Zoho without manual remapping. Tax codes exist in both systems, but the rules that govern when they apply—and how they print on compliance documents—differ. You migrate the transaction, but it may not validate in your tax authority's system. Recurring invoice schedules. QBO stores when invoices recur and what day they're due. Most migration tools dump the invoices but lose the schedule. You have to recreate recurring invoices in the new platform. This is tedious but not risky—you just stop automating billing until you rebuild the rules. Approval workflows and permission hierarchies. QBO's approval chains and role-based access don't export. You rebuild access from scratch. This is a governance reset, not a data loss, but it delays your team's ability to enforce controls on day one. Notes, attachments, and internal comments. QBO lets you attach PDFs and add notes to transactions. Some export tools preserve the text of those notes; most lose attachments. Your deal context evaporates. Mitigation: bulk-export notes to a CSV and ask your team to rebuild critical ones in the destination platform. The tax-year cliff: why mid-fiscal migration breaks your audit trail Here's the gotcha that costs accountants weeks of remediation. If you migrate mid-fiscal year—say, in August, partway through your tax year—your opening balance in the new platform is the sum of all QBO transactions through July. That opening balance is correct. But your audit trail is broken. In QBO, every transaction has a timestamp and a sequence. In the destination platform, you're importing a flat file. The transaction sequence is lost. If an auditor asks "walk me through the path of that revenue entry," you can show them the transaction in QBO up to the migration date, then the same transaction in the new platform after. But the linkage is severed. You've split your audit trail across two systems. The fix: migrate at a natural fiscal boundary (year-end, quarter-end). If you must migrate mid-year, document the cutover date explicitly in your accounting records. Record an opening balance journal entry in the destination platform that ties back to your last reconciliation in QBO. Keep QBO live for reference for at least one full tax year after migration. If your destination platform is an integrated accounting module (rather than a standalone accounting application), this r