Your subscriber in Kuala Lumpur renews in three weeks. She has always been billed in MYR with SST at 6%. Then she relocates to Singapore. Her renewal invoice is now due in SGD, and the tax jumps to 8% GST. Her renewal is for the same service, the same price in USD (your base currency), but everything about the tax calculation has changed. Most accounting software treats tax as a customer attribute, not a transaction one. The system records her as "Customer: XYZ, Tax Rate: 6%" and never re-evaluates. When her renewal invoice generates, it either uses the old rate (creating a compliance gap), or you have to manually override it and lose auditability. If you're scaling and handling dozens of these moves per month across Southeast Asia, spreadsheet fixes and manual overrides become your hidden cost. The core problem: fixed tax rate per customer Here's how most platforms handle taxation: Customer master record: One tax ID, one tax rate, one currency. Invoice generation: Pull the tax rate from the customer record; apply it to the line item. Regional moves: You update the customer record manually, but the old invoices stay in the system with the wrong rate. This design works for businesses whose customers rarely change jurisdictions. It breaks when you operate subscription billing across Malaysia, Singapore, and Indonesia—where relocation, visa expiry, and business registration changes are normal. A single customer record cannot hold the truth: their tax rate is valid only for a specific invoice date in a specific location. Build the scenario: five subscribers, three countries, three currencies Let's walk through a realistic month. You operate a SaaS platform billing in USD, but customers in three countries pay locally to avoid currency swings. All subscriptions renew on the first of the month. Monthly subscriber base: Customer A (Malaysia, MYR, SST 6%): Renews 1 Feb as planned. Customer B (Malaysia, MYR, SST 6%): Renews 1 Feb but relocated to Singapore 15 Jan. Must switch to SGD, GST 8%. Customer C (Singapore, SGD, GST 8%): Renews 1 Feb as planned. Customer D (Indonesia, IDR, PPN 11%): Renews 1 Feb as planned. Customer E (Singapore, SGD, GST 8%): Renews 1 Feb but her business just registered in Malaysia. Needs a second invoice line at SST 6% for the portion delivered there. Now you generate invoices. Here's where each platform fails: Wave: No tax handling at all for regional moves Wave doesn't support multi-currency invoicing natively. You'd have to create separate line items in each currency, which means separate invoices or a single invoice with mixed currencies and no tax logic. If you update the customer's home currency, old invoices don't recompute. Compliance audit? You'd explain invoice-by-invoice why the tax rate changed. QuickBooks Online: Tax assumes USD and one rate QuickBooks Online ties tax rates to the tax jurisdiction , which is tied to the customer address . When Customer B moves to Singapore, you update her address. The next invoice applies SGT 8%. But there's a lag: you must manually re-test the address→jurisdiction→tax-rate logic, and if you invoice before the system re-indexes, you get the old rate. For mixed-jurisdiction invoices (Customer E), you need separate line items and separate tax calculations per line—no single invoice can hold both without error-prone manual adjustment. Xero: Better, but currency conversion still breaks tax Xero supports multi-currency invoicing and ties tax codes to line items, not customers. This is closer to correct: you can apply SST 6% to one line and GST 8% to another on the same invoice. But Xero still assumes you know the tax rate at invoice time. If a customer moves after you generate a quote, you must re-enter or re-quote. And if the invoice is already issued, changing the tax rate retroactively requires a credit memo and new invoice—two transactions instead of one corrected one. The audit trail shows the mistake. Zoho: Flexible but requires custom fields and workflows Zoho allows custom fields on invoices and can apply different tax codes to different line items. However, there's no built-in trigger that watches for a customer's address change and re-evaluates tax on subsequent invoices. You'd have to build a Zoho flow or integrate via Zapier: watch for address change → trigger tax re-evaluation → regenerate pending invoices. This works, but it's a custom workflow, not a standard feature. If you mess up the logic, you'll apply the old tax rate and discover it in the audit. Why transaction-level tax tracking is the answer The fix is to decouple tax from the customer master and anchor it to the invoice itself, with these fields captured at invoice time: Invoice date: The tax rate is valid as of this date. Delivery location (or billing address at invoice time): Determines which tax jurisdiction applies. Currency: The local currency used for the invoice and tax calculation. Tax rate and tax code: Stored on the invoice line, not looked up from the customer. Ef