Collections, at most companies, runs like this. Download the balances. Assemble a list. Read back through the correspondence history with each customer to work out what has already been said. Write every chaser by hand. Repeat for every entity.
It is low-level work and it eats a finance day, which is why it slips, which is why the cash arrives later than it should. It is also almost never the thing that gets automated, because it is too specific to buy off a shelf and too small to put in front of engineering.
At All Gravy it now runs as an agent that tracks outstanding balances across all 4 entities, reads the correspondence history with each customer, and drafts and sends the reminders.
"The dunning agent gives us the full picture of what is outstanding and handles the chasing. That used to be my afternoon."
Linea Meldgaard Andersen, Finance Analyst, All Gravy
entities the dunning agent tracks outstanding balances across at All Gravy
average time saved on repetitive admin work at teams running their own Custom Agents
of bookkeeping automated at Dreamdata with Light and custom agents
Why workflow automation usually stalls
Every finance team has a list of workflows it would automate. Very few of them get automated, and the reason is almost never the technology.
It is that the workflows worth automating are specific. Not "chase overdue invoices," which any tool does, but "chase overdue invoices, except the 3 customers renegotiating, and check what we already said to them last month, and use a different tone after 60 days." That specificity is the whole value, and it is also what makes the workflow impossible to buy off a shelf and expensive to get built.
So it goes on a roadmap. A ticket gets written. Engineering has more urgent work, reasonably, and the finance team keeps doing it by hand while the request ages.
Peter Egehoved at Dreamdata described the structural version of this to Light directly: a platform vendor has to optimise for everyone, and a company can optimise for itself. That asymmetry is real and it does not resolve by the vendor trying harder.
What changes when the finance team writes it
An admin describes the job in plain language, sets a schedule, and the agent runs from then on under its own identity, delivering the result into Slack or into Light. No builder, no rules engine, no syntax. Every run lands in the jobs table showing the instruction it used, the tools it called and what came back, so the work is checkable rather than trusted.
The important part is who is doing the specifying. The person who knows that customer 14 is renegotiating, and that the Norwegian entity invoices on different terms, and that a particular vendor always bills a month late, is the person in finance. Handing them the ability to write the workflow removes the translation step where most of the specificity was getting lost.
Teams running these report saving 80% of their time on average on that category of work. At Dreamdata, where the controller has been writing them against his own chart of accounts, the bookkeeping figure is 95%.
Old model
Request it, wait, do it by hand
The workflow is too specific to buy and too small to prioritise, so it stays on a roadmap while the team runs it manually.
Light's model
Describe it, schedule it, check it
An admin writes the instruction in plain language and sets the cadence. Every run shows the prompt, the tools called and the result.
What changes
Specificity survives
The person who knows the exceptions writes the rule, so nothing is lost translating a finance workflow into a ticket.
The workflows worth starting with
The pattern across companies doing this well is that the first agents are unglamorous and run on a clock.
Chasing what is outstanding, across every entity, with the history read first. Finding card transactions with no receipt and messaging the person who owes it. Flagging vendors whose spend moved more than expected month over month. Freezing the cards of people who left and posting the list to finance. Listing bills that arrived without a purchase order and telling the team that owns them. Preparing the accruals that come round every month and leaving them for a human to post.
Two of those come straight from companies asking for them. Lovable wants the offboarding one, because today an employee who has left keeps a live card until somebody remembers to kill it. Teton wants the wallet one, because cards die mid-month when the balance runs out and nobody is watching the balance. In both cases the agent raises the alarm and a human still moves the money, which is the correct division of labour for anything irreversible.
None of those are hard problems. All of them are things that currently depend on somebody remembering, which is the actual failure mode. Work that depends on memory rather than on a schedule fails quietly, and the failure only surfaces at month-end.
Where the boundary sits
Worth being precise, because this is the question that matters at approval time.
An agent runs with the tools it is given and does what its instruction says, on the schedule set for it. It holds its own principal, so everything it does is tracked against that identity rather than a shared account, and a creation and update log ties it back to the person who wrote it and anyone who has changed it since. Every run is visible in the jobs table alongside every other job.
What it does not have is judgment about its own scope. It does what it was told, which is why the instruction is the control and why the person writing it should be the person accountable for the process. That is a reasonable division, and it is the same division that applies to a junior hire, except this one is legible after the fact in a way a person's afternoon never was.
The teams getting the most out of this are not the ones who automated the most workflows. They are the ones who worked out which parts of their week were running on somebody's memory, and gave those a schedule instead.
See Custom Agents, the rest of the workforce, or book a demo.