Your checkout form asks for a tax ID. The customer enters it. The invoice generates. Then accounting rejects it three days later because the format was wrong, or the validation never ran, or it ran against the wrong ruleset for that country. Most ecommerce platforms and checkout builders treat tax ID fields as optional text boxes. They don't validate. They don't regionalize. And in Malaysia, Singapore, and Indonesia—where tax authorities now require exact formatting for e-invoicing—a malformed tax ID means the invoice fails submission to LHDN, IRAS, or DGT before your customer even sees it. This guide maps the exact field requirements, validation logic, and platform support for NPWP (Indonesia), UEN (Singapore), and NOPPB (Malaysia). You'll get a checklist to configure your checkout correctly the first time. Why your checkout's tax ID field is silently breaking invoices Three things happen when a tax ID arrives at checkout in the wrong format: Silent rejection at invoice submission: Malaysia's MyInvois system, Indonesia's e-Faktur, and Singapore's GST reporting all validate tax IDs in real time now. A malformed NPWP or UEN passes through your checkout and invoicing system, then bounces when you submit to the tax authority. By then it's 3–5 days old and you're scrambling to reissue. Accounting reconciliation breaks: Your GL expects a normalized tax ID for grouping by supplier or customer. If checkout accepts "123456789012" and "12.3456.789.0-123.000" as the same NPWP, your reconciliation logic fails. Invoices split across GL accounts and audits spiral. Vendor payment holds: If you're buying from Indonesian suppliers, their invoice must carry a valid NPWP or you can't claim input tax. If your payment form doesn't validate NPWP at entry, you're issuing vendor invoices that the tax office won't recognize. The fix is not complex. It's a combination of client-side format validation (catch typos before submission) and server-side normalization (strip spaces and punctuation, then validate against the country's checksum rules). NPWP (Indonesia): 15-digit format with checksum validation Format: 15 digits, no spaces or punctuation. Often displayed as XX.XXX.XXX.X-XXX.000 for readability, but the raw value is 15 consecutive digits. Anatomy: Digits 1–2: Area code (01–99, assigned by DGT regional offices). Digits 3–5: Serial number within that area. Digit 6: Check digit (calculated from digits 1–5 using a modulo-11 algorithm). Digits 7–15: Additional serial and status codes (business category, activity type, administrative subdivision). Validation rule: The check digit (position 6) is computed as 11 minus ((digit1×2 + digit2×3 + digit3×4 + digit4×5 + digit5×6) mod 11). If the result is 10, it becomes 0; if 11, it becomes 0. Any mismatch means the NPWP is invalid. What breaks: Customers often paste an NPWP with dots and dashes. Your form must strip these before validation. Also, leading zeros matter—"01234567890123" is not the same as "1234567890123". Checkout configuration: Input field: Accept 15 digits. Regex pattern: ^\d{15}$ after stripping non-digits. Client-side: Strip spaces, dots, and dashes immediately on blur or paste. Server-side: Validate the check digit before saving. If invalid, reject with a clear error ("NPWP check digit failed; please verify digits 1–5 and resubmit"). Display: Format as XX.XXX.XXX.X-XXX.000 for the invoice, but store the 15-digit raw value in your GL. UEN (Singapore): 9 characters, mixed alphanumeric with check logic Format: 9 characters: NNNNNNNNT, where N = digit and T = check character (letter or digit). No spaces or punctuation. Anatomy: Characters 1–8: A unique business reference number (assigned by ACRA, the Singapore corporate registry). Character 9: A check character derived from the first 8 digits. Validation rule: Convert each of the first 8 digits to its weighted sum (position 1 × 5, position 2 × 4, position 3 × 3, position 4 × 2, position 5 × 7, position 6 × 6, position 7 × 5, position 8 × 4). Sum them, divide by 11, take the remainder. The check character is derived from a lookup table (0→A, 1→B, ..., 9→I or 10→Z, depending on ACRA's latest version). In practice, most platforms just call ACRA's API to verify rather than computing locally. What breaks: UENs are often confused with registration numbers. A Singapore business might have both a UEN (unique entity number, issued by ACRA) and a GST registration number (different format). Forms that ask for "Registration Number" without specifying UEN often get the wrong value. Also, UENs for foreign entities registered in Singapore have a different prefix and check logic. Checkout configuration: Input field: Accept exactly 9 characters. Regex: ^[0-9]{8}[A-Z0-9]$ . Client-side: Uppercase any letters automatically. No spaces or dashes allowed. Server-side: Call ACRA's Business Entity Search API (free, real-time) to confirm the UEN exists and retrieve the registered business name. This is more reliable than checksum validation because