Usage Crystallization

TL;DR — Before anything can be priced, something has to decide what each customer actually used. That number is never simply observed. It is derived from observations that arrive from different sources, at different times, with different degrees of trust — and some of which never arrive at all. At the close of a period all of it reduces to one figure per subscription, and that figure sets. Everything downstream inherits it. That work is the usage stage, and it is the one place in a billing system where the question is not what a thing should cost, but what actually happened.

A quick note on words. The stage has names, and they came from the industries that hit the problem first. Utilities called it metering, after the instrument on the wall. Telecoms, where consumption arrived as discrete records rather than a rising register, called the collecting and normalising of it mediation. Billing software landed somewhere plainer: cloud providers sold computing power the way electricity is sold — pay for what you use — and the word that stuck was usage. Usage records, usage reports, usage-based billing.

The three stages differ in what they produce. Rating turns a quantity into a charge. Billing gathers the charges belonging to one customer, across every subscription they hold, and works out the totals and the tax that only exist at the level of the bill. Both produce money. This stage produces a quantity — an account of what happened, against which the money is worked out afterwards.

Everything downstream inherits that account, and no amount of correct arithmetic on the money can repair it if the account itself was wrong.

The Usage Chain

A water meter does not measure consumption. It counts. The number on the register is the total volume that has passed through it since the day it was installed, and it only ever goes up. Read it today and you learn something true about the meter. You learn nothing at all about the month.

Consumption is the difference between two readings. That sounds trivial, and it is the single most consequential fact about this stage, because it means usage is never observed. It is derived. It depends on a number taken weeks earlier, by someone or something else, that has to still be there and still be right.

Two distinct activities happen between the instrument and the money, and they tend to get called by the same word. Separating them is most of the work.

Usage ingestion

Taking observations in and recording them faithfully. An observation is a value, a timestamp, a source, and the subject it belongs to: meter 4471, reading 80,082, first of the month, uploaded from the route sheet. That is the whole of it. There is no consumption in it and certainly no money.

Ingestion's only obligation is fidelity — to store what was actually reported, including the readings that look wrong, because whether they are wrong is a question for later.

Usage metering

Applying the rule that turns those observations into one chargeable number. The rule is called the billable metric, and it takes a different shape depending on what is being measured. Water is the difference between this month's reading and last month's, times whatever multiplier the meter requires. Mobile data is the sum of every session in the period. Waste collection is a count of how many times the bin was emptied.

It is rarely as tidy as two readings a month apart. A meter may be read four times in a cycle, or reported daily by a radio module, so metering is also a choice about which observation counts — for a register, usually the latest valid reading in the period, measured against the one posted at the end of the last.

What comes out is the billable quantity: one number, for one subscription, for one period. Previous posted reading 80,082, latest valid reading 80,225, so the quantity is 143. That number is the entire output of the stage. Everything upstream — every route sheet, every failed transmission, every argument about whether a meter was misread — exists to produce it, and everything downstream consumes it without looking behind it again.

This is the moment worth naming, and it is worth noticing that it is a moment somebody chooses. Up to then the picture is fluid: readings are still arriving, some are still missing, some are still wrong. Then the metric is run across the period and the quantity sets. It is no longer a running impression of what a customer used — it is the official account, and changing it afterwards is a correction rather than an edit.

The Shapes Usage Comes In

The stage is not really about meters, which becomes obvious as soon as you look at what actually feeds it.

Cumulative readings are the utility case. A register that only climbs, differenced across a period. The awkward property is that a reading has no meaning alone, so a gap in the sequence does not lose a month — it merges two. The next bill absorbs both, and it will look like a customer who suddenly doubled their consumption rather than a system that lost a number. The failure disguises itself as a fact about the customer.

Discrete events behave in the opposite way. A parcel collected, an API call served, a machine hired for a day: each arrives complete, carrying its own quantity. You add them up. Lose one and you undercount by exactly one, visibly and proportionately. This is the shape telecom was built around, and the shape most software billing assumes.

Allocated shares have no instrument behind them at all. Where submeters were never installed, a building's total consumption gets divided among units by an attribute — floor area, occupant count, bedrooms. A unit's quantity for the month is its share of a number measured somewhere else entirely. Nothing was observed about that unit, and yet the output is the same kind of thing: one number, one subscription, one period.

Estimates are the fourth shape, and the uncomfortable one. When a reading does not arrive — the unit was locked, the module is dead, the route was not finished — the cycle cannot simply stop, because a thousand other customers are waiting on it. So a figure is produced from the same period last year, or from a recent average, or from whatever policy the business has settled on. It occupies the same slot as a measurement and is not one.

Four different derivations, one kind of output. That is the clearest evidence that this is a stage rather than a technology. Its job is to produce a defensible quantity, and a meter is one way to get there among several.

What This Demands From a System

Strip away the industry and the same six decisions appear wherever usage is billed, whether what is being measured is water, mobile data or bins emptied.

1 — What the system needs to know about the instrument

For a register the metric is not really a choice: a meter's quantity is the movement between two readings. What does have to be known is narrower and specific to the device — what it measures and in what unit, and the multiplication factor its readings have to be scaled by. Both belong to the instrument rather than to the customer, and they have to travel with it when it moves.

2 — How observations get in

Readings and events arrive in bulk, from a hardware feed, a handheld on a route, or a file from a third party. They have to be accepted against an identifier the field already uses — the reference on the meter or the account — rather than an internal key nobody outside the system has ever seen.

