You've built a clean onboarding flow. Customers enter tax ID, upload business registration, confirm address. It works in your home market. Then you sign your first customer in Singapore, and the form fails at field three because IRAS requires a different ID format than your Malaysia customer provided. Your second Indonesia client gets stuck because NPWP validation happens after document upload, not before—and she's already rejected the form twice. This isn't a friction problem. It's a design problem. Regional tax rules don't converge; they branch. A single linear onboarding process breaks because Malaysia's MyInvois, Singapore's IRAS, and Indonesia's NPWP have different validation gates, sequencing requirements, and document rules. You can't fix this with one form. You need conditional flows that detect location and route customers through the right steps in the right order. Where Single Processes Break: Three Real Divergences Tax ID collection looks identical on the surface. Every customer needs a tax number. But the rules underneath are incompatible. Malaysia: MyInvois and Real-Time Validation Malaysia's LHDN (Inland Revenue Board) requires invoices to pass MyInvois validation before they're legally issued. Your customer's tax ID—their identification number (usually 12 digits, format: XXXXXXXXXX-XX)—must validate in real time against the LHDN database during onboarding. If validation fails, the customer can't issue invoices at all. The sequence matters: tax ID first, then business registration, then bank details. Why? Because MyInvois won't accept an invoice from a business unless that business's ID has already cleared. Singapore: IRAS ID and UEN Binding Singapore requires a Unique Entity Number (UEN), which is the customer's IRAS registration number. Unlike Malaysia's real-time validation, Singapore's IRAS number comes from the Accounting and Corporate Regulatory Authority (ACRA) first. You can't validate IRAS ID until the business is registered with ACRA—and ACRA registration takes days. This means your onboarding flow must handle a gap state: customer enters UEN, but ACRA records may not be live yet. Singapore customers can't proceed immediately. They need a "pending verification" step that other countries don't require. Indonesia: NPWP and Tax Filing History Indonesia's tax ID (NPWP—Nomor Pokok Wajib Pajak) is 15 digits and controlled by the Directorate General of Taxes (DJP). Validation is harder than Malaysia's real-time check: the customer's NPWP must exist in the DJP database, AND the customer must have filed at least one tax return to be eligible for automated invoicing in most systems. The ordering is inverted from Malaysia and Singapore: you collect NPWP first, but you can't activate invoicing until you've confirmed the customer's tax filing history. This often requires document upload (a copy of the last tax return filing receipt) before the system considers the customer "ready." A single linear onboarding process cannot satisfy all three because the validation gates, sequencing, and document requirements are not just different—they're incompatible. Malaysia needs real-time ID validation before anything else. Singapore needs a pending state for ACRA registration. Indonesia needs tax filing history proof before activation. The Cost of Getting This Wrong When you force all customers through one path: Malaysia customers get blocked: Their MyInvois validation fails because the system doesn't know how to check LHDN rules. Invoices sit unsigned. Support escalations spike. Singapore customers wait indefinitely: They enter a UEN that won't validate for days. Your system rejects the form. They abandon onboarding or call support, adding 15–20 minutes per customer. Indonesia customers drop at document upload: They don't understand why you need tax filing history. The form feels broken. You lose 20–30% of Indonesia sign-ups before they finish. At 10 new customers per month across three countries, that's 1–2 hours of support overhead per cycle, plus 3–5 lost deals. Over a year, one broken onboarding costs you ₱40K–80K in support labor and lost revenue. Build Conditional Flows Instead: The Three-Path Model Design onboarding as three separate flows, not one. The customer's registration country triggers which path they enter. Each path matches the actual rules. Path 1: Malaysia (MyInvois) Step 1: Detect country and set context Customer selects "Malaysia" at signup. System loads Malaysia-specific validation rules and document requirements. Step 2: Collect and validate tax ID first Ask for tax ID (format: XXXXXXXXXX-XX). Call the MyInvois API or your invoicing platform's LHDN validation endpoint in real time. If valid: proceed. If invalid: show specific error ("This ID does not match LHDN records. Check the format and try again.") Do not proceed until this passes. This is a hard gate. Step 3: Collect supporting documents Business registration (SSM certificate). Authorized signatory ID (only for GST registrants;