Legacy AR automation and AI native collections: what actually changed

The accounts receivable platform a finance team bought six or seven years ago is probably still doing exactly what it was sold to do. Reminders leave on schedule. Invoices reach the right inbox. Customers pay through a portal. The aging report refreshes overnight. Nothing is broken, nobody is complaining loudly, and the renewal goes through each year without much discussion.

In a large number of those same companies, that platform sits about three feet from a collector who spends the first hour of every morning deciding by hand which thirty or forty accounts to chase that day.

Both things have been true for years, and for most of those years the second one was simply the cost of doing business. What shifted recently is that the triage hour stopped being unavoidable. This article characterises what the first generation of AR automation genuinely solved, why it stopped where it did, what moved underneath it, and how to tell whether any of that reaches your team. The last part includes the cases where the honest answer is that it does not.

Before the shortlist, decide which shape of software you are buying

Most finance teams shop a list of collections tools. A collections tool automates one step of the order-to-cash cycle. In this category the step is the sending, which is why the deciding still starts your morning. What sits alongside that choice now is an end-to-end order-to-cash analyst: from a step to the whole cycle, from one policy for every account to one estimate per customer, from a queue you sort at eight to a queue that arrives ranked, from three desks holding credit, collections and forecast to one owner of the book. Either shape can be right. The shape decides your ceiling.

Key takeaways

1. The first generation of AR automation solved the sending. Scheduled dunning, invoice delivery, payment portals and aging dashboards are largely finished problems, and the platforms built around them do that work reliably today.
2. The unsolved half of collections has always been the deciding: which accounts to work today, in what order, with what message. That stayed with the collector because it depends on per customer payment behaviour, which a rules engine has no way to represent.
3. The clearest test of whether the second era reaches your team is whether AR headcount has grown roughly in step with invoice volume. If it has, automation solved sending and left the actual constraint untouched.
4. Quadient AR, which many finance teams still call YayPay, is a capable first generation platform for invoice delivery, scheduled cadence and aging visibility. The gap worth examining at renewal is who assembles the daily call list.
5. Staying on a first generation platform is a defensible decision. A team live for under a year, with flat invoice volume and a configuration it likes, will spend more on a migration than it recovers in the first year.

What did the first generation of AR automation actually solve?

Sending at scale, and it solved it properly.

Before these platforms existed, dunning was a person, a spreadsheet and a mail merge. Invoices went out attached to individual emails. Follow ups happened when somebody remembered. Whether a customer had received an invoice at all was a question answered by asking them. The first generation fixed all of that with real engineering: scheduled reminder sequences, escalation ladders that pull in an account owner at the right stage, invoice delivery with confirmation, a self serve portal where customers can view balances and pay, an activity log so any collector can see what was said, and an aging dashboard that gives a manager the shape of the book in one screen.

None of that was trivial to build. Email deliverability at volume is a genuine engineering problem. Keeping open invoice data in step with an ERP that was never designed to publish it is harder. A customer facing portal that a finance team trusts enough to point its largest accounts at is harder still. Those platforms earned their place, and the ones that still lead on delivery and cadence continue to do that job well.

If your requirement stops at reliable sending, your current tool is probably fine. Nothing further in this article is going to change that, and you should be suspicious of anyone who tells you otherwise.

Why did the first generation stop where it did?

Because the deciding depends on information those systems were never built to hold.

A rules engine expresses policy. If an invoice is 30 days past due and the balance is above a threshold, send template B, then escalate on day 45. Policy is uniform by construction, which is exactly what makes it dependable. Every account of the same age and size gets the same treatment, and the treatment is auditable.

Ranking is a different kind of statement. To put one account above another you need an estimate of how that specific customer behaves: how they have paid across their own history, how long their approval cycle runs, which contact actually responds, what an early warning looks like for them rather than for the average customer. Building that requires holding per customer history, scoring it, and keeping score as behaviour moves. A rules engine has nowhere to put any of it.

There was also no commercial pressure to build it. Through most of that period, AR software was bought on feature checklists, portal branding and integration counts. A vendor that spent two years building per customer payment models would have had nothing to show on the checklist that won deals.

Then. Configuration answered the question of what everyone should receive on day 30. Now. The system answers the question of who is likeliest to slip this week and why.

What did that leave sitting on the collector's desk?

Two things: the triage hour, and the institutional memory.

The triage hour is easy to quantify. Take four collectors, each spending an hour every morning sorting an aging report into a call list. That is 20 hours a week. Across a working year it lands near 960 hours, close to half a full time role, spent deciding what to do rather than doing it. That half role produces no calls, no emails and no collected cash. It exists purely to convert a list sorted by date into a list sorted by judgment.

The institutional memory is harder to quantify and more expensive to lose. In most teams one or two collectors hold the real map of the book: which controller signs off on Fridays, which customer disputes every freight line, which account always pays on day 47 no matter how many reminders arrive. When that person changes jobs, the ranking quality drops the following Monday, because the ranking lived in their head and the system holds no copy.

