Usage Metering
From raw events to a defensible invoice line
Usage metering is where usage-based revenue is won or lost. LedgerUp ingests raw usage events, deduplicates and handles late arrivals, rates them against the terms in the signed contract rather than a billing configuration, and keeps a traceable link from each event through the invoice line to recognized revenue.
What usage metering is
Usage metering is the collection, aggregation, and rating of consumption events — API calls, seats, compute minutes, messages, transactions — into billable quantities. Metering counts what happened; rating turns that count into money using the contract's rate card, tiers, minimums, and caps. Most revenue leakage in usage-based businesses happens in the gap between the two: the count is right, but it's rated against terms that don't match what the customer actually signed.
How usage becomes revenue
The pipeline from raw event to recognized revenue.
Ingest usage events
Events arrive from your product, data warehouse, or billing engine through the API, a warehouse sync, or a native integration — with the customer, metric, quantity, and timestamp needed to bill and later defend the charge.
Deduplicate and handle late arrivals
Retried event deliveries are collapsed by idempotency key so nobody is double-billed, and events that arrive after the period closes are applied to the period they actually belong to, with a visible adjustment rather than a silent restatement.
Aggregate into billable quantities
Raw events roll up per customer, metric, and billing period using the aggregation the contract specifies — sum, peak, unique count, or last value — because the same event stream produces different totals under different methods.
Rate against the signed contract
Quantities are priced using the terms in the executed agreement: rate card, tiers and whether they're graduated or volume-based, included allowances, committed minimums, overage rates, and caps.
Reconcile before invoicing
Rated usage is checked against what's about to be invoiced and against the prior period. Unbilled usage, missed overages, and unexplained swings surface here, while the invoice is still a draft.
Recognize the revenue
Usage revenue flows into the ASC 606 / IFRS 15 schedule with the underlying events attached — so recognized revenue traces back to metered usage rather than being derived from the invoice.
What metering has to get right
The details that decide whether a usage invoice survives a customer challenge or an audit sample.
Event identity and idempotency
A stable event ID so retries and replays collapse instead of double-counting — the single most common cause of over-billing on usage contracts.
Timestamps and period boundaries
Event time versus ingestion time, and which one decides the billing period. Getting this wrong shifts revenue between periods, which auditors test directly.
Aggregation method
Sum, peak, unique count, or last value per metric — set from the contract, since the same events produce very different bills under different methods.
Tiering model
Graduated tiers (each unit priced in the tier it falls in) versus volume tiers (all units priced at the tier reached). Both are common and they produce different totals.
Allowances, minimums, and commits
Included usage, committed minimums with or without true-ups, and how unused commitment carries forward or expires.
Overage rates and caps
What each unit past the allowance costs, and any negotiated ceiling — the terms most often present in the contract but absent from the billing configuration.
Proration and mid-period changes
Plan changes, upgrades, and amendments that land mid-period, and how allowances and minimums prorate across the change.
Retention of raw events
The raw events behind every invoice line, kept and linked, so a customer dispute or an audit sample can be answered from evidence rather than reconstruction.
docs.ledgerup.ai
Open the usage metering guide
Event schemas, ingestion methods, aggregation and tiering configuration, and backfill handling are documented on the docs site.
Go to docs.ledgerup.aiUsage Metering FAQ
What is usage metering?
Usage metering is the collection, aggregation, and rating of consumption events — API calls, seats, compute minutes, messages, transactions — into billable quantities. Metering counts what happened; rating turns that count into money using the contract's rate card, tiers, minimums, and caps.
What's the difference between metering and rating?
Metering counts usage; rating prices it. Most usage-based revenue leakage happens in the gap between them: the event count is correct, but it's priced against a billing configuration that drifted from the signed contract — a negotiated rate never entered, an overage tier nobody set up, a cap applied that the agreement doesn't contain.
How do you handle late-arriving usage data?
Events that arrive after a billing period closes are applied to the period they actually belong to and produce a visible adjustment on the next invoice, rather than silently restating a closed period. The adjustment carries the underlying events, so both the customer and an auditor can see exactly what moved and why.
How does LedgerUp prevent double-counting usage events?
Every event carries a stable identifier, and ingestion is idempotent — a retried or replayed delivery collapses onto the existing event instead of creating a second one. Duplicate events are the most common cause of over-billing on usage contracts, and they're also the hardest to notice, because the invoice looks internally consistent.
Does LedgerUp replace my metering or billing engine?
No. If you already meter in Stripe, Orb, Metronome, or your own pipeline, LedgerUp sits downstream and reconciles: it re-rates the usage against the signed contract and flags where the invoice and the agreement disagree. Teams without a metering layer can ingest raw events into LedgerUp directly through the API.
How is usage-based revenue recognized under ASC 606?
Usage revenue is generally recognized as the usage occurs, since the customer consumes the benefit as it's delivered — but contracts with minimums, committed amounts, tiered pricing, or overage caps introduce variable consideration that has to be estimated and constrained. That's why the link from raw usage to recognized revenue has to be traceable: it's the evidence behind the estimate.