AI for Collections in Technology: Failed Payments, Invoices and the Suspension Decision
A technology company that bills by subscription keeps delivering while the money is late. The product runs, support answers, and every day of delay adds cost rather than deferring cash. That is what separates this ledger from a trade debt book, where the goods have gone and payment is the only open question. The strongest lever you hold, switching the service off, is also the most destructive, and its existence warps every conversation held in front of it.
One ledger, two failure modes
Card paying customers fail mechanically and silently. A charge was attempted, something at the issuer said no, and the only trace is a line in a payments log that nobody reads.
Invoiced enterprise customers fail procedurally and humanly. A payment run falls on a fixed day, an approver is on leave, a purchase order has exhausted its value, a query was raised internally and never relayed to you. Someone always knows why, and will explain if you reach them.
Those two populations need different detection, different actions and different owners, which is why one list sorted by days overdue is useless. It puts last night's soft decline beside a disputed implementation invoice from the spring.
When a card fails and nobody is told
In most subscription businesses the largest single leak of recurring revenue is not bad debt. It is payments that were going to succeed and did not: a card that expired, an issuer declining for insufficient funds that would authorise days later, a fraud control reacting to a recurring charge, a card closed when the billing contact left.
None of that is a credit judgement, and a model has the signal to tell the cases apart: the decline reason, the payment history, the point in the month, how near expiry sits. The output is not a score but a decision: retry this one, ask that one for a new card, treat the third as a question about ability to pay.
The retry pattern is a design decision
Most retry schedules were inherited: whatever the billing system shipped with, plus an adjustment somebody made in a bad quarter. The questions worth deciding are how many attempts, how far apart, whether to align with pay dates, and what each message says.
The right answer differs by cause. Insufficient funds argues for waiting and retrying near month end, an expired card for asking immediately for new details instead, a suspected fraud block for a message that explains the charge rather than asking for money. There is also a ceiling, because every extra attempt costs goodwill and a customer who was always going to pay eventually reads the sequence as harassment.
Churn you did not choose
A customer who wanted to stay and left because a payment failed is a different event from one who decided to go, and reported together the first disappears. Measure it on its own and attribute it: expired card, hard decline, no response to the update request. That tells you whether to fix the retry logic, the email, or the card update flow in the product.
What has to be true before an invoice can be paid at all
An enterprise invoice can be perfectly correct and structurally unpayable. The purchase order reference is missing, it went to whoever signed the contract rather than to payables, it needs submitting into a procurement portal somebody was given credentials for once, or your company is not set up as a supplier. Chasing that as a collections matter wastes months, when it can be caught before issue by comparing what the customer's paperwork requires against what you are about to send.
For balances already outstanding, the work is reading the replies. Portals and shared payables inboxes produce text containing the answer: a submission reference, a rejection reason, the approver it sits with.
The usage invoice that is correct and still disputed
Consumption billing produces something trade debt does not have: an invoice that is arithmetically right, contractually right, and far larger than the customer planned for, because a team ran a backfill or left a test environment running.
The first message back is rarely a refusal, and treating it as one manufactures the dispute you feared. Separate the customer asking what happened from the one asking for a credit and the one declining to pay, because only the last is collections work. For the first, the answer is an explanation: which account, which period, what changed since the last invoice, which contract term applies. Better still, catch the spike as it happens, so the contact is a warning and not a bill.
Seats, amendments and the credit a salesperson promised
Behind a surprising share of overdue balances sits an entitlement question nobody settled. The customer counts fewer seats than you invoiced, a mid term amendment changed the price and billing kept the old one, or a credit promised verbally was never raised. The customer pays what was agreed while you chase what you think is owed.
Those documents exist, spread across a contract repository, a sales tool and somebody's mailbox. An agent that reconciles them before a chase goes out prevents the worst outcome here, a dunning email sent to a customer who is right.
Turning the service down before switching it off
The option to restrict access is why this book behaves unlike any other, and the fastest route from late payer to former customer with a grievance. AI should prepare that decision and never take it: the notice the contract requires, who uses the service and how heavily, whether the amount is disputed, whether anyone has yet spoken to a human. Then a named person decides, and the record shows that they did.
Build the middle ground first: a read only mode, a downgrade, or new users blocked while existing ones keep working, each applying pressure without removing what the customer's operations depend on. The notice has to say what stops, when, and what reverses it, because a warning the customer cannot act on is only a threat.
When an open balance meets a renewal date
Eventually an unpaid invoice and a renewal land in the same week, the point of most leverage and most risk, because what is at stake is not one invoice but the next term of revenue.
The account owner and the finance owner need one picture before either speaks: the balance, its age, the queries behind it, and whether this is cash timing or dissatisfaction showing up as slow payment. An agent produces that brief reliably. It should not draft the ultimatum, because tying a renewal to a balance is a commercial decision with a signature on it.
Matching the money when the payment tells you nothing
Cash arrives by every route: card settlements batched with fees netted out, a treasury transfer carrying no reference, a portal payment covering several invoices, a payment net of withholding that will never equal the invoice. Matching is pattern work, and the signals are amounts, dates, payer names, partial references like "INV 4471 PART", and how this customer has paid before. Duplicate records such as "Northwind Ltd 2" are usually why a receipt looks unmatchable.
Allocate automatically only where confidence is high and the amount reconciles exactly, and propose the rest to a person with the reasoning visible. Set allocation order by policy, not by the model, because which invoice a part payment clears changes ageing, disputes and what you chase next.
Terms decided before the deal closes
Some balances were always going to be late, and the decision happened at signature: annual terms for a company that pays quarterly, extended terms conceded to win a deal, no deposit on a large first commitment. At quote stage, flag the terms being offered against how comparable customers have actually paid, as a prompt to a deal desk rather than a veto.
Resellers are a third pattern worth separating, because the partner rarely pays before the end customer has paid them. Your overdue balance is a report on someone else's collections process, and the lever is the partner agreement rather than the reminder.
Who contacts the customer, and which balances to let go
In most technology companies three parties chase a late payer independently: the account manager who wants the renewal, the finance team working the ageing report, and an automated sequence nobody has read recently. Decide who owns the chase for each segment before automating anything, and let every system see what the others have sent.
Self serve balances can run almost entirely automatically. Named accounts should never receive an automated message the account owner has not seen, so let AI draft and schedule while the relationship owner holds a short veto window. Some balances also cost more to pursue than to forgive, and a model can surface those against a policy and clear them in a batch with a reason recorded.
Where AI fails here
It cannot tell you why a customer is not paying when the reason was never written down. If the cause is a champion who left, a budget cut, or a quiet decision to move at renewal, no document reading finds it and a phone call does.
It is confidently wrong about entitlement when your own records disagree. Where the billing system, the contract and the order form tell three stories, a model picks one and argues it well, which is worse than no answer. These disputes need a human conclusion.
None of it survives a billing system that is wrong. If invoices leave with the incorrect price, the wrong contact and no purchase order, AI applied to collections is a faster way of chasing your own mistakes.
Start with the money that leaves by accident
Start with failed card payments. The segment is self contained, the volume is high, and the result shows up in retained revenue within a billing cycle or two. Instrument it before you change it, then alter one thing at a time: routing by decline reason, then timing, then the messages.
Then take the invoices that cannot be paid because something administrative is missing, and measure how many overdue balances are explained that way before building anything. Leave suspension, renewal leverage and anything that speaks to a named account until the first two work and your people trust the output. If a view of how that sequencing applies to your book would help, Adopt AI Partners is at hello@adoptaipartners.com.