Two different systems answer the question “how many does this customer have left?“. One is a meter and the other is a ledger. Teams confuse them constantly, and the confusion is expensive.
What a meter is for
A meter counts consumption against a limit. Ten thousand API calls a month is a limit, and so is a hundred requests a minute, or five gigabytes of storage. The count goes up as the customer uses the service, and it resets on a schedule.
A meter is cheap and fast to run. It is the right tool when the units are an allowance. The customer is permitted them and does not own them.
You can tell which you have by what happens when the period ends. An allowance expires and nobody is owed anything. A meter that resets to zero has destroyed no value, because there was no value in it, only permission.
What a ledger is for
A ledger records what someone owns. Prepaid credits a customer paid for are owned, and so are loyalty points they earned, a gift-card balance and a wallet. Units like these were issued in exchange for money or effort, they can be transferred, and they can be refunded and disputed. When the period ends they do not vanish, because they are still owed.
A ledger therefore answers questions a meter cannot:
- What did this customer pay for, and what have they used?
- What is our liability for unused credits right now?
- What happened to the credits that expired last quarter?
- Can we prove that this refund was for credits that were actually purchased?
Answering any of these needs a record with two sides, one for where the units came from and one for where they went. That is what double-entry means.
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. The finance team asks for a statement of the customer’s credit movements, and a counter cannot produce one 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 in a hurry and the ten problems are still unsolved.
The failure mode of choosing the ledger
The opposite mistake is cheaper, and it still happens. Putting a plain allowance on a ledger turns every API call into a transaction with a counterparty, and the journal grows by millions of permanent rows a month. The guarantees that a ledger exists to provide, such as balance, immutability and floors, are protecting nothing, because an allowance has no value to protect. For that reason Ledger’s own pricing page counts API calls on a meter.
A simple test
Ask what a refund would mean. If 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 a metering service counts, caps and resets that allowance. The calls are not property, and 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 keep the credits on a ledger and the request rates on a meter. The two systems count different things and never need to agree with each other.
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 migration that works has three steps.
- 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 the two every day. 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 how an accountant opens a new set of books. It labels the history before the migration as a starting position only.
Ledger models credits as an asset type alongside money and stock. The credits and loyalty use case walks through selling a pack, reserving for a job, committing what was used, refunding the rest, and reading the liability off the books at any time.