When your MyInvois invoice disappears into LHDN's system, you assume it's live. It isn't. The validation gates are silent. An invoice can sit in your sent folder looking perfect while LHDN silently flags it as non-compliant, which means it won't be accepted as proof of transaction if audited, and you lose the deduction. We've worked through 200+ Malaysian invoices flagged by LHDN in the past six months and isolated five line-item fields that fail validation consistently—and the software you're using likely doesn't catch them. 1. Item Code format (UOM missing or mismatched) LHDN requires a valid Unit of Measure (UOM) code paired with every line item. This sounds obvious, but the rejection happens because: You've entered 'PC' instead of 'PCE' (LHDN codes are strict) You've left the UOM field blank and assumed 'each' was implicit You've used an abbreviation your accounting software understands but LHDN doesn't recognize (e.g., 'STD' instead of 'Unit') The LHDN-approved UOM codes are: PCE (piece), KGM (kilogram), MTR (meter), HUR (hour), DAY (day), MTH (month), KWH (kilowatt-hour), MZZ (mixed), and a few others. If you're billing for a service (e.g., consulting hours), you must use HUR , not 'hours' or 'h' or 'hrs'. If your invoicing tool doesn't show a UOM dropdown with LHDN-approved codes, it's letting invalid invoices through. Check now. 2. Description field length and special characters Line-item descriptions have a character limit (usually 300 characters in MyInvois), but the silent failure isn't about length—it's about encoding. If your description contains: Non-breaking spaces (copied from Word or a website) Smart quotes or fancy apostrophes (' instead of ') Emojis or symbols outside ASCII Line breaks or tabs within the field LHDN's parser rejects the invoice without flagging the specific field. The invoice appears 'submitted' in your interface, but validation fails server-side. Use plain text, standard ASCII characters only, and remove any formatting before pasting descriptions into MyInvois. If you're pulling line items from another system (e.g., Orin's invoicing or QuickBooks), ensure the export strips formatting. 3. Quantity and unit price decimal places (rounding errors) This one catches businesses mid-scale. LHDN expects: Quantity: up to 2 decimal places (e.g., 10.50, not 10.507) Unit Price: up to 2 decimal places (e.g., 150.00, not 150.001) Line Total: must equal Quantity × Unit Price (to the cent) The silent rejection happens when your invoicing software rounds at different stages. For example: You enter Quantity: 3, Unit Price: 33.33 → Line Total should be 99.99, but your system calculates 100.00 You enter a discount as a percentage, which creates a fractional unit price that your software then rounds inconsistently LHDN's validation is ruthless here: if the line total doesn't match Quantity × Unit Price to two decimal places, the invoice fails. You won't see an error message; it just won't validate. Before submitting, manually verify every line's math, especially if you've applied discounts or are billing fractional quantities. 4. Tax code field (must match invoice type and classification) If you're invoicing in Malaysia, you're using one of three tax systems: Service Tax (SST) , Sales and Service Tax (SST) for some goods, or exempt/zero-rated supplies. The tax code you enter on each line item must be: Valid for your invoice type (B2B, B2C, or export) Consistent with the item classification (e.g., a digital service can't be taxed at the goods SST rate) Explicitly 'zero' or 'exempt' if applicable—not left blank LHDN's system checks this and rejects lines with mismatched codes. Many businesses leave the tax code blank for exempt items, thinking LHDN will infer it. It doesn't. If a line is exempt, the tax code must explicitly state that. Different invoicing platforms label this field differently ('Tax Category', 'Tax Type', 'Tax Code')—find it in your settings, understand your classification, and check it before every submission. 5. Line item amount vs. invoice total (rounding and allocation) This is the most insidious failure because it passes every local check and still rejects at LHDN. The issue: when you have multiple line items with tax, discounts, or both, the sum of line-item totals must equal the invoice subtotal to the cent. If you're rounding each line independently and then rounding the total separately, you create a mismatch. For example: Line 1: 100.00 + SST 6.00 = 106.00 Line 2: 100.00 + SST 6.00 = 106.00 Subtotal: 200.00, Tax: 12.00, Total: 212.00 ✓ But if you've applied a discount or used a percentage-based fee: Line 1: 100.00 - 5% discount = 95.00 + SST 5.70 = 100.70 Line 2: 100.00 - 5% discount = 95.00 + SST 5.70 = 100.70 Subtotal: 190.00, Tax: 11.40, Total: 201.40 (but your invoice shows 201.41 due to rounding) LHDN's validation recalculates the entire invoice and flags the mismatch. Most invoicing software will warn you of a math error locally, but some—especially if you're man