An AR agent should escalate when the next step changes a commercial commitment, reflects a real dispute, or rests on facts it cannot verify from the approved record. The routine work around collections is fair game: assembling the invoice history, spotting a missing remittance reference, preparing a follow-up, routing the case to the right owner. It should stop well before it promises a concession, changes credit terms, writes off a balance, or leans on a customer whose account needs human judgment.
Draw that boundary and the agent earns its place. Collections teams do not need another dashboard summarizing aging. They need help moving the ordinary cases forward without a system creating a customer, revenue, or policy problem in the name of speed.
Begin with the collection queue
An overdue invoice is rarely one simple condition. A buyer paid but left off the invoice number. A purchase-order mismatch is holding up approval. A customer says the shipment was short, the service was incomplete, or the balance is wrong. Some accounts need a reminder. Others need a person who understands the relationship and the exposure.
Map that queue before you pick a model or draft a message. For each case, write down the trigger, the approved sources, the expected output, and the owner. A narrow first version might take an overdue invoice from the ERP, pull the approved account and payment history, compare open balances against remittance data, and classify the next step as routine, incomplete, disputed, or high risk.
The output should be a case record. Show the invoice and amount, the source records consulted, the reason for the classification, the proposed next action, and the owner of any escalation. That gives the collector somewhere to start and gives a reviewer something to argue with.
Define what the agent may do
Keep the first production scope small and explicit. An AR agent can usually prepare the work a collector already does from established systems:
- Check whether the invoice is open, paid, credited, or already in a collection workflow.
- Match a payment or remittance reference when the evidence is clear enough to propose a match.
- Gather the purchase order, invoice, delivery record, and prior approved correspondence into a case packet.
- Draft a reminder from an approved template and put it in a human review queue.
- Route a routine missing-information case to the account owner or collections team.
The system runs with the permissions of the person or service account that owns this narrow job. It does not search unrelated customer records because it happens to reach them. It does not send a message, update a promise-to-pay date, or change an invoice status unless that action sits inside the approved workflow and has cleared the required review.
OWASP's guidance on excessive agency is direct about the mechanism: grant the minimum privileges the task needs, run downstream actions in the requesting user's context, and require human approval for high-impact actions. The OWASP write-up on excessive agency covers the security reasoning. In AR the high-impact list is easy to name. Anything that moves money, changes terms, or reaches the customer belongs behind an approval.
This is a control design problem as much as an AI design problem. Finance teams already separate who approves a transaction, who has custody of the asset, and who records the entry, because putting all three in one place is how errors and fraud go unnoticed. An agent does not get an exemption from that logic. No single automated path should interpret the evidence, change the financial record, and approve its own result. Where full separation is impractical, add a compensating control such as a reviewer on the final action or a reconciliation somebody else performs.
Escalate for a reason people can act on
An escalation earns its keep by explaining what stopped the workflow. Avoid a generic "needs review" status. Build specific reason codes that match the team's policy and route each one to an accountable owner.
Escalate when:
- The customer disputes the amount, quantity, delivery, contract terms, tax treatment, or service outcome.
- The account asks for a discount, payment plan, credit extension, waiver, settlement, or write-off.
- A payment looks related to the invoice but the amount, entity, date, or remittance evidence conflicts.
- The customer carries a legal, insolvency, fraud, executive-relationship, or account-hold flag under existing policy.
- Required records are missing, stale, unreadable, or inconsistent across the approved systems.
- Confidence falls below the threshold the finance team set for that action.
Every escalation keeps the original records and names the policy condition that triggered it. A collector or credit manager needs to know whether they are looking at a missing reference, an alleged billing error, or a requested concession. They should not have to reconstruct the agent's path from a paragraph of generated text.
The agent's authority ends there. A person decides whether to issue a credit memo, adjust terms, pause collection activity, accept a settlement, or send a relationship-sensitive response. Those are commercial and policy calls, and they deserve a named owner even when the agent has already assembled most of the evidence.
Treat exceptions as product requirements
The happy path is easy to describe: invoice open, contact correct, payment status clear, reminder approved. Production failures live in everything else.
Decide what happens when a customer account has merged, when two invoices match one payment, when money arrives in a different currency, or when the order system and the ERP disagree. Decide what the system does when an approved data source is unavailable. Usually it should leave the financial record alone, create an exception with whatever source references it did find, and notify the responsible team through the existing queue.
Ambiguous evidence is the failure mode to design against. OWASP's guidance on misinformation recommends grounding outputs in retrieved, verified records and keeping human review on sensitive material rather than trusting a fluent answer. The OWASP write-up on misinformation has the detail. In practice, a proposed payment match should cite the remittance record it relied on, so a collector can reject it in seconds.
The human-oversight model belongs in writing, in the same place as the rest of the collections policy. Name the scope of the workflow, the actions the agent may take, the reviewer behind each escalation reason, and what response time that reviewer owes. Written down, the agent's limits become testable. You can point at a case and say whether the system behaved correctly instead of debating whether the output sounded reasonable.
Make the exception record operational too. Case ID, inputs and versions used, classification, confidence or rule result, proposed action, reason code, recipient, reviewer decision, final outcome. That record is what lets the team audit a mistake, revise a policy rule, and see where the workflow still needs people.
Shadow the current process first
Start with one segment of the aging queue, such as invoices past a defined number of days with no account hold. Let the agent shadow the existing collection process. It prepares a packet and drafts the next message while a collector compares its recommendation against the normal workflow.
Use that stretch to test the cases collectors still complain about: partial payments, duplicate invoices, disputed shipments, customers with multiple entities, promises to pay that have been rolling for months. Measure preparation time, reviewer acceptance, correction rate, routing accuracy, and how many cases correctly stopped. Track a safety measure next to throughput, such as messages withheld for a valid escalation or case classifications that came back wrong.
Sennu's approach to this kind of work is to connect a custom AI system to the systems of record that already run the workflow, then make access controls, auditability, and human review visible in the product itself. For AR that means supporting the collector's process rather than building a parallel one finance cannot explain or govern.
Once the review data shows the routine cases are reliable, widen the scope in small, well-defined steps. Let a pre-approved reminder send after review. Later, permit a low-risk status update with a clear rollback. Keep disputed balances, concessions, credit decisions, and write-offs with people until the business has deliberately designed the policy, permissions, evidence standard, and audit trail behind those decisions.
You end up with a collections workflow that wastes less time hunting for records and clearing avoidable blockers, and that knows when to stop. The second half matters as much as the first. An AR agent without it just hands finance a new exception queue to clean up.