Two very different systems both answer the question “how many does this customer have left?”, and teams confuse them constantly. One is a meter. The other is a ledger. The confusion is expensive because each is excellent at what the other is bad at.
What a meter is for
A meter counts consumption against a limit. Ten thousand API calls a month; a hundred requests a minute; five gigabytes of storage. The count goes up as the customer uses the service and resets on a schedule. A meter is cheap, fast and simple, and it is the right tool whenever the units are an allowance — something the customer is permitted, not something the customer owns.
The tell is what happens when the period ends. An allowance expires and nobody is owed anything. A meter that resets to zero has not destroyed value, because there was no value, only permission.
What a ledger is for
A ledger records ownership. Prepaid credits a customer paid for, loyalty points they earned, a gift-card balance, a wallet. These units have a source (they were issued, in exchange for money or effort), they can be transferred, and above all they can be refunded and disputed. When the period ends they do not vanish; they are still owed.
A ledger therefore answers questions a meter cannot:
- What did this customer pay for, and what have they used?
- What do we owe all customers in unused credits right now — our liability?
- What happened to the credits that expired last quarter?
- Can we prove that this refund was for credits that were actually purchased?
Every one of these needs a record with two sides: where the units came from and where they went. That is double-entry, and that is the ledger.
The failure mode of choosing the meter
Teams start with a meter because credits look like a count. It works until the first refund. Refunding a counter means guessing how many of the current units came from the purchase being refunded. Then comes the first dispute, and the finance team asks for a statement of the customer’s credit movements, which a counter cannot produce because it only ever stored the total. Then the auditor asks what the company’s total liability for unused credits is, and the answer is “the sum of a column that we sometimes adjust by hand”.
At that point the team builds a ledger, usually in a hurry, and usually with the ten problems unsolved.
The failure mode of choosing the ledger
The opposite mistake is cheaper but real: putting a plain allowance on a ledger. Every API call becomes a transaction with a counterparty, the journal grows by millions of permanent rows a month, and the guarantees — balance, immutability, floors — are protecting nothing, because an allowance has no value to protect. Ledger’s own pricing page meters API calls with a meter, not a ledger, for exactly this reason.
A simple test
Ask what a refund would mean. If refunding is meaningful — the customer gave something and can get it back — the units are property and belong on a ledger. If a refund makes no sense because nothing was given, it is an allowance and a meter will do.
Using both, deliberately
Most products end up needing both, and the clean design keeps them apart. Ledger’s own commercial model is a small example: the free plan allows a number of API calls a month, and that allowance is metered — counted, capped, reset — by a metering service, not by the ledger. The calls are not property. Nobody is owed a refund for calls they did not make.
A software product that sells prepaid credits and also rate-limits its API would do the same: credits on the ledger, request rates on a meter. The two systems answer different questions and never need to agree with each other, because they count different things.
Moving from a counter to a ledger
Teams that have already built the counter often ask whether they can migrate without a big bang. The shape that works:
- Open the books at the current balances. Post one opening transaction per customer, moving their current credit count from an “opening balance” account into their account. The books now agree with the counter as of a known moment.
- Dual-write for a period. Every purchase, use and refund updates both the counter and the ledger. Reconcile daily: the counter and the customer’s ledger balance must match exactly, and any difference is a bug in one of the two paths.
- Cut over reads. Once the reconciliation has been clean for as long as your risk appetite requires, serve balances from the ledger and stop writing the counter.
The opening-balance account is not a trick; it is exactly how an accountant opens a new set of books, and it means the history before the migration is honestly labelled as a starting position rather than pretended to be a full record.
Ledger models credits as an asset type alongside money and stock, so the credits and loyalty use case shows the shape: sell a pack, reserve for a job, commit what was used, refund the rest, and read the liability off the books at any time.