And they have to be stored as reported, with their source and their timestamp intact. A reading that looks wrong is still what was reported, and the moment it is silently repaired the evidence is gone.

3 — What can be trusted

A reading below the one before it. A jump of a thousand times the usual. A meter silent for two cycles. These are questions about a fact, and the only stage equipped to ask them is the one still holding facts — by the time a number has become money it is far too late to wonder whether it was ever true.

The rows that fail have to be kept rather than dropped, too. Discarded silently, they leave a system that cannot tell a customer who used nothing from a meter nobody could read.

4 — What happens when nothing arrives

The unit was locked, the module is dead, the route was not finished. The cycle cannot stop, so a figure is produced from history — and which history counts is a business decision, not a technical one. An average across last year suits steady consumption; the same month last year suits anything seasonal; taking the higher of the two is a deliberately cautious position.

Whatever is produced has to travel onward still marked as an estimate, and stay correctable when the real reading appears, or the next period differences against a guess and the error becomes permanent.

5 — What happens when the instrument changes

A register has a finite number of digits, so eventually it wraps to zero and the subtraction returns a negative number. A meter replaced mid-cycle leaves two registers covering one month, the second rarely starting at zero — read naively, that is a customer who consumed minus eighty units. A multiplier gets corrected, and every historical quantity silently changes meaning unless it was recorded against the period rather than the meter.

None of this is visible in the current reading. It is only visible in the relationship between readings, which is where usage lives.

6 — How the quantity is settled and handed on

At some point the observations stop being a running impression and become one number, for one subscription, for one period — and that is what rating receives. Worth noting that this is an act rather than a date passing: somebody, or something, decides the period's account is now closed.

The quantity also has to survive as a record rather than be consumed on the way past. One still standing as a fact can be rated again when a tariff is backdated. One turned straight into a charge cannot — the fact and its interpretation were fused, and separating them afterwards means unpicking arithmetic never designed to be reversed.

There is a subtler version of the same mistake, and almost every system has one somewhere: a unit conversion — litres to cubic metres, bytes to gigabytes — sitting inside a rating formula rather than in the metric. It works. It is also measurement logic living on the money side of the boundary, where nobody thinks to look for it, and it means the stored quantity and the billed quantity are quietly in different units.

How Billspree's Usage Engine Helps

Billspree's usage engine is built for metered utility billing — water, gas and electricity, where a register is read on a cycle. That context settles most of what follows, and Billspree answers each of those six decisions with something you can point at.

What the system knows about the instrument is a Meter. Not a field on the customer — a record of the physical device, with its number, its brand, its type and unit, its purchase date and its multiplication factor. A meter is created unassigned and inactive, and becomes billable only when it is attached to a Subscription. Because the MF lives on the device, it travels with the device.

Observations arrive as Meter Readings, entered directly, uploaded as a CSV, or sent through the API for hardware that reports on its own schedule. They are keyed on the subscription's reference number — the identifier already written on the meter and the account — and each carries its reading date, a health status and a comment, so a meter that has been struggling for three cycles reads differently from one that failed once. Nothing is repaired on the way in.

All of it happens inside a Bill Term. The term is the container the billing orchestrator opens when a Billing Group's period falls due, and every reading, estimate, adjustment and draft for that cycle belongs to it. That is what makes the awkward parts of measurement safe to work through: the term can be reviewed and reprocessed as a unit, and nothing is committed until the bills are posted.

Missing readings are filled by an estimation method chosen in advance. Five are supported — the average of last year, the same month last year, whichever of those two is greater, and the maximum or minimum of last year — because the right answer is a business position rather than a technical one. Steady consumption suits an average; anything seasonal suits the same month a year ago; the greater of the two is a deliberately cautious stance. Running Estimate All across the term derives the missing reading as the previous reading plus the estimated usage, and flags it as estimated rather than actual, so the estimate stays visibly an estimate through billing and audit.

A replaced meter is a Meter Change Operation. Run from within the term, it recognises that the new register starting lower than the old one is not consumption of minus eighty units. Standard consumption is bypassed, the difference is resolved as a Meter Change Adjustment, and both meters' history survives intact — so no negative usage is ever billed and the audit trail still shows what actually happened.

The quantity is settled by Post Readings, and that is the moment the account closes. For a metered service it takes the latest valid reading captured during the term as the Current Reading, measures it against the previously posted one, and the difference is the billable quantity — regardless of how many intermediate readings arrived. For an unmetered service it sums every usage transaction in the term instead, which is how three waste collections become a quantity of three.

What reaches bill processing is that settled figure, held as a record rather than passed through. Before it gets there the period is reviewable: a usage report shows each subscription's previous reading, current reading, consumption and variance together, with filters for the cases worth a second look — zero usage, no current reading, movement past a threshold. That review sits between measurement and money, which is the only place it can catch a stuck meter before a customer is billed on it.

Full detail on what is described here is in the docs: Capture Usage Data, Post Readings, Usage Estimation and Meter Change Operation — and for the containers all of it runs inside, Bill Term, Billing Group and Bill Run.

Ask an operator how their billing works and you will hear about invoices, rates, and the run at month end. Ask what their customers used, and where that number came from, and how they would know if it were wrong — and the conversation slows down.

It is the part that decides whether everything after it is true.