How to Automate Collections: A Complete Guide for 2026

Automating collections means automating the whole path from a finished invoice to applied cash, rather than only the reminder emails. Monk is an AI-native invoice-to-cash platform that runs invoicing, portal submission, collections, cash application and dispute routing as one system, which is the only arrangement in which automation compounds rather than cancels itself out. There are five things worth automating: getting the invoice delivered and accepted, the follow-up itself, the handling of replies, cash application so the aging report is true, and the routing of disputes and deductions. There is a sixth category that should stay with a person: concessions, terms changes, serious disputes and legal escalation. Most teams automate the second item, leave the rest manual, and conclude that collections automation does not work.

The reason that conclusion is wrong is arithmetic. If part of your overdue ledger consists of invoices the buyer's system never accepted, no cadence can collect them, because the recipient cannot approve a document that does not exist on their side. If cash application runs days behind, part of every chase list is people who have already paid. Automating messages on top of a wrong list produces more messages and the same cash. Fix what the list is made of, then automate the contact, then automate what happens when somebody replies.

Is the invoice delivered and accepted, or only sent?

An invoice that a buyer's system rejected is not late, because as far as that system is concerned it does not exist.

Across the receivables Monk manages, 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice. Coupa, Ariba, Tungsten, Taulia, Jaggaer, SAP Business Network and a long tail of buyer-specific portals each define what a payable document looks like. The PDF you emailed is a courtesy copy. The payable object is the submission the portal accepted, and acceptance is a separate event with its own timestamp.

Automation here has three parts. The first is submission: pushing the invoice into the right portal in the right format, with the PO number, PO line reference, unit of measure, tax code and remit-to details that portal expects. The second is validation before submission, which catches predictable rejections while they are cheap to fix: a PO that reads each while your invoice reads cases, a legal entity mismatch between Acme Corp and Acme Manufacturing UK Ltd, an expired certificate of insurance, an unverified bank record. The third is acceptance tracking, so a rejection becomes an event with an owner and a deadline rather than a notification in a portal mailbox nobody opens.

What does automating the follow-up itself involve?

It means automating the decision about what to send, to whom and when, rather than the act of sending.

A scheduler firing a reminder at day 3, a firmer one at day 14 and a final notice at day 30 automates typing. It does not automate judgement, because a calendar has no view of why the invoice is unpaid. The version that changes outcomes branches on the state of the invoice. An invoice waiting on a goods receipt gets a request for the goods receipt. One sitting with a named approver gets a message naming the approver, the amount and the date it cleared validation. One with an open dispute gets nothing until the dispute closes, while the rest of that account carries on being chased.

Contact selection deserves the same treatment as message selection. Most ledgers carry one accounts payable address per customer and no record of who replies. Useful automation holds several contacts per account, tracks which respond, detects bounces and quarantines, and moves to the next person rather than repeating into a dead mailbox. It also respects the buyer's payment calendar: if a customer runs payment files on the 10th and the 25th with an approval cut-off three working days earlier, the only chase that can change anything lands before that cut-off.

Who is reading the replies?

Almost nobody automates reply handling, which is why teams that automate sending find their inbox load rises.

Every effective chase produces a reply, and replies arrive in a small number of recognisable shapes: a promise to pay with a date, a request for a copy invoice or a W-9, a portal instruction, a short-pay explanation, a deduction reference, a dispute, an out-of-office with a delegate, a bounce, a redirect to a different person, or a request for a payment plan.

Each has a correct next action that does not require a human decision. A promise to pay is recorded against the invoice with its date, suppresses chasing until two days after that date, and reappears on a list the moment it is broken. A document request is answered by sending the document. A redirect updates the contact record and re-sends. A portal instruction opens a submission task. A dispute stops the chase on that invoice and opens a case with a reason code.

What makes this automatable is context rather than keyword matching. A system holding the invoice, the PO, the submission history, the prior conversation and the payment record can read a two-line email and place it correctly. Monk's Intelligent Collections ingests the context of the conversation, which is what allows a reply to be classified and acted on rather than forwarded to a person to read.

Is your aging report true?

An aging report is only as accurate as your cash application, and unapplied cash makes every downstream decision wrong.

The mechanics are unglamorous and they decide everything. A payment lands as a lump sum covering nine invoices with no remittance advice. An ACH reference field carries the payer's own internal voucher number. A cheque arrives for an amount that matches no invoice, because a deduction was taken. A remittance arrives as a PDF in a different mailbox from the payment. Until each is matched, the invoices stay open, and open invoices get chased.

Automating cash application means matching on more than the reference field: amount combinations across open invoices, customer identity from the bank descriptor, remittance documents parsed out of email attachments and portals, short-pay differences reconciled against deduction codes, and a suggested-rule layer built from the rules you approve. Monk's AI cash application matches around 80% of incoming payments automatically, rising to 95% with suggested matching rules. The rest reach a person with candidate matches already assembled.

Where do disputes and deductions go?

They go wherever a person happens to send them, which is why they are the slowest category on most ledgers.

Monk's measurement is that 39% of cash flow slowdown is caused by edge cases, and disputes and deductions are the largest family within that. The failure is rarely the dispute itself. It is that the dispute lives in an email thread with no reason code, no owner, no value and no review date, so the chase keeps running and the customer concludes nobody is listening. Six months later it reads as a write-off request rather than a correction.

