CASE STUDY · SUBSCRIPTION & BILLING MANAGEMENT TECH
Migrating a client to usage-based subscription billing.
- 30%Billing disputes down 30%
- 9%Revenue per customer up 9% over two quarters
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised SaaS company. Name withheld under confidentiality.
A metering, rating and invoicing system with reconciliation. Product events were captured as usage records, rated against a written price book and turned into invoices. Every invoice line could be traced back to the events behind it.
- 1The company charged flat prices, but its customers used the product very differently.
- 2Light users felt they overpaid.
- 3Heavy users cost far more to serve than they paid.
- 4Sales gave one-off discounts to hold accounts, and nobody could say what a customer should be billed.
- 5Finance rebuilt invoices by hand at month end.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01In the shadow run, a group of invoices came out higher than the old ones
The cause was late events. Some product services sent usage hours after the billing window closed, so the old process had missed them and the new one had not. We first thought the new system was wrong.
- PROBLEM 02It was more accurate
We added a clear cut-off rule, a grace period for late events and a separate adjustment line for anything arriving after close. We also told customers in advance how late usage would show up. That removed a likely source of disputes.
- PROBLEM 03A second, smaller problem came from credits
Sales had promised credits to some accounts by email, and none were in the billing data. Shadow invoices ignored them and looked too high. We ran a short audit with account managers, loaded every valid credit with an expiry date and made credits a field that sales could request but not apply directly.
- PROBLEM 04The shadow run then matched
03 · THE PROCESS
How we ran it.
We worked in four phases with a weekly demo to product and finance.
- 01Step 1
Discovery: we mapped current plans, discounts and exceptions, then agreed a price book with finance.
- 02Step 2
Build: we delivered metering first, then rating, then invoicing, each tested against real past invoices.
- 03Step 3
Shadow run: for two billing cycles the new system produced invoices that no customer saw. We compared them with the old ones daily.
- 04Step 4
Cut-over: customers moved in groups, smallest and friendliest first, with the old system kept as a fallback.
A short weekly review covered open mismatches. Finance owned the decision on every disputed rule.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Product and finance change prices by editing the price book, not by asking engineering for a code change.
- NOW 02
Support answers a billing question by opening the invoice line and its usage records.
- NOW 03
Discounts have end dates and an owner.
- NOW 04
Month-end close starts from the reconciliation report instead of spreadsheets.
- 30%
Billing disputes down 30%
- 9%
Revenue per customer up 9% over two quarters
05 · WHAT WE BUILT
How it works.
- Usage events carried a unique ID, a customer ID, a timestamp and a quantity.A deduplication step dropped repeats.
- Events were stored unchanged in an append-only log.Corrections were new records, never edits.
- A rating service read the price book, which was versioned, and priced each event.Tiers and included allowances were data, not code.
- Invoices were generated from rated lines, with a link back to source events for every line.
- A nightly reconciliation job compared event totals, rated totals and invoice totals, and raised an alert on any gap.
- Customers saw a usage page that matched the invoice, using the same data.
- Controls
- Three controls protected the money. Price book changes needed approval from finance and were versioned, so any invoice could be recomputed under the rules in force on its date. Invoices above a set size were held for a human check before sending. A daily report listed customers whose usage jumped or fell sharply against their own history, so odd data was seen before an invoice went out.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company charged flat prices, but its customers used the product very differently. Light users felt they overpaid. Heavy users cost far more to serve than they paid. Sales gave one-off discounts to hold accounts, and nobody could say what a customer should be billed. Finance rebuilt invoices by hand at month end. When a customer questioned a charge, the answer took days.
- What did Brandsmashers build?
- A metering, rating and invoicing system with reconciliation. Product events were captured as usage records, rated against a written price book and turned into invoices. Every invoice line could be traced back to the events behind it.
- How was the work run?
- We worked in four phases with a weekly demo to product and finance.
- What were the results?
- Billing disputes down 30%; revenue per customer up 9% over two quarters.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
