Cut the searching, not the checking

Aria finances invoices. A supplier is paid now for an invoice their own customer will settle in 30 or 60 days.

Between the customer paying and the supplier being able to finance the next invoice sits reconciliation: matching the payments we get from customers to the invoices we financed. Until that matching is made in full, the money has arrived yet nothing has moved. Traditionally, that decision was a person's job. An ops agent read a bank label, an amount and a date, and went looking for the loan it closed. When a transfer arrives, it has to be matched to one of 1,778 open financings on average, up to 21,000. The expensive part was never the deciding at the end of that search. It was the search.

An hour with a debt collection agent

Before designing anything I sat with one of the agents for an hour. What I expected to watch was somebody working through the queue in our tool. What she actually did was keep our tool open on one side and a spreadsheet she maintained herself on the other, and work out of the spreadsheet.

The spreadsheet was not a workaround for a missing feature. It was where she kept the thing our product had no place for: what she already knew. Which payer a given sender name usually turns out to be, which debtors pay in odd amounts, what she checked last week. Our tool asked her to start every transfer from nothing, 1,778 candidates deep, and she had quietly built herself the memory it lacked. That hour set the objective. Not to make her faster at searching, but to stop making her search.

Three signals, and why none of them decide

An engineer and I built matching from three signals carried by data we already had: does the sender name look like the debtor's name, does the free-text label contain something shaped like an invoice number, does the amount match an invoice exactly. Measured over twelve months of real transfers, at least one of them fires on 75%+. All three match about 2%. The signals are complementary but not perfect: excellent for coverage, poor for confidence, since for most transfers you hold exactly one of them, and one signal is a hint, not proof.

Given a wrong match redirects money to the wrong party, we have no place for hints. So we decided that nothing auto-applies. Instead, ops stop searching and start reviewing. That is a different job, and a much faster one.

What I parked

The obvious fix is to give every supplier their own account to receive on. Then the account the money lands in tells you who it belongs to and the search collapses before it starts. It is a good answer and I parked it: it means migrating every client onto per-supplier repayment wallets, which is a change at our payment provider and an operational change at every client, and it would land long after the team needed relief. Letting clients reconcile their own invoices in our portal I killed more cheaply, on the argument alone, because it does not remove the work, it relocates it onto somebody whose goodwill we depend on and who has less context on the debtor side than we do. Not every idea deserves a prototype.

Clients noticed before anything measured it

In early 2026, reconciliations were not the top of our priorities. We saw volumes rising and we wanted to help ops team handle it. Yet we heard back from clients that the impact was larger than expected. Money was no longer stuck somewhere unexplained, and there was more room to finance the next invoice.

That was enough for the work to stop being a line on somebody's roadmap. This is how I started running a team of 3 owning reconciliation and cash recovery.

Because overpayment happens more than 30% of the time, a reconciliation is a reviewable object rather than a single action: what came in, what it was applied to, what is left over. The remainder is shown as a balance, not hidden.

A queue is a supplier who cannot finance today

Each supplier has a ceiling on how much financing can be running at once. A loan occupies part of that ceiling until a repayment matches it in full. Matching releases the ceiling, the ceiling releases financing, and Aria pays the next invoice.

So a repayment sitting unmatched in an internal queue is not an ops inconvenience. It is a supplier who has been repaid by their customer and still cannot finance anything today, looking at a limit they believe they already cleared. That is what the clients had described back to us, before there was a number for it. It is also not what I designed against. I designed against the searching; the waiting is what made the searching worth cutting.