Chasing Invoices With an AI Agent, Politely and on Time

Nobody enjoys chasing invoices. The work is repetitive, mildly awkward, and easy to postpone, which is exactly why receivables age. An invoice that should have been paid at day 30 quietly becomes a day 55 problem because the follow up email never got written, or got written once and never escalated.

This is a strong fit for an AI agent, but only under one condition: the agent never sends anything on its own. Payment reminders sit at the intersection of money and customer relationships, and a wrong tone, a reminder sent to someone who already paid, or a duplicate chase can do real damage. The pattern that works is detection and drafting by the agent, sending by a human.

This article walks through how to build exactly that: an ai invoice follow up agent that finds overdue invoices, drafts an escalating reminder sequence, and parks every single send as a pending approval that you review before it goes anywhere.

Why invoice chasing decays without a system

Manual invoice follow up fails in predictable ways.

First, detection is inconsistent. Someone has to remember to check the aging report, cross reference it against recent payments, and figure out which invoices actually need a nudge. On busy weeks this check gets skipped, and the invoices that slip are the ones that age worst.

Second, escalation stalls. A single polite reminder is easy to write. The harder part is the sequence: a gentle note at 7 days overdue, a firmer one at 21, a direct message about next steps at 45. Most people send reminder one and then feel awkward about reminder two, so it never happens. The invoices that need escalation most get the least of it.

Third, tone drifts under pressure. When you finally sit down to chase a 60 day overdue invoice at the end of a frustrating week, the email you write is not the email you would have written calmly. Templates help, but templates also read like templates, and customers notice.

Fourth, context gets lost. Was this customer already contacted? Did they reply asking for a revised PO number? Did finance agree to extended terms? Without a record, you either re-chase people who already responded (annoying) or skip people who went quiet (expensive).

An agent addresses all four failure modes: it checks on a schedule without forgetting, it applies the escalation ladder mechanically, it drafts in a consistent tone regardless of anyone's mood, and it keeps memory of what was sent and when.

The shape of the agent

On Skopx, you build this agent by describing it in chat at Create Agent. There is no canvas to wire up and no code to write. You explain what you want in plain language, and the chat assembles the agent: instructions, trigger, tool grants, budgets, and success criteria. If you have not built an agent before, the walkthrough on creating your first agent covers the general mechanics; here we focus on the invoice specific decisions.

The agent has five working parts.

Detection. The agent needs to know which invoices are overdue. Depending on where your billing lives, that means querying Stripe for open invoices past their due date, reading a Google Sheet your finance team maintains, or running a read-only SQL query against a connected Postgres or MongoDB database. Skopx data source queries are read-only with bound parameters, so the agent can look but never modify billing records.

Classification. Not every overdue invoice deserves the same treatment. The agent buckets each one by how overdue it is and checks its own memory for prior contact, so an invoice that received a reminder five days ago is not chased again today.

Drafting. For each invoice that is due a touch, the agent writes a reminder email matched to the escalation stage: friendly at stage one, firm at stage two, direct at stage three. Each draft includes the invoice number, amount, original due date, and a payment link if your billing system provides one.

Approval. This is the load-bearing part. The agent's Gmail or Outlook grant is set so that sending email always requires approval. Every draft parks as a pending approval showing the exact call and arguments: the precise recipient, subject line, and full body. You approve, and exactly that parked call executes once. You reject, and nothing is sent. Nothing leaves the building without a human reading it first.

Reporting. Every run ends with a markdown report: how many invoices are overdue, total outstanding amount, which reminders were drafted, which are awaiting your approval, and what changed since the last run.

Writing the instructions

The instructions are plain language, editable, and versioned. A reasonable starting set for this agent:

Every weekday morning, find all invoices that are overdue by 3 or more days. For each one, check memory for prior reminders. Apply this ladder: 3 to 13 days overdue and no reminder sent in the last 7 days, draft a friendly reminder. 14 to 29 days overdue, draft a firmer reminder referencing the earlier note. 30 or more days overdue, draft a direct email proposing a call to resolve payment and mentioning that we may need to pause work. Never draft more than one email per customer per run, even if they have multiple overdue invoices; consolidate into one email listing all of them. Match the customer's communication style if we have prior threads. Never invent payment terms, discounts, or legal threats. All emails go to approval; never assume a draft was sent until it is approved. Finish with a report summarizing the receivables position and the drafts awaiting review.

A few of these lines are worth calling out because they encode judgment that generic automation misses.

One email per customer per run prevents the embarrassing case where a customer with four overdue invoices gets four separate nagging emails in one morning.

Never invent payment terms or legal threats is a hard boundary. Language models will, if unconstrained, sometimes escalate rhetorically in ways your company never authorized. Saying "we may pursue collections" in an email is a business decision, not a drafting choice, and the instructions should forbid the agent from making it. The broader discipline of constraining agent behavior is covered in the guide to AI agent guardrails.

