Migrating your invoicing history to a new platform is not a weekend project. It's a 6–8 week commitment that touches tax records, cash reconciliation, and audit trails. If you pick the wrong tool, you don't just waste time—you orphan critical data, break year-to-date balances, and expose yourself to compliance gaps when LHDN, IRAS, or ATO comes calling. This checklist helps you stress-test a new invoicing platform before you move a single invoice. It covers the 12 operational, tax, and technical gates that most evaluation spreadsheets skip. Run it on a sandbox. Use real invoices. Then decide whether the platform is worth migrating into. 1. Tax ID validation and real-time compliance gates Your invoicing platform must validate tax IDs before you can post an invoice. If it doesn't, compliance happens after the fact—and after-the-fact compliance is a scramble. In Malaysia, this means MyInvois validation. In Indonesia, e-Faktur. In Singapore, GST registration checks. In Australia, ABN lookup. The platform should: Reject invoices with missing or malformed tax IDs in real time (not in a batch report three days later). Cross-check GST/SST registration against the issuing authority's database (not just a format check). Lock tax ID fields once an invoice is posted (so you can't retroactively change it). Store a timestamp of when validation passed (for audit trails). Test this: Create an invoice with an invalid NPWP or ABN. The platform should refuse to post it. If it lets you save it as a draft and only flags it during export, you've found your first red flag. 2. Multicurrency without hidden conversion rules If you invoice in USD, SGD, MYR, and IDR, your invoicing platform must handle each currency independently. What most platforms hide is the conversion rate lock. When you issue an invoice in USD, the platform must: Capture the exchange rate at the time of invoice (not at payment or posting). Lock that rate so it doesn't change if rates fluctuate before the customer pays. Record the rate in the invoice PDF and in the export (not buried in metadata). Report foreign exchange gains or losses separately from invoice revenue. Test this: Issue a USD invoice on 1 January, receive payment on 15 January after rates move. Your platform should report the FX gain/loss as a separate line item when you reconcile—not bake it into the revenue number. 3. Recurring invoice rules that don't orphan dates Most platforms handle simple monthly subscriptions. They break on retainers that need to invoice on specific dates (e.g., the 1st, or 30 days after last payment) or on multiple schedules for the same client. Your platform must support: Recurring rules anchored to a fixed date (1st of month), an event (payment received), or an interval (every 30 days). Multiple recurring schedules per client (e.g., product subscription on the 1st, retainer on the 15th). Skipping holidays or weekends without breaking future invoice dates. Stopping a recurring schedule without retroactively deleting past invoices. Test this: Set up two recurring invoices for the same client—one on the 1st, one on the 15th. Skip the July 15th invoice. Does the next one invoice on August 15th, or did the entire schedule collapse? 4. Payment method tracking that doesn't lose data in the export You need to track how much revenue came in via bank transfer, PayPal, Stripe, or cash. Your invoicing platform must record the payment method on every transaction—and most importantly, that method must survive the export to your accounting system. Check for: A dedicated payment method field on every invoice (not a hidden tag). Automatic payment method capture if you're using a payment processor (Stripe, PayPal, Razorpay). Ability to reconcile payment method against your bank or payment processor statements. Export that includes payment method in the CSV, XML, or API response (not just in the web UI). Test this: Record a payment via Stripe. Export your invoices to CSV or to your accounting platform. Can you see which invoices came in through Stripe versus bank transfer? If the export shows only the amount and date, the platform is stripping context. 5. Custom fields that don't break on export or sync You may need custom fields—project codes, cost centers, internal references—that don't exist in the platform's standard schema. Most platforms let you add them, but few platforms export them cleanly. Verify: Custom fields are stored in the same record as standard fields (not in a side table that disconnects during export). You can make a custom field required (so invoices don't go out without it). The custom field appears in the invoice PDF, the export, and the API response. The platform doesn't charge extra per custom field (some do). Test this: Create a custom field for project code. Issue an invoice, fill in the project code, and export to CSV. Is the project code in the CSV? Now try syncing to your accounting system. Does the project code sync through, or does the platform's integratio