Indonesia and Malaysia have built hard requirements into their tax systems. Indonesia's e-Faktur mandate (in force since July 2024) and Malaysia's MyInvois submission rules (mandatory for businesses above the filing threshold) aren't suggestions—they're gates. Submit an invoice that doesn't meet the spec, and it either bounces back unsigned or worse: sits in limbo while your customer's tax audit clock ticks. We tested four platforms against real-world invoices to see which ones catch validation errors before submission, and which ones leave you explaining rejections to your accountant at 11 PM on a Friday. What MyInvois and e-Faktur actually require MyInvois (Malaysia's invoice data intake system run by the Inland Revenue Board, or LHDN) requires: Valid SST registration number or exemption code (not optional, not a string you guess at) Correct tax code mapping for each line item (standard rate 6%, exemptions, zero-rated goods) Customer tax ID (NRIC, Passport, or Registration number; format matters) Discount rules applied before tax calculation, not after Invoice series and numbering in sequential order with no gaps Proper currency and exchange rate if multi-currency e-Faktur (Indonesia's electronic invoice system under the Directorate General of Taxes, or DGT) requires: NPWP (Nomor Pokok Wajib Pajak, the taxpayer ID) for both seller and buyer; invalid or unregistered NPWPs are rejected outright SKU and description alignment with the goods/service list registered in the tax authority's database Correct VAT rate (0%, 10%, or specific treatment codes for exempt items) Serial number format matching LHDN-controlled ranges (a prefix-sequence-suffix pattern) Timeliness — e-Faktur must be submitted within 30 days of issue or before the customer files their return, whichever is sooner Both systems will reject invoices that fail validation. Both systems will tell you what failed—but only if you read the XML response. Most invoicing software doesn't. Testing: Xero Xero has native MyInvois support via LHDN API integration. When you configure a Xero entity in Malaysia and assign the correct SST number, Xero will validate invoice line items against tax codes before submission. This is the right behavior. What we found: Validation catches SST number format errors when you first enter it; invalid digits are rejected at setup. Tax code mapping is enforced — you cannot create an invoice line with a tax code that doesn't exist in the LHDN codelist without Xero warning you. Customer tax ID is optional at invoice creation , but Xero flags it as missing when you attempt MyInvois submission. The platform will not submit until you add it. Discount application — Xero applies discounts before tax by default, which is correct. No trap here. The gap: Xero does not validate the customer's tax ID format (NRIC vs. Passport vs. Reg number distinction). You can enter a number that passes Xero's checks but fails LHDN's format validation. You'll discover this when LHDN rejects the submission. Xero will then show you the LHDN error, but you have to manually fix the ID in Xero and resubmit. For e-Faktur, Xero has no native integration. If you operate in Indonesia, you must export the invoice data and submit via a third-party e-Faktur platform or the tax authority's portal directly. Testing: Zoho Zoho Books (the invoicing module in Zoho's ecosystem) has a MyInvois connector and advertises e-Faktur support. We tested both. MyInvois in Zoho: Zoho validates SST number format at setup and stores it at the organization level. Tax codes are pulled from a Zoho-maintained codelist, not directly from LHDN. This is a risk: if LHDN's codes change and Zoho's don't sync in time, your invoices may fail validation even though Zoho said they were OK. Customer tax ID is not required at invoice creation. Zoho will warn you at submission, but the warning appears after you hit the submit button, not before. This is a UX failure—you don't know you're blocked until you try. Discount handling is correct (pre-tax), but we found a bug: if you create a line-item discount and then change the quantity, the discount amount does not recalculate proportionally. You end up with incorrect tax base. Zoho's validation doesn't catch this either. e-Faktur in Zoho: Zoho advertises e-Faktur support, but the implementation is not a direct tax authority integration. Instead, Zoho exports the invoice data in a format compatible with third-party e-Faktur service providers. You still have to use a separate platform to submit to the Indonesian tax authority. This means Zoho is not validating against the DGT's live codelist; it's validating against a template. Real-world NPWP validation, for example, is surface-level (digit count, no special characters) but not checked against the tax authority's registry. The gap: For businesses that need to submit natively without a middleman, Zoho e-Faktur support is incomplete. You'll discover validation gaps after export. Testing: Wave Wave (owned by