There is a third cost that gets noticed late. Uniform cadence means the customer who reliably pays on day 47 receives the same four escalating reminders as the customer who is quietly heading toward a write off. One of them ignores the reminders because they always pay eventually. The other ignores them because reminders were never going to be the intervention that worked. Sending the same sequence to both trains everybody to treat your dunning as background noise.

Then. The system knew an invoice was 40 days old. Now. The system knows that 40 days is normal for this customer and alarming for that one.

What changed underneath the interface?

The system now holds a per customer estimate of payment behaviour, and it acts on that estimate rather than presenting it.

In practice this shows up in four places. The work queue arrives ordered by likelihood to slip, built from that customer's own payment and dispute history rather than from days overdue and invoice size. Outreach is drafted in the register that has worked with that relationship before, so the first message a collector sends is an edit rather than a blank page. The ranking updates when behaviour updates, which means a customer who starts drifting surfaces while the balance is still small. And cash application runs against the same underlying data, so payments and remittances match without a person keying them.

That last point is the one buyers underrate, and it is measurable early. In a proof of concept with a customer processing over a million invoices a year, data was visible within one day of connecting the ERP, and 78 percent of 1,150 ACH, wire and lockbox payments matched automatically before anyone configured a single rule. Out of the box, on live payments, with no tuning. The remaining 22 percent is real work, and any vendor claiming otherwise is describing a demo rather than a deployment. The mechanism that makes any of this checkable is that a proof of concept runs on your own data before you sign, so the figure you carry into the decision is a figure from your own book.

Then. Evidence arrived when the configuration project ended. Now. Evidence arrives while the evaluation is still running.

Then and now, one operational question at a time

The generational change is easiest to see when you take it one question at a time rather than one feature at a time.

Read down the middle column. Every one of those first generation answers is a correct answer to the problem as it was understood at the time. That is the point. The category did not fail at what it set out to do. It finished, and the remaining half of the job needed a different kind of system.

What does the second era look like on a Tuesday morning?

The visible difference is that the day starts with work rather than with sorting.

A collector opens the queue and the first fifteen accounts are already ordered, each with a short reason attached: this customer has stretched from 38 days to 52 across the last two cycles, this one has an unresolved dispute blocking a large invoice, this one has a controller who has stopped opening messages. Drafts sit against each account in the tone that has worked with that contact before. The collector's judgment goes into editing and calling, which is the part of the job that only a person can do.

Then run the arithmetic on your own book, because that is what decides this. One day of DSO on a company doing $120M of annual revenue is roughly $329,000 of cash sitting in receivables instead of in the bank. Tesorio reports an average DSO reduction of 33 days across its customer base, a 3x increase in collector productivity, more than $200M of working capital freed up for customers, and a 98 percent platform retention rate. Averages across a customer base are a reason to run the calculation on your own numbers rather than a forecast of what your book will do. Take your revenue, divide by 365, and decide for yourself how many days of DSO would need to move before a replacement project pays for itself.

How does Tesorio compare to Quadient AR, formerly YayPay?

Quadient AR, which a large number of finance teams still call YayPay, is a capable first generation platform. The difference worth examining at renewal is who decides the day.

Start with what it does well, because it does several things well. Quadient AR handles invoice delivery at scale, scheduled dunning with escalation, a customer payment portal, aging and collections visibility, and activity tracking across a credit to cash workflow. Collectors who have used it for years know it. It is established, it is familiar, and the cost of leaving a platform that works is real and frequently underestimated. A team whose requirement is reliable sending is generally well served by it.

The naming itself distorts evaluations, so it is worth being explicit. YayPay was folded into Quadient's portfolio and the product now sells as Quadient AR. Buyers researching under one name routinely miss the reviews and discussion written under the other, which leaves them working from half the available evidence. If you are running this comparison, search both names and read both sets.

The gap follows the same line as the rest of this article, and it runs between two categories rather than between two logos. From a collections tool you get the book presented and the ranking left to your collector, which is precisely what that category was designed to deliver. From an end-to-end order-to-cash analyst you get a book already ordered by likelihood to slip, outreach drafted from how that customer has paid you before, and an order that revises itself when the behaviour moves. Tesorio was built to the second shape. Whether your book needs that shape is a question your own Tuesday morning answers.

On scored comparison, there is a gap in this page and it is deliberate. We hold verified G2 index data for our own product and none for Quadient AR, so no scored head to head appears here. Publishing estimated figures would make every other number on this page easier to dismiss. What can be sourced: in the G2 Summer 2026 Enterprise Accounts Receivable reports, Tesorio ranks first in all three indices, with Usability at 9.03, Implementation at 8.59 and Relationship at 8.69. Time to go live measures 1.31 months against a category average of 5.35 months. User adoption sits at 95 percent against a category average of 64 percent, and Ease of Admin at 99 percent against a category average of 85 percent. Those figures describe Tesorio against the category, and the category average includes platforms this article does not name. Pull both G2 profiles yourself and weigh implementation and adoption heavily, since those two tell you more about your first year than any feature count.

