You issue one invoice to a regional client. Twenty percent of the work happened in Kuala Lumpur (Malaysia, 6% GST), fifty percent in Jakarta (Indonesia, 10% PPN), and thirty percent in Singapore (no GST). The invoice total is USD 10,000. Your accountant now has a problem: three GL codes, three tax rates, three currency conversion points, and rounding errors that cascade through close. Most invoicing platforms treat this as one line item and one GL post. They're wrong. The moment you cross a tax border on a single invoice, you need three separate GL postings, three separate tax calculations, and a proration rule that survives audit. This playbook shows the math, where software fails, and how to set it up in platforms that actually support it. Why one invoice across three countries breaks standard invoicing The problem looks simple in theory: allocate revenue by geography, apply the correct tax rate, post to GL. In practice, three hidden traps emerge. First: tax rates collide on one document. Malaysia charges 6% GST on services. Indonesia charges 10% PPN. Singapore charges 0% GST on cross-border services (but 8% GST on domestic ones—which this is not). A single invoice line that says "consulting services: USD 10,000" cannot carry three tax treatments. You have to split it. Second: forex rounding happens at each step. You invoice in USD. Malaysia's GL is in MYR, Indonesia's in IDR, Singapore's in SGD. Each currency pair has its own mid-market rate, and your bank settlement rate differs again. If you round at invoice time, GL post time, and settlement time, the differences accumulate. By close, you have 47 cents unreconciled across three GL accounts. Third: GL structure forces a choice between accuracy and auditability. Some teams flatten everything to one GL line and manually adjust. Others create three GL codes upfront but fail to tie them back to the invoice line item, so the audit trail breaks. Neither survives a tax audit. The proration formula: revenue, tax, and GL allocation Here's the formula that works. Start with the invoice total and revenue share: Invoice total: USD 10,000 Malaysia share: 20% = USD 2,000 Indonesia share: 50% = USD 5,000 Singapore share: 30% = USD 3,000 Now apply tax rates before currency conversion: Malaysia: USD 2,000 × 1.06 (GST inclusive) = USD 2,120 gross Indonesia: USD 5,000 × 1.10 (PPN inclusive) = USD 5,500 gross Singapore: USD 3,000 × 1.00 (no GST) = USD 3,000 gross Invoice subtotal (before tax): USD 10,000. Invoice tax: USD 620. Invoice total: USD 10,620. Now convert each segment to local currency at the spot rate you used when you issued the invoice . Do not use the bank settlement rate—use the rate on the invoice date. Malaysia MYR: USD 2,120 × 4.35 (USD/MYR on invoice date) = MYR 9,222 Indonesia IDR: USD 5,500 × 15,650 (USD/IDR on invoice date) = IDR 86,075,000 Singapore SGD: USD 3,000 × 1.35 (USD/SGD on invoice date) = SGD 4,050 Now calculate tax in each local currency by backing it out of the gross: Malaysia tax (GST): MYR 9,222 ÷ 1.06 = MYR 8,698.11 revenue. Tax = MYR 523.89 Indonesia tax (PPN): IDR 86,075,000 ÷ 1.10 = IDR 78,250,000 revenue. Tax = IDR 7,825,000 Singapore: SGD 4,050 revenue. Tax = SGD 0 Here is where platforms fail: they round the tax calculation before assigning GL codes. If they round MYR 523.89 to MYR 524, the revenue line becomes MYR 8,698, and your invoice total no longer ties to the GL sum. Your accountant spends two hours finding eight cents. The fix: assign GL codes to the exact cent , then round only at GL post. GL structure: three codes, one invoice Your GL account chart now needs: 4100 Revenue – Malaysia Services 4105 Revenue – Indonesia Services 4110 Revenue – Singapore Services 2200 GST Payable – Malaysia 2205 PPN Payable – Indonesia 1250 Accounts Receivable – Regional Client (multi-currency) When you post the invoice, create three separate line items in your GL journal: Entry 1 – Malaysia segment: Debit: AR – Regional (MYR 9,222) Credit: 4100 (MYR 8,698.11) Credit: 2200 (MYR 523.89) Entry 2 – Indonesia segment: Debit: AR – Regional (IDR 86,075,000) Credit: 4105 (IDR 78,250,000) Credit: 2205 (IDR 7,825,000) Entry 3 – Singapore segment: Debit: AR – Regional (SGD 4,050) Credit: 4110 (SGD 4,050) Your AR account now shows USD 10,620 (the invoice total) in three currencies. Each revenue GL code shows the correct local tax treatment. Each tax GL code shows what you owe in each jurisdiction. This ties cleanly to the invoice. The audit test: Your invoice document says USD 10,620. Your AR account says MYR 9,222 + IDR 86,075,000 + SGD 4,050, converted back to USD at invoice-date rates = USD 10,620. If they don't match to the cent, you have a rounding leak. Where invoicing platforms break Most platforms—Xero, FreshBooks, Wave—treat a multi-line invoice as a single GL post with a single tax code. Xero: Allows multiple tax codes per invoice, but forces you to specify the total amount per tax code manually. If you later change the revenue allocation, y