AI agents for accounts receivable: collecting cash without breaking the ledger

We’ve made the case that accounts payable is the faster, safer enterprise agent win than the consumer booking bot everyone demos. Receivables is the same argument turned around, and the stakes are higher. Payables is money you owe on your own schedule. Receivables is money you’ve already earned, sitting in someone else’s bank account, aging one day at a time while a person in a spreadsheet decides who to email next. Every extra day of Days Sales Outstanding is working capital you financed for a customer who didn’t ask you to.

The receivables function is not one job. It’s a chain: invoice, then apply the cash when it arrives, then chase what’s late, then resolve the short-pays and deductions, then decide who gets credit in the first place. Each link has a different shape, a different failure mode, and a different answer to the only question that matters for automation. Can a machine do this, or does a human have to sign? Get that split wrong and you either leave the agent doing nothing useful, or you let it post cash to the wrong invoice and spend the next quarter unwinding it. This post is the honest map of where an agent earns its keep in AR, and where it must stop.

The chain, and where the time goes

Order-to-cash on the receivables side runs invoicing → cash application → collections → deductions and disputes → credit. The invoice itself is the easy part; billing engines have generated invoices from orders for years. The pain lives downstream, in three places:

Cash application, matching incoming payments to open invoices and posting them to the AR subledger. It is historically the most manual and error-prone step in the entire function, because the payment and the explanation of what it’s for arrive separately, in different formats, on different days.
Collections: deciding who to chase, when, on what channel, in what tone, and following up until they pay. Done by hand, it’s triage by gut feel: the loudest overdue account gets the call, not the one most likely to respond.
Deductions and disputes: the customer paid less than the invoice, and now someone has to figure out why, whether the short-pay is valid, and who owns fixing it.

These are the links where an agent changes the economics, and they’re worth taking one at a time, because the automation story is different for each.

Cash application: the match is the whole game

Here’s the mechanic that makes cash application hard. A payment shows up (a wire, an ACH, a check swept through a bank lockbox) and it’s just money. The remittance, the data that says which invoices the payment covers, arrives on a separate path: an EDI 820 file from a large buyer, a PDF emailed by a mid-market customer, a spreadsheet downloaded from a customer AP portal, or an addendum record riding along with an ACH. For a lockbox check, the bank scans the batch and transmits a data file overnight, so the cash exists in your account before you have any structured idea what it’s for.

The job is to reconcile the two. And the matching is rarely clean:

One-to-one, one payment, one invoice. Trivial.
One-to-many: one wire covers twelve invoices, and the remittance lists all twelve. Straightforward if the remittance is structured, miserable if it’s a PDF.
Partial and short-pay, the payment covers part of an invoice, or several invoices minus a deduction. Now you’re not matching, you’re investigating.

This is exactly the shape a well-built agent is good at: parse messy remittance from any channel, propose the match against open invoices, and flag the ones it can’t resolve. When the buyer sends a clean EDI 820, straight-through match rates get very high: the 820 is the gold standard precisely because it carries invoice references, amounts, and adjustment codes in a machine-readable format. The agent’s real value is the long tail: the emailed PDF, the portal export, the payment with no remittance at all, where the alternative is a human reading a document and typing invoice numbers into the ERP.

A retriever-grounded agent action for this looks, in shape, like the following: illustrative, not a literal API, because the object names depend on whether your subledger lives in Revenue Cloud Billing, an ERP, or a specialist AR platform:

{
  "action": "proposeCashApplication",
  "payment": {
    "id": "PMT-88213",
    "amount": 48250.00,
    "currency": "USD",
    "received": "2026-08-31",
    "channel": "ACH",
    "remittance_source": "email_pdf"
  },
  "proposed_matches": [
    { "invoice": "INV-10432", "applied": 25000.00, "confidence": 0.98 },
    { "invoice": "INV-10455", "applied": 22000.00, "confidence": 0.97 },
    { "invoice": "INV-10460", "applied": 1250.00,  "confidence": 0.61,
      "flag": "short_pay", "variance": -1750.00,
      "reason_code_guess": "damaged_goods" }
  ],
  "unapplied": 0.00,
  "requires_review": true
}

