A services firm with teams in Kuala Lumpur, Singapore, and Jakarta invoices clients across all three markets from a single Xero account. On the surface, it works: invoices go out, payments arrive, the accountant reconciles quarterly. Then an LHDN audit flags a batch of MyInvois invoices for missing SST registration numbers. Singapore's Inland Revenue Authority rejects a GST return because the same invoice was coded differently in two markets. Indonesia's tax authority holds a payment pending e-Faktur validation against an NPWP that wasn't matched at point of sale. Three separate compliance failures, one unified platform. The problem is structural: Malaysia, Singapore, and Indonesia have evolved incompatible tax regimes. A platform that handles one well often creates friction, manual workarounds, or blind spots in the others. This isn't a limitation of bad software—it's the tax system working as intended, with each country enforcing local rules. The question isn't whether to use one platform for all three. It's what to centralize and where to plug in local accounting software. What each country actually requires Malaysia: SST registration, MyInvois filing, and real-time validation Malaysia's Service and Sales Tax (SST) applies to most services at 6%. If you're registered, every invoice must: Include a valid SST registration number (e.g., 12-0123-45678901-0) Be filed in MyInvois (the mandatory e-invoicing portal) within 24 hours of issue Pass real-time validation: LHDN checks the buyer's SST ID and status before acceptance Match the buyer's tax identity or risk rejection and payment delay A buyer with an invalid or lapsed SST ID will cause the invoice to fail MyInvois submission. The invoice sits in draft state until either the buyer corrects their tax ID or you mark them as exempt. Most invoicing software (Xero, FreshBooks, Zoho Books) can integrate with MyInvois, but integration depth varies. Xero's MyInvois connector handles routine filings but may lag on real-time buyer validation. If a buyer's SST lapses midway through a month, you'll discover it when the invoice fails MyInvois, not when you hit send. Real-world friction: A Malaysian contractor invoices a buyer whose SST was suspended for non-compliance. Xero accepts the invoice creation. MyInvois rejects it. The payment stalls for two days while the buyer reactivates their SST. The invoice was never flagged in Xero's workflow. Singapore: GST on supply, CPF on payroll invoices, and separate reporting Singapore's GST is 9% (as of January 2024) and applies to most goods and services. The compliance load is lighter than Malaysia's real-time filing but has its own traps: GST invoices must show the supplier's Unique Entity Number (UEN) and buyer's UEN (if registered) If the invoice is also a payroll document (e.g., contractor payments), CPF contributions may apply, creating a dual tax obligation GST is reported on the Goods and Services Tax Return (GSTR) quarterly; CPF is a separate monthly filing A single invoice can trigger both GST and CPF withholding logic, depending on the buyer's entity type Generic invoicing software handles GST calculation, but the CPF layer—especially when a single invoice is both a supply and a payroll document—often requires manual intervention. Xero and FreshBooks support GST coding, but they don't natively branch logic to flag CPF implications on invoices to certain buyer types. Indonesia: e-Faktur, NPWP validation, and real-time matching Indonesia's Value Added Tax (PPN) is 12% and is enforced via e-Faktur (electronic tax invoice). The system mirrors Malaysia's real-time validation but is stricter on NPWP (tax ID) matching: Every invoice must be filed in e-Faktur within 30 days of issue The buyer's NPWP must match the tax authority's records at point of filing; if the NPWP is invalid or mismatched to the buyer's name, the invoice fails You cannot issue an invoice without a valid buyer NPWP unless the buyer is explicitly exempt (e.g., individual consumers) Corrections to a filed invoice require a formal tax credit note, not a simple amendment NPWP validation in e-Faktur is unforgiving. If the NPWP doesn't match the buyer's legal name in the tax authority's database, the invoice is rejected, and payment is delayed. Many invoicing platforms allow you to record an NPWP, but they don't validate it against Indonesia's tax registry before you send the invoice. You only discover the mismatch when e-Faktur rejects the filing days later. The consolidation trap: What looks unified breaks silently A single invoicing platform (Xero, Zoho Books, FreshBooks, Wave) can issue invoices across all three markets. The standard workflow is: Create invoice in the platform Select the relevant tax regime (Malaysia SST, Singapore GST, Indonesia PPN) Calculate and display the tax Integrate with the local tax authority (MyInvois, GSTR, e-Faktur) On paper, this is elegant. In practice, three problems emerge: 1. Buyer validation is passive, not active Xero a