You issue one invoice in Singapore dollars to a Malaysian client, price a line item in Indonesian rupiah, and calculate tax across both currencies. The invoice total reconciles. But when you post to the GL, the amounts diverge by ₹8,000—enough to trigger a tax audit query and stall your month-end close. This is not a bug in your software. It's a silent design choice about where you convert, how you round, and when you recalculate tax. Most platforms handle one-currency invoices flawlessly. Multi-currency invoices expose the cracks. Here's how to map the gap and fix it before your GL auditor finds it. Why rounding errors stack across three currencies Start with a real case: a ₹100,000 invoice split across three currencies. Line 1: SGD 5,000 (hardware) → Convert to INR at 1 SGD = 62.5 INR = ₹312,500 Line 2: MYR 8,000 (services) → Convert to INR at 1 MYR = 20.1 INR = ₹160,800 Line 3: IDR 15,000,000 (support) → Convert to INR at 1 IDR = 0.0053 INR = ₹79,500 Subtotal in INR: ₹552,800. Now apply 18% GST: ₹99,504. Invoice total: ₹652,304. But your GL received three separate conversion transactions—each rounded independently at different decimal places. SGD rounds to 2 decimals (₹312,500.00), MYR to 2 decimals (₹160,800.00), IDR to whole numbers (₹79,500). The GL subtotal calculates to ₹552,800, and 18% GST is ₹99,504—so far, clean. Then your invoicing platform recalculates tax after it posts GL entries. Now it sees a slightly different subtotal due to how it stored intermediate rounding. GST becomes ₹99,512. The difference: ₹8 per currency, times three currencies, equals a ₹24 variance that balloons to ₹8,000 when you're handling bulk regional invoices or multi-leg projects. The real damage: your invoice says one total, your GL says another, and your tax return sits between them. Conversion point: where most platforms diverge Platforms fall into three camps based on when they convert currency. Camp 1: Convert at entry, then post You enter line items in their native currency (SGD, MYR, IDR). The platform converts each one to your base currency (INR) before you save the line. You see ₹312,500 on the invoice immediately. The GL receives one pre-converted figure per line. No rounding drift because the conversion happened once, visibly, and the invoice and GL both use the same converted value. Platforms that do this well: Xero, when configured with a fixed exchange rate table. You set today's rates centrally; every invoice uses them consistently. Risk: If you change the exchange rate mid-invoice (due to market movement or client negotiation), you have to manually recalculate or delete and re-enter lines. It's safe but rigid. Camp 2: Store native, convert at post You enter SGD 5,000. The platform stores it as SGD 5,000 on the invoice line. When you post to the GL, it applies the rate at that moment and converts to ₹312,500. The invoice displays SGD 5,000 (or both, if you have dual-currency display), and the GL shows ₹312,500. Platforms that do this: Wave, Stripe Invoicing, and many cloud-native systems. Flexibility is high—you can adjust rates or add new lines without recalculating the whole invoice. Risk: If the GL posting rate differs from the invoice-display rate, your invoice and GL will never reconcile. Wave, for example, lets you set a custom rate per invoice—but if you forget, it defaults to today's rate, not the rate you intended when you created the line. The tax recalculation often uses a different rate than the GL posting, creating a hidden delta. Camp 3: Dual-currency posting (rare, usually only in ERP) The GL receives two rows per transaction: one in SGD (the original), one in INR (the converted). You close the deal when both balance. This is bulletproof for audit but clunky for reporting—your revenue report has to sum across two currencies. Platforms that do this: Oracle NetSuite, SAP, and Odoo when configured with multi-currency GL. Not typical for SMB invoicing platforms. The safest approach for regional teams: pick one platform, one conversion point, and one exchange rate source. Don't mix Xero's rates with your bank's rates. Use OANDA or a central rate service and lock it in at invoice creation time, not at posting time. Rounding rules: where tax breaks Once you've converted, you round. The order matters. Scenario A: Round each line, then sum and tax. SGD 5,000 × 62.5 = ₹312,500.00 (no rounding needed) MYR 8,000 × 20.1 = ₹160,800.00 (no rounding needed) IDR 15,000,000 × 0.0053 = ₹79,500.00 (no rounding needed) Subtotal: ₹552,800 Tax on subtotal (18%): ₹99,504 This is clean in a frictionless case. But in reality: SGD 5,100 × 62.5 = ₹318,750.00 Discount on line 1: 5% = ₹15,937.50 → rounds to ₹15,938 or ₹15,937? Net line 1: ₹302,812 or ₹302,813 That ₹1 difference multiplies across lines and compounds with tax. Scenario B: Tax each line, then sum. Some jurisdictions (e.g., Malaysia's SST, Indonesia's PPN on specific goods) apply tax per line, not on the subtotal. If you're invoicing across regions, you mig