Metered Billing Explained: Architecture, Pitfalls, Systems

Multi-dimensional metering, credit ledgers, and hybrid overage enforcement each introduce their own failure modes, and they compound as pricing models evolve. These examples break down what each model demands at the infrastructure layer.

What is metered billing?

Metered billing is a pricing model where charges are calculated based on actual usage. Instead of a fixed fee, the system tracks consumption and applies pricing rules to determine what a customer owes.

At a system level, metered billing ties billing directly to measurable events:

• Tokens consumed in AI or LLM workloads
• API calls processed by your service
• Storage used over time
• Compute time or resources consumed

Each of these events must be captured, attributed to a customer, and translated into billable units. 

Example: How AWS uses metered billing at scale

AWS built its pricing around usage from the start. Instead of fixed contracts, customers pay based on actual consumption across compute, storage, and data transfer. This model helped AWS reach 32.4% market share in Q4 2019.

One example is Amazon S3. Pricing depends on how much data you store and how often you access it:

• Standard tier for frequently accessed data
• Infrequent access tier at a lower cost
• Intelligent tiering that automatically adjusts pricing based on access patterns

This goes beyond simple usage tracking. AWS is constantly measuring different types of usage, figuring out what bucket they fall into, and pricing them correctly. At that point, billing is tightly tied to how your system works under the hood.

How metered billing works

Metered billing works by tracking usage events, aggregating them over a billing period, applying pricing rules, and generating an invoice based on that consumption.

It sounds straightforward, but each step depends on systems that need to stay consistent under load.

Usage tracking

Usage tracking is where everything starts. If you get this wrong, nothing downstream matters.

Every billable event needs to be captured at the moment it happens, tied to the right customer and subscription, and stored in a way you can audit later. In practice, this usually means an event pipeline with ingestion, validation, and durable storage.

The tricky part is reliability. Events don’t behave cleanly in production, so your system needs to handle:

• Retries and duplicate events that can inflate usage if not deduplicated
• Service outages or delays that create gaps in tracking
• Backfills and reprocessing when data needs to be corrected

This is why you need idempotency and deduplication built into the pipeline. Miss events and you lose revenue. Double count and you lose trust.

Billing cycle

The billing cycle defines when you stop counting and start charging.

Monthly is common, but some systems move to daily or near real-time billing. The complexity shows up when state changes mid-cycle. Upgrades, downgrades, cancellations, or plan changes all require splitting usage and applying the correct pricing to each segment.

This is where simple “count and multiply” logic breaks. You need time-aware aggregation.

Rate determination

Rate determination is where usage becomes money.

At a basic level, you map units to price. In reality, pricing is rarely flat. You have tiers, volume discounts, feature-based pricing, and sometimes contract-specific overrides.

For example, the first million API calls might cost one rate, the next ten million another. That means your system needs to track total usage and where that usage falls within pricing thresholds.

This logic has to be deterministic and consistent. If the same usage produces different charges in two systems, you have a reconciliation problem.

Invoice generation

Invoice generation is the final step, but it depends on everything upstream being correct.

The billing system takes aggregated usage, applies pricing rules, and produces an invoice. Tools like Stripe, Chargebee, or Zuora handle invoicing and payments, but they rely entirely on the accuracy of the usage data you send.

If your aggregation or pricing logic is off, the invoice will be wrong. The billing platform won’t fix that for you.

Customer visibility

Customers need to see what you’re charging them for before the invoice shows up.

Real-time usage dashboards, alerts, and detailed line items reduce surprises and support tickets. Without visibility, every unexpected charge becomes a support issue.

This also means your internal numbers and customer-facing numbers have to match. If they don’t, you’ll spend time debugging instead of shipping.

Where systems break

Most failures come from small mismatches between systems, such as:

• Duplicate events from retries that inflate usage
• Lagging aggregation jobs that delay or skew totals
• Pricing logic drift between services or environments
• Mid-cycle changes that are not applied consistently

Metered billing only works when tracking, aggregation, pricing, and billing stay in sync. When they don’t, the issue shows up in your invoices, and by then it’s already customer-facing.

Metered billing vs. usage-based billing

Metered billing and usage-based billing both charge based on consumption, but they differ in where usage is processed and how pricing logic is applied.

With metered billing, your system is responsible for turning raw events into billable units. That means building and maintaining:

• Aggregation jobs to roll up usage per customer
• Deduplication and idempotency handling
• Business logic for pricing tiers and thresholds

