Invoice rejection isn't a billing problem—it's a data collection problem that lands in your inbox three weeks late. A client sends their SST number as "SST12-34567" when it should be "12-34567". Your accountant flags it. You send a correction request over email. They don't reply for four days. The invoice sits unpaid while you chase format rules nobody told them about in the first place. The fix is simpler than it sounds: validate tax IDs on WhatsApp before you ever generate an invoice. Collect NPWP (Indonesia), SST (Malaysia), ABN (Australia), and other regional identifiers in a conversational flow that checks format, handles errors, and stores valid data where your invoicing tool can find it. No rejections, no back-and-forth, no payment delays. Why tax ID validation fails without gatekeeping Most teams ask for tax IDs after the sale closes. A prospect books a call, signs a contract, receives an invoice—and only then do you ask for their NPWP or SST. At that point, they're annoyed, distracted, or genuinely confused about what number goes where. They type it wrong. Your invoicing software either rejects it silently or accepts it and your accountant catches the error during reconciliation. The cost compounds: Invoice delay: Rejection forces a reissue, pushing cash collection back 5–10 days. Compliance risk: Malaysia's SST (Service and Sales Tax) and Indonesia's e-Faktur system require exact tax ID matching. Wrong format = the invoice never registers with the tax authority. Manual reconciliation: Your finance team spends 15 minutes per invoice correcting data instead of closing the books. Audit exposure: Mismatched records between your invoicing software and the tax authority create gaps that auditors flag. Validation on WhatsApp flips the order: collect and verify the tax ID before the invoice is ever generated. The client sees immediate feedback ("That SST number looks right" or "That format doesn't match—try again"), and your invoice pipeline only receives clean data. Validation rules for NPWP, SST, and ABN Each regional tax ID has a specific format. Enforcing the rules at collection time stops bad data from entering your system. NPWP (Indonesia—Nomor Pokok Wajib Pajak) Format: 15 digits, no spaces or hyphens. Example: 123456789012345 . Check: First digit is never 0. Digits 9–12 contain branch code (usually 001 for head office). Validation rule: Length = 15, all numeric, first digit ≥ 1. Error message: "NPWP must be 15 digits, starting with 1–9. Please re-enter." SST (Malaysia—Service and Sales Tax) Format: 12 digits: RRDDMMSSNNNNN (registration date + unique number). Often written as 12-3456789-123 but stored without punctuation. Check: Digits 1–6 represent a valid date (RRDDMM, where RR = year, DD = day 01–31, MM = month 01–12). Validation rule: Length = 12, all numeric. Day and month values within range. Error message: "SST must be 12 digits (e.g., 123456789123). The first 6 digits should be a valid date. Please check and re-enter." ABN (Australia—Australian Business Number) Format: 11 digits, no spaces. Example: 12345678901 . Check: Includes a check digit (position 1–2 is weighted checksum against positions 3–11). Validation rule: Length = 11, all numeric. Apply ABN checksum validation algorithm (weighted modulo 89). Error message: "ABN must be 11 digits. The checksum didn't validate—please double-check and re-enter." Store all tax IDs in normalized form (no spaces, hyphens, or punctuation) so they match across your invoicing , accounting , and CRM systems . Building the WhatsApp intake flow A tax ID validation flow runs in three stages: collection, validation, and storage. Here's how to build it using Orin's unified messaging with built-in AI or a no-code automation layer. Stage 1: Trigger and context The flow starts when a client signals they're ready to invoice. This could be: A booking confirmation on your calendar. A contract signature via e-signature . A manual tag in your CRM ("Ready to Invoice"). A customer initiating a WhatsApp conversation with a keyword (e.g., "Send Invoice"). The bot sends an opening message with context: "Hi Sarah! Before we send your invoice, we need to verify your tax details. Are you registered in Indonesia (NPWP), Malaysia (SST), or Australia (ABN)?" The client selects one. The bot then branches to the correct validation rule set. Stage 2: Collection with inline validation Once the client selects their region, the bot requests the tax ID with clear formatting instructions: "Please enter your 15-digit NPWP (no spaces or hyphens). Example: 123456789012345" The client sends the ID. Your automation immediately checks it against the validation rule: Valid: "Thanks! I've saved your NPWP. Your invoice is ready to send." → Proceed to Stage 3. Invalid format: "That doesn't look right. NPWP is 15 digits, all numbers. You sent: 12345678901234 (14 digits). Please try again." Invalid date range (SST only): "The first 6 digits should be a valid registration date (YYMMDD). You sent: