Can You Build a Collections Agent on ChatGPT or Claude?

Yes, you can build a collections agent on ChatGPT or Claude, and for a small book run by one person it may be the right answer. Monk is an AI-native invoice-to-cash platform that runs invoicing, delivery, cash application and collections as one system, so we have an obvious interest here, which is a reason to be careful rather than dismissive. The part everyone expects to be hard is now easy. Drafting a well-judged reminder from an aging row, summarising a long thread, proposing a next action and classifying an inbound reply are solved problems with a decent model and a decent prompt. What breaks is everything wrapped around the model, and it breaks at production scale rather than in the demo.

The realistic starting stack costs an afternoon. An aging export from QuickBooks or NetSuite, a prompt template holding your tone rules and escalation ladder, a small script to loop through rows, and the Gmail API to send. Two hours in you have drafts that read better than the templates you were using, taking account of the invoice number, the amount, the age and whatever context you paste in. That is a real gain and this post will not pretend otherwise.

What can you build in an afternoon, and how good is it?

Four things, all good enough to use, and each useful without the others.

The first is drafting. Give a model an aging row, a short customer history and a tone specification, and it produces a reminder that references the right invoice with the right amount and pitches its firmness to the age of the debt. It handles awkward cases better than a template: a customer with three overdue invoices and one recent payment, or one who paid the wrong amount.

Summarising is the second. A thread that has run for eleven messages across two people and a forwarded internal chain reduces to five accurate lines. This saves more time than drafting does, because reading is the expensive part of the job.

The third is suggesting a next action. Given the history, a model will propose calling rather than emailing, escalating to the account owner, or waiting until after the buyer's payment run. It is right often enough to be worth reading and not often enough to run unsupervised, which is the correct place for it.

Classifying replies is the fourth: buckets such as promise to pay, dispute, request for documents, out of office, wrong recipient. Accuracy on clean cases is high, and this is also where the trouble starts.

Why does state break before the model does?

Because collections is a long-running conversation with memory, and a script that regenerates its view of the world on every run has none.

Consider the sequence. Monday, your script emails 40 customers about overdue invoices. Tuesday, six pay and two reply. Wednesday, the script runs again from a fresh export. If the export is a day stale, it chases people who have paid, which is the fastest way to lose credibility with your own customers. If the script crashed halfway through Monday and you restarted it, some customers received two identical emails four minutes apart. If a colleague chased manually on Tuesday, the script sends a third message on Wednesday.

Fixing this means building things that have nothing to do with AI. A durable record of every message sent, keyed by invoice and contact. Idempotency keys on the send operation, so a retry after a timeout is a no-op rather than a duplicate. A revalidation check before send that re-reads invoice status, because approving on Monday and sending on Thursday is a different action. A cooldown per contact, so a customer with nine overdue invoices gets one message. And a lock, so two runs cannot overlap.

None of this is difficult engineering. It is a week or two of careful work, and not the week you planned to spend. It is also the part where failure is visible to customers rather than to you.

What happens to your domain reputation when a script starts sending?

Volume changes the physics, and mail that lands in spam is worse than mail you never sent, because you believe it arrived.

A person sending thirty emails a day from a mailbox with years of history has a reputation providers trust. A script sending three hundred a day from the same domain, in bursts, with similar structure and a link in every message, looks different to a spam filter. The failure is quiet: messages marked sent, few bounces, and a response rate drifting downwards for reasons that look commercial.

The minimum controls are known and unexciting. SPF, DKIM and DMARC configured for the sending domain. Volume ramped over weeks rather than switched on. Bounce handling that suppresses an address after a hard bounce rather than retrying it monthly. Monitoring of delivery and reply rates by recipient domain, because one large customer blocking you at the gateway is invisible in an aggregate number. And a decision about whether collections mail leaves your primary domain at all, since a deliverability problem caused by chasing will also affect sales and support mail.

Reply rate is also your only feedback signal, and deliverability pollutes it. If your prototype's response rate is poor, you cannot tell from inside the script whether the writing is wrong, the timing is wrong, the contact is wrong, or the message never arrived.

Why is classifying the inbound reply harder than writing the outbound one?

Because you control the format of the outbound message, and the customer chooses the shape of the reply.

Real replies are not clean. A message reading "we'll get this over to you shortly" is a promise with no date, and treating it as a commitment produces an embarrassing follow-up. A reply arrives from someone who is not the recipient, forwarded internally with three layers of quoting, and the only new content is one line at the top. An out of office names an alternative contact, which most parsers discard. A message says the invoice is being processed, which says nothing about the date. Another mentions in passing that the purchase order was closed, which is the real blocker.

Classification accuracy matters asymmetrically. Misreading an out of office as a promise costs a missed follow-up. Misreading a dispute as a delay costs a chase sent to a customer who has told you they are unhappy, and that mistake reaches a sales director. A prototype accurate on clean cases and confident on ambiguous ones will make it, because ambiguity is common and confidence is the default.

Production needs a confidence threshold with a human queue behind it, entity extraction rather than only a label, meaning the promised date, the disputed amount and the named alternative contact, and a feedback loop where a corrected classification changes the routing for that account rather than sitting in a log.

What does the exception layer add that a better prompt cannot?

Facts the model does not have and cannot infer.

Across the receivables Monk manages, 39% of cash flow slowdown is caused by edge cases, and 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice. Neither appears in an aging export. Your prototype sees an invoice 52 days overdue and writes a firm, well-composed reminder. The invoice was rejected by the buyer's portal on day 4 for a missing purchase order line, and nobody in accounts payable can pay a document their system never accepted. The message is fluent and useless, and it teaches the customer that your chases carry no information.

