You sell SaaS to customers across Malaysia, Singapore, and Indonesia. One customer signs a ₹1,200/month recurring contract. But they have subsidiary entities in all three countries, and they want one invoice split three ways: the revenue, the tax, the GL codes—everything prorated by usage or entity location. Your invoicing platform either handles this natively or you're in spreadsheet hell for the next three years. The problem isn't rare. It's catastrophic and silent. The invoice calculates fine. It posts to GL. Then tax season arrives and your accountant finds that SST liability, GST input credit, and PPn expense bases don't reconcile to your GL. You've been manually adjusting journal entries for 18 months. The audit trail is gone. This playbook walks you through the exact math, shows which platforms handle it, and gives you a step-by-step setup for platforms that don't. The Math: One Invoice, Three Tax Codes Let's work with a real scenario: Customer: Pan-Asia logistics company with entities in KL, SG, Jakarta Contract: ₹1,200/month (₹400 per entity) Billing model: Equal split across three subsidiaries Tax rates: Malaysia SST 6%, Singapore GST 8%, Indonesia PPn 10% On the surface, it looks simple: invoice ₹1,200, split three ways, calculate tax for each leg. But there are three landmines. Landmine 1: Which entity receives the tax-inclusive or tax-exclusive amount? In Malaysia and Indonesia, invoices are typically tax-exclusive (the SST/PPn sits on top). Singapore invoices can be either, but GST is also exclusive. So: Malaysia leg: ₹400 + SST (₹24) = ₹424 Singapore leg: ₹400 + GST (₹32) = ₹432 Indonesia leg: ₹400 + PPn (₹40) = ₹440 Total invoice amount: ₹1,296 (not ₹1,200). But here's where most platforms fail: they calculate the invoice subtotal first, then apply a single tax rate. You're invoicing ₹1,200. Apply "standard tax" at 6% and you get ₹1,272. That's wrong for all three countries. The GL will not balance to the invoice line items. Landmine 2: GL account splits by tax jurisdiction Your GL structure likely looks like this: 4100 – Revenue (Malaysia) 4200 – Revenue (Singapore) 4300 – Revenue (Indonesia) 2100 – SST Payable 2200 – GST Payable 2300 – PPn Payable When you post the invoice, the GL entry must be: Debit Accounts Receivable ₹1,296 Credit Revenue (Malaysia) ₹400 | Credit SST Payable ₹24 Credit Revenue (Singapore) ₹400 | Credit GST Payable ₹32 Credit Revenue (Indonesia) ₹400 | Credit PPn Payable ₹40 If your platform posts all revenue to a single 4100 account and all tax to a single 2100 account, your reconciliation is broken before the invoice goes out. Tax authorities will reject it. Landmine 3: Proration and partial month refunds The contract runs month-to-month. Customer cancels mid-month. Do you refund ₹600 (half revenue) or ₹598 (half revenue minus half the tax)? The tax code matters. Most platforms prorate the revenue cleanly but fail to prorate the tax liability. You issue a ₹600 credit note but only ₹588 of it actually reverses the tax liability. The GL entry doesn't balance. Now your tax GL account is overstated. Platform Audit: Which Tools Handle This Natively? I tested five invoicing platforms against this exact scenario. Here's what holds up. Orin Billing Orin's billing engine lets you define tax rules by geography and set per-jurisdiction GL codes at invoice creation. When you create a recurring invoice: Define three "tax regions" (Malaysia, Singapore, Indonesia) Link each region to its own GL revenue and tax payable accounts The system automatically proration tax when usage or subscription end dates change GL entry is split across the correct accounts; the journal balances Credit notes reverse tax liability correctly Full Orin billing documentation covers the setup. The native AI assistant can walk you through mapping your GL codes per region on first use. Xero Xero allows multiple tax rates on a single invoice via line items, but requires you to split the invoice into three separate line items manually (one per country). It does not prorate tax on partial-month refunds—you have to adjust the credit note by hand. GL posting works correctly once you've split the line items, but the manual step introduces human error at scale. QuickBooks Online QBO supports multiple tax rates via line items but does not natively link line items to different GL accounts. You can assign each line to a different account, but tax liability defaults to a single account. Proration is manual. Not recommended for multi-jurisdiction recurring revenue. Wave Wave does not support multiple tax rates on a single invoice. You must create three separate invoices. This breaks your billing cycle logic and creates reconciliation nightmares when customers pay one invoice but not the others. FreshBooks FreshBooks allows multiple tax rates via line items and GL code assignment per line. However, tax proration on refunds is not automatic—you must manually calculate and adjust. For a small team managing 10–20 multi-jurisd