Three States & the Install Base
Last updated 12 Oct 2026
At a glance
Every product a customer holds exists in three states: what was sold, what is live, and what is charged. Different systems own each, and different events move each. The Install Base is the agreed answer to "what does this customer have?", and billing must be driven from it or reconciled against it.
The picture
One product, three records, three events on different days. Reconciliation is how you know they still agree.
1 · Lifecycle events
Day 5 · COM
Order line completes
Day 11 · SOM / network
Activation confirmed
Day 11 · Billing
Charge start date set
A lost message or a fix in one system only leaves the states out of step
2 · Three states
Commercial
ACTIVE · 10 GB plan
What did the customer buy?
Product Inventory (TMF637)
Service
ACTIVE · data service
What is live on the network?
Service Inventory / network
Billing
ACTIVE · from day 11
What are we charging for?
Billing subscription
The Install Base is the agreed answer to “what does the customer have?”
3 · What the comparison finds
All three agree
Healthy
Service active, billing not
Leakage: nobody complains, so it runs for months
Billing active, service not
Overcharging: the customer finds it first
How it works
Three states that must agree
| State | Question it answers | Typical owner | Healthy value (10 GB plan) |
|---|---|---|---|
| Commercial | What did the customer buy? | COM / Product Inventory | ACTIVE, 10 GB plan |
| Service | What is live on the network? | SOM / Service Inventory / network | ACTIVE, data service provisioned |
| Billing | What are we charging for? | Billing account / billing subscription | ACTIVE, recurring charge from activation date |
Most revenue problems, and most billing complaints, are a disagreement between these three.
Why they diverge
Each state is moved by a different event at a different time: the order completes in COM, activation completes in SOM, the charge starts in billing. A failed message, a manual fix in one system only, or a fallout order closed without being completed leaves them out of step.
The Install Base
The Install Base is the logical record of the customer's current product and service state. It may be implemented across Product Inventory (TMF637), Subscription Management, CRM/COM or related inventories. Few operators have one system called "Install Base". What matters is that one record is agreed as the system of record and billing is driven from it, or reconciled against it. Where two systems each believe they own it, they drift.
| Product / component | Status | What it means for billing |
|---|---|---|
| Mobile plan | ACTIVE | Recurring charge every cycle |
| SIM | ACTIVE | Resource linked to the plan; no charge of its own here |
| 10 GB add-on | ACTIVE | Recurring add-on charge; allowance available to rating |
| Roaming | ACTIVE | Roaming usage can be rated and charged |
| Old plan | TERMINATED | No further charges; history kept for disputes and audit |
How lifecycle events reach billing
The logical sequence is the same for every change; the call chain varies by architecture.
| Event | COM | SOM / network | Install Base | Billing |
|---|---|---|---|---|
| New service | Order validated and decomposed | Service and SIM activated | Instance ACTIVE with activation date | Recurring charge from the activation date, not the order date |
| Modification | Mid-cycle upgrade ordered | Allowance and policy changed | Old version closed, new ACTIVE with effective date | Prorates: credit for the old plan, charge for the new |
| Termination | Cease and end date recorded | Service deactivated, resources released | Instance TERMINATED | Final prorated charge; recurring charge stops |
| Pattern | How billing learns of the change | Trade-off |
|---|---|---|
| COM → Billing | COM calls billing when the order line completes | Simple; COM's view of completion may not reflect what the network did |
| COM → Subscription Mgmt → Billing | A subscription layer owns product state and drives billing | Clear ownership; one more system to keep in step |
| COM → event bus → Billing | Order events published; billing subscribes | Loose coupling; needs guaranteed delivery, ordering and replay |
| COM → SOM → service event → Billing | Billing starts on the activation event | Follows what is live; product state can drift if not also updated |
| One order platform → Billing | A suite handles order and billing | Fewer hand-offs; tighter dependency on one vendor model |
Every pattern can lose, duplicate or delay an event. Choosing one decides where the failure appears. It does not decide whether failures happen.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product instance (commercial state) | Product Inventory / Subscription Management | COM, CRM, self-care | Billing, Rating / OCS | TMF637. The Install Base view; one system must be agreed as owner. |
| Service instance (service state) | Service Inventory | — | Product Inventory, Assurance | TMF638. Confirmed by SOM on activation; the network holds the running configuration. |
| Billing subscription (billing state) | Billing | — | Product Inventory | Price, charge start date, bill cycle and discounts for the chargeable item. |
| Product order and completion date | COM | — | Billing | TMF622. Order completion is not the same event as service activation. |
In practice
Some suites hold the product instance and the billing subscription as one record. Most estates hold them in separate systems, often from different vendors, and keep them in step through order integration plus periodic reconciliation. Many operators run more than one integration pattern at once: one for mobile, another for fixed, a third for enterprise products ordered through a separate stack.
That is why Install Base to Billing reconciliation (6.9) exists in every serious operator, whichever integration pattern they chose.
The trade-off
What it solves
An agreed Install Base gives billing one record of what the customer has, so charges follow holdings and disagreements can be found by comparison.
What it does not solve
- Lost or delayed events between the systems that own each state.
- Manual fixes made in one system and not the others.
- Customers migrated with service and billing records carried across separately.
What it adds
- Agreeing which system owns "what the customer has" is a governance decision several teams will contest.
- Two records of the same product instance must be kept in step and reconciled on a schedule.
- Event-driven integration needs guaranteed delivery, ordering and replay, or changes disappear silently.
Architecture decision
Which event should start the recurring charge?
Order completion in COM
Choose when COM only completes an order line after fulfilment confirms activation, so completion and activation are the same moment.
Service activation event from SOM
Choose when order completion and activation can differ (field installs, appointments), and the product state is updated from the same event.
Product state change in Subscription Management
Choose when a subscription layer is the agreed Install Base owner and already consumes both order and activation events.
Breaks if billing starts on one event and the Install Base is updated by another, with no reconciliation between them. Charges and holdings then drift apart and nobody sees it until customers or auditors do.
Takeaways
Key Takeaways
- Every product exists in a commercial, a service and a billing state, usually in different systems
- Service without billing is leakage; billing without service is overcharging
- The Install Base is a responsibility that may span several systems; one record must be agreed as owner of "what the customer has"
- Recurring charges start from the activation date, not the order date
- No integration pattern removes the need for Install Base to Billing reconciliation
Check yourself
A customer ordered on day 5 and the engineer activated the line on day 11. The first invoice charges from day 5. Which integration choice causes this?Show answerHide
Billing started on the order event (order captured or completed in COM) rather than the service activation date. The fix is to start the charge from the activation date recorded by fulfilment.
A cancelled broadband line is still being billed, but network and service inventory show it ceased. Which state is wrong, and how is it found at scale?Show answerHide
The billing state: the termination event did not reach billing, or was not applied. It is found by Install Base to Billing reconciliation, comparing terminated instances with active billing subscriptions.
Two systems both claim to hold "what the customer has". What happens over time?Show answerHide
They drift. Each is updated by different events and fixes, and billing will agree with one and not the other. One must be agreed as the system of record, and the other reconciled against it.