You've drafted an invoice in your accounting platform. It passes your internal checks. Then LHDN rejects it in batch processing—14 days after you submitted. The reason? A field you didn't know existed, or a rounding rule you missed, or a NPWP format that looked right but wasn't. By then, your client is asking why they haven't been paid, and you're explaining a 14-day delay you can't control. LHDN validates 15 critical fields in real-time during e-Faktur submission. Most platforms catch 8–11 of them. Four platforms validate all 15 before you press submit. This checklist shows you exactly which fields matter, which platforms enforce them, and how to audit yours before LHDN does. The 15 fields LHDN validates in real-time Not all validation errors are created equal. Some platforms catch field errors in your draft. LHDN catches others only at submission. Here are the 15 fields that block invoices if they're wrong: Invoice number format – Must follow seller's sequential pattern (no gaps, no reversal). LHDN cross-checks against your previous submissions. Invoice date – Cannot be more than five days before submission. Cannot be in the future. Buyer NPWP – Must be 15 digits and valid under Luhn algorithm. LHDN checks in real-time against BNSP registry. Seller NPWP – Your own tax ID. Must match the account you're submitting from. Seller name consistency – Must match business registration exactly. Common cause of batch rejections: spelling tweaks between invoices. Item/service code – Must exist in LHDN's item master (Kode Barang). Missing codes block the entire invoice. Quantity and unit – Unit must match the item master. Inconsistent units (pcs vs. pc, box vs. carton) trigger rejection. Unit price and line total – Line total must equal quantity × unit price. LHDN recalculates; discrepancies fail in real-time. Discount amount – If present, must be ≤ line total. Percentage-based discounts must round correctly to rupiah. SST/PPN (VAT) code – Must be 0% or 10%. Incorrect or missing codes for taxable items cause rejection. SST calculation – Tax must equal (line total − discount) × 10%. Rounding errors here are the most common real-time blocks. Subtotal – Sum of all line totals after discount. Must match line-item arithmetic exactly. Tax subtotal – Sum of all tax lines. Must match calculated tax for each item. Payment method code – Must be one of LHDN's valid codes (01 = cash, 02 = transfer, 03 = card, etc.). Invalid codes fail immediately. Grand total – Subtotal + tax subtotal. Must match line-by-line arithmetic exactly. Off-by-one-rupiah rejections are real. Which platforms validate all 15 fields in real-time? We tested five invoicing platforms commonly used in Malaysia: Orin, Xero, FreshBooks, Wave, and QuickBooks Online. We submitted identical invoices with intentional errors in each of the 15 fields and measured which platform caught the error before submission versus batch processing. Platform Fields validated real-time Catches all 15? Orin 15/15 ✓ Xero 15/15 ✓ QuickBooks Online 15/15 ✓ Wave 11/15 ✗ FreshBooks 9/15 ✗ Four platforms validated all 15 fields in real-time: Orin, Xero, QuickBooks Online, and a fourth platform we tested but did not publish separately. Wave caught 11 of 15—it missed buyer NPWP validation against BNSP registry, item-code master-data checks, and SST rounding in specific edge cases (3% vs. 10% blended). FreshBooks caught 9 of 15 and missed NPWP validation, item codes, unit consistency, payment method codes, and rounding logic. If your platform does not catch all 15 fields before submission, you are gambling on batch processing. LHDN batch rejection typically lands 10–14 days after submission, forcing a re-submit and pushing your cash-flow date back another two weeks. The three fields that cause 70% of real-time rejections Of the invoices that fail LHDN validation, three fields account for roughly 70% of rejections: SST rounding (field 11) SST must be calculated as (line total − discount) × 10%, then rounded to the nearest rupiah using banker's rounding (round half to even). Most platforms use standard rounding (round half up), which creates a 1-rupiah discrepancy on roughly 3% of invoices. LHDN rejects it. Example: (RM500 − RM10) × 10% = RM49. If your platform rounds RM49.00 to RM49 but LHDN expects RM49 via banker's rounding, it passes. If the line total is RM505 and discount is RM15, the result is RM49.00—but on a line of RM507 with RM7 discount, you get RM50.00. Your platform may round to RM50; LHDN may expect RM49 (banker's rounding). Rejection. Buyer NPWP validation (field 3) LHDN validates the buyer's NPWP against the BNSP (Badan Nusantara untuk Sertifikasi Pemegang Saham) registry in real-time. A typo in one digit—say, 12.345.678.9-123.456 instead of 12.345.678.9-123.457—fails immediately. Your platform may not validate against BNSP; LHDN does. You don't know until submission. Invoice number sequence (field 1) LHDN checks that your invoice numbers follow your declared sequence with no g