Teams often begin usage billing with a small table and a multiplication step. That is reasonable for a prototype. The surprise is how quickly the surrounding correctness work grows once the number affects revenue.
What expands beyond the first meter
- idempotency for retries and partial failures,
- late and out-of-order events,
- subscription and price effective dates,
- unique-user counting and other non-additive aggregates,
- raw history for disputes and reconciliation,
- period freezing and backfills,
- rating, tax, invoicing, payment collection, dunning, and credits.
Those are different problem domains. The mistake is assuming you must either build all of them or outsource all of them to one vendor.
A better boundary: own the usage facts
Your application is the only place that truly knows what work happened. Emit stable usage facts from that boundary and keep them in a metering layer that is independent of the current payment processor.
Then decide separately whether Stripe, Lago, another billing platform, an ERP, or internal software should perform rating and invoicing.
When building the meter yourself is reasonable
If usage volume is small, aggregation is simple, and one engineering team can own the invariants, an internal meter can be entirely sensible. The important part is recognizing the invariants early rather than treating the table as ordinary analytics telemetry.
When a dedicated metering layer earns its keep
The case gets stronger when many services emit usage, retries are common, events arrive late, billing vendors may change, or customers need explainable reconciliation. At that point the meter is infrastructure with a stable contract, not a feature hidden inside invoice code.
Where UsageBox fits
UsageBox is intentionally narrower than a billing suite. It provides idempotent usage ingestion, raw events, catalog/subscription context, and monthly rollups. It has no monetary rating engine, no invoice generator, no prepaid-credit ledger, and no customer portal today.
If you need one vendor to own the whole quote-to-cash stack, use a broader billing platform. If your problem is keeping usage trustworthy and portable while the biller remains replaceable, that is the UsageBox boundary.
See build vs buy usage billing for the decision framework and the usage metering hub for the implementation pieces.