In conversation with Alex Louisy, co-founder and CEO of Upflow
Barely a week goes by without another vendor announcing an "autonomous collections agent." The claims are getting bolder, the demos slicker, and the noise, frankly, deafening. So we sat down with Alex Louisy, who has spent eight years building Upflow into one of the most credible names in accounts receivable, to separate the signal from the marketing. His central argument is simple and, if you run an AR book, worth listening to: Creating an AI collections agent is easy. Building one you can actually trust with your book is an entirely different discipline.
Here is what that difference looks like.
Everyone is shipping an "AI collections agent" right now. What's the difference between building one and building one that works?
The uncomfortable truth is that automation in finance has never been the hard part. It has always been easy to fire off an automated email, to draft a reply, to trigger a workflow. You can wire something onto the back of your ERP in an afternoon and demo it beautifully. The hard part, the only part that has ever mattered, is whether you can trust it. Can I trust that this message went to the right person, said the right thing, and moved the account forward rather than damaging a relationship I have spent years building? That is the real question, and it is conveniently missing from most of the marketing. So when people ask me about the difference between a poor collections agent and a good one, I say the difference is entirely about trust, and trust is not a feature you announce. It is something you earn, slowly, in the product.
You talk about a hierarchy of needs in AR. Where should teams actually start?
From our experience, finance professionals often try to apply AI to complex problems, first. We argue they should do the opposite. Start with the simple tasks, not the complex cases. In our data, somewhere between 70 and 80 percent of the interactions a receivables team handles are technical, not commercial. Those customers aren’t refusing to pay, they just can’t. The invoice went to the wrong contact, the PO number is missing, the direct debit failed. These are not complex tasks. They are friction, repeated thousands of times.
My favourite example: we know that once you sign a new customer, around 20 percent of first invoices go to the wrong person. They go to whoever signed the order form, which is almost never the person who pays invoices. That individual then has to notice the email, care enough to answer that they are not the right point of contact, and forward it to Finance, which doesn’t often happen. That single failure mode quietly delays a huge amount of cash.
This example is precisely the kind of thing agents are genuinely excellent at: reading the mess, classifying it correctly, "this is a wrong contact, this is a promise to pay, this is an invoice request," and taking the right next step. It is not glamorous. But get the unglamorous 80 percent right and automatically done, at scale, and you have already transformed the working day of a finance team. That has to come before anyone talks about autonomy.
So where does fully autonomous collection actually fit in?
Later than people think, and selectively. If I look at a typical merchant maybe 20 percent of their customers are enterprise. Those are the last things I would ever put on autopilot. The relationship is too valuable and the edge cases too costly.
It is actually the same logic finance teams have always applied. In the old world, you automated the long tail, the smaller accounts you did not have time to touch personally, and you kept the important relationships in human hands. Agents do not change that principle, they just raise the bar for what "automated" can safely mean. You roll out autonomy where the cost of a mistake is low, you prove it works, and only then do you extend it.
You keep returning to trust. How do you build it into the product rather than just claiming it?
You reject the black box. The model most of the market is quietly selling is: switch it on, it will work automatically. The reality is you find out a month later which customers are shouting at you. That is not a trust model, that is a gamble, and no serious finance leader is going to take it with their own receivables.
What we do instead is build the trust layer into the mechanism. The first thing our agents do is learn from the past. We have years of real human traces inside Upflow, the actual way a client's collections team has worked, what they said, when they escalated, how they handled each situation. When we launch an agent for a customer, it ingests how that team has genuinely operated, sometimes over several years. So it does not start from a blank page with a generic tone of voice. It starts already sounding like you, already reflecting your judgement. That is the difference between an agent that represents your business and one that merely sends emails under your name.
From there, we give our users significant control over the operation of the agent. You can clearly set the boundary of what they are allowed to do, not to, and when to escalate to a human, to ensure that the finance team is always in control. No black box.
Finally, we give our users a lot of insights on how those agents are performing. Those analytics are closing the loop on the level of trust. These analytics are not only volume driven, they also measure the quality of the interaction with the customers, as you want to make sure anyone in the business, including your agents, improves your customer relationships.
If you combine the past behavior, strong controls, and insights to close the loop, you have the foundations of how we built “trusted agents”.
What does that look like day to day for a finance team?
Three modes, and the team chooses: manual, semi-autonomous, and fully autonomous. Most people live in semi-autonomous for a long time, and that is by design. The agent proposes, the human confirms. It suggests the classification, drafts the reply, recommends the next action, and the user accepts it or edits it.
The crucial part is what that accept-or-edit signal gives you. We can measure how often a suggestion is accepted as-is, and how often it needs editing first. That is the trust being quantified. And, importantly, it is the user who decides when the number is good enough to let go of the wheel, not us telling them it is ready. Over time, as confidence grows, the share of the book running autonomously expands. My expectation, product-wise, is that it keeps growing until it is most of the book, but rationally, earned account by account. Someone should never wake up and dump their entire ledger onto an agent to see what happens. They should arrive at full autonomy because the evidence took them there.
Some people say that platforms who launched before the advent of AI will never be able to match the performance of AI-native providers. What do you say?
I would argue it is the exact opposite. Thanks to the AI labs such as Open AI and Anthropic, building the AI component isn’t hard. The harder part is to build the infrastructure needed for an effective collections platform. For example, the connections we built over years, into ERPs, payment gateways, email providers, CRMs, are not baggage. They are the foundation the agents stand on. An agent is only as good as the data and the reach it has. You can be as "agent-native" as you like, but if you cannot see the invoice, the payment status, the contact history and the business context from your CRM and email inbox, and act across all of them reliably, you do not have an agent, you have a demo. The plumbing is not the boring part of this story. It is what makes the intelligent part possible.
How should a CFO separate the myth from the reality when everyone is making the same claims?
Look at the logos, and look at the use cases. Not the homepage, the customers. Anyone can write "autonomous agents" on a website. Far fewer can show real companies trusting those agents with real work at scale. The claim that matters is not "we have autonomous agents," it is "we automate processes that customers actually use and trust," and that leaves evidence. If a vendor cannot point to that evidence, then you can draw your own conclusions.
There is a related trap I would warn teams about, which is the build-it-yourself temptation. Right now a lot of capable people look at this and think, I have the tools, I will just build it in-house.
From a product perspective, you can build something that drafts a reply. What you will discover is that the drafting was never the hard part. The reliability at scale (especially if you’re managing high volumes of customers/invoices), the connectivity, the edge cases, the trust, the years of behavioural data, that is the work, and it does not come for free just because the language models are now good.
From a security perspective, you also need to be careful before allowing a DIY solution to access your ERP and other critical systems, to turn them into communication channels. Customer data (who they are, how much you charge them, etc) is one of the most valuable assets and that should not be gambled with. Here again, applying the highest security standards, such as SOC 2 Type 2, make sense when evaluating vendors.
If you strip away all the noise, what's the one thing finance leaders should hold on to?
Honestly, one principle, and it's the same one we started with eight years ago. Everything we've just talked about, the build-versus-buy question, the penetrating questions about track record, the refusal to gamble with your customers, all of it collapses into a single idea that’s anchored into our Financial Relationship Management value proposition, the category we pioneered.
My tagline has not changed the whole time: it has always been easy to create automation in finance, the only question that has ever mattered is whether you can trust it. Everything we are doing with agents is just the same question, asked at a higher, much more powerful level. Get the trust right, and this genuinely transforms how finance teams work and your customer relationships in a positive way. Skip it, and you have built a very expensive way to damage your relationship with your customers at scale.
If you want to hear how Liquidity Lab helps clients manage the challenges raised by Alex, such as how to build agents which learn from your feedback, drop us a note.