Five questions to put to Quadient AR, or to any incumbent, before you renew:

1. When two accounts are the same age with the same balance, what does the system use to decide which one my collector works first?
2. Show me an account whose priority changed this month because the customer's behaviour changed, and show me what triggered the change.
3. What share of incoming ACH, wire and lockbox payments match without a person touching them, measured on my data rather than on a prepared demo set?
4. Which configuration changes can my team make without filing a support ticket, and which ones need you?
5. If invoice volume doubles next year, what happens to the size of my collections team?

One honest note in their favour. A team already live on Quadient AR, keeping pace with its book and content with scheduled cadence, has no strong reason to move. The case for switching rests entirely on collector capacity, and if capacity is not your constraint then the case does not exist.

What should you be sceptical of when a vendor says its agent decides which accounts get worked first?

Four things, and the fourth catches most people.

Claims about an agent with no measurable output. Ask which decision the software makes on its own: whether it ranks the book by likelihood to slip and reorders that ranking as a customer's behaviour changes. Drafting text is the easy half and every vendor in the category can now do it. Ranking accounts by likelihood to slip, and being measurably right about it, is the half that changes a collector's day. Ask how accuracy is measured and what the vendor does when the ranking is wrong.

Any promise of flawless integrations. Integration reliability is the most common complaint across the accounts receivable software category, and a vendor who tells you failures do not happen is telling you they have not looked. The useful questions are what happens when a sync fails, how long detection takes, who owns the fix, and whether a failed sync silently pauses a cadence that a collector believes is still running.

Replacement projects justified on features. If the business case rests on a capability the team will use twice a year, the migration cost will exceed the benefit. The case has to rest on daily work, which means it has to be expressible in hours per collector per day or in days of DSO.

Evaluations run on vendor prepared data. A demo built on a clean sample set proves nothing about your book, where the interesting behaviour lives in partial payments, credit memos, consolidated remittances and disputed freight lines. Insist that your own ERP is connected during the evaluation, and set a number in advance that the trial has to hit. An automatic match rate on your real payments tells you more about how the first year will go than any scripted walkthrough.

When is staying on a first generation platform the right decision?

More often than a vendor will tell you. Four cases where staying put is the correct call.

You went live in the last twelve months. The switching cost will exceed the gain this year regardless of how good the destination is. Revisit in four quarters.

Your invoice volume is flat and your team is holding. If AR headcount has not moved while volume has not moved, the triage hour is a fixed cost you have already absorbed. Spend the project budget somewhere with a bigger constraint.

Your DSO problem starts upstream. If late payment traces back to how sales negotiates terms, or how billing issues invoices, or how disputes get resolved, replacing collections software will disappoint you. Fix the upstream process first, then re examine.

One frustrated administrator is driving the evaluation while the collectors are content. That is an admin workflow problem wearing a platform problem's clothing. Solve the workflow, then revisit the platform question in six months with firmer evidence.

How do you tell which era your own problem belongs to?

Four questions, answered honestly, in about twenty minutes.

1. Has AR headcount tracked invoice volume? If volume grew 30 percent and the team grew 30 percent, automation solved sending and left the constraint exactly where it was. If volume grew 30 percent and the team held flat, something in your process is already absorbing the difference and you should find out what before you buy anything.
2. Who decides the daily call list, and how? If a person sorts an aging report every morning, multiply that hour by your collector count and by 48 weeks. That number is the size of the prize, and it is the one the finance committee will ask about.
3. What happens when a collector leaves? If their account knowledge leaves with them, that knowledge was never in the system, and you are carrying a key person risk on a process that touches every dollar of revenue.
4. How much of your dunning is one cadence for everyone? Uniform cadence is the clearest available sign that the tool cannot differentiate between customers. Count how many distinct sequences are actually running. If the answer is two or three across hundreds of customers, you have your answer.

If those four answers point at sending, your current platform is doing the job you bought it for. If they point at deciding, the constraint is structural and no amount of additional configuration will reach it.

Where this leaves you

The first generation of AR automation solved a real problem completely, and the platforms that own delivery and cadence continue to do that work well. Teams whose volume is flat, whose headcount is holding and whose collectors are content should stay where they are and spend the money elsewhere.

The teams for whom something genuinely changed are the ones where AR headcount climbs with invoice volume, and where the book stays clean because one experienced collector holds the map. That is a structural constraint rather than a staffing one, and it is the specific thing the second era addresses.

The question sitting underneath the Quadient AR comparison

Quadient AR does what a collections tool is built to do: it takes the sending off your team and shows you the state of the book. Plenty of teams need that and nothing more. An end-to-end order-to-cash analyst is asked for a different job: hold credit, collections, cash application and the AR forecast in one place, and answer for the cycle rather than one step of it. From step to cycle. From policy to behaviour. From a screen that reports to a system that ranks and keeps re-ranking. If sending is your constraint, renew with confidence. If deciding is, no collections tool on the shortlist reaches it.

See what an agent that ranks your book by likelihood to slip actually decides