Notice the last line. Two of the three lines matched cleanly and could post automatically under a confidence threshold. The third is a short-pay with a guessed reason code, and that’s the boundary. The agent can propose it; a human decides whether a $1,750 deduction for damaged goods is valid or a customer trying it on. Which brings us to the rule that governs the whole function.

Where the human still signs

Cash application posts to the general ledger. That makes it a controlled process, and no amount of model confidence changes the control. The line to hold:

Auto-post the clean matches. High-confidence, fully-applied, no-variance matches, one-to-one and structured one-to-many, can post without a human, under a threshold you set and can defend to an auditor.
Route everything else to a person. Short-pays, unapplied cash, on-account postings, and any match below the confidence threshold go to a queue where a human approves the posting. The agent has done the expensive part, finding the likely answer, but the segregation-of-duties principle that keeps AR auditable says the person who investigates a deduction shouldn’t also be the one who silently writes it off.

Three decisions in AR are never the agent’s to make alone, no matter how good the automation gets:

Writing off bad debt. Moving a receivable to bad debt is a P&L event. An agent can surface the candidates and assemble the evidence; a human authorizes the write-off.
Approving or extending credit terms. More on this below: an agent can score and recommend, but granting a credit line or releasing a credit hold is a risk decision that sits with a credit manager.
Escalating to an agency or legal. Handing an account to third-party collections or legal has consequences an agent can’t weigh. It proposes; a human commits.

This is the same discipline we’ve written about for the financial close, where the agent reconciles but never crosses the SOX boundary. Receivables is the same instinct: automate the investigation, gate the posting.

Collections: triage, not a mail merge

Manual collections is triage by volume: whoever shouts loudest, or whoever the collector happens to remember, gets worked. That’s backwards. The account worth a call today is the one where a call today changes whether you get paid this month, and that’s a prediction, not a to-do list.

An agent restructures collections around that prediction. Grounded in payment history and open AR, it can prioritize the worklist by expected impact, then run the outreach cadence, the dunning sequence, choosing timing, channel, and tone per account instead of firing the same template at everyone. A customer who always pays on day 35 doesn’t need a day-31 threat; a serial late-payer with a big balance needs an early, firm, specific nudge. Vendors in this space report meaningful DSO reductions and lift in collection rates from exactly this shift from blanket reminders to prioritized, personalized outreach, the gains come from working the right accounts, not from sending more email.

The dunning cadence an agent can own looks like this:

Pre-due reminder for accounts with a history of slipping, a light touch before anything is late.
Day-1 to day-7 friendly nudge with the invoice attached and a payment link, on the channel that account responds to.
Day-15 to day-30 firmer, specific: the amount, the age, the terms, an offer to resolve any dispute.
Beyond terms: escalation drafted by the agent and approved by a human before it goes to a manager, an agency, or legal.

Two guardrails make this safe rather than reckless. First, tone and content are bounded: the agent drafts within templates and a policy, and a payment agent talking to your customers is exactly the kind of natural-language surface that needs the layered controls that keep an agent in scope. Second, and this is the one teams get wrong: the agent must not be able to offer a concession to close the conversation. A collections agent that can grant a discount, waive a late fee, or extend terms to make an angry customer go away is a P&L leak with a friendly voice. This is the same failure mode as a retention agent that resolves churn by giving away the discount, the agent drafts the save, a human authorizes anything that costs money.

Deductions: the short-pay is a workflow, not an error

Deductions are where receivables bleeds. A customer pays $48,250 against $50,000 of invoices and takes a $1,750 deduction for damaged goods, a pricing discrepancy, a promotional allowance, or a shipping claim. In high-volume industries, manufacturing and consumer goods especially, deductions run to thousands of small events a month, and the unglamorous truth is that a lot of invalid deductions get written off simply because nobody had time to dispute them inside the window.

This is agent-shaped work. Given a short-pay, an agent can classify the deduction by reason code, pull the supporting documents (the proof of delivery, the pricing on the order, the promotional agreement) assemble the case, and route valid disputes to the customer and invalid ones to a collector for recovery. It’s structurally the same evidence-hunt-against-a-deadline problem as chargeback representment, where the evidence lives outside the CRM: the agent’s job is to gather and assemble fast, and a human’s job is to decide the ones that are ambiguous. The value isn’t the classification; it’s that deductions stop expiring unworked.

