Your Complete Guide to Quote to Cash: Part 3

How much cash is your billing process leaving on the table?

Every extra day between delivering value and sending an invoice is another day you’re waiting to get paid.

And as pricing gets more complex, with usage, tokens, credits, commitments, and custom terms, billing lag compounds fast.

Tabs is built to eliminate that lag by turning contracts and usage into accurate invoices automatically, without the spreadsheets and manual work.

The impact? Faster billing. Faster cash. Less work for finance.

So what is billing lag costing your business?

Use the Tabs Billing Lag Calculator to get your number. 

Gee wiz. I run a recruiting company now. Life comes at ya fast.

We do finance hiring. And we place at the manager, director, and VP levels.

Welcome to our final post on the quote to cash process.

Five layers down, three to go.

You'll notice that every layer we've covered so far has a HEAVY product element to it. And the three elements we'll cover today (finally?) tilt towards finance.

Though that's a little misleading... Each of them got harder because of decisions made upstream, by people who don't work in finance (also why we can’t have nice things).

Way back in post one I asked whose job the Q2C process actually is?

It's fundamentally an operational process that needs to have heavy finance ownership because you need to get that money in the bank.

In a tech company it's increasingly becoming a product problem, because pricing and packaging sits with the product team. Your pricing and packaging is a manifestation of your product strategy.

And that product strategy now includes how you make money, pay taxes on that money, and recognize the revenue (which is kind of sorta different than "making money" if you've been around accounting departments long enough).

Everything we've talked about so far in this series (usage based pricing, hybrid pricing, having global customers, enterprise agreements) all sounds like a billing problem. But it's simultaneously a tax problem.

At some point billing complexity creates tax complexity.

Any company selling anything more than one SKU in one geography needs to think super hard about tax. Even in the US there are tax permutations for tax on event and ticketing vs tax on software. And tax thresholds vary by states, and even counties (Suffolk County, MA, what up, represent!) which is hard to track manually.

Also, California…

Tax is like rev rec in the sense that it's a compliance obligation you need to stay on top of.

As you think about usage based billing and emitting events and capturing those events with a metering system, you need to make sure that for everything you sell you have a tax system that can charge the right tax and grow with you as your strategy changes.

And that it handles the entire tax life cycle… just like billing, tax has a lifecycle. You have to register, then calculate, then file, and then remit.

Therefore, every SKU needs the right product tax code, because the system can only charge correctly if it knows what you actually sold.

And in a lot of geographies the invoice has to render the tax rate and show how it was calculated. Get that wrong and the invoice isn't compliant, which means you're (obvi) not collecting on it either.

People often think tax is something that happens after the transaction goes down (myself included). But I've learned through trial and lots of painful error that you have a better shot at getting it right when it's embedded in the transaction itself.

Why is getting paid more complicated than you'd think?

Surprisingly, it's not because your customers don't want to pay you (most of the time). It's because there are lots of humans in the loop and systems between companies that don't talk, and love to auto reject if you're off by a penny.

Customers pay slowly unless you have a very mature collections department and you are willing to enforce the penalties on collection. And not many companies actually charge 2% interest, or whatever the law will allow them to, when a customer is late. Because they don't want that customer to churn!

And we have to remember that everyone is trying to run the best cash conversion cycle possible. You are not the only one. Everyone is playing the same game.

Right now collections are treated as a back office function, and let me tell you, this function is RIPE for AI disruption. Maybe not for the mega large customers you have (still contact them with a human and a thanks for your biz), but for the long tail of customers whom you trade 12 emails and 11 attachments for $120 bucks, yea agents can help.

At the moment we spend a ton of time with humans parsing through inboxes. They go down the queue and they get to it when they get to it. And if you mess up anything you go back to the bottom of the queue.

If we wanted to make an analogy to another part of the org, we've seen Customer Support get a complete facelift with AI. This is bound to happen with collections, which are, at their core, also a customer support function (how you interact with a customer at the point of payment is ABSOLUTELY a customer support type function). Similar to customer support an AI agent can triage simple things like the bank account being off, and speed up the collections lifecycle.

Yes, there are sometimes people who do not want to pay you. But there are many more that want to pay you but cannot because of a simple mistake.

Failed payments are another type of collections problem. There's a lot of tech that tries to collect using machine learning retries (or building a dunning system like I did and totally sledgehammering everyone with late notices until they officially churn… woops).

What's most important, system or no system, is treating collections like a disciplined process. That means we cannot sign contracts without building the muscle organizationally to make sure we collect.

The final reason collections can be hard are if people are not, well, using the product you want them to pay for. Usage based pricing introduced this fun quirk to shelfware. If people don't use the product, you may end up invoicing them for merely the minimums because it's a usage based contract and the rep disappeared after signing the deal.

And this goes back to running a disciplined process from sales through Q2C. We sign the contract, then we make sure the customer actually gets onboarded and uses the thing. If the contract is built on usage, we need sellers who drive usage.

We've quoted the deal, we've signed the contract, we've provisioned the product, we've billed the customer, we've calc'd tax, and we've collected cash.

From an accounting perspective we're almost at the moment of truth.

If you're actually in a subscription world your life is pretty simple. You can do it in a spreadsheet and amortize based on the contract term.

It's trickier with usage because the revenue is variable and your deferred balance is shrinking. That second part is a forecasting problem more than an accounting one. Deferred revenue was the thing that told you what next quarter looked like, but consumption models mean you don't know when revenue is coming in. I've discussed this at length in my writeups on Snowflake and Databricks. By definition, variable revenue is bursty and spikey.

Then there's the cutoff. Where do you stop your accrual when usage arrives late because the metering pipeline reports in arrears? That's a judgment call, and it's much better made in advance than on an ad hoc basis.

So make it in advance. Write down every way usage billing can go wrong, then write the policy.

There are many opportunities for leakage in the flow when it comes to the equation of the value you deliver vs the value that you recognize.

We've followed a dollar through a company, the way you once followed a bill through Capitol Hill. Throughout this we had billing at the center.

Tax got complicated because billing got complicated. Collections got harder because usage minimums invented a new flavor of shelfware. And rev rec got harder because the metering pipeline reports in arrears and CPAs weren’t exactly trained to deal with that type of stuff.

Billing stopped being backoffice shit when pricing became product shit.

Is someone who sits away from the product team going to know that giving someone read and write access via the new MCP is going to tank the company's costs? Not until you tank it!

At a high level, when it comes to CPQ, the tension I often hear about is velocity. As Ricky Bobby says, I just wanna go fast.

While finance wants the new pricing model live this quarter, because it will make a bunch of money, the CPO is the one who has to come back and say the billing system does three of the five things we need. Therefore, somebody has to write shit glue code for the other two, so maybe we can do it in three months?

I am not an engineer. But I know that owning the whole chain from product event down to invoice, entitlements included, is hard engineering.

When the pricing and packaging decisions that determine your revenue growth and your unit economics are being made at the speed of the product team, the finance systems gotta keep up.

Go forth and prosper. And bill / recognize / collect that money.

I covered the entire Quote to Cash Process (in excruciatingly fun detail) with Stripe’s former Head of Product for Billing, Wisam Hirzalla. This is the DEEP cuts.

Wishing you gross margins that move for reasons you picked,

CJ