Usage-native billing built on raw events — meter once, price flexibly, re-rate when reality changes.
Orb is a billing engine designed for consumption pricing from the event up. It ingests raw usage events, defines meters over them (including SQL-defined metrics), rates them against plans, credits, and commits, and issues invoices — with the unusual property that pricing is decoupled from metering, so you can change a price or fix a meter and re-rate history without re-instrumenting the product. For AI companies juggling tokens, credits, and per-model rate cards, that architecture is the pitch.
Which of the capability map's modules Orb covers — each links to the module's own page, with every tool that supports it.
| Module | Phase | Depth | Note |
|---|---|---|---|
| Fulfill & Bill | |||
| Usage Event Ingestion (API) | Consume & Meter | Core | |
| Idempotency & Deduplication Layer | Consume & Meter | Core | |
| SQL-Based Billable Metrics | Consume & Meter | Core | Metrics defined in SQL over ingested events. |
| Aggregation & Rollups | Consume & Meter | Core | |
| Event Correction & Replay | Consume & Meter | Core | Re-rate history after meter fixes or price changes — the architectural signature. |
| Late-Arrival Event Handling | Consume & Meter | Core | |
| Mediation Engine | Consume & Meter | Supported | |
| Wallet / Credit Drawdown | Consume & Meter | Core | Prepaid credits, burndown, expiry, and top-ups as first-class primitives. |
| Rating Engine | Rate & Bill | Core | |
| Invoice Generation | Rate & Bill | Core | |
| Threshold Alerts & Notifications | Consume & Meter | Supported | |
| Auto Top-Up / Replenishment | Consume & Meter | Supported | |
| Self-Service Billing Portal | Rate & Bill | Supported | |
| Billing Simulation / Dry Run | Rate & Bill | Supported | |
| Run Revenue Operations | |||
| Proration Engine | Lifecycle Changes | Supported | |
| Revenue Recognition (ASC 606) | Financial Operations | Partial | Rev-rec reporting feeds the ERP; the ERP stays the system of record. |
| Grow Revenue | |||
| Consumption-to-Commit Conversion | Expansion Channels | Supported | PLG-to-contract motion — convert on-demand usage into committed contracts. |
| Real-Time Usage Dashboards (Customer-Facing) | Platform & Intelligence | Supported | Embeddable customer-facing usage and spend views. |
Scored against UsagePricing's Usage-based billing & metering rubric v1.0 (0 weak · 1 adequate · 2 strong), assessed July 2026. Requirements we couldn't verify from public material stay unscored — never guessed. Read the method.
| Requirement | Score | Why |
|---|---|---|
| Real-time balances & drawdown Can a customer (and your product) see an accurate credit or spend balance mid-period? | 2 · Strong | Prepaid credits with drawdown, expiry, and balance APIs are first-class primitives. |
| Correction & re-rating When a meter was wrong, can you fix history without hand-editing invoices? | 2 · Strong | The architectural signature — void, backfill, and replay events, then re-rate history under corrected prices. |
| Commits, credits & custom rate cards Can it express how enterprise AI deals are actually signed? | 2 · Strong | Commitments, credits, and per-customer plan overrides are core product surface. |
| Billable-metric flexibility Can finance define a new meter without re-instrumenting the product? | 2 · Strong | Billable metrics defined in SQL over raw ingested events. |
| Invoice & proration correctness Do mid-cycle changes, consolidation, and multi-currency come out right? | 1 · Adequate | Proration and invoice grouping are solid; deep multi-entity consolidation is thinner than incumbent billing suites. |
| Rev-rec & ERP handoff Can the numbers survive an audit once they leave the billing system? | 1 · Adequate | Rev-rec-ready reporting and ERP syncs exist; the ERP remains the system of record for the ledger. |
| Ingestion scale & integrity Does the meter stay correct at production event volumes? | 2 · Strong | Idempotent event API plus batch paths, with late-arrival handling documented as core behavior. |
| Price-change velocity How fast can you ship a pricing change safely? | 2 · Strong | Decoupled pricing and metering plus simulation lets price changes ship and re-rate without re-instrumentation. |
The event-sourced core. Where subscription-era billing systems bolt usage onto plan objects, Orb treats the event stream as the source of truth — late events, corrections, and audits replay cleanly, and finance gets a drill-down from invoice line to raw events. Credits and prepaid commits with drawdown are first-class, matching how AI infrastructure actually sells.
Deeper into the AI pricing stack: richer credit and commitment mechanics, margin/COGS visibility alongside revenue, and analytics that treat pricing as something to simulate and iterate, not just execute. Orb is positioning as the system of record for consumption revenue — the layer between the warehouse and the ERP.
According to UsagePricing's corpus, Orb appears in 8 of 307 monetization-signal blocks — small next to Stripe's 89, but concentrated in exactly the segment this site tracks: AI-native companies with token, credit, or hybrid pricing. The corpus pattern is Orb-on-Stripe: Orb owns meters, rating, and invoice logic; Stripe keeps the vault and settlement. The open question we watch is durability — the build-vs-buy line, since the biggest AI companies in the corpus still run in-house metering pipelines Orb would love to replace.
Platform fee, sales-quoted. Scales with usage volume and features rather than a percentage of billings.
COGS alongside revenue per customer and feature — pricing decisions with unit economics attached.
Expanded prepaid-credit, commitment, and drawdown mechanics — matching the contract shapes AI infrastructure actually signs.
Mayfield-led round to scale the usage-based billing platform as AI-native demand accelerates.
8 of the companies the Blueprint tracks — from public job posts, engineering blogs, and filings. Every claim links to its evidence on the company page.
Orb starts from raw events and treats rating as replayable computation — SQL meters, credits, commits, re-rating — while Stripe Billing starts from subscriptions with meters attached. The corpus pattern isn't either/or; it's Orb for pricing logic with Stripe underneath for payment and settlement.
Companies whose pricing is genuinely consumption-shaped — tokens, API calls, compute — especially once credits, negotiated rate cards, or commit contracts appear. If you sell flat seats, it's more engine than you need.
No. Orb produces the rated, auditable revenue detail and rev-rec-ready reporting; NetSuite or the ERP still owns the ledger and the close. Billing-engine-to-ERP sync remains part of the integration work.
By overlap on the capability map — computed, not curated.
Tools co-named with Orb in tracked companies' stacks.