Every dunning action carries a decision. A collector looks at an invoice, judges how likely it is to be paid on time, and picks a media channel, such as an email, a digital letter, or a phone call. That decision is hard for an agent to learn from, for two reasons.
The first is incompleteness. When a collector decides a phone call is more appropriate than an email, we never get to see the outcome of the medium they didn't choose. Therefore, action data is always incomplete, and quantifying whether the phone call was the right response requires complex statistical solutions.
The second challenge is the reasoning and experience collectors use to make the decision. Collectors chase hardest on the invoices they expect to be late, so a direct comparison of channels measures the triage more than the action.
Over the last few months, internal research has explored grouping similar actions and comparing their outcomes like for like. At Tech Hack 26, our team stored the data in a graph representation, and allowed it to drive agentic dunning predictions.
The shape of action data
The action dataset is notoriously tricky. One action can chase several invoices at once. One invoice can require many actions before clearing. To compare actions, we needed to build connections between them, allowing an Aimie agent to navigate from one action chain to another and compare the outcomes.
Figure 1 is the first graph I drew of the dataset. It shows the two units, invoices and actions, and how they evolve over time. One action can chase several invoices. Action 1 acts on both invoice A and invoice B. And one invoice receives several actions over its life. Invoice A is acted on by Actions 1, 2, and 3 as its status moves toward cleared. Its two edges, SIMILAR_ACTION between comparable actions and NEXT_ACTION between consecutive actions, were our first attempt at linking action chains, and section 05 explains why both were later revised.
Figure 1. The first graph schema: actions act on invoice statuses, and similar actions are linked to each other.
To begin the hack, we used an anonymized dataset from one large vendor's collections, with about 2 million executed actions on cleared invoices across more than 150,000 buyers, for invoices issued between 2024 and 2026. Our aim was to represent this dataset as a graph, explore the emerging structures and allow an Aimie agent to navigate it.
Comparing chased and unchased invoices
The naive approach is to compare each buyer's chased invoices with the same buyer's unchased ones. In this starry-eyed world, you might expect direct communication such as phone calls and visits to stand out, legal actions perhaps to have a considerable impact, and the less aggressive email reminders to just edge ahead of no action at all.
Instead, every channel comes out late. Within a buyer, invoices that received an email, digital letter, or phone call cleared later than invoices that received nothing (Figure 2). To make this clearer, all actions in the chart below were executed pre-dunning, before a collector knew the invoices would be late.
Figure 2. Pre-dunning actions, compared with the same buyer's unchased invoices, before accounting for targeting.
Taken at face value, chasing an invoice before it is due makes it later, which would make every action perversely ineffective. In reality, collectors target invoices they expect to be late. If we naively trained an agent on this data, it would predict that no action is always the best action.
Grouping comparable actions
Previous research demonstrated that this bias could be removed by clustering actions into similar groups and comparing the effectiveness of an action only against invoices within the same group. Within a group, comparable invoices that received a different channel stand in for the action we never saw. One objective of the hack was to identify a set of parameters that define similar actions. The conditions we finalized are below:
Collectors have different strategies, methods and skills. Buyers respond to each differently, and to the company they buy from.
Higher-value invoices are collected and paid differently.
Business payment behavior changes over time with success, failure, new policies, and staff.
A collection action one week after the due date is treated differently from one in pre-dunning.
We also applied topological rules to resolve action effectiveness more clearly. The comparison keeps only groups where a media choice was made (at least two media channels across at least two invoices) and drops any invoice that received two channels in one group, since the outcomes will be identical. Of the 2 million actions we started with, the conditions formed 450,000 groups, and the channel-choice rules kept 11,000 of them, covering 26,000 actions. This left only 1.3% of the original data, another reminder of the need for big data when it comes to AI development.
Measuring an action against its group
Inside a group, each action is measured against the average days late of the comparable invoices in that group, so zero means an invoice was paid like its peers. This group-centered outcome is what the rest of the work is built on. It lets two channels be compared on invoices that looked the same when they were chased.
The magnitudes of days late relative to the group-centered mean are not accurate, due to their sensitivity to the grouping algorithm. Change the groups, change the values. An Aimie agent cares more about when a phone call is better than by how much.
Figure 3. Actions compared with comparable invoices in the same group, across all dunning stages.
Once each actioned invoice is compared with invoices that looked the same, most of the lateness in Figure 2 disappears. Invoices actioned by phone cleared earlier than comparable invoices actioned another way.
The groups match on the invoice-action pair, modeling what a collector looks for when selecting a media channel. Comparing outcomes within a group then lets an agent understand why the collector picked a channel. A collector's knowledge of a buyer, such as which buyers pick up the phone, can now feed the agent's reasoning.
Storing a group-relative outcome
When representing the data as a graph, we hit some interesting challenges. The first schema in Figure 1 joined comparable actions with a SIMILAR_ACTION edge. It had nowhere to store the days late relative to the group's average, which belongs to one action, on one invoice, in one group. An action-invoice pair can belong to several overlapping groups, so neither node nor that edge holds a single value.
The revised schema defines a new unit, the Chase. A Chase node uniquely identifies one action taken on one invoice, which allows the same action-invoice pair to be a member of many different groups.
Furthermore, the Figure 1 schema specified a NEXT_ACTION edge. However, when one action can be executed on many invoices, this edge becomes poorly defined, as it does not specify which invoice the action was next for. With Chase as the unit, NEXT_CHASE links chases on the same invoice in time order.
Alongside this, we defined a SimilarGroup node. A Chase can therefore store the invoice's days late relative to the group mean on an IN_GROUP edge, so a Chase in two groups carries two edges to the group nodes, each with its own group-centered days late.
Figure 4 is one section of the graph with real data.
Figure 4. One section of the revised graph: two invoices, two actions each compared by two groups at different snapshots.
On the left, two actions chased the same invoice. Each action triggered its own chase, and the NEXT_CHASE edge links the first chase to its follow-up on that invoice. The right side repeats the pattern for a second invoice. Each chase stores its days late relative to its group's average on its IN_GROUP edge. The top SimilarGroup holds the first chase on each invoice and the bottom group holds the two follow-ups, so each group compares chases on two different invoices.
Exposing the graph to Aimie IQ
An agent choosing the next action needs to know whether this buyer would pay sooner with a phone call than with an email. It cannot observe the answer, so it needs comparable past decisions to stand in for it. The third objective of our hack was to expose the graph to Aimie IQ through a Model Context Protocol (MCP) server. This lets Aimie IQ decide which action to take next, with the comparable invoices behind the decision. Given an invoice, the agent finds its nearest comparison groups, compares outcomes across the channels in question, and answers with the comparable invoices it used. Figure 5 shows this reasoning.
Figure 5. Aimie IQ answering a channel question for a demo buyer.
This shows the LLM behind the Aimie IQ agent can navigate the graph. It takes the invoice a user or agent is working on as an entry point, finds similar invoices, and draws conclusions from how their outcomes differ. The same entry point extends to other differentiators, such as invoice status or invoice amount. It could also let a user ask Aimie IQ to justify an action, to "analyze the collection actions for this buyer", or "how well does this buyer respond to digital letters?"
What comes next
This exploration gives us a new way into the action data, reducing the targeting bias in like-for-like action comparisons and letting an agent navigate between comparable invoices. It shows Aimie which conditions make one action work better than another, such as the timing, the buyer, the invoice status, or the channel. That signal could then feed into the next generation of Aimie action model training, improving prediction performance while giving collectors the interpretation directly through Aimie IQ.
The same graph could let Aimie IQ answer questions such as:
- Why does Aimie predict a digital letter?
- Analyze my collection performance for disputed invoices with this buyer
- Is a follow-up action on this invoice worth it?
Future extensions of this work could include:
Predict the best sequence and timing of actions for a buyer
A graph neural network over chases, invoices and groups
Allowing the agent to enter, traverse and extract data more easily from the graph.
To help form groups and to remove the selection bias in the number of prior actions. An invoice on its fifth chase is there because the first four did not get it paid.
So a chase can be linked to the invoice status it moved.
