Selling over WhatsApp in Indonesia works until tax time arrives. The moment you issue an e-Faktur (electronic invoice) to a business buyer, you've entered the formal tax system. You now need their NPWP (Nomor Pokok Wajib Pajak—tax ID), you must validate it, and you must record it in your digital submission to the tax authority. Miss a single step, and your invoice won't be accepted by the buyer's accounting system, your cash flow stalls, and the tax authority flags it later. The problem is that most WhatsApp-plus-CRM setups treat tax compliance as a back-office task. It's not. It needs to happen at point of sale—when the customer first agrees to buy. This guide walks through the real workflow: how to collect NPWP in the WhatsApp conversation itself, how to verify it before confirming the order, and how to route that data into your invoicing system so e-Faktur issues cleanly the first time. Why NPWP collection matters more than you think Indonesia's tax authority (DJP) publishes a public NPWP registry. When you issue an e-Faktur to a buyer, the system cross-checks the NPWP you've recorded against that registry. If the number is wrong, rejected, or missing entirely, the invoice bounces—not immediately, but when the buyer tries to input it into their own accounting software or claim input tax credit. Here's what actually happens in practice: Day 1: You send a WhatsApp invoice. Customer says "OK, I'll pay." You record it in your system. Day 3: Payment arrives. You issue e-Faktur in your tax accounting software. Day 5: Buyer's accountant tries to input your invoice into their system. The NPWP doesn't match their records, or it's formatted wrong. Invoice rejected. Day 6-10: Back-and-forth on WhatsApp, email, and calls. You reissue. This time it's accepted, but you've lost a week and burned credibility. The fix is brutally simple: collect and validate NPWP before you confirm the sale. Not after. Building the WhatsApp-to-CRM tax intake flow Most businesses treat WhatsApp as a chat channel, separate from their CRM. But WhatsApp is your primary sales channel for many Indonesian SMBs and resellers—it's where the deal happens. Your CRM should see that conversation in real time, and your tax workflow should be baked into the deal itself. Here's a concrete example using WhatsApp, a CRM with deal tracking , and e-Faktur submission: Customer initiates via WhatsApp. "Hi, I want to buy 5 units of Product X at the quoted price." Your sales rep asks for tax details. "Great! For the invoice, I'll need your NPWP and company name. Do you have that?" Customer provides NPWP. "Yes, it's 12.123.456.789.012-345." (16-digit format.) CRM auto-validates format and checks the public registry. If the format is wrong (too many digits, contains letters, etc.), the system flags it immediately. If the registry lookup fails or returns "inactive," your rep gets an alert. Deal is created in CRM with NPWP and validation status recorded. This becomes the source of truth for invoicing. Once payment is confirmed, e-Faktur is generated automatically. The NPWP field is pre-filled from the deal record. No manual re-entry. e-Faktur is submitted to tax authority and a copy is sent to the customer over WhatsApp. The magic is in step 4: validation at point of sale. Most businesses skip this and pay for it later with rejections and rework. NPWP validation: What you need to check NPWP format in Indonesia follows a strict pattern: XX.XXX.XXX.X.XXX.XXX. That's 16 digits with embedded periods. Each section means something (region, sequence, type of business), but for your purposes, you need to check: Format: Exactly 16 digits (periods are stripped by the system). If the customer gives you 15 or 17 digits, it's wrong. Active status: The DJP database is public and queryable. Some online tools and accounting software can check this in real time. If the status shows "inactive" or "suspended," you cannot issue a valid e-Faktur to that NPWP. The buyer's accountant will reject it. Company name match: Cross-check the company name the customer gave you against the name registered to that NPWP. Mismatches (PT vs. Toko vs. CV prefixes, spelling, abbreviations) are red flags and often cause downstream rejection. If you're using a CRM with built-in automation , this validation should happen silently in the background. Your rep doesn't need to know the technical steps—they just see a green checkmark or a warning flag in the deal record. Invoicing platforms that enforce the workflow Not all accounting and invoicing software is built for Indonesian e-Faktur compliance. Many international platforms (QuickBooks Online, FreshBooks, Xero) offer Indonesia modules that are afterthoughts—they don't integrate deeply with your sales process. They're designed to issue invoices at the end of the cycle, not to enforce tax data collection at the start. Look for tools that: Integrate with your WhatsApp inbox so customer conversations are visible without switching apps. Make NPWP a required f