Lago vs Orb 2026: Metering, Pricing, and Ownership

Lago or Orb: decide who should operate billing

Choose Lago when deployment control and access to an open-source billing engine are important requirements, and your team can own the corresponding operations. Choose Orb when you prefer a managed commercial platform and want to define billable metrics over usage events using SQL. Neither choice removes the need to reconcile product usage, customer contracts, invoices, and accounting records.

Usage-based billing infrastructure converts customer consumption into charges under an agreed pricing model, then produces the records needed to invoice and explain those charges.

TL;DR: Lago deserves the shortlist for teams that need a self-hosting option; Orb deserves it for teams prioritizing managed billing and query-driven metrics. Both vendors' commercial offerings require quotes. Decide using your actual contract rules and correction scenarios, rather than assuming either vendor is cheaper or easier from its positioning.

Pure usage-based pricing: 21.2% of surveyed SaaS companies according to SBI (2025). That survey describes pricing adoption, not vendor performance. Your decision still depends on whether your business combines consumption with subscriptions, commitments, credits, or negotiated exceptions.

Who this is for

This comparison is for a billing or product lead who already understands what customers consume and is choosing where metering, pricing configuration, and invoice generation should live. It is especially useful when changing a package requires application releases, finance cannot explain an overage, or enterprise exceptions are accumulating outside the billing system.

Red flags: customer usage cannot be reliably attributed to an account or subscription; nobody owns reconciliation and billing incidents; the existing billing tool already handles your straightforward subscription and overage rules.

If those conditions apply, repair the event contract or simplify the operating process before migrating. A more flexible billing engine can express more rules, but it cannot decide which rules your customers agreed to.

Key Takeaways

• Lago's deployment options make it a candidate when infrastructure control matters; self-hosting requires an accountable owner for upgrades, recovery, and incidents.

• Orb's SQL-based metrics make it a candidate when billable consumption requires transformations over raw events; those queries still need review and change control.

• Public commercial pricing is Quote-based for both vendors. Obtain comparable proposals using the same event volumes, billings, integrations, and support requirements.

• Corrections deserve as much attention as initial invoice creation. Replay duplicates, late usage, and disputed events before committing to either engine.

• Keep billing calculations in the chosen engine and design surrounding reconciliation, approvals, and reporting around an explicit system of record.

How we evaluated billing fit

This is a public-information buyer's guide, not a deployment benchmark. The weights below are our proposed procurement rubric, not research findings or measured vendor scores. They emphasize invoice correctness and operating ownership because a feature that exists on paper may still require substantial integration work.

The proposed weights total 100%. Change them before procurement if self-hosting is mandatory, your accounting integration is fixed, or credit deductions are central to the product. Treat a failed mandatory requirement as a disqualifier rather than averaging it away with unrelated strengths.

Research sample: 321 SaaS operators and executives according to SBI (2025). That context matters: industry surveys help identify questions, but they do not establish that Lago or Orb will implement your contracts correctly.

Request evidence tied to your proposed configuration: a representative event payload, a pricing rule, an invoice preview, a correction, and an export. Keep unsupported requirements marked unknown until documentation, contractual commitments, or a controlled evaluation resolves them.

Lago's fit: deployment control with an ownership obligation

Lago's Premium offering supports cloud and self-hosted deployment, and its listed capabilities include billable metrics, prepaid credits, customer-specific plan overrides, invoice previews, and credit notes. Progressive billing, tax integrations, and CRM or accounting integrations are listed as add-ons, according to Lago. Confirm the edition and commercial scope for each required capability.

Best fit: a team that explicitly needs deployment choice and wants billing infrastructure it can operate within its own environment. That is an architectural preference, not proof of lower ownership cost. A self-hosted installation still requires infrastructure, backups, upgrades, monitoring, and a documented recovery process.

Implementation should begin with the event contract. Agree on customer and subscription mapping, what constitutes billable consumption, which event properties carry quantities, and how failures are retained for replay. Then map commercial rules to plans and charges before finance reviews invoice output.

The main limitation for procurement is edition ambiguity. Open-source availability does not establish that a particular commercial feature is included in your intended installation. Require an explicit capability list and separate implementation responsibilities from ongoing support. An add-on that is essential to your workflow belongs in the initial proposal.

Disqualify the self-hosted route if nobody will own recovery and patching, or if the team expects the vendor to operate infrastructure that it has chosen to run itself. Evaluate the cloud route separately; rejecting self-hosting does not automatically reject Lago.

During evaluation, ask the billing operator to investigate an intentionally incorrect quantity using ordinary permissions. The useful outcome is an explanation connecting source usage, aggregation, applicable pricing, and invoice state. If that explanation requires undocumented database edits, resolve the gap before migration.

Orb's fit: managed billing and query-defined consumption