Every pricing change touches this pipeline. Switching from per-call to per-token billing, for example, usually means rewriting aggregation logic and backfilling data.

With usage-based billing, you send raw events instead of pre-aggregated totals. The billing platform ingests those events and applies metric logic internally.

That shifts complexity out of your pipeline, but introduces different concerns:

• Event volume and ingestion throughput
• Schema consistency across services
• Dependency on the billing platform for pricing logic

In practice, the choice depends on where you want that complexity to live. Metered billing keeps control in your system. UBB pushes more logic into the billing layer.

Platforms reflect this split. Stripe Billing follows a metered billing approach, while Metronome, now part of Stripe's product suite following its 2026 acquisition, is built for event-driven usage-based billing.

In both cases, entitlements are handled separately. Billing tracks and charges for usage, but enforcement of limits happens in a different layer before billing ever sees the data.

What metered billing requires engineers to build

Most teams underestimate the scope of a metered billing implementation. The billing platform handles invoice generation and payment processing. Everything upstream is your problem.

The systems your team has to build or maintain include:

• Event ingestion: A pipeline that captures usage events, attributes them to the correct customer and subscription, and stores them durably at scale
• Deduplication logic: Protection against double-counting events if a service emits duplicates during retries or outages
• Aggregation layer: Logic to roll up raw events into the quantities your billing platform expects
• Limit enforcement: Real-time checks that stop or warn customers approaching their usage cap, before the invoice is generated
• Mid-cycle handling: Logic for upgrades, downgrades, and cancellations that happen partway through a billing period
• Grandfathering: Support for customers on legacy pricing who should not be moved to new rate cards automatically

Miro shipped a metered billing and credits implementation in under 6 weeks with Stigg, work that would otherwise have taken quarters to build and maintain in-house. The team saved 5,000 engineering hours by adopting Stigg rather than extending and maintaining that infrastructure themselves. The gap between estimate and reality is common. The initial scope rarely accounts for edge cases that only appear at scale.

When to use metered billing

Metered billing makes sense when usage varies significantly across customers, and when that variation is material enough that flat-rate pricing would be unfair to one side.

Use metered billing when:

• Usage per customer spans multiple orders of magnitude (a free user runs 100 API calls; an enterprise customer runs 100 million)
• Your product has real marginal costs tied to usage: compute, tokens, data transfer, storage
• Customers expect to pay proportionally to the value they extract
• You need to prevent a small number of heavy users from consuming resources that degrade service for others

Metered billing usually isn’t worth it when:

• Usage differences between customers are small and don't correspond to meaningful cost differences
• The usage metric is difficult to explain to customers in a way that feels fair
• Tracking infrastructure costs more to build than the revenue precision it delivers

AI products have made metered billing more common in SaaS. LLM inference has direct marginal costs: more tokens consumed means more compute spent. That cost structure makes flat-rate pricing difficult to sustain at scale.

Segment8 reported a case where a single customer generated a $67,000 bill from runaway usage. Without limits in place, usage can scale faster than expected. That’s what pushes teams toward metered billing and enforcement layers that cap or throttle usage in real time.

How entitlements work in usage-based and metered billing

Entitlements work by defining and enforcing usage limits before any billable activity is recorded, so that metered billing only tracks allowed consumption.

Metered billing tracks usage and generates invoices. It does not control access. That happens in the entitlements layer.

In a metered system, entitlements act as the guardrails for usage:

• A plan might allow 50,000 API calls per month
• Another might allow 1,000
• Enterprise plans may have custom or unlimited limits

These limits are enforced at runtime, before the request is processed. If a customer exceeds their entitlement, the system can block, throttle, or prompt for an upgrade.

Entitlements can come from multiple sources:

• Base plan
• Add-ons
• Trials or promotional credits

When multiple sources apply, the system resolves them into a single effective limit.

How entitlements enforce limits in metered systems

An entitlement check returns structured data used during request handling:

• Access status: Can this request proceed
• Usage limit: The allowed cap
• Current usage: What has been consumed
• Unlimited flag: Whether limits apply

This data is used directly in the request path:

• The backend checks entitlements before processing usage
• If allowed, the request is executed and usage is recorded
• If not, the request is blocked or flagged

This is what connects metered billing to real system behavior. Billing happens after usage, but enforcement happens before it. Without this layer, metered billing can track usage, but it cannot control it.

Credits in metered billing for AI products

Credits are a prepaid version of metered billing. Instead of charging at the end of a cycle, customers buy credits upfront and spend them as they use the product.

