01
Usage outgrew the rating engine
Minutes, messages and fax pages rate cleanly. The inference, the API call and the machine hour billed to that same customer never reach the engine — and those are the lines they now question.
Usage billing for vCons · voice, messaging, fax · release 0.1
Bill anything
expressible
as a vCon.
A call. A message. Three pages of fax. Then the AI inference and the machine hour that landed on the same customer. Send us the vCon; we work out who owes for it, price it, charge it, and hand back a signed receipt you can put in front of that customer six months later.
voice minute/message delivered/fax page/ai inference/door entry/forklift runtime/document analysis/data egress/sensor hour/
One vCon in, one priced charge out.
Illustrative data
What happened
What we work out
What lands on the bill
Charged
POSTED · 1 CHARGE
Revenue escaped the rating engine.
02
Every vendor invents a log
Each new usage source arrives with its own CSV, webhook or database view. Integration cost scales with vendor count, and none of it is signed.
03
Record and charge diverge
Evidence of what happened lives in one system, the charge in another. Six months later nobody can reconstruct the decision that produced the amount.
Six stages. The order is load-bearing.
Canonicalize before hashing. Resolve identity before pricing. Freeze pricing before authorizing. Authorize before accounting.
The format doesn't care what the event was.
Voice, messaging and fax are where vCons already live, and where we start. The same envelope carries anything else whose usage reduces to a quantity or a session — the gateway treats them identically.
| Event | Source | Unit | Qty | Rate code | Mode |
|---|
Billing Handles
A handle is whatever your source can actually assert: a fob ID, an agent name, an extension, a vehicle tag. It is not an account number, and it should not have to be.
Resolution walks a time-bound graph from that handle to the account that pays. Every edge carries a validity window, so a fob reassigned in March still charges the tenant who held it in February.
cst234_fob:F0B-8842 └─ fob → asset valid 2026-01-04 → open └─ asset → site valid 2025-11-20 → open └─ site → account valid 2025-11-20 → open → Customer 234 / Account 1000456
Resolved at event time, not submission time. The path is stored with the operation and replayed on dispute.
Rules that hold when things go wrong.
Billing systems are judged on their failure modes. These are ours, stated before you ask.
You send vCons. We do the billing.
One endpoint. No middleware to run, no shadow ledger to reconcile. Your rate plans stay yours — we price against them and give the charge back to you with the evidence attached.
- Input
- vCon core draft-03, signed
- Interface
- HTTPS, one submit call
- Output
- Priced charge + receipt vCon
- Pricing
- Your rate plans, unchanged
- Retention
- Replayable operation record
Build status · release 0.1
We're looking for four design partners.
Release 0.1 is a working prototype, not a product you can buy yet. We're starting with the operators and platforms already producing vCons for voice, messaging and fax. Partners run it against a sandbox with their own rate plans, and their usage source is what we build an adapter for first.
Tell us what you'd send us.
We read every one of these. The useful ones tell us what produces your usage today — a softswitch, a messaging gateway, a fax server, something stranger — and what you currently do to turn it into a charge.
Submissions go to the vCon Ledger team. We use what you send to reply and to plan adapter work; we don't sell it or pass it on. See the Privacy Policy.