Three in four B2B software companies changed pricing or packaging in the last twelve months, and the fastest-growing were roughly three times more likely to adjust frequently.
Most of the tooling conversation is about making changes fast. A no-code product catalog means you can launch new pricing without waiting on engineering, and billing stops being a developer problem. That part is largely solved.
The part that is not solved is knowing whether the change is any good before your customers find out.
Most pricing decisions are still made from a spreadsheet model built on assumptions about usage, then shipped, then evaluated a quarter later from revenue. By which point three things have changed at once and nobody can attribute the outcome to the pricing.
There is a better move available, and almost nobody uses it.
Replay the rate card against usage you already have
You have every usage event from last quarter. A rate card is a function from usage events to an invoice. So run the new function over the old events.
That gives you the invoices your proposed pricing would have produced, per customer, for a period where you already know what actually happened. No assumptions about adoption. No modelled usage curves. The real distribution, priced two ways.
It converts a pricing decision from an argument into arithmetic, and it costs nothing but compute.
Four questions it answers that a model cannot
Who gets materially worse off, by name. A spreadsheet tells you average revenue per account moves up 12%. A replay tells you that 14 specific customers see a bill increase over 40%, and here they are, and here is their combined ARR. That list is the difference between a pricing change and a churn event. You cannot produce it from a model because the pain is always in the tail.
Whether your margin survives the tail. Revenue is the easy output. Run cost through the same replay and you get gross margin per customer under the new card. At a median AI gross-margin target of about 50%, a blended number is the average of profitable small accounts and unprofitable large ones. The replay shows you which accounts go underwater and at what volume, before you have committed to the price.
Whether the shape is right, not just the level. Two rate cards can produce identical total revenue with completely different distributions. One takes more from a handful of heavy accounts; the other spreads it across everyone. Same number at the bottom, very different renewal conversations.
What the allowance is actually costing you. Included usage is usually set to make a price page look right. Replay tells you how many customers sit just under the allowance, which is where margin looks best and expansion goes to die.
Then ship it in an order that cannot surprise anyone
The replay is step one of six, not a substitute for the rest.
- Replay the candidate card against two to four quarters of real usage. Model per-customer margin, not just revenue.
- Size who gets worse off. Name the cohort, count it, total its ARR. If you cannot produce that list you are not ready.
- Roll out to new customers first. You get a clean signal without breaking the cost expectations existing customers built their budgets on.
- Hold two billing cycles and watch adoption, not revenue. Revenue hides the most important failure mode. If a fee is suppressing feature adoption, you see it in features-used-per-account long before you see it in churn.
- Migrate existing customers deliberately. Version the plan, grandfather the old one, set a price-lock period. Never move anyone into a worse deal silently.
- Announce before the invoice arrives. A pricing change discovered on a bill is a support ticket with a renewal attached.
Step 5 is worth dwelling on. One vendor in 2026 tested moving an existing capability behind a higher tier and got a public backlash for it. Adding a premium tier is ordinary. Moving something people already have is not, and the difference costs nothing to respect.
What has to be true architecturally
A replay is only possible if three things hold, and they are the same three that make fast repricing possible in the first place.
Usage events are stored, not just aggregated. If you only keep monthly totals, you cannot reprice them under a card with different tiers or dimensions. Keep the events. This is also why auditable usage data matters beyond compliance.
Rate cards are data, versioned. A new price is a new version, not a code change. If pricing lives in application logic, your repricing cadence is your deploy cadence and a replay means running an old build.
Pricing is separable from metering. The meter records what happened. Pricing decides what it costs. Keep them apart and you can ask "what would this have cost" as a query rather than a migration.
Get those and the replay is close to free. Miss them and no amount of pricing strategy helps, because you cannot evaluate a change until it has already happened to somebody.
The short version
Everyone is optimising how fast they can change a price. The more useful question is whether the change is right, and you already have the data to answer it.
Price last quarter twice. Compare the invoices. Then decide.