Orb lists 3 commercial plans—Core, Advanced, and Enterprise—with custom pricing. Its pricing model uses billings and events, with a platform fee also applying to Advanced and Enterprise; Salesforce and NetSuite integrations are listed for those higher tiers, according to Orb. Include your required integration tier in the comparison from the outset.

Best fit: a team that wants a managed billing service and whose usage definitions benefit from querying event data. Orb documents custom SQL metrics, so the evaluation should include your actual transformations rather than just a simple event counter. Ask who reviews metric changes and how the operator checks their effect on invoices.

Implementation still needs a stable source event schema, customer mapping, subscription configuration, and downstream finance handoffs. Hosted infrastructure reduces the infrastructure you operate directly; it does not decide whether a failed request is chargeable or whether a customer-specific discount applies.

Documented reporting grace period: 12 hours, configurable account-wide according to Orb. The same documentation warns that backfilling before the current billing period for customers using the credit ledger may not update deductions in issued invoices, and that ordinary ingestion and backfills have distinct idempotency considerations.

Those details are meaningful limitations to test, particularly for prepaid products and delayed telemetry. Ask the vendor to walk through a dispute after invoice issuance and a historical credit adjustment. Do not equate the ability to amend an event with permission to rewrite every downstream financial record.

Disqualify Orb if the proposed service cannot meet a mandatory deployment requirement or if its documented correction behavior conflicts with your accounting process and no acceptable adjustment procedure exists. Conversely, do not reject it solely because your team could build the same calculations: maintaining those calculations is part of the alternative's cost.

Normalize the features before comparing proposals

The matrix summarizes the documented commercial capabilities discussed above. It is a scope comparison, not a claim that every capability is available in every edition or that either vendor has passed your evaluation.

Some cells describe different implementation approaches rather than missing features. SQL flexibility matters if your metrics need it; deployment flexibility matters if your architecture needs it. Neither advantage is useful when it adds complexity without addressing a requirement.

If metering is the unresolved part of the architecture, use the B2B SaaS metering comparison to refine the event and reconciliation questions before choosing the broader billing engine.

Pricing and TCO: obtain comparable proposals

Pricing checked October 10, 2026.

The commercial offerings below are Quote-based because the vendor pricing pages do not publish monetary rates. The plan names and availability come from the primary pricing pages cited in the vendor profiles. No private quote, remembered rate, or third-party estimate is substituted for public pricing.

Lago's open-source deployment path should receive its own ownership assessment; it is not interchangeable with Premium. Avoid treating source availability as an all-inclusive commercial proposal. Likewise, Orb's invoice-based billings metric deserves careful review: its pricing page includes taxes and other invoice amounts in that definition.

Request proposals using the same operating assumptions. Include ordinary traffic, duplicate delivery attempts, retained history, usage spikes, customer-specific contracts, accounting destinations, and support expectations. Ask how amendments, backfills, and migration traffic affect billable usage under the vendor agreement.

Build the ownership model around software charges, hosting where applicable, initial migration, integration maintenance, reconciliation labor, and incident response. Separate one-time work from recurring work. Use your actual staffing costs and quoted terms; public information alone cannot establish which vendor is cheaper.

A meaningful exit comparison also asks what you can export: customers, subscriptions, pricing configurations, event history, invoices, and adjustments. Determine whether the export is sufficient to reproduce an explanation of an old bill, rather than merely import current customer names elsewhere.

Make the invoice explainable before replacing the engine

Usage-based pricing preference: 39% of surveyed enterprise CIOs according to L.E.K. Consulting, citing a survey about purchasing AI applications (2025). That finding concerns buyer preference in a specific context; it is not a Lago-versus-Orb ranking or evidence that a billing migration improves growth.

The practical lesson is to make consumption understandable. Your customer should be able to connect the product's usage display to the invoice's quantities, allowance, and overage. Decide which system owns each number before adding another reporting or automation layer.

Consider a clearly illustrative customer contract, not either vendor's platform pricing: it includes 10,000 API calls and charges $0.02 for each additional call. Suppose the source contains 12,500 distinct calls plus 200 duplicate deliveries, producing 12,700 delivery attempts. Under this hypothetical rule, chargeable overage is 12,500 − 10,000 = 2,500 calls, and the usage charge is 2,500 × $0.02 = $50. Lago's documented transaction_id identifies the event, while external_subscription_id associates it with the subscription, according to Lago. Preserve identifiers across retries, then demonstrate that the configured metric and allowance produce this expected charge; the calculation is a proposed acceptance example, not a reported test result.

A proposed US Tech Automations workflow could trigger when a billing-period usage export becomes available, read the selected engine's usage and draft-invoice data, and compare it with warehouse totals by customer and subscription. Its output would be a reconciliation packet containing matched quantities, unmatched events, and exceptions. Prerequisites include authorized read access through supported APIs or exports, stable account identifiers, agreed metric definitions, and a destination for review. Finance would approve exceptions before invoice finalization; the workflow would not silently change billable usage.

