Three invoicing tools look like redundancy. Pick one, move everything, save money. Then the migration happens. Your invoices come across. Your customers sort of come across. Then your accountant asks why there's no payment history since the migration, why the tax codes don't match your audit trail, and why your aging report shows invoices that were already paid. Not every field moves clean. Not every system lets it. The difference between a smooth migration and a three-week rebuild is knowing what orphans before you sign the contract. What actually transfers: the safe layer Start with what moves predictably across nearly every invoicing platform: Invoice headers and line items. Invoice number, date, amount, description, quantity, unit price. These are the core. They export and import across CSV or API with minimal friction. Customer master data. Name, email, address, tax ID. If your new platform has a customer table, this layer usually maps without loss. Basic tax codes. Standard VAT, GST, SST rates. If both systems support the same tax regime (e.g., GST in Australia), the rates themselves transfer. The application to invoices is another story. Invoice status flags. Draft, sent, paid, overdue. Most platforms use similar states and can import these as metadata. These four layers are your baseline. They almost always transfer without data loss. The real migration risk sits in everything else. What orphans most often: the hard layer Plan on rebuilding or losing these: Payment history and reconciliation tags. Which payment method, when it landed, which bank account, partial payments, write-offs. Most invoicing platforms store payment records separately from the invoice ledger. When you export invoices, you export the invoice. The payment log stays behind. Your new platform will see "paid" status but won't know how it was paid or have the audit trail your accountant needs. Aging reports and customer credit. "This customer paid 45 days late for six months, then switched to on-time." That behavioral history doesn't live in the invoice itself—it lives in your platform's reporting engine. You won't export it because it doesn't exist as data, only as computed metrics. Your new platform starts fresh with no aging context. Custom fields and line-item attributes. If you've added "project code," "internal order number," or "cost center" to invoices, check whether your new platform has equivalent custom fields before you migrate. Many platforms support custom fields but with different naming, validation rules, or export restrictions. A field that's required in your old system might be optional (or unsupported) in the new one. Invoice templates and styling. Layout, branding, conditional fields, footer logic. Templates are usually platform-specific. A PDF template that works in FreshBooks doesn't port to Xero. You'll rebuild branding from scratch or accept the new platform's defaults. Recurring invoice rules and schedules. If you have invoices set to auto-generate monthly with specific logic (e.g., "invoice on the 1st, net 30, apply discount if paid by the 15th"), that logic is often hardcoded in your old platform's database and doesn't export. You'll recreate the schedule in the new tool, but you'll lose the historical view of which invoices were auto-generated vs. manual. Approval workflows and audit trails. Which user approved an invoice, when, from which device, with what comment. These metadata fields are rarely standardized across platforms. If compliance or internal process requires an audit trail, you'll need to document the cutover date and note that pre-migration invoices have limited audit history in the new system. Dunning sequences and late-payment communications. If your old platform automated reminder emails for overdue invoices, that sequence is not an export. You'll set it up fresh in the new platform, but you'll lose the record of which reminders were sent to which customer for which invoice pre-migration. The pattern: anything that's a process or behavior (payment reconciliation, aging trends, approval workflows) orphans. Anything that's structured data (invoice number, amount, customer name) usually moves. The tax compliance test: run it before migration If you're in Malaysia, Singapore, or Indonesia, tax validation is not optional. Before you migrate, export 20 invoices from your old system and run them through your new platform's tax validation: Export a sample invoice from the old system. Pick one that has multiple tax codes, one with a reverse charge, and one with a discount. Include the tax ID, rates applied, and amounts. Check how the new platform reads tax codes. If your old system labels it "Tax Code: SR" and the new one expects "GST: Standard Rate," the mapping isn't automatic. You'll need a translation table. Test the import path. Use the platform's CSV import template (not a manual re-entry). Does the tax code column import correctly? Does the system recalculate tax, or does it trust your impo