The front of the O2C chain is credit, deciding whether to extend terms to a customer and how much. Agentic credit management is real and moving fast: online credit-application intake, automated scoring against policy, continuous portfolio monitoring that watches for behavioral shifts in payment patterns, and automatic order holds when risk crosses a threshold. Handled well, standard accounts get scored and approved without a human, and only the complex enterprise exceptions route to a credit analyst.

But credit is a risk decision, and the automation boundary is the same as everywhere else in AR: the agent scores, monitors, and recommends; a credit manager owns the line that grants a limit or releases a hold. An agent that silently raises a customer’s credit line based on a pattern it liked is an agent making a lending decision, and that’s not a decision you want made by something that can’t be deposed. Continuous monitoring that flags a deteriorating account for review is the win. Continuous monitoring that acts on it unsupervised is how you find out your bad-debt exposure grew while everyone trusted the machine.

Where Salesforce fits, and where it doesn’t

If your quote-to-cash already lives on Salesforce, a lot of this has a natural home. Revenue Cloud, now Agentforce Revenue Management, carries billing, invoicing, payments, and collections natively, generating invoices directly from orders and billing schedules, which means the receivable and the customer relationship sit in the same platform the collections agent already understands. Data Cloud gives that agent a grounded, unified view of payment behavior and open exposure across every source, so prioritization isn’t guessing. Agentforce runs the collections outreach and the deduction triage as governed actions, and Flow Orchestration coordinates the human approvals where the ledger demands them.

Be honest about the seam, though. Many enterprises keep the AR subledger and the hard cash-application matching in an ERP or a specialist platform (HighRadius, Billtrust, Versapay, Esker, Emagia) that has spent years on remittance capture and match rates. When that’s your reality, the right architecture isn’t to rebuild cash application in Salesforce; it’s to let the specialist own the match and posting, and let Salesforce own the customer-facing collections relationship, the dispute conversation, and the analytics, integrated, not duplicated. Pretending Salesforce is your AR engine when your ledger lives in NetSuite or SAP is the same category error as pretending it’s your supply-chain planning optimizer. Draw the boundary where the systems are.

What to build first

Don’t try to automate the whole chain at once. The fastest, safest win is cash application on the messy channels, the emailed PDFs and portal exports where humans currently retype invoice numbers, with auto-post gated to high-confidence clean matches and everything else queued for approval. It’s high-volume, it’s provably auditable, and it frees the exact people you then want running the judgment calls. From there, collections prioritization and drafted dunning is the next layer, because it compounds: every day of DSO you pull back is working capital returned. Deductions and credit come after, once the team trusts the agent on the money it can already see.

Model the savings before you commit: the hours reclaimed from cash application and deduction triage are the concrete part of the business case, and our automation savings calculator is built for exactly that kind of process math. The receivables agent that survives production is the one that took over the investigation and left the postings, the write-offs, and the credit decisions to the humans who can answer for them. That’s not a limitation of the technology. It’s what makes it safe to turn on.

Understanding the basics

Can an AI agent do cash application automatically?

Partly, and the split matters. An agent can parse remittance from any channel (EDI 820, emailed PDF, portal export, ACH addenda) and propose matches against open invoices, including one-to-many and partial matches. High-confidence, fully-applied, no-variance matches can post automatically under a threshold you set. But short-pays, unapplied cash, and low-confidence matches should route to a human for approval, because cash application posts to the general ledger and segregation-of-duties controls require it.

What is the difference between AR and AP automation?

Accounts payable automates money you owe: invoice capture, three-way match, and payment on your own schedule. Accounts receivable automates money owed to you (cash application, collections, deductions, and credit) where the timing is the customer’s, not yours. AR is higher-stakes for working capital because every day of Days Sales Outstanding is cash you’ve earned but haven’t collected. The automation discipline is similar: let the agent do the investigation, gate the postings and money decisions to a human.

What should a collections agent never be allowed to do?

Offer a concession to close a conversation. A collections agent that can grant a discount, waive a fee, or extend terms to placate an angry customer is a direct P&L leak. It should prioritize accounts, draft and send bounded dunning outreach, and assemble disputes, but any decision that costs money (a write-off, a credit-term change, an agency or legal escalation) must be authorized by a human.

Deciding which parts of your order-to-cash an agent should own and which stay with a person is a normal first conversation for our team. Talk to us, we’ll map your AR chain against where the ledger needs a human, before you automate anything.