A second configurable US Tech Automations workflow could trigger when a pricing change receives internal approval, read an approved contract export and the current billing configuration, and compare the proposed effective dates, allowances, and rates. Its output would be a migration review packet and draft operational tasks for the billing owner. Prerequisites include a structured source of approved terms, permitted vendor configuration access, and a supported preview or export path. Product and finance would review the differences before any subscription changes; unavailable data would remain an exception rather than an inferred value.

These proposed workflows sit above the billing engine. They coordinate evidence and decisions while Lago or Orb remains responsible for configured metering and rating. The usage reporting automation guide provides related reporting context; choose your billing definitions before designing the report.

DIY orchestration deserves a fair comparison

Zapier, Make, n8n, and an in-house service can support surrounding workflows. Run histories, retries, error branches, and audit evidence can be configured; they are not exclusive reasons to buy another service. For example, execution investigation and error workflows are documented according to n8n. The buyer still designs and owns observability, idempotency, escalation, access controls, retention, and maintenance.

The proposed managed design would differ through explicitly assigned responsibilities: persist reconciliation inputs, route ambiguous differences to a named reviewer, and document replay and escalation procedures. Require those deliverables in the scope. If your team already maintains them effectively in an existing automation tool, duplicating that layer adds little value.

A parallel-run checklist that exposes billing surprises

Build an evaluation dataset before changing production collection. Keep invoice delivery and payment collection disabled in the evaluation environment, and compare candidate output with independently calculated expectations. The following numbers are synthetic inputs for a count-based metric, not vendor limits or observed results.

Add late-event and historical-credit cases separately because their expected financial outcome depends on your invoice state, vendor configuration, and contract rules. A valid evaluation must distinguish event acceptance, metric aggregation, rating, invoice finalization, and accounting adjustment.

Then walk the operator through an interrupted export, a failed integration, and an account identifier that cannot be matched. Each should produce an actionable exception with retained evidence. An apparently successful workflow that drops unmatched events should fail your acceptance process.

Before cutover, document which system may create invoices, which may collect payments, how historical invoices remain accessible, and how rollback preserves customer state. Run the same account through both configurations and explain every difference. Do not retire the old process merely because the new engine generated an invoice.

Questions that should decide the shortlist

Is Lago or Orb cheaper?

Public commercial pricing does not establish a cheaper choice. Compare written proposals and your ownership costs using identical assumptions. A self-hosted architecture can shift work to your team, while a managed service can shift infrastructure responsibility to the vendor; neither shift automatically reduces the total.

Can Lago replace Orb for a self-hosting requirement?

Lago is the clearer candidate when self-hosting is a mandatory requirement. Confirm that the intended edition includes your commercial capabilities and that security, recovery, and support responsibilities are acceptable. Deployment choice alone does not prove equivalent behavior for every existing Orb configuration.

Does Orb eliminate custom billing engineering?

Orb can provide the billing engine, but your team still owns product instrumentation and integration decisions. SQL-defined metrics also need review, representative inputs, and change control. The objective should be reducing unnecessary duplicated billing logic while retaining clear ownership of event quality.

Can either platform handle credits and negotiated contracts?

Both have relevant capabilities, but suitability depends on the specific contract and correction lifecycle. Evaluate allowance application, expiration, customer-specific pricing, invoice issuance, and disputed consumption together. A credits checkbox does not demonstrate that historical deductions can be changed in the way your finance team requires.

Should we keep our existing subscription tool instead?

Keep it when it already expresses your pricing and produces explainable usage invoices. Migration adds event mapping, historical reconciliation, and operating changes. The Recurly versus Stripe Billing comparison can help frame whether your requirement is subscription management or a more specialized usage engine.

When NOT to use US Tech Automations?

Use a simpler existing tool when vendor-native exports already satisfy reconciliation, an established Zapier, Make, or n8n workflow has adequate controls, or your in-house service already has maintained ownership and audit evidence. Additional orchestration is also premature when usage definitions and customer attribution are unresolved; fix those prerequisites first.

Choose the owner, then the engine

Lago is the stronger shortlist candidate when deployment control is a requirement and operating ownership is explicit. Orb is the stronger shortlist candidate when a managed service and query-defined metrics match your architecture. The final decision should follow comparable quotes and demonstrated behavior for your contracts, corrections, and finance handoffs.

Your next step is to assemble representative usage, an approved contract, and an expected invoice, then ask each finalist to show the complete explanation. Where cross-system reconciliation remains manual, see how US Tech Automations could configure the review workflow around the chosen engine, with access prerequisites and human approval points defined before implementation.