The same holds for the expired certificate of insurance, the goods receipt the depot never posted, the invoice raised against the wrong legal entity, the short payment with an unstated deduction, and the promise made verbally to your account manager. Each is a specific blockage with a specific fix, and each is invisible from the ledger.

A better prompt cannot solve this, because the information is not in the context. Solving it means monitoring portal submissions and their rejection reasons, tracking compliance documents against expiry, parsing remittance advice, and recording every promise as a structured object with a date and an owner. That is a data pipeline, and it is the largest item on the list.

What do audit trails, approval gates and write-back cost to build?

More than the agent, and they are the items least likely to be in your estimate.

An audit trail for customer communication records the exact content sent, the recipients, the timestamp, the invoice and amounts referenced, the model and prompt version, whether a human approved it and who, and any inbound response linked to it. Chat transcripts do not satisfy this. When a customer's CFO writes to say your tone was unacceptable, or an auditor asks how a balance was pursued, you need a retrievable record rather than a scroll through a shared mailbox.

Approval gates are simple to describe and fiddly to build well: a queue, a rendered preview of the exact message, an approve and edit path, a rejection with a captured reason, expiry on stale drafts, and a policy engine deciding which drafts need approval at all. Then autonomy tiers, so a reminder under a stated value to a customer with no open dispute can go on its own.

Write-back is where the integration bill lands: logging activity in the CRM, updating collection status in the ERP, recording the promise to pay where the team can see it, and applying the cash when it arrives. Each system has its own authentication, object model, rate limits and sandbox, and each changes without asking you.

How does Monk handle this?

Monk builds the six items above as the product and puts agents on top of them.

Connections to QuickBooks, NetSuite, Salesforce, HubSpot, Stripe, Slack and Gmail make the invoice, the customer, the payment and the conversation one object rather than four systems and a spreadsheet. AI cash application matches 80% of receipts automatically, rising to 95% with suggested matching rules, which keeps the ledger current enough that nobody is chased after paying. Julia, Monk's AI agent for Intelligent Collections, runs the follow-up and achieves a 24% higher response rate than standard dunning, with 90% of collections resolved with zero human intervention. Intelligent Collections ingests the context of the conversation, so a reply mentioning a closed purchase order changes the next step rather than being filed. Customers see an average 40% reduction in DSO and save 26 hours a month. 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?

Score your own situation before deciding, because a weekend project serves some teams well and leaves others exposed.

Building it yourself is the right call when the book is small enough that one person knows every account by name, when a human presses send on every message, when volume never makes deliverability a scale problem, when disputes are rare, and when nobody outside your team will need to audit what was said. Under those conditions the afternoon prototype is a sensible tool rather than a compromise, and the six problems above stay theoretical for you.

It stops being the right call when any of those changes. The usual first breach is volume: the day a person can no longer review every draft is the day you need state, idempotency and approval policy rather than attention. The second is enterprise customers, who bring portals, entities and compliance documents. The third is a second operator, because two people and a script produce duplicates within a fortnight.

The test to run this week is cheap. Take last month's outbound chases and count three numbers: how many went to customers who had already paid or disputed, how many were second messages nobody intended, and how many produced a reply you had to read carefully to classify. If all three are near zero, build it yourself. If not, the work ahead is plumbing rather than prompting. To see that plumbing already built, book a demo.

Frequently Asked Questions

Can ChatGPT or Claude write a good collections email?

Yes, and better than most templates, provided you give it the invoice details, the customer history and explicit tone rules. Models handle awkward cases well, such as a customer with several overdue invoices and one recent payment. Writing quality is not the constraint on a collections process. Knowing which customer to write to, about what, and whether anyone should write at all is the constraint.

What is the first thing that breaks in a DIY collections agent?

State. A script that rebuilds its view of the world from a fresh export on each run has no memory of what was sent yesterday, no way to know a colleague chased manually, and no protection against sending twice after a crash. Customers notice duplicates immediately. Fix it with a durable message log, idempotency keys, per-contact cooldowns and a revalidation check before every send.

Will sending automated chases hurt our email deliverability?

It can, and the failure is quiet rather than obvious. Bursts of similar messages from a domain with no sending history look like bulk mail, and the result is silent filtering rather than bounces. Configure SPF, DKIM and DMARC, ramp volume slowly, suppress hard bounces permanently, and monitor delivery and reply rates per recipient domain.

How accurate is AI at classifying customer replies?

High on clean cases and unreliable on the ambiguous ones that matter most. Vague promises with no date, forwarded threads, out of office messages naming an alternative contact, and replies where the real blocker is mentioned in passing all cause errors. Use a confidence threshold with a human queue behind it, and extract entities such as promised dates rather than only a label.

How long does it take to build a production collections agent?

The drafting and classification take an afternoon. State, deliverability, reply handling, exception capture, audit and write-back are the rest, and they are ongoing rather than one-off, because integrations and mail provider rules change. Treat it as a small internal product with an owner. If nobody has capacity to own it in six months, that is a signal about the approach.

Do I need approval gates if only one person uses the tool?

If that person reviews every message before it goes, the gate exists in the form of their attention. The question is what happens the week they are on leave or the month volume doubles. A gate becomes necessary once drafts outnumber the time available to read them, and that point arrives without announcing itself. Build the audit record before the gate, because it is cheap and it cannot be reconstructed later.

Is a DIY agent enough for enterprise customers?

Rarely, because enterprise buyers introduce failure modes a prototype cannot see. Most large buyers require submission through a vendor portal, so an invoice can be delivered by email and still be unpayable, and a chase sent in that state does damage. Add entity mismatches, compliance documents and multi-step approvals, and the reason an invoice is unpaid is rarely the reason your export suggests.