Never assume a draft was sent matters because the agent's memory should record sends only after approval, not after drafting. If you reject a draft, the next run should treat that customer as not yet contacted at that stage.

Because instructions are versioned, you can tighten the tone or adjust the ladder thresholds over time and see exactly what changed between versions if the agent's behavior shifts.

The escalation ladder in practice

Here is a concrete example sequence, clearly hypothetical, for an invoice of $4,200 due July 1.

Stage one, drafted July 8. "Hi Dana, a quick note that invoice #1042 for $4,200 was due on July 1. It may already be in process on your side; if so, please ignore this. The payment link is below if it is easier. Happy to resend the invoice or answer any questions."

Stage two, drafted July 22. "Hi Dana, following up on invoice #1042 for $4,200, now three weeks past its July 1 due date. I sent a note on the 8th and have not heard back. Could you let me know when we can expect payment, or whether anything is blocking it on your end? If the invoice needs to be reissued with different details, I can turn that around quickly."

Stage three, drafted August 5. "Hi Dana, invoice #1042 for $4,200 is now more than a month overdue and I have not been able to reach you about it. I would like to get this resolved this week. Could we find 15 minutes to talk, or could you connect me with the right person in your accounts payable team? I want to keep things on good terms and get this settled."

Notice what the ladder does: each step is firmer but none is hostile, each references the prior contact so the customer sees a coherent thread rather than disconnected nags, and the amounts and dates are pulled from the billing data rather than typed from memory. The agent produces drafts like these consistently, and you get final say on every one.

Why every send goes through approval

It is tempting to let stage one reminders send automatically and only gate the firmer stages. Resist that for at least the first months of running the agent, and probably forever. Here is the reasoning.

The cost asymmetry is stark. Reviewing a drafted reminder takes perhaps twenty seconds. A reminder sent to a customer who paid yesterday, or whose payment is stuck in your own reconciliation queue, costs goodwill you cannot easily buy back. Payment data is also messier than it looks: partial payments, credit notes, disputed line items, and payments recorded in one system but not another all create situations where "overdue" in the data is not "overdue" in reality. The human reviewer is the last check against data problems the agent cannot see.

Skopx makes this review cheap in a specific mechanical way. Under an approval-required grant, a write-shaped action does not execute. It parks as a pending approval showing the exact call the agent wants to make: the literal recipient address, subject, and body it will send. Approving executes exactly that parked call, once. Rejecting executes nothing. There is no ambiguity about what you approved, and the agent cannot swap content after you sign off. Approvals can also expire, which is the right behavior for payment reminders: a draft that sat unreviewed for a week is stale, because the invoice may have been paid in the meantime, and it should die rather than send.

Reads, by contrast, flow without approval. The agent can query Stripe, read the aging sheet, and check email threads freely; only the send is gated. This split is what makes the agent useful rather than annoying: you are never asked to approve a lookup, only the one action that actually touches a customer. The full design space here is covered in the article on AI agents with human approval.

Grants, budgets, and the trigger

Grants. Give the agent read access to your billing source (Stripe, a Google Sheet, or a read-only database connection) and email access set to "asks first every time" for sends. If you want a softer starting posture, Skopx also has a drafts-only mode where the agent can create drafts in your mailbox but can never send at all; some finance teams prefer this permanently, treating the agent purely as a drafting assistant inside their existing email workflow.

Trigger. A schedule fits this job: every weekday at 8:00 UTC, say, so drafts are waiting for review with your morning coffee. Manual runs remain available when you want an on-demand receivables check before a board meeting. If your billing system can fire webhooks on invoice events, a webhook trigger can catch invoices the moment they tip overdue, though for most teams a daily schedule is simpler and fast enough. The tradeoffs between schedules and webhooks are laid out in the triggers guide.

Budgets. Set tokens per run, tokens per day, a max step count, and a minute cap. An invoice chaser's workload scales with overdue count, so a run that suddenly wants ten times its normal budget is a signal something is wrong (a data source returning garbage, or a loop). On Skopx, three budget failures auto-pause the agent, which is exactly the fail-safe you want on anything that touches customer communication.

Memory. The agent's memory persists between runs and holds the working state: which invoices were chased, at what stage, on what date, and which approvals were granted or rejected. This is what makes run two a delta ("three new overdue invoices since Thursday, two prior chases resolved by payment") rather than a full rescan, and delta runs are typically cheaper.

Manual chasing vs. blind automation vs. an approval-gated agent

The middle column is what most dunning software offers: reliable but blind. The right column keeps the reliability and adds judgment back in at the only point where judgment matters, the send.

What can go wrong, honestly

An honest accounting of the failure modes, because no agent setup removes them entirely.

