A bill the customer
could have
predicted.
Charging for usage moves the risk of a strange month from you to your customer. Then you send them the result after the fact. A customer who cannot predict the bill does not renew it. Here is how we build the parts that make usage billing survivable. A meter you can trust. A billing run that gives the same answer twice. A commercial safety net against a spike. And a renewal that starts while there is still time to have it.
01 — Why it breaks
Churn that looks like productWhen customers leave a usage business, everyone reads it as a product problem first. That is the department that owns the word. Almost nobody looks at the billing system. But an invoice is a monthly conversation with your customer's finance team. If that conversation keeps going badly, the renewal is decided long before anyone brings it up.
- You bill for usage after the month has ended, and the customer sees nothing during it. The first time they see what they used is on the invoice.
- There is no ceiling. A strange month produces a bill nobody budgeted for. And there is no way to cap it, spread it, or warn anyone in advance.
- The meter cannot be run again. Asked to prove a charge, nobody can reproduce the number. Which means, from the customer's side, nobody can disprove their suspicion either.
- A reading arrives twice after a retry and gets billed twice. Or it arrives late and gets quietly thrown away. Both stay invisible until somebody complains.
- Disputed invoices pile up. Each one costs finance time, delays your cash, and leaves behind a customer who no longer trusts the meter.
- Renewals start on or after the contract end date. By then the decision has usually already been made somewhere else.
- The signs that a customer is about to leave — falling activity, repeated disputes, usage sliding below what they committed to — are all in the data. They are connected to nothing and to nobody.
02 — How we do it
04 movementsMeasuring what the customer uses
Every number further down the line is a claim about the meter. So the meter comes first. Define exactly what you charge for. What counts. The moment it counts. The unit you measure it in. And how finely you record it. Then define the boring cases, because they are the ones that cause the disputes. What the system does with a reading that arrives late. Out of order. Twice. Or with a timestamp from a device whose clock is wrong.
Every reading carries a unique reference from wherever it came from. If the same reference arrives twice, the system throws the second one away. A retry from a device or a gateway is not revenue. We store the raw readings before we add them up, and we never edit them. The totals are worked out from the raw readings, and if the two ever disagree, the raw reading wins. Late arrivals get a written rule. Either you accept them into the open month up to a stated cut-off, or you carry them into the next one. What you do not do is leave it to whatever the plumbing happens to do. And completeness is a check, not an assumption. Every month, count the readings that left the source system and count the readings that reached the billing system, and make sure the two agree. Usage that never arrives fails silently. It fails in the customer's favour, right up until the day somebody notices and asks them for a year of back charges.
A billing run that gives the same answer twice
Add the readings up to whatever level the price is expressed in. Per device per day. Per call. Per gigabyte per month. Per active seat. Keep those totals as something you can rebuild from the raw readings at any time. Then price them. Tiered rates. Volume rates. Minimum spends. Volumes the customer committed to. Charges for going over. And part-month charges where a subscription changed mid-month.
The rule that sits above all of that is this: the billing run has to be repeatable. The same readings and the same subscription must produce the same charges, whether the run happens on the first of the month or again on the fifth after you find a mapping error. In practice that means four things. Nothing in the pricing logic depends on what time the run happened. A new run replaces the old charges rather than editing them in place. Price lists are dated, so re-pricing an old month uses the prices that applied then, not the prices that apply now. And a run that fails half-way is rolled back rather than left half-done. Without this you cannot fix an error without sending credit notes to undo your own mistake. You cannot run the old and new systems side by side during a migration. And you cannot answer a customer who asks why the number moved.
Committed volumes, and a ceiling on a bad month
Once you can trust the meter, you can offer deals that were not safe before. A committed-volume discount rewards a customer for forecasting honestly. They promise to use a certain amount over the term. They get a better rate for it. And they carry the risk of not using it all. A ceiling puts a known limit on a bad month. It can be a hard cap. A soft cap that warns them and keeps going. A burst allowance that eats into what they committed to. Or a mechanism that spreads a spike across the rest of the term.
The detail is in what happens at the edges. What happens to a commitment the customer did not use up by the end of the term. Do they lose it, carry it forward, or extend? Losing it is the easiest to build and the one customers argue with hardest. Does an overage charge count towards their next commitment, or is it billed and forgotten? Does a burst allowance top itself back up? These are pricing decisions dressed up as systems decisions. The people who own pricing should make them. And they should make them with the revenue consequences on the table before the contract template is written, not after. Spreading a spike across the term, in particular, usually creates a fee that moves up and down — and under ASC 606, the US accounting rule for when you may count revenue, that changes how much you are allowed to count now. It is far cheaper to answer that question at the design stage than during the audit.
Usage in the open, and renewals that start early
A customer should never learn what they used from the invoice. Show them during the month. What they have used so far against what they committed to. Where they will land by the end of the month at the current rate. What that will cost. And an alert when they cross a line they set for themselves. Most disputes are not arguments about price. They are surprise. Remove the surprise and most of the queue goes away without changing a single rate.
The same data drives the renewal. Renewals should start well before the contract ends. Early enough that there is time to do something about it, which for most companies means a full quarter and never the last month. The account team gets the renewal quote, the customer's usage against their commitment, anything unresolved on the account, and the warning signs — all in one place, while any of it can still be changed. A renewal conversation that starts on the end date is not a renewal conversation. The same view works the other way too. A customer who keeps using more than they committed to is a conversation to have, not an overage charge to send. And the warning signs — falling activity, rising disputes, usage drifting below commitment — get wired into that workflow. So an account going the wrong way surfaces months out, in front of a person whose job it is to do something about it.
Caps and committed-volume discounts cost you money in the spike months. That is not a side effect of the mechanism. That is the mechanism.
It would be easy to present a ceiling as a free win. It is not one. A cap means an unusually heavy month bills less than it otherwise would have. A committed-volume discount means the unit price drops in exchange for a forecast. Both turn revenue that was high and jumpy into revenue that is lower and steady. There is no version of the deal where the customer gets the certainty and you keep the upside.
The argument for making the trade is that jumpy revenue in a usage business is partly borrowed from the renewal. A customer blindsided by a bill is already part-way through deciding to leave. The upside you booked in the spike month is being repaid, with interest, at the end of the contract. That is a real argument. It is not a guarantee. And you should test it against your own numbers before you commit. What share of your billing comes from months that would have hit a cap? Which customers do those months belong to? What would the cap have cost you against them? If the spike revenue comes from customers who renew happily anyway, the case is weaker. Work it out, then decide.
- Where the ceiling sits. And whether it is a hard cap, a soft one, or a burst allowance taken out of what they committed to.
- What happens to a commitment the customer did not use up by the end of the term. This is the clause customers read first.
- Whether overage counts towards the next commitment. And whether spreading a spike across the term creates revenue you have billed but cannot yet count.
- What the ceiling costs the customer. A cap given away for nothing is a discount you did not decide to give.
- What the sales team is allowed to negotiate on any of the above. And what the billing system can actually do.
04 — What you end up owning
After we leaveThe meter
A written definition of what you charge for. An agreement with each source system about the unique reference on every reading. Written rules for duplicates and for late arrivals. And a monthly check that everything the source system sent actually reached the billing system. When somebody asks whether the usage is right, the answer is a report rather than an opinion.
The billing engine
The pricing setup, with the test cases that prove it works. Dated price lists. Written rules for part-month charges. And a written procedure for safely re-running and correcting a month you have already billed. A pricing change can then be tested before it reaches an invoice.
The commercial model
Committed volumes and ceilings built into the system, rather than promised in a contract the system cannot honour. With the rules for drawing down a commitment and truing it up at the end. What happens to what the customer did not use. And the revenue consequence of each structure, written down beside it.
The renewal motion
The usage view the customer sees, and the alerts that go with it. The renewal workflow, with its trigger points, the warning signs wired into it, and everything the account team needs in one place. And a runbook for the renewal desk saying what to do when a warning fires. A warning nobody has to act on is just a dashboard.
Usage billing sits upstream of revenue recognition, and the decisions you take here land there. If you are building committed volumes, overage charges or spike-smoothing, read the ASC 606 playbook → alongside this one.
05 — The other playbooks
All playbooks →If customers are leaving and everyone is blaming the product, and nobody has audited the invoice, start with an assessment. You get a written diagnosis, and it is yours whether or not you hire us to act on it.