Complex billing models become much easier to change when the usage meter records stable facts and the rating system owns commercial rules. Mixing both concerns inside product code makes every pricing experiment an instrumentation migration.
The meter should answer quantity questions
- How many API calls did this subscription make this month?
- How many unique active users appeared?
- What was the maximum concurrent or peak value?
- How many tokens or compute units were consumed?
Those facts remain useful whether the commercial model is subscription plus overage, pure pay-as-you-go, prepaid credits, a commitment, or a negotiated enterprise contract.
The rating layer answers money questions
Tiers, volume discounts, graduated rates, minimum commitments, credit burn, currency, tax, and proration are rating or invoicing concerns. They may depend on metered quantities, but they should not change what the source event means.
Version commercial rules, not history
A price change should not mutate the historical usage event. Store the usage fact once and version the pricing rule that interprets it. That gives you a path to reproduce a period and explain why the amount changed.
Handle plan changes with effective intervals
A customer's current plan is not enough to interpret a backdated event. Subscription and pricing state need effective dates so an event can resolve against the state that existed at event time.
Where UsageBox fits
UsageBox currently owns the metering side: event ingestion, subscription/catalog resolution, raw usage retention, and monthly quantity rollups. It does not currently provide monetary rating, credits, tax, proration, or invoice generation.
That means UsageBox can sit in front of a full billing platform rather than trying to replace it. The advantage is portability: the product emits usage to one stable meter while pricing and payment systems can evolve independently.
Compare the two responsibilities in what a billing API must do and build vs buy usage billing.