The Growing Importance of Order to Cash in the Age of AI

Growth should create leverage, not more administrative work.

If revenue doubles and your finance team is just reviewing twice as many receipts, that’s not scale. That’s linear workload growth.

That’s why I use Brex. Brex built an Intelligent Finance platform with AI agents that automate repetitive work — receipts, categorization, policy enforcement, reconciliation — so that finance output improves as the business grows, and I can focus on scaling the MM empire.

If you care about operating leverage, your finance stack should reflect that.

See why 35,000 companies like Anthropic, DoorDash (and me!) use Brex to spend smarter and move faster.

I’d like to buy you a beer if you live in the Bay Area on Thursday May, 14th.

Come hang with fellow Mostly Metrics readers.

I’ll be telling my favorite renewal rate jokes and I’ve asked the bar to play an eclectic mix of 80’s Joel and deep cuts from Creed’s second album.

Can’t wait to meet you IRL.

Giving stuff away for free has really changed.

I mean, we used to do this to an extent - try before you buy, the whole PLG thing.

But this was the traditional SaaS world where you hoped you’d get someone to commit and pre-pay for a whack of licenses after a 7 day free trial or a freemium plan that was paywall gated to get to full product depth. Now we are living in an era where it’s normal to give away some type of service, usually a number of LLM credits, to hook people. And those trials have an enormous cost.

So the question becomes how do we design better systems to improve our order to cash process so we don’t grow ourselves into the ground?

Now, you may be reading this on your phone on the toilet and say,

No, and it’s even worse. Your mentality still has to change.

The way software was historically been delivered allowed for:

This made for a nice timeline where you got paid before people used the service, and you only paid for your COGS after they both paid and used it

AWS tells you what you owe at the end of the month, then it's net 30 or 45 after that. So that's 60 days of float. And payroll is two weeks in arrears if you think about it.

That buffer is gone now.

The bulk of products now sell through one of two models:

As a result, you don't have the same buffer anymore. The negative cash conversion cycle within your COGS has evaporated.

For the longest time, the knock on software was that it wasn't profitable at the company level. But at least it was above the OPEX line. The gross margins were:

Your OPEX was where you burned the funding: people to build and sell the product, a few brave souls in G&A. But the gross profit was self-funding.

That's changing.

One caveat before anyone @ me: as you get into larger enterprise contracts, people start buying up and prepaying for credits. That alleviates a lot of the pain. But the longer tail of customers are probably not prepaying. The gap still exists.

And yet… order to cash has really been kind of like a fragmented series of systems up until this point. There's no real ownership.

It’s different pockets of stuff going on. A series of administrative points of entry and they're not connected.

Which is scary, because if your monetization model is messy, your whole growth engine is fragile.

And even if you aren't using LLMs in your product today, customer needs could look completely different in six months. Maybe you don't have an outcome-based resolution model. Maybe it's some hybrid. But you need infrastructure that can change without requiring six months of engineering work.

The challenge becomes: can you design a system where you're getting paid faster by customers using your AI than you have to pay your LLM bills?

Can we, in essence, outrun our LLM costs (especially when a large portion is dedicated to acquiring new users… essentially CAC).

You may never fully outrun them. But you can find enough efficiency to decrease your DSO (days sales outstanding). Even marginal improvements add up.

Here are five ways to improve your cash conversion cycle if you're selling an AI product on a usage or outcome based model.

Help reps go faster. You don't want them fucking around with dropdown fields when they are trying to get a deal done.

Before you start hunting for manual inputs to kill, you need a picture of what you actually want. What does the ideal process look like? What do reps touch, and what do they not? Where does data live, and what's the single system of record everything flows through? Write that down first. Most companies skip this and go straight to auditing the mess they have, which means they end up optimizing a broken process instead of replacing it.

