Your invoice passed every internal check. Your finance team flagged no errors. Then LHDN rejects it with a cryptic validation error, and you're back in a spreadsheet hunting field-by-field for what went wrong. This happens because MyInvois validation doesn't fail on the obvious stuff—it fails on five specific fields that accountants consistently fill incorrectly, even when the data itself is right. The pattern is clear: LHDN's e-Faktur system enforces rules that feel arbitrary until you understand the underlying business code logic, decimal precision rules, and date formatting. Most rejections cluster in the same five zones. Fix those, and your submission pass rate jumps from 68% to 94%. 1. Supplier NPWP format—leading zeros and segmentation rules Your NPWP looks valid. It's 12 digits. But MyInvois rejects it because you've either: Dropped the leading zero on the first digit (valid NPWP: 012345678901 , submitted as 12345678901) Added spaces or dashes that the system doesn't expect Used a tax ID type code that doesn't match the NPWP structure The validation rule is strict: NPWP must be exactly 12 numeric digits with no separators. Leading zeros are mandatory. If you're pulling NPWP data from a supplier form or legacy system, that data often gets stored as a number (not text), and spreadsheet imports automatically strip leading zeros. Fix: In your invoicing system, force NPWP fields to text format before submission. If you're using spreadsheet imports, prepend a single quote (') to the cell or format the column as text first. When building an invoice in code or via API, validate NPWP as a 12-character string and reject anything shorter. Real-world example: A supplier's NPWP is 012345678901. Your system stores it as 12345678901 (dropped zero). MyInvois rejects the invoice with "invalid supplier identifier." You correct it, resubmit, and it passes instantly. 2. SST registration number—business type code mismatch You have a valid SST number. Your supplier is registered for Service and Service Tax. But the invoice rejects because your business type code doesn't match the SST scheme. This one stings because the SST number itself is correct—the validation failure is on the relationship between SST and business classification. MyInvois enforces a mapping: Code 01 (Individual/Sole Proprietor): Can hold SST but not service tax registration for all service types. Code 02 (Partnership): SST standard; service tax eligibility depends on activities. Code 03 (Company): Full SST and service tax eligibility. Code 04 (Co-operative): Limited service tax eligibility. If your invoice lists the supplier as a sole proprietor (code 01) but the SST registration indicates a company structure (code 03), the system rejects it. The mismatch is the problem, not the SST number. Fix: Before invoicing, audit your supplier master data. Verify that the business entity type on file matches the business structure indicated by the SST registration . If a sole proprietor registered an SST number under a business name (not their personal name), flag that in your records and use the matching entity type code in MyInvois submissions. 3. Amount precision—implicit rounding and tax line-item breakdown Your invoice subtotal is ₹12,500. SST is 6%, which is ₹750. Total: ₹13,250. MyInvois rejects it, claiming the amount doesn't match tax calculation. The issue: you've rounded 6% of ₹12,500 to ₹750, but MyInvois re-calculates it internally and gets ₹750.00 (exact). The amounts match, so why reject? Because the line-item tax amounts don't add up to the summary-level tax amount when you round mid-calculation. MyInvois expects all tax line items to be listed individually, and their sum must reconcile to the total tax claimed. If you've grouped items and rounded tax per group, the individual line-item tax amounts may not equal the total when rounded. Fix: Use precise decimal arithmetic —never round tax at the line level. Calculate tax to at least four decimal places, then round only the final total. If you're using spreadsheets, use formulas (not hard-coded values) so that line-item taxes are calculated fresh each time. When submitting via API or invoicing software, ensure that the sum of all line-item tax amounts equals the reported total tax to the cent . Example: Invoice with three line items, each taxed at 6%. Item A: ₹100 → ₹6.00 tax. Item B: ₹100 → ₹6.00 tax. Item C: ₹100 → ₹6.00 tax. Total tax: ₹18.00. This passes. If you've rounded Item A tax to ₹5.99 due to a prior rounding step, the line items sum to ₹17.99, which doesn't match the declared ₹18.00, and MyInvois rejects it. 4. Invoice date and tax period—off-by-one month and timezone issues Your invoice is dated 2024-10-01. You submit it on 2024-10-15. MyInvois rejects it as "tax period mismatch." The rule: invoices must be submitted within the tax month they're issued in, or within a grace period (typically 7–14 days into the next month). If you submit on 2024-11-20, an invoice dated 2024-10-01 is now