Many billing systems,
folded into one,
without billing anyone wrong.
Nobody plans to run several billing systems. You inherit one. You build another for a product the first one could not price. You keep the oldest one alive because some customers are still on it. Here is how we fold them back into one system. Agree the model before anything moves. Move customers in small groups. And run the old and the new system side by side until every invoice line matches.
01 — Why it breaks
Several systems, one customerBilling systems do not multiply because anyone was careless. They multiply because of a series of sensible decisions. A new product the old system could not price. A company you bought that came with its own system. A country with a tax rule nobody wanted to build into the existing one. Each decision was the cheap option at the time. Put together, they mean the answer to what do we bill this customer now depends on which system you ask.
- Each system has its own product list, its own pricing rules, and its own idea of what a customer record looks like.
- The same customer sits in more than one system, under different reference numbers. There is no reliable way to match them up.
- Someone has to check the systems against each other by hand, every month. All that work produces is an answer to which system was right.
- You cannot close the books until that checking is done. So the close moves at the speed of the slowest argument.
- Nobody has one set of numbers to trust. Revenue by product, by market or by customer group is put together by hand. Two people can do it and get two different answers.
- A new market or a new price has to be set up in every system. Or you set it up in one and accept that the systems now disagree on purpose.
- Nothing can be switched off. Some customers are still on the oldest system. Moving them was never funded. So the licence renews for another year.
- The real cost is not the licences. It is that no single person can say, with evidence, what the company billed last month and why.
Consolidation is worth doing when the checking has become the bottleneck rather than a nuisance. And when the mess has started to cost you things you wanted to do — a new market, a new price, a new bundle — rather than only costing you time. Below that line, the honest advice is usually to patch the joins and leave the systems alone.
02 — How we do it
04 movementsOne model, agreed before anything moves
This is a modelling job before it is a migration job. The first thing we produce is one target model. What a customer is. What an account is. What a subscription is. The products, the plans, how each one is priced, the price lists and the discounts. Alongside it we list every single thing that exists in every old system. Each one gets mapped to the thing that replaces it, or gets a written reason why it should not survive. A fair amount will not survive. Duplicate plans. Prices no live customer is on. Charges that only exist because one system could not express what another one could. Getting that list agreed is where the arguments happen. Better there than in the middle of a switchover.
The customer model is the part people wave through. Decide what a customer actually is. A legal entity. A billing account. A parent with subsidiaries in three countries. A contract. Decide which reference number is the real one. Decide how the old reference numbers survive as nicknames, so a support agent can still find the account a customer just rang about. Then make the order the border between the sales systems and the finance systems. An approved order arrives at the billing system in one agreed shape. It is priced once. It is invoiced once. It posts to the accounts with a trail back to the order line that caused it. Most companies with several billing systems never treated the order as a border at all. That is why the CRM and the accounts stopped agreeing long before anyone noticed.
Small groups, and a side-by-side run that has to come out clean
You do not move every customer in one night. We move them in small groups, and we order the groups by difficulty rather than by size. The simplest, most uniform group goes first. That way the migration machinery gets proven on the customers least likely to break it. The strange contracts go last, handled by a team that has already learned the system.
Every group gets a dual-run before it moves. That means the old system and the new system both bill the same month, from the same subscriptions and the same usage. Then we compare the two bills line by line. Every difference gets one of two endings. Either it is explained and the explanation is written down — an old bug in how part-months were charged, a rounding rule we fixed on purpose, a plan that has been retired. Or it is a fault in the new setup and we fix it. A group moves across when its dual-run is clean. Not when the plan says the date has arrived. That is the hardest promise to keep, and it is the only one that matters.
The half-finished cases are the whole difficulty. Subscriptions part-way through their term. Changes applied to some months and not others. Invoices still unpaid. Cash that has come in but not been matched to an invoice. Credit balances the customer has not used yet. Revenue you have billed but not yet earned, which has to land in the new system exactly as the old one left it — contract line by contract line, not as one lump sum. We sort all of that out during the dual-run, while being wrong still costs you a correcting entry rather than a customer.
What the comparison actually has to prove
Matching the invoice totals is not enough. Two invoices can add up to the same number and be wrong in opposite directions. A proper comparison has to prove three things in order. Each one catches errors the one before it cannot see.
One: every line matches. For each invoice line, the same charge, the same quantity, the same rate, the same period of service, the same handling of part-months, the same tax and the same tax country, the same currency and the same exchange rate, the same legal entity, the same customer. Two: the totals match, worked out separately. Total billed. Revenue billed but not yet earned. Money owed to you. Credit balances and unmatched cash. The entries posted to each account in the ledger. Each of these is calculated fresh from the new system and compared to the old one. We do not derive them from the line-by-line check that already passed. Three: every difference is on a list. Each difference has a category. Each category has a count and a decision. And every category is closed out. If the list still has a bucket called other, the comparison has not finished. It has stopped.
Run it for at least two full billing cycles per group. Monthly contracts, annual contracts and contracts changed mid-term do not go wrong in the same month. One clean cycle mostly proves that the easy contracts are easy.
A billing run you can repeat, then old systems that actually die
If you cannot run the billing twice and get the same answer, you cannot trust it. You also cannot run it side by side with the old system at all. So we build the new system to be re-runnable from day one. Every usage record and every incoming message carries a unique reference. If the same one arrives twice, the system throws the duplicate away. The same inputs produce the same charges whether the run happens on the first of the month or again on the fifth after we fix a mapping error. 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. A message that fails is retried, or parked in a queue that somebody owns. It is never quietly dropped. All of this is what lets you fix a setup error and re-run the month, instead of sending every customer a credit note to undo your own mistake.
Then you switch the old systems off. This is the part everyone skips once the new system is live and the money has run out. An old system left running read-only just in case is an old system that will still be there in three years. Still licensed. Still consulted. Still contradicting the new one. Still the reason a simple reporting question takes two days. So we agree the shutdown conditions before the switchover, not after. Old invoices exported in a form you can reprint without the old software. Records you are legally required to keep, kept in an archive rather than in a live system. Ledger history carried across. Every integration pointed at the new system and every old connection actually switched off, not merely unused. And a date after which nobody logs in, with a name against it.
Consolidation does not create your data problem. It removes the places you were hiding it.
Most of what goes wrong in a consolidation was already wrong. Several systems can each make sense on their own and still contradict each other. You can live with that quietly for years. One system cannot. These are the problems we look for first, because they show up late and cost the most when they do.
- A pricing bug that has been there for years and is now what customers expect. Decide out loud whether to copy it or fix it. If you fix it, tell them before the invoice does.
- The group nobody wants to talk about. Customers on prices that no longer exist, cannot be sold, and still have to be honoured. They will not fit the new model. Model them anyway, before the group they belong to moves.
- Revenue you have billed but not yet earned, moved across as one lump sum instead of contract line by contract line. It passes the first close and fails the first audit. By then the old system is gone.
- Treating tax and legal entity as someone else's problem, further down the line. They are part of the model. They are also what stops a group from moving, at the last minute.
- Letting the side-by-side run become a formality when the dates get tight. The side-by-side run is the safety check. Cutting it short does not remove the risk. It moves the risk onto your customers.
- Extra work sneaking in disguised as a data fix. Every consolidation gets offered the chance to redesign the pricing too. Judge that on its own merits, in its own project.
- Nobody named as owner of the shutdown. Without one, the last five per cent of the migration never finishes. And the pile of systems you set out to shrink gains one more.
04 — What you end up owning
After we leaveThe model
The new customer, subscription and product model, written down. The product catalogue as it is set up. The old-to-new mapping, field by field, with a keep-or-retire decision recorded against every old item and the reason next to it. In two years, when somebody asks why a charge type no longer exists, the answer is in a document.
The comparison
The side-by-side comparison reports for every group of customers, with each difference categorised and closed out. Plus the checks that outlive the project. A monthly check that orders match invoices, and a monthly check that invoices match the ledger. The next time the numbers drift apart, a report catches it rather than a customer.
The runbooks
The switchover runbook, with the way back written down while it was still hypothetical. The instructions for running billing each month, including how to safely re-run a month and how to reprocess a stuck message. The shutdown plan, with its conditions and a named owner. All of it written for the person on shift, not for the person who built it.
The knowledge
The test cases that prove the billing engine works, so a future change can be tested rather than hoped about. Your administrators trained to add a new product, a new price list or a new market without calling us. Handover is not a slide deck at the end. It is your people doing the setup during the build, with us in the room.
The test of a consolidation is not the launch. It is the first change you make afterwards without us. A new plan, a new market, a correction to a month you already billed. If that change is routine, the work was done properly.
05 — The other playbooks
All playbooks →If you are running more billing systems than you can name in one breath, start with an assessment. You get a written diagnosis, and it is yours whether or not you hire us to act on it.