Your accountant has stopped complaining about your invoicing software. That's not a good sign. It usually means they've given up and built a shadow workflow—manual journals, spreadsheet corrections, month-end friction that costs 4–6 hours they'll never bill you for. By then, the damage is architectural. The problem isn't that your invoicing tool is broken. It's that it wasn't built for the handoff between you and your accountant. Most platforms optimize for speed and UX on the front end, then dump a chaotic data shape into the back office. Tax codes drift. Payment matching breaks. Multi-currency rounding compounds. NPWP or SST validation never happens until the invoice is already out. Then reconciliation turns into detective work. Here's what actually causes that friction, which platforms stumble hardest, and how to audit your setup before it metastasizes into a permanent reconciliation tax. Tax code drift: the silent killer A tax code assignment that works in your invoicing platform doesn't always translate cleanly into your accounting software. You set 18% GST on a service line item in your invoicing tool. It syncs to Xero as "GST on services." Your accountant recodes it to "GST on professional fees" because that's how your tax return is structured. Next month, you override the coding to match last month. Your accountant flags it. The month after, it reverts. Nobody wins. This happens because invoicing platforms and accounting software use different tax code hierarchies. An invoice tool might have three GST buckets; your accounting software has seven. The sync works one way at reconciliation. The second you manually adjust a tax code in your accounting software, the link breaks. Next sync overwrites your correction. The fix: Before you sync anything, map your tax codes end-to-end. Write down every tax rate and code you use in invoicing. Now open your accounting software and list its tax structure. Where do they not match? Ask your accountant which codes matter for your tax return. Then configure your invoicing platform to match those—not the other way around. If your invoicing tool doesn't support custom tax code mapping, you've already chosen wrong. Most accountants will not tell you about tax code drift until it's cost them 20 hours of manual rework. By then, they're too frustrated to explain it clearly, so you don't know what to fix. Payment matching breaks when your customers pay differently You invoice in GBP but accept payments in USD. A customer pays £1,000 via Stripe on a Thursday. Friday morning, the exchange rate has moved 0.8%. Your invoicing platform records a £1,000 received; Stripe shows £998 landed due to conversion. Your accountant reconciles bank deposits to invoices. The £2 gap is not a rounding error. It's a currency variance that now lives in a suspense account until someone manually matches it. This multiplies when you use multiple payment processors. Stripe to GBP bank account, Wise for international transfers, direct bank deposits from corporate clients. Each processor records currency conversion differently. Some round at the transaction level. Others aggregate and round. Some don't reconcile automatically at all. Xero and QuickBooks handle multi-currency invoicing reasonably well—they'll flag exchange variance. Wave doesn't handle multi-currency at all; every transaction syncs at your home currency, and the math is your problem. Zoho Books can match payments to invoices but requires manual variance approval, which adds a reconciliation step your accountant has to touch every month. The fix: If you invoice in multiple currencies, test payment matching in your accounting software with real transactions before you commit. Create a fake invoice in GBP, pay it via Stripe to a USD account, and watch what happens in your ledger. Can your system handle the variance? Will it match automatically or dump it in suspense? If your accountant has to manually approve variance every month, the time cost will kill you at scale. NPWP and SST validation: caught too late You invoice a customer in Malaysia. You didn't validate their tax ID before the invoice went out. Three weeks later, your accountant flags it: the invoice is missing the valid SST registration number. In Malaysia, this is required for B2B invoices over a certain threshold. The invoice is now non-compliant. You have to reissue. Your customer is confused. The accounting entry has to reverse and repost. Most invoicing platforms have a tax ID field. Few have real-time validation. You type in a tax ID; the system doesn't check if it's actually valid or registered for the tax rate you assigned. It just stores the string. Come month-end, when your accountant reviews invoices for compliance, they find entries with missing, partial, or malformed tax IDs. The invoice still hit your ledger. Now there's a cleanup cost. This is especially painful in Southeast Asia, where tax ID formats vary by country and change periodically. Indonesia's NPWP form