The data is wrong. If your billing system says an invoice is open but the customer paid by wire to a bank account that has not been reconciled, the agent will draft a chase. The approval gate is your protection, but only if the reviewer actually knows about the wire. Mitigation: have the agent note in each draft's context anything ambiguous it found, such as a customer reply in the email thread mentioning payment.

Tone misses on a sensitive account. Some customer relationships are in delicate states the data does not show: a renewal negotiation, an escalated support issue. The agent does not know unless you tell it. Mitigation: maintain an exclusion list in the instructions ("never draft reminders for these accounts without being asked") and update it as situations arise. Instructions are editable at any time, and edits are versioned.

Duplicate chasing across channels. If a colleague also chases invoices by phone, the agent's memory does not know about those calls. Mitigation: keep a shared note or sheet the agent reads before drafting, or accept that the reviewer will catch overlaps.

The agent stalls or misbehaves. Runs can be stopped mid-flight, and pausing the agent acts as a kill switch for queued runs. Every run's step timeline is visible with humanized labels and expandable raw results, so when a draft looks wrong you can trace exactly which query produced the data behind it. That transparency is not decorative; it is how you debug. The article on run transparency goes deeper on reading timelines.

It will not collect hard cases. An agent drafting polite emails will not resolve a customer who has decided not to pay. At some point a human conversation, revised terms, or a collections process takes over. The agent's job is to make sure invoices never reach that point through neglect, and to surface the ones heading there early.

Measuring whether it works

Define success criteria when you build the agent, because Skopx evaluates every run report against them. Useful criteria for this agent: every invoice overdue by 3 or more days was either drafted against, excluded for a stated reason, or already mid-sequence; no customer received more than one draft; every draft's amounts and dates match the billing data; the report includes the total outstanding figure and its change since the last run.

Over weeks, the numbers that matter live outside the agent: days sales outstanding trending down, the share of invoices resolved at stage one rising, and the count of invoices ever reaching stage three falling. The agent's own reports give you the leading indicators: how many invoices tip overdue each week and how fast chases resolve. A well-run sequence tends to shift resolution earlier, because the stage one reminder actually goes out at day 7 instead of day 25.

Track the review burden too. If you are rejecting a large fraction of drafts, the instructions need tightening; each rejection is a free piece of feedback about what the agent misjudged, and a one-line instruction edit usually fixes a whole class of them.

FAQ

Can the agent send reminders without my approval?

Only if you configure it that way, and for invoice chasing you should not. With the email grant set to ask first every time, every send parks as a pending approval showing the exact recipient, subject, and body. Approving executes exactly that call once; rejecting executes nothing. There is also a drafts-only mode where the agent can never send at all, only create drafts in your mailbox.

What billing systems can it read?

Anything reachable through Skopx's integrations or data sources: Stripe among the nearly 1,000 Composio-backed integrations, Google Sheets if finance tracks receivables there, or a direct read-only SQL connection to Postgres or MongoDB with bound parameters. See the integrations page for the full catalog. Reads flow without approval; only write-shaped actions like sending email are gated.

How does the agent avoid chasing someone who already paid?

Two layers. First, each run re-queries the billing source fresh, so an invoice marked paid disappears from the overdue set. Second, the human approval step catches the cases the data misses, such as a payment made but not yet reconciled. Neither layer alone is sufficient; together they make wrong sends rare. The agent's memory also records what was sent and when, so it never re-chases inside the cooldown window you set.

What happens if a customer replies to a reminder?

Replies land in your mailbox like any other email, and the conversation is yours from there. You can have the agent check the thread for replies before drafting the next stage, so a customer who wrote back "processing this Friday" does not get a stage two escalation on Thursday. That check is a read, so it needs no approval.

Does this replace collections or dunning software?

For early-stage chasing, it can cover the same ground with more flexibility in tone and a human check on every send. It does not replace a formal collections process for seriously delinquent accounts, and it should not: the agent's instructions should explicitly forbid legal language, because that escalation is a business decision for a human. Think of the agent as making sure invoices never age into collections through simple neglect.

Where this fits in a finance agent stack

Invoice chasing rarely stays a solo agent for long. The same pattern of scheduled detection, drafting, and gated sends extends naturally to renewal reminders on the revenue side and expense review on the cost side, and teams often run a morning KPI digest alongside so the receivables position lands in the same daily rhythm as everything else.

Start smaller than that. Build the one agent, run it manually a few times against real data, review every draft skeptically for two weeks, then let the schedule take over while keeping the approval gate. The goal is not to remove yourself from invoice follow up. It is to reduce your role to twenty seconds of judgment per reminder, applied at exactly the moment judgment matters, while the detection, the ladder, and the drafting run without you having to remember them. That is the version of ai invoice follow up that actually gets money in the door without burning the relationships it depends on.