Your accounting software sends the invoice, marks it sent, and moves on. The customer sees it, maybe opens it on mobile, maybe forwards it to accounting—and then nothing. Three days later, you send a reminder. A week later, another. By day 30, the invoice sits unpaid while you chase the customer by email, Slack, and eventually phone. The problem isn't that reminders exist. The problem is that they're treating a workflow failure like a reminder failure. Between invoice send and bank deposit, something is broken. It might be one of five things, and fixing the wrong one wastes weeks. The five places collections actually fail Before you add another reminder, map where your invoices stall. Each failure point has a different fix. 1. Payment method mismatch (the most common silent killer) You invoice in AUD. The customer's system accepts USD. You accept bank transfer and card. They only use regional payment gateways—local APM (alternative payment method) in Malaysia (FPX, DuitNow), Indonesia (GCash, Dana), or Singapore (PayNow). The invoice arrives. They open it. They can't pay it. They email asking for a payment link. You send one. They use it. Two days later. Three days later. Meanwhile, you've already sent your first reminder. This happens more in Southeast Asia than anywhere else because of fragmented payment rails. Fix it by: Embedding a dynamic payment link in every invoice that detects the customer's region and shows only local methods Recording their preferred payment method in your CRM before invoicing, not after Testing the payment path manually before sending the first invoice in a new region 2. Tax code errors that block payment processing Malaysia requires SST IDs (Service and Sales Tax). Indonesia requires NPWP. Singapore requires GST registration or exemption status. If the tax ID is missing, incomplete, or formatted wrong, your accounting software may flag the invoice as non-compliant. The customer's AP system won't pay it. You don't know why. You see it as unpaid and send a reminder. The customer knows it can't be paid until the tax ID is correct. You're both stuck. The fix is validation before send, not after: Collect and validate the tax ID during customer onboarding, not on the first invoice Store it in your CRM linked to the customer record Run a pre-send check: does the invoice have a valid tax ID? If not, pause and prompt instead of sending If the tax ID fails validation (format, registry check, or local rules), flag it as a blocker before the invoice leaves your system 3. Payment plan requests masquerading as non-payment Customer receives a $5,000 invoice. They can't pay it in full. They ask if they can split it. You say yes. Now you have one invoice and multiple promised payments. Your reminders are chasing the invoice, not the payment schedule. The customer thinks they're following the plan. You think they're ignoring you. Fix this by treating payment plans as a workflow, not an exception: When a customer requests a plan, generate separate invoices for each milestone or segment, each with its own due date Link them in your CRM so you can see the full commitment at a glance Automate reminders tied to each segment's due date, not the original invoice date Track which segments are paid and which are outstanding, separately 4. Unpaid reminders sent to the wrong person Invoice goes to the procurement team. Reminder goes to the email address on file—which is a group inbox that rotates staff. Sometimes it lands on someone with approval authority. Often it doesn't. The person with authority never sees it. The person who sees it has no power to pay. You send more reminders to the same address. Nothing changes. Fix this by owning the contact path: During onboarding, collect the AP contact name and role, not just an email Document the approval chain in your CRM: who receives the invoice, who approves payment, who processes it If a reminder bounces or goes unanswered for three days, escalate to the next person in the chain—don't send another copy to the same address Use unified messaging to reach them on the channel they actually use: SMS, WhatsApp, email, or Slack 5. Late invoices arriving after the payment batch has closed Large organizations process payments on a fixed schedule: every Tuesday, every other Friday, once a month. If your invoice arrives on Wednesday, it misses this week's batch. It sits until next batch. You see it as unpaid for a week and send a reminder. The customer received it fine; they're just waiting for the next payment run. You've created artificial urgency where none exists. Fix the timing: Document your customer's payment cycle during onboarding Schedule invoices to send no later than 2–3 days before their payment batch closes If you can't hit that window, batch the invoice with others and send the group together The end-to-end collection workflow that actually works Here's what a closed loop looks like in practice: Customer onboarding: Collect tax ID, validate it against