An AI agent for AR collections is fundamentally a drafting assistant: it reads a customer's aging, payment history, and past correspondence, and drafts a next-action recommendation and a message. What it should never do is decide unilaterally to escalate an account, threaten legal action, or send anything without a human reading it first — the reputational and legal risk of an autonomous collections message is too high for that to be a reasonable default.
Grounding in the aging report
The agent's context for a given customer should be pulled directly from Acumatica's AR data via the REST API — open invoices, due dates, days overdue, payment history, and any existing collection notes — rather than summarized from memory or a stale cache. Feed that structured data to the model rather than asking it to "check on customer ACME," since the model has no independent access to Acumatica and any number it produces without a grounding fetch is a guess.
aging = acumatica_client.get_customer_aging(customer_id) # real API call
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=600,
messages=[{
"role": "user",
"content": f"Customer aging data (source of truth, do not alter figures):\n"
f"{json.dumps(aging)}\n\n"
f"Draft a collections email for the oldest overdue invoice. "
f"Use the exact amounts and dates given. Tone: firm but professional. "
f"Do not mention legal action or late fees unless present in the data."
}]
)Tiered escalation, not autonomous escalation
Model the agent's output as a recommendation with a tier — reminder, second notice, escalate to collections team — rather than an action it takes directly. A collections specialist reviews the recommendation and the draft message, edits if needed, and sends. This keeps the tone and relationship judgment (which customers are reliable-but-slow versus genuinely at risk) with the human who has context the aging report alone doesn't capture.
When rendering the final email, template the amount and due date fields directly from the API response rather than trusting the LLM to have copied them correctly into its draft. A template with placeholders filled from validated data eliminates an entire class of "the agent said the wrong number" bugs.
Handling disputes and payment promises
When a customer replies disputing an invoice or promising payment by a date, the agent's job is to classify the reply and extract the relevant facts (disputed amount, promised date) into structured fields Acumatica can store as a follow-up task or note — not to unilaterally adjust the invoice or close the collections item. Classification and extraction are a good fit for an LLM; changing financial records based on an email is not.
Measuring impact
Track days-sales-outstanding (DSO) trend and the ratio of drafts a human sends unedited versus heavily rewrites, rather than just "number of emails sent." A high unedited-send rate tells you the drafts are actually useful; a collections team quietly ignoring the drafts and writing their own tells you the agent isn't earning trust yet.
Wrapping up
Collections is a relationship function wearing a data-entry hat. The agent should own the data-entry and drafting part — pulling the aging, writing the first draft — and leave every judgment call about tone, leniency, and escalation to the person who owns the customer relationship. If you are stuck on something specific, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.