Your invoice passes every validation rule inside your accounting software. You hit send. MyInvois receives it. And then—silence. Two hours later, you check the submission status. Rejected. No error message. No field highlighted. Just: rejected. This is the MyInvois tax ID trap. The validation doesn't fail loudly at creation. It fails silently at transmission. By then, you've already sent 50 invoices that need resubmission, your client sees a duplicate, and your compliance timeline slips. The root cause is that most invoicing platforms—even enterprise ones—don't validate tax ID format against MyInvois rules at the moment you enter the data. They validate syntax. They don't validate jurisdiction-specific format, length, or structure. When the invoice hits the Malaysian tax authority's servers, the mismatch is discovered. Rejected. No appeal. Start over. This guide maps the five fields that cause silent rejections, shows you the exact format rules for NPWP (Indonesia), UEN (Singapore), and BRN (Malaysia), and gives you a pre-transmission audit checklist so rejections never reach the gateway. Field 1: Tax ID Format (NPWP, UEN, BRN) Must Match Jurisdiction Length Exactly The first silent failure is simple: your tax ID is the wrong length, and your invoicing tool doesn't catch it. Malaysia BRN: 12 digits, no spaces, no dashes. Format: NNNNNNNNNNNN. Example: 123456789012. Most tools accept this. But if your accounting software auto-formats it as NN-NNNNNN-NNNNN (11 digits + 1 in the last field), MyInvois rejects it because the system field expects exactly 12 contiguous digits. Indonesia NPWP: 15 digits. Format: NN.NNN.NNN.N-NNN.NNN. The dots and dash are structural—they're part of the format spec, not optional formatting. If you store it as NNNNNNNNNNNNNNN (15 digits, no separators), MyInvois may accept it at submission but fail at validation because the authority's system expects the separators in exact positions. Test both formats with your provider. Singapore UEN: 9 characters. Format: NNNNNNNNN or NNNNNNNNX (9 digits, or 8 digits + 1 letter). Sole proprietors use NNNNNNNNN-X format (10 chars with a dash). This is where regional businesses commonly slip: they use the dash in UEN, but their invoicing tool strips it during export to MyInvois, creating a mismatch. The fix: Before you go live, export a test invoice from your system and inspect the raw XML or API payload that hits MyInvois. Print the tax ID field character by character. Count. Does it match the spec? If your tool rounds or strips characters during export, you've found your rejection point. Field 2: Buyer Tax ID Must Exist and Match Seller Format Rules The second silent failure: the buyer's tax ID is missing, malformed, or uses a format that doesn't match the invoice's recipient jurisdiction. MyInvois requires the buyer (recipient) tax ID on every B2B invoice. If you're invoicing a Malaysian company from Singapore, the buyer field must contain a valid Malaysian BRN—not a Singapore UEN, not a generic business registration number, not 'N/A'. If the buyer is a sole proprietor without a formal tax ID, MyInvois rules vary by state. Some jurisdictions allow an identity card number in that field; others reject the invoice outright. Check with your buyer's tax authority before you issue. Do not guess. If the buyer is a foreign entity (non-Malaysian), some invoicing platforms let you leave the tax ID blank or use 'FOREIGN' as a placeholder. MyInvois often rejects this silently. Confirm with your platform and the LHDN (Malaysian tax authority) what format is acceptable for cross-border invoicing. If the buyer tax ID is correct but your invoicing tool stores it in the wrong field (e.g., in a 'registration number' field instead of 'tax ID'), the export will either blank the field or send the wrong value. Check your field mapping before the first submission. This is why consolidation into a single invoicing platform matters: Orin's invoicing module enforces buyer tax ID format at entry—it won't let you save an invoice without matching the format to the buyer's jurisdiction. You catch the error before transmission, not after rejection. Field 3: Invoice Date and Tax Period Must Align With MyInvois Calendar Rules The third silent rejection is timing-based. Your invoice date is correct by your accounting calendar, but MyInvois rejects it because it falls outside the tax period your account is registered for. Malaysia: MyInvois submissions must fall within your registered tax quarter (or month, depending on your return frequency). If your account is set for quarterly filing (Jan-Mar, Apr-Jun, Jul-Sep, Oct-Dec), an invoice dated March 31st is valid. An invoice dated April 1st, submitted in April, may be rejected if your MyInvois account hasn't been opened for the Q2 submission window yet. Check your registration with the LHDN. Indonesia: e-Faktur has a 7-day grace period from invoice issue date. If you issue an invoice on January 1st but don't submit to e-Faktur until