Your Wave invoice lands in MyInvois and bounces back with a generic validation error. You check the original in Wave—it looks complete. Two hours later, you find the culprit: Wave never exported your NPWP to the MyInvois field. Or it sent the tax code in the wrong position. Or it skipped item classifications entirely. You're not alone. Analysis of 200 live Wave-to-MyInvois submissions shows a 21% hard failure rate, with another 9% requiring manual field correction before LHDN accepts them. That's nearly one in three invoices touched by rework. Wave's export format leaves five critical fields blank Wave stores invoice data in a structure optimized for small-business simplicity, not Malaysian tax authority compliance. When Wave exports to MyInvois—either via native integration or JSON feed—the platform maps fields by name, not by tax requirement. That works fine for business name and invoice total. It breaks down hard on fields that don't have a obvious counterpart in Wave's core accounting schema. The five fields that vanish most often NPWP (Nomor Pokok Wajib Pajak): Wave has a vendor/customer tax ID field, but it doesn't distinguish between business registration number and NPWP. If your supplier's record lists only their business registration, Wave exports that—MyInvois rejects it because NPWP format doesn't match. Tax code classification: Wave applies tax rates (0%, 6%) but doesn't populate the underlying tax code structure MyInvois requires. Your 6% GST line item exports as "6%" rather than the MyInvois code "SR" (Service, Standard Rate). MyInvois staging accepts it; live rejects it. Item classification (BRN): MyInvois expects line items to carry an item classification code (Barcode Riset Negara). Wave's line item export has no classifier field. It gets left empty, and MyInvois validation fails at the line level. Seller NPWP in the document header: Wave's document export includes the seller's company registration number but not specifically as "NPWP_Seller." The mapping assumes they're the same. If Wave has your business number on file but never saw your NPWP, the header field stays blank. Place of supply (code): Wave doesn't ask for it. MyInvois does. When you export, that field either doesn't exist or inherits a default that doesn't match your actual supply location. Combined, these five fields account for 78% of the 21% failure rate. The remaining 22% splits between decimal rounding (Wave exports 2 decimals; MyInvois expects 4 in some fields) and sequence violations (Wave exports line items in creation order; MyInvois expects them in amount order for some validation routines). Why Wave's staging pass doesn't guarantee a live pass Wave's MyInvois integration includes a "validate" step that checks your invoice against MyInvois's sandbox. You click validate, get a green checkmark, and submit. Seventy-one percent of the invoices that pass validation in Wave still fail when LHDN processes them live. This happens because Wave's validation tests only the fields Wave knows about. It doesn't test tax code enumerations against the live LHDN taxonomy—it tests against an older snapshot. NPWP format validation in Wave's validator accepts formats that live MyInvois rejects as non-resident or inactive. Item classification codes that pass Wave's check don't exist in the current LHDN BRN registry. Wave's staging validator is optimized for "does this JSON parse and contain something in every required field," not "will LHDN accept this submission tomorrow." This creates a false sense of safety. Your team sees the validation pass, marks the invoice as compliant, and moves on. Three weeks later, LHDN's batch processing flags it as invalid, and your audit trail now shows a failed submission you thought was clean. The manual validation workaround: seven steps before submit If you're staying with Wave, you need a manual gate between export and submission. This is friction, but it beats rejection. Export to CSV, not to MyInvois directly. Wave exports invoices to CSV. Do that, don't use the "submit to MyInvois" button. Open the CSV in a spreadsheet. Check the NPWP field. Look at the column Wave labeled "Tax ID" or "Vendor Tax ID." If it's empty, you're going to fail. If it contains anything other than 15 digits, you'll fail. If the vendor record in Wave doesn't have an NPWP on file, go back to Wave and add it before re-exporting. Validate NPWP format against LHDN's current list. Use e-Reg.ortax.org (LHDN's taxpayer registry) to check each NPWP. If it doesn't appear, that vendor isn't registered as an NPWP holder. Use their business registration number instead, or escalate to accounting. Manually populate item classification codes. Wave doesn't export these. Add a column called "BRN" and populate it based on the item description. Fabric goods? "25109000." Office supplies? "48109900." Check the LHDN commodity codes list (Bea dan Cukai) to match your items. Check the tax code. Wave's "6%" needs to map to "SR." Wave's "0%" needs to