If you bill clients in Malaysia, Indonesia, and Singapore—even on the same retainer-plus-project deal—you know the pain: one invoice lands in your accounting system as three separate GL entries, each tagged with its own currency code, tax regime, and payment method. By month-end, your GL reconciliation is a wreck. Worse, your accountant can't tell if the ₹50,000 variance is a real error or just currency rounding across three countries. The root cause isn't bad software. It's bad invoice design. Most teams structure multi-country invoices as separate line items per country, which triggers automatic GL splits. Instead, you need a single consolidated invoice architecture that respects tax rules in each country but stays unified in your GL. This playbook walks you through the exact structure: how to map revenue, taxes, and payments so one invoice creates one GL debit, one credit, and zero manual reconciliation. Why your current multi-country invoices splinter Here's the chain reaction: You create separate line items per country: "Malaysia retainer (MYR)", "Indonesia project (IDR)", "Singapore retainer (SGD)". Your invoicing system sees three currencies: It can't consolidate, so it flags each for separate processing. Your tax rules differ by country: Malaysia needs SST at 6%, Indonesia needs e-Faktur registration and PPh, Singapore needs GST at 8%. Each triggers a different tax GL account. Your payment method varies: One client pays via bank transfer in IDR, another via international wire in SGD. That's two payment GL splits. Your accounting software syncs each as atomic: Three currencies + three tax regimes + two payment paths = seven GL line items for one invoice. By invoice 20, your GL is unmappable. By invoice 100, your accountant stops trusting the sync and reconciles manually—defeating the purpose of automation. The consolidated invoice structure: One native invoice, one GL footprint The fix is architectural. Instead of splitting by country, you consolidate by revenue component and settlement currency . Here's the template: Step 1: Choose a single invoice currency (not the billing currency) If you bill in MYR, IDR, and SGD, do not create three invoices. Create one invoice in your reporting currency (typically USD or your home currency). List each revenue line in the reporting currency, then show the converted amounts per country in a footnote or schedule. Example: Invoice USD-2025-001 | 15 Jan 2025 Client: PT Maju Jaya | Jakarta, Singapore, Kuala Lumpur Revenue Schedule: — Malaysia retainer (Jan): USD 1,000 (equiv. MYR 4,500 @ 4.50) — Indonesia project (Jan): USD 2,000 (equiv. IDR 32M @ 16,000) — Singapore setup (Jan): USD 500 (equiv. SGD 675 @ 1.35) Total: USD 3,500 Payment: Three separate bank transfers per country (see Payment Terms). Why this works: One invoice, one currency in your GL, three payment channels. Your accountant sees USD 3,500 revenue, not a tangle of currency codes. Step 2: Unify taxes in a single tax schedule, not per-line Don't embed SST, VAT, and e-Faktur into each line item. Instead, create a Tax Schedule section that calculates tax by component and shows the GL account mapping: Revenue Component Amount (USD) Tax Regime Tax Rate Tax (USD) GL Tax Account Malaysia retainer 1,000 SST 6% 60 2200-SST-Payable Indonesia project 2,000 PPN (e-Faktur) 10% 200 2210-VAT-Payable-ID Singapore setup 500 GST 8% 40 2205-GST-Payable Critical: Each GL tax account is discrete (one for SST, one for e-Faktur, one for GST). This respects local tax rules but centralizes them in a single invoice, so your system sees one document to sync, not three. Step 3: Map payments by settlement currency, not invoice line Your client pays you three separate ways. Map each payment to a discrete bank account GL and settlement currency, but anchor all three to the same invoice total: Payment Terms: MYR 4,500 + SST 270 = MYR 4,770 → Transfer to Bank of Malaysia account (GL: 1200-BOM-MYR) IDR 32M + PPN 3.2M = IDR 35.2M → Transfer to Bank Central Asia (GL: 1205-BCA-IDR) SGD 675 + GST 54 = SGD 729 → Transfer to Standard Chartered (GL: 1210-StanChart-SGD) In your accounting system (Xero, QuickBooks, or Orin's invoicing module ), configure each bank account as a distinct payment method on the same invoice. When the client pays all three tranches, three payments post to three bank accounts, but they all resolve to one invoice total of USD 3,500 + taxes. Step 4: Configure GL mapping in your invoicing tool, not your accounting software This is the crux. Before you sync to QuickBooks or Xero, configure the GL codes in your invoicing tool (or Orin's billing module) so that each line item and each tax component routes to the correct GL account at creation time . Do not rely on your accounting software's auto-mapping rules. In Orin or your invoicing platform: Set the revenue GL to 4100-Services-Revenue (not split by country). Map each tax regime to its own GL account: 2200-SST-Payable, 2210-VAT-Payable-ID, 2205-GST-Payable. Map each pay