An AR agent should escalate when the next step changes a commercial commitment, reflects a real dispute, or relies on facts it cannot verify from the approved record. It can handle the routine work around collections: assemble the invoice history, identify a missing remittance reference, prepare a follow-up, and route the case to the right owner. The agent should stop before it promises a concession, changes credit terms, writes off a balance, or presses a customer whose account needs human judgment.
That boundary makes an AR agent useful. Collections teams do not need another dashboard that summarizes aging. They need help moving the ordinary cases forward without allowing a system to create 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 may have paid without including the invoice number. A purchase-order mismatch may be holding up approval. A customer may say the shipment was short, a service was incomplete, or the balance is wrong. Some accounts need a gentle reminder. Others need a person who understands the relationship and the exposure.
Map that queue before choosing a model or drafting a message. For each case, write down the trigger, approved sources, expected output, and owner. A narrow first version might receive an overdue invoice from the ERP, retrieve the approved account and payment history, compare open balances with remittance data, and classify the next step as routine, incomplete, disputed, or high risk.
The useful output is a case record, not an automatic demand. It should show the invoice and amount, the source records consulted, the reason for the classification, a proposed next action, and the owner of any escalation. That gives the collector a place to start and gives a reviewer a way to challenge the agent's conclusion.
Define what the agent may do
The first production scope should be small and explicit. An AR agent can usually prepare work that a collector already performs from established systems:
- Check whether the invoice is open, paid, credited, or already assigned to 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 reviewable case packet.
- Draft a reminder using an approved template and place it in a human review queue.
- Route a routine missing-information case to the account owner or collections team.
The system should use the permissions of the person or service account that owns this narrow job. It should not search unrelated customer records simply because it can reach them. It should not send a message, update a promise-to-pay date, or change an invoice status unless that action is part of the approved workflow and has passed the required review.
This is a control design problem as much as an AI design problem. The U.S. Government Accountability Office's internal-control standards describe segregation of duties as a way to address risks from incompatible authority, custody, and accounting responsibilities. The standard also calls for alternative controls when separation is not practical. Those standards are written for federal entities, but the underlying operating lesson applies to AR systems: do not give one automated path the ability to interpret evidence, change a financial record, and approve its own result. See the GAO Green Book for the source framework.
Escalate for a reason people can act on
An escalation is only useful if it explains what stopped the workflow. Avoid a generic "needs review" status. Build specific reason codes that match the team's policy and route them to an accountable owner.
For example, 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 appears related to the invoice but the amount, entity, date, or remittance evidence conflicts.
- The customer has a legal, insolvency, fraud, executive-relationship, or account-hold flag under the team's existing policy.
- Required records are missing, stale, unreadable, or inconsistent across the approved systems.
- The agent's confidence falls below the threshold the finance team set for that action.
Each escalation should preserve the original records and state the policy condition that triggered it. A collector or credit manager needs to know whether the issue is 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 human 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 decisions. They deserve a named owner, even when the agent has prepared most of the evidence.
Treat exceptions as product requirements
The happy path is straightforward: invoice open, contact correct, payment status clear, reminder approved. Production failures live in the rest of the queue.
Decide what happens when a customer account has merged, when two invoices match one payment, when a payment arrives in a different currency, or when the order system and ERP disagree. Decide what the system does when an approved data source is unavailable. In most cases, it should leave the financial record unchanged, create an exception with the source references it did find, and notify the responsible team through the existing queue.
An AI system also needs a documented human-oversight model. NIST's AI Risk Management Framework describes voluntary practices for defining roles and responsibilities, documenting system scope, and assessing human oversight. Its core is not a collections policy, but it is a useful checklist for making the agent's limits testable. The NIST AI RMF Core is the primary source.
Make the exception record operational. Include the case ID, inputs and versions used, classification, confidence or rule result, proposed action, reason code, recipient, reviewer decision, and final outcome. That record helps the team audit a mistake, revise a policy rule, and measure where the workflow still needs people.
Build beside the current process
Start with one segment of the aging queue, such as invoices that are overdue by a defined number of days with no account hold. Run the agent beside the existing collection process. It can prepare a packet and draft the next message while a collector compares its recommendation with the normal workflow.
Use that period to test the cases the team remembers: partial payments, duplicate invoices, disputed shipments, customers with multiple entities, and long-running promises to pay. Measure preparation time, reviewer acceptance, correction rate, routing accuracy, and the number of cases that correctly stopped. Track a safety measure alongside throughput, such as messages withheld for a valid escalation or incorrect case classifications.
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. For AR, that means the agent should support the collector's process instead of creating a parallel process that finance cannot explain or govern.
Once the review data shows that routine cases are reliable, expand one bounded action at a time. You might allow a pre-approved reminder to send after review, then 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 explicitly designed the policy, permissions, evidence standard, and audit trail for those decisions.
The result is a collections workflow that spends less time finding records and chasing avoidable blockers. It also knows when to stop. That is the difference between an AR agent that helps the team collect cash and one that creates a new exception queue for finance to clean up.