In AI systems, this is common because usage is tied to tokens, compute, or model calls.

Supporting credits requires more than tracking usage:

• Credits are issued in blocks with their own expiry dates and cost basis
• Paid and promotional credits are tracked separately
• Burn order matters, for example using promotional or expiring credits first

Depletion behavior also needs to be defined:

• Hard depletion stops usage when credits run out
• Soft depletion allows overages and flags them for billing later

Every transaction must be written to an append-only ledger. This ledger is used for:

• Revenue recognition
• Auditing and dispute resolution

This is where most teams underestimate the work. You need a system that accurately tracks credit state, burn order, and history.

Stigg handles this with built-in support for credit blocks, expiry, burn order, and ledger tracking, so teams don’t have to build and maintain it from scratch.

Where Stigg fits in a metered billing stack

Stigg handles the product-facing layer of metered billing. It defines what customers can access, how much they can use, and tracks that usage before billing.

Billing platforms handle invoices, tax, compliance, and payments. Stigg sits upstream of that.

Typical stack:

• Product
• Stigg (entitlements, metering, credits)
• Billing (Stripe, Zuora, etc.)
• Finance (NetSuite)

Stigg integrates with billing; it doesn’t replace it. Billing systems process charges, whereas Stigg controls access and usage.

For teams with data residency requirements, the enforcement layer needs to run inside their own infrastructure. A BYOC deployment keeps entitlement data within the VPC and removes any dependency on external uptime for read-path decisions.

How Stigg handles entitlement checks at scale

Stigg uses a sidecar architecture for low-latency enforcement:

• Runs as a Docker container in your environment
• Maintains a local Redis cache of entitlement data
• Cache hits resolve instantly from local memory
• Cache misses fall back to Stigg's Edge API at 100ms, with a configurable timeout to prevent upstream latency from cascading into your application.

This keeps entitlement checks fast enough to run in the request path without adding noticeable latency.

When teams outgrow in-house systems

Most teams start with a simple setup that works early on, but complexity builds over time.

What starts as a quick solution turns into a system that requires ongoing maintenance and coordination across teams. That’s usually the point where teams either rebuild internally or move to a dedicated solution.

Enterprise accounts run teams, departments, products, and agents that all draw from shared budgets simultaneously. The enforcement layer has to stay accurate and fast across all of it, or the checks get disabled and the protection disappears.

How to implement metered billing without breaking your system

Stigg sits in the request path and enforces entitlements, credits, usage limits, and spend governance synchronously before compute runs.

• Entitlement checks run from a local Sidecar cache. Cache hits resolve immediately, and cache misses fall back to Stigg's Edge API at ~100ms, with a configurable timeout to keep upstream latency out of the request path
• The credit ledger tracks every deduction against the correct block, with burn order, expiry, and concurrent write safety built in
• Budget controls apply at the user, agent, team, and org level without a data model rewrite for each hierarchy level
• The BYOC Sidecar runs inside your own VPC, keeping enforcement live during upstream interruptions with no external data dependency
• Stigg sits above your existing billing stack and syncs usage events to Stripe, Zuora, or any existing provider without touching payment infrastructure

Teams that only need the credit ledger or entitlement enforcement layer can adopt either component independently. There’s no requirement to use the full stack.

Engineering teams that have outgrown homegrown metering or are building this layer for the first time should see how Stigg’s runtime layer fits into their stack.

FAQs

1. How do you track usage accurately in metered billing?

You track usage accurately in metered billing by capturing every billable event with unique identifiers and storing it in a reliable event pipeline. Most systems use idempotency keys and deduplication logic to prevent double-counting or missing events.

2. What are common metered billing mistakes teams make?

Common metered billing mistakes include relying on incomplete usage tracking, skipping deduplication, and not handling mid-cycle changes correctly. These issues often lead to billing discrepancies and customer disputes.

3. Can metered billing work without real-time enforcement?

No, metered billing cannot reliably work without real-time enforcement if you need to control usage. Without enforcement, customers can exceed limits before billing catches up, which creates risk for both cost and system performance.

4. How do you test a metered billing system before launch?

You test a metered billing system by simulating real usage patterns, including retries, spikes, and failures. Teams also validate aggregation logic and compare system-generated usage against raw event logs to ensure accuracy.

5. What is the difference between usage limits and billing limits?

The main difference between usage limits and billing limits is that usage limits control access in real time, while billing limits only affect how charges are calculated after usage occurs. Usage limits prevent overconsumption, while billing limits do not.