You invoice a client in Singapore on the 15th. They pay from a Malaysian bank account on the 28th. The exchange rate moved 2% in between. Your accounting team now has three different FX rates in your records depending on whether they're looking at invoice date, payment date, or settlement date. Your tax consultant is confused. Your finance manager is confused. Your platform only lets you pick one currency per invoice. This is the moment most invoicing platforms reveal their fundamental design flaw: they were built for single-market teams. Even the ones that claim "global support" treat multi-currency as an afterthought—a checkbox feature that doesn't actually solve the operational and compliance problems that cross-border teams face every day. The breakage isn't random. It happens in three specific places, and understanding where your platform fails is the first step to fixing it. The FX timing problem: invoice date vs. payment date vs. settlement Most platforms let you pick a currency. They do not let you handle what happens when that currency moves between invoice and payment. Here's the realistic scenario: you invoice a client in Thailand (THB) on January 10. Your accounting software converts it to USD at the rate on that day: 1 USD = 34 THB. Your invoice shows $3,000 USD equivalent. The client pays on February 3. The exchange rate is now 1 USD = 35.5 THB. Your payment processor receives the same THB amount but it's worth less in USD now. The delta sits somewhere—in your accounts receivable, in an FX gain/loss line, or nowhere at all, creating a reconciliation nightmare. Standard platforms handle this with one of three broken approaches: No FX handling: You invoice in one currency, get paid in another, and manual adjustments become your job. I've seen finance teams lose weeks to this. Invoice-date-only: The platform locks the FX rate at invoice time. Payment mismatches are recorded as overpayment/underpayment with no context. Your accountant has to dig into bank statements to find the real issue. Automatic mid-rate guessing: The platform picks a spot rate somewhere in the middle and hides the FX difference in a rounding or fees line. Your numbers are "close enough" but auditable nowhere. The right approach requires three separate fields: invoice-date rate, payment-date rate, and settlement rate—and a clear audit trail showing which one was used where. Only platforms that touch actual payment processing (and thus see real settlement rates) can get this right. Tax jurisdiction breaks the single-recipe approach Invoicing software assumes one tax rule. Reality has five. You have a team spread across Singapore (GST), Malaysia (SST), Indonesia (PPN), Thailand (VAT), and Vietnam (VAT). Same company, same client type, completely different tax treatment: Singapore: GST is optional until you hit $1M turnover, and reverse-charge rules apply to B2B services. Malaysia: SST differs for goods vs. services, and certain exports are zero-rated. Indonesia: PPN is 11.5% (as of 2025) but reduced rates apply to certain categories, and the e-Faktur system has its own validation rules. Thailand: VAT can be withheld at source for certain service categories, and the rate varies. Vietnam: VAT starts at 10%, but manufacturing and certain sectors have 5% or 0%. A platform built on "pick a tax rate and apply it" will: Let you create invoices that don't comply with local rules (missing fields, wrong line-item breakdowns, unsupported currencies). Not warn you when an invoice structure violates jurisdiction-specific requirements. Make it impossible to run regional tax reports without exporting to a spreadsheet and rebuilding them by hand. Produce documents that local tax authorities won't accept. I've seen teams invoice in Vietnam with Malaysian SST rules, only to discover the invoice is worthless for compliance when their accountant tries to file. Payment processor gaps create currency dead zones Your invoicing platform supports 80 currencies. Your payment processor supports 12. You create an invoice to a Vietnamese client in VND. The platform accepts it. The client's payment processor (often Stripe, PayPal, or a regional rail like 2C2P) doesn't handle VND. The money never settles into a currency your team actually uses. You're back to manual bank transfers, which means weeks, fees, and reconciliation chaos. The real constraint isn't the invoicing platform. It's the payment rails: Stripe: Supports ~135 currencies but payouts in ~40. A Vietnamese invoice might arrive in USD, forcing a second conversion step. PayPal: Accepts payments in 25 currencies, pays out in fewer. Regional coverage is patchy. Local processors (2C2P, Fintech Karya, etc.): Tighter regional support but limited currency pairs and often require manual intervention for edge cases. Traditional bank transfers: Slowest, cheapest for large amounts, and they handle any currency—but reconciliation is manual. A platform that doesn't know which payment processor you're using can