The automatable parts are the routing and the bookkeeping. When a short payment arrives, the difference should be quantified, assigned a reason code, and routed by that code: pricing variances to the account owner, shortfalls and damages to operations, service credits to the customer success owner, tax and entity errors back to billing. The invoice should be split so the undisputed balance keeps aging and keeps being chased while the disputed portion is held, and the review date should escalate on its own when it passes.

What should you deliberately not automate?

Anything that changes the commercial relationship should be a human decision with a name attached to it.

Four categories belong on that list. Concessions come first: credits, write-offs, waived late fees and settlement offers. An automated concession is a policy you did not intend to publish, and buyers share information about which suppliers give ground. Terms changes come second: moving a customer from net 30 to net 45, granting an early settlement discount or agreeing a payment plan changes the value of the account and should sit with whoever owns the margin.

Legal escalation is third. Final demands, agency referrals, credit holds and anything starting a formal process should require an explicit human step, because they are hard to reverse and can put a supply relationship at risk over an invoice that turns out to have been rejected by a portal. Serious disputes are fourth: where the amount is material, the argument contractual or the relationship strategic, the value of automation lies in the preparation rather than the reply.

What are the alternatives?

Several platforms cover parts or all of this cycle, built around different designs and different buyers.

How does Monk handle this?

Monk runs these layers in one place, so the output of each becomes the input of the next.

On delivery, Monk submits and tracks invoices into vendor portals and networks, covering the 92% of enterprise invoices that must be submitted that way rather than paid from an emailed PDF. Acceptance and rejection arrive as events, so a rejected invoice is routed for correction instead of aging into a dunning cycle.

On follow-up and replies, Julia, Monk's AI agent for Intelligent Collections, runs the chasing and the inbound handling. Intelligent Collections ingests the context of the conversation, so a message reflects the invoice state, the submission history and what the customer last said, which is why Julia achieves a 24% higher response rate than standard dunning. Monk resolves 90% of collections with zero human intervention, and cases needing a person arrive with the history attached. Voice Collections is a separate product for accounts where a call is the next step.

On cash and exceptions, Monk's AI cash application matches around 80% of payments automatically, rising to 95% with suggested matching rules, and disputes are captured with codes and owners rather than living in a thread. Monk integrates with QuickBooks, NetSuite, Salesforce, HubSpot and Stripe, along with Slack, Gmail, Docusign, Anrok, Plaid and Mercury. Customers report 26 hours a month saved and a 40% average reduction in DSO. Monk manages more than $2B in accounts receivable, is SOC 2 Type II compliant, and onboarding takes less than one week.

Where should you start?

Audit what your current chase list is made of, then automate in stages so each layer has clean inputs.

This week, take the fifty oldest overdue invoices and sort them into four buckets: never accepted by the buyer's system, accepted but blocked on a missing document or approval, disputed or short paid, and awaiting payment. Count the last bucket: that number is the share of your ledger a reminder can influence, and for most teams it is smaller than expected. Then measure the age of your unapplied cash.

Keep the exclusion list explicit from day one. Write down which accounts, amounts and situations require a person, put it in the configuration rather than in someone's head, and review it monthly. To see delivery, Intelligent Collections, reply handling and cash application run against your own ledger, book a demo.

Frequently Asked Questions

What does collections automation include beyond reminder emails?

It includes invoice delivery and portal acceptance, branching follow-up based on invoice state, handling of inbound replies, cash application so the ledger reflects what has been paid, and routing of disputes to owners with review dates. Reminder emails are one layer of five, and automating that layer alone tends to increase message volume without changing collected cash.

Why does invoice delivery belong in a collections project?

Because an invoice a buyer's system rejected cannot be collected. Most large buyers pay from a submission accepted by their portal, so acceptance is a separate event from sending. Invoices that failed submission look identical to slow payers on an aging report. Confirming acceptance removes a category of overdue balance no amount of chasing would resolve.

How do you automate replies without sending something inappropriate?

By classifying the reply against the context of the invoice and the conversation, then acting only within a defined set of safe actions. Recording a promise to pay, sending a statement, updating a contact and opening a dispute case are reversible and low risk. Concessions, terms changes and legal escalation stay with a person. Write that boundary into the configuration rather than leaving it to judgement in the moment.

Should cash application come before or after collections automation?

Run them together, and treat cash application as the earlier priority if you have to choose. Unapplied cash means part of every chase list consists of customers who have already paid, and those contacts cost credibility with the customers you least want to annoy. Once matching is running, the aging report becomes a reliable input for everything else.

What should never be automated in collections?

Concessions such as credits, write-offs and waived fees, changes to payment terms, formal legal escalation, and serious or contractual disputes. All four change the commercial relationship or are hard to reverse. Automation still helps around them, by assembling the invoice history, the contract term and the delivery record so the person deciding has everything in one place.

How long does it take to see results?

Delivery and contact hygiene changes show up within weeks, because they remove invoices that were never collectable by chasing. Follow-up and reply handling change response rates in the first month. Cash application and dispute routing take longer to reach a steady state, since both improve as rules accumulate. With Monk, onboarding takes less than one week and customers see results in their first month.

Does automating collections damage customer relationships?

It depends on whether the messages carry information. A generic reminder to a customer who has already paid, or whose invoice was rejected by their own portal, damages the relationship. A short message naming the invoice, the amount, the purchase order and the missing item is treated as administration and answered. Fewer, better-aimed contacts tend to improve the relationship.