An autonomous worker that clears the receivables queue on its own
An AI worker that owns the receivables backlog end to end: it matches payments and sends reminders on its own, and pauses at an approval gate before writing off a balance or escalating an account.
The brief, in specifics
- Industry
- Professional Services
- Duration
- 9 weeks
- Cooperation model
- Fixed price, phased
- Services
- Autonomous workerApproval gate designEscalation routing
- Integrations
- HubSpotDocuSignXeroGoogle Workspace
- Technologies
- PythonCeleryPostgreSQLLarge language model APIApproval workflowStructured logging
- Team
- 1 Project lead1 Product designer1 ML engineer1 Backend engineer1 Data engineer
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
What we were brought in to do
The receivables backlog only moved when someone sat down and worked it, so it never quite got worked down. We built an autonomous worker that owns the queue full-time, matching payments and sending reminders on its own while pausing for a human decision on anything consequential.
A professional services firm where receivables were two analysts' secondary duty, worked in bursts between client engagements. The aging report was accurate and nobody was reading it. The engagement was commissioned after a quarter-end where two accounts crossed a hundred and twenty days without a single reminder being sent. Both were eventually paid in full after one phone call.
AI & Automation
Where the old way broke
Two analysts split reconciliation duty between client work, so the aging report only got attention in bursts. Accounts drifted past 60 and 90 days before anyone circled back, and write-offs happened ad hoc with no consistent review.
The queue only moved when someone chose to move it, and that choice competed with billable work, so it lost. The result was a specific pattern, not a general slowness: accounts were either chased promptly or not at all, depending on whether they happened to sit near the top of the report during a quiet week. Write-offs were made ad hoc with no consistent review.
We deployed a worker that runs the receivables queue continuously: matching incoming payments to open invoices, sending staged reminders, and flagging accounts that cross an aging threshold. Every write-off or collections-agency escalation stops at an approval gate for a partner's sign-off.
Continuous queue ownership
The worker runs the receivables queue on its own, all the time, with no one invoking it per batch.
The worker holds the receivables queue continuously through Celery, with no nightly batch to wait for, so a payment landing at eleven is matched at eleven. Matching runs on amount, reference and payer history, and a payment that splits across invoices or arrives short is decomposed on the spot instead of dropped into an exceptions pile for someone to sort out on Friday.
- Runs the queue continuously; no nightly batch window
- Matches on amount, reference and payer history
- Split and short payments decomposed, never dumped in exceptions
Payments matched as they land, with no batch window: a £9,340 payment received at 23:04 matched at 23:04 on amount, reference and payer history, split across three invoices, and the £690 shortfall left open instead of sent to exceptions.
The approval gate: three decisions on a partner's desk, a dissolved client, a disputed balance and three unopened reminders, with the write-off open beside its account history, aging position and the worker's recorded reasoning.
Gated consequences
Write-offs and agency escalations stop at an approval gate; routine matching and reminders run straight through.
The gate sits where the consequence becomes irreversible: matching a payment and sending a staged reminder happen unattended, while a write-off or a handover to a collections agency stops and waits for a partner. The request arrives with the account history, the aging position and the worker's reasoning attached, so approving it is a real judgment call and never a rubber stamp.
- Gate placed at irreversibility, not at every action
- Matching and reminders run unattended; write-offs stop
- Approvals arrive with history, aging and reasoning attached
Inspectable actions
A morning's work in order, every line with the rule behind it: matches, reminders, one proposal held at the gate and a credit note refused outright, with one reminder's structured record and the three timestamps that explain why the account was chased.
Every action logged with its reasoning, so the aging queue can be audited after the fact.
Every action writes a structured log line carrying the account, the decision, the inputs it was made on and the rule or model output behind it. That's what makes the aging queue auditable after the fact: a partner asking why an account was chased three times gets the three timestamps and the trigger for each, with nothing reconstructed from memory.
- Structured log per action: account, decision, inputs, reasoning
- The aging queue auditable months later
- Reminder history reconstructable to the timestamp
What we built together
- 01
Mapped the queue's goal, states, and what counted as a consequential action
Drawing the reversible line precisely took longer than automating either side of it, and it's the artifact the partners actually reviewed.
- 02
Automated payment matching and staged reminders for routine aging
Matching runs on amount, reference and payer history, and staged reminders escalate on their own schedule, whether or not anyone opens the report.
- 03
Placed approval gates in front of write-offs and collections escalations
Write-offs and agency escalations stop and wait, with the account history, aging position and the worker's reasoning attached to the request.
- 04
Wired action logging and drift alerts so the aging queue stays inspectable
Every action writes a structured log line carrying the inputs and the reasoning, so the aging queue can be audited months later with nothing reconstructed.
Operational results after launch
−22%
Days sales outstanding
76%
Accounts auto-resolved
100%
Write-offs reviewed pre-approval
Days sales outstanding compares the two quarters after launch with the two before. Accounts auto-resolved is the share closed by matching or reminder without a human touching them, measured on accounts, not value; the large accounts still get a person. The write-off figure is structural: no write-off can occur without an approval record.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Phase by phase
Phase 1: Define
What the worker owns
Mapped the queue's goal, its states, and, critically, which actions were consequential enough to need a human.
- State model
- Consequential-action list
Phase 2: Automate
The routine path
Automated payment-to-invoice matching and the staged reminder sequence for normal aging.
- Matching logic
- Reminder sequence
Phase 3: Gate
Where it must stop
Placed approval gates in front of write-offs and collections escalations, with the partner's sign-off recorded.
- Approval gates
- Sign-off audit trail
Phase 4: Observe
Drift and accountability
Wired action logging and drift alerts so a change in the worker's behavior surfaces before it compounds.
- Action log
- Drift alerts
- Operator runbook
The decision rules: four that run unattended and cover 2,344 of the month's actions, two that stop for a partner, and two things the worker may never do at all.
About our collaboration
A cross-functional team of 5 worked on a fixed price, phased basis over 9 weeks, covering Autonomous worker, Approval gate design, Escalation routing. We ran a weekly demo and kept a shared board they could read at any time. Their team took over day-to-day operation before the engagement ended, with handover built into the last phase.
The phases were drawn around the approval gate instead of around features: the gate and its logging shipped before any autonomous action did, so no version ever existed that could write off an account unattended. Partners reviewed a week of the worker's proposed actions before it was allowed to take any of them.
What we'd carry into the next one
- 01
Autonomy is only safe where the consequences are reversible. The gates are the design itself.
The gates are what made the autonomy acceptable: everything reversible runs unattended, and drawing that line precisely is more of the work than the automation.
- 02
Logging the reasoning mattered more than logging the action; the action alone couldn't be reviewed.
An action log says what happened; a reasoning log says whether it should have. Only the second one answers a partner asking why an account was chased three times.
- 03
Most of the queue was routine. Naming the small consequential slice is what made automating the rest defensible.
Most of a receivables queue is unambiguous. Naming the small consequential slice is what let the rest run without anyone needing to supervise it.
One overdue account
Two actions run on their own. The third waits for a partner.
The same account, three moments: a short payment matched overnight, a staged reminder, and a write-off the worker isn't allowed to make alone. Switch tabs, or use the arrow keys once one is focused.
A split, short payment arrives late at night. Matching is reversible, so the worker allocates it the moment it lands, leaves the £850 shortfall open on the right invoice, and logs why.
- INV-3016£0Cleared
- INV-3033£85043 days
- Payment lands£4,900 · reference WENDOVER 3016
- Match on amount, reference, payer historyNo single invoice at £4,900 · names INV-3016 · pays oldest first
- Decompose across invoices£3,600 clears INV-3016 · £1,300 to INV-3033
- Leave the shortfall open£850 stays on INV-3033 · not sent to exceptions
- Write the log lineRule R2 · inputs and reasoning recorded
ran unattended · R2 decompose · £3,600 → INV-3016, £1,300 → INV-3033, £850 left open
Where the line sits: at irreversibility, not at every action. Matching and reminders run on their own; write-offs and agency escalations wait for a partner.
From a payment landing to a decision someone can audit
The gate and its logging shipped before any autonomous action did, so no version of this pipeline ever existed that could write off an account unattended.
- 01 · TriggerPayment lands or an account agesA payment arriving at eleven is picked up at eleven, and an account crossing an aging threshold is flagged when it crosses.
- 02 · QueueCelery worker holding the queueThe worker owns the receivables queue continuously, with no one invoking it per batch. There's no nightly window to miss.
- 03 · EngineMatching, reminders and the gateMatches on amount, reference and payer history; decomposes split and short payments; write-offs and agency escalations stop for a partner.
- 04 · StatePostgreSQL + structured logEvery action writes a line with the account, decision, inputs and the rule or model output behind it, so the queue can be audited months later.
- 05 · DeliveryPartner approvals and drift alertsApproval requests carry history, aging and reasoning, the sign-off is recorded, and a change in the worker's behavior alerts before it compounds.
What the worker can't do alone
Approval gates & an auditable queue
Nothing irreversible runs unattended
Write-offs and collections-agency escalations stop at an approval gate. No write-off can occur without an approval record, and partners reviewed a week of proposed actions before the worker took any.
Every action carries its reasoning
Each action logs the account, the decision, its inputs and the rule or model output behind it. A partner asking why an account was chased three times gets three timestamps and a trigger for each.
Drift surfaces before it compounds
Drift alerts watch the worker's behavior, and an operator runbook covers what to do when one fires, so a change is caught while it's one account and not a quarter.
Receivables only moving when someone has a quiet week? Scope your build in three minutes.
Scope your buildNearby engagements
AI & AutomationA private legal assistant grounded in verified precedents
A private knowledge assistant that searches internal case files and precedents, providing cited answers legal teams can verify in seconds.
Legal & Law Firms · 14 weeks
Product DesignAn onboarding flow that guides trial users to value
A redesigned SaaS trial onboarding experience with progressive checklists, sample data, and inline guidance that turns signups into active subscribers.
Professional Services · 10 weeks
Product DesignA design system that brought speed and consistency to 4 product teams
A token-based design system in Figma and React that eliminated component duplication across 4 product squads and cut the time from design handoff to merged frontend.
Professional Services · 14 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
