The "you still owe us" email that went to a customer who already paid
Picture the worst version of automated collections: a polite, firm follow-up lands in a good customer's inbox asking for payment on invoice #4471. The customer paid it eleven days ago by ACH. The remittance hit the bank but never got matched in the ledger, and the account rep had logged a side note — "agreed to net-45 on this one" — in a CRM field nobody's draft ever read. Now your AP contact is forwarding the email to their boss with the subject line "is this how they treat clients?"
That single bad send costs more than the invoice. And it's exactly why collections follow-up is such a good first AI workflow for IT and data teams to build — not because dunning is easy to automate, but because the work that makes it safe is the same work that makes every later AI project trustworthy: getting one customer's truth to reconcile across systems before anything is drafted. IBM's Institute for Business Value research on AI capabilities is blunt about this: capability tracks with data reliability, clear process ownership, adoption, and measurement — not with model choice. Collections forces all four into the open on day one.
The reason the data fragments is structural. Invoice status sits in the accounting system. The actual payment sits in the bank feed or the payment processor. The promise-to-pay and the disputed line items live in the rep's CRM notes and a buried email thread. None of these systems was built to agree with the others. The first thing your AI workflow has to do is the unglamorous part: pull those four facts together and notice when they conflict.
Build the packet, not the send button
Here's the scope discipline that separates a useful build from a liability. The workflow's job is to assemble a follow-up packet and draft the language — invoice source, account context, tone calibrated to the relationship, and a named escalation owner. Its job is explicitly not to push external pressure on a partial record. A human approves before anything leaves the building. Those two boundaries — four inputs in, one approval gate out — are the whole design.
What goes in the packet is where the specificity lives. For each open item the AI surfaces: the invoice and its aging, the matched (or conspicuously unmatched) payment, any open dispute or credit memo, the last logged commitment from the rep, and a confidence flag when those don't reconcile. If payment evidence exists but isn't matched, the packet routes to cash application, not to the customer. If a dispute is open, it routes to the account owner. Only clean, reconciled, genuinely-overdue items get a drafted follow-up — and even those wait for a person to hit send.
The hard part is permissions, because financial and customer-communication records sprawl across shared drives, mailbox history, Teams threads, and CRM exports. Microsoft's documentation on Microsoft 365 Copilot data protection architecture is worth reading closely here: AI retrieval has to honor identity, access controls, sensitivity labels, and audit trails. A collections assistant that can read every rep's private notes and every customer's payment terms is a breach waiting for a subpoena. The NIST AI Risk Management Framework gives you the structure to handle this deliberately — map where the data and the harms are, measure the failure modes (the wrongful-dun rate above all), manage the controls, and keep ownership unambiguous. For collections, the harm isn't abstract: it's customer trust and revenue treatment, the two things you can't easily buy back.
Measure the wrongful-dun rate before you measure speed
Most teams instrument this backwards. They track how many follow-ups went out and how fast — the vanity metrics — and ignore the one number that actually protects the business. Start with the metrics that catch the #4471 disaster: invoice-match accuracy (did the AI correctly link payments to invoices?), disputed-item detection rate (did it catch the open disputes before drafting?), and draft correction rate (how often does the human reviewer have to fix what it wrote?). Then add approval cycle time and escalation quality. The win you're shipping isn't fully automated dunning — it's a cleaner handoff to finance and account owners, with the embarrassing sends caught before they happen.
A grounded way to start Monday: pull last quarter's collections follow-ups and audit, by hand, how many went to customers who had already paid, had an open dispute, or had a logged payment-terms exception. That percentage is your baseline wrongful-dun rate, and it's almost always higher than anyone wants to admit. It's also the number your AI workflow has to beat — if a draft assembled from reconciled data can't outperform your current manual process on that single metric, you don't have approval to automate the send yet.
Stand up the guardrails before you let anything touch a customer. Work through AI governance and training so the access controls and approval gates are real, not aspirational, then size the payback with the AI ROI Calculator. PwC's Responsible AI survey makes the point that responsible AI is about practical controls at the point of use — and in collections, the point of use is the moment before a real customer reads a real demand for money.