Once you have the ideal state, work backwards. Map every place the current reality diverges from it. Every time a human touches a deal in transit — copying data from one system to another, chasing a signature, translating a contract into a billing field — that's a choke point. Assign a day value to each one. You'll find your DSO hiding in that list.

The other reason to start with ideal state: it tells you what kind of tooling you actually need. If you know what your system of record is supposed to be, you can find interchangeable pieces that plug into it cleanly — rather than buying tools and then figuring out how to stitch them together after the fact.

To make it concrete: there may be 2 days baked into your DSO just because contracts take forever to get sent out. Another 3 days from back-and-forths with confused customers who don't understand what they've been charged for. You'd be shocked at how many delays trace back to a process nobody designed on purpose.

A big mistake I see is people trying to find point solutions for every single part of the billing lifecycle.

That hurt to even write.

The instinct after seeing that list is to go find one platform that does all of it. Good luck. Tools that claim to own the full lifecycle rarely do any single part of it well. What actually works is designing the process flow first — how do you want a deal to move from signed to billed to collected, and who or what touches it at each step — and then finding tools that fit that architecture and talk to each other cleanly. The system comes second. The design comes first.

The difference matters because tool selection looks completely different depending on what you're optimizing for. If you've designed a flow where the CRM is the system of record and everything else writes back to it, you're shopping for different things than if billing owns the source of truth. Get that decision made before you ever sit through a demo.

Raise your hand if you've ever worked at a company that just kept adding SKUs because customers asked for them.

Here's why it becomes a billing nightmare: every SKU needs its own pricing logic, proration rules, upgrade and downgrade paths, and revenue recognition treatment. It compounds fast. A catalog with 40 SKUs isn't 4x harder to manage than one with 10. It's more like 10x, because the combinations multiply. I think the word for it is permutations.

Many a billing system implementation has gone off the rails before a single invoice got sent — just from the weight of the catalog.

And the irony is that you added SKUs when customers asked for more. Now those same customers are asking you to bundle things into packages. Your billing system was not built for either direction.

Every time I've watched a company fix this, they land in the same spot: 3-5 core packages, a handful of add-ons, and a deliberate decision to sunset or fold in everything else. Simple enough that a new rep can quote it from memory. If you can’t remember what you’re charging for, your customer is going to get lost in the sauce as well.

Biggie Smalls said Mo SKUs, Mo Problems.

Oh - Ironically, LLMs are actually great at helping you clean this up. Feed your order history into one and ask it to find which SKU combinations customers actually buy together.

This is a newer metric, but it's becoming one of the most important ones for AI businesses. Here's Kunal on what he's building:

The tokens are just the start. You're also paying for:

Kunal's framing for his engineering team: "If we didn't have an AI agent product, how much of this would we still need?" Whatever the answer is, that delta is part of your fully loaded AI cost. Start building that picture now.

This sounds counter intuitive so bear with me.

We talk about growth versus efficiency at the P&L level. But you have to make that call at the LLM level too: on each transaction, on each customer cohort, how much do you want to protect margin versus deliver the best possible experience?

Kunal's view:

Most people treat this as a binary. Protect margin or protect experience. The CFOs I've seen get it right treat it as a dial - something you tune over time, not a decision you make once and live with.

If your monetization engine is messy, your whole growth engine is fragile. And while it often goes unsaid, a unified order to cash leads to a better customer experience. People usually don’t look at billing as the customer experience it is. You can totally screw up how your customer feels about your ACTUAL product because the BILLING product is a terrible experience.

COGS are no longer a simple game. You can’t run your goal line offense. FB dive up the middle isn’t working and the wishbone offense is no longer around. It’s more complicated. So I get you may not have inventory but it doesn't really matter if you don't get the foundations right. The world is changing so quickly around us where you have to be agile, you have to experiment with different pricing needs.

Order to cash is really the manifestation of your business model, the critical stuff that no one sees but it's the growth engine that's there. Don’t let it work against you in this new age.

Hoping you collect your net 30 payments in 30 days,

CJ