.png)
Month-end at a usage-based company starts with a warehouse export. Someone on the accounting team pulls last month's usage from Snowflake, lines up each customer's activity against the rate in their contract, follows up with the data team on the accounts that don't match, and builds the invoice file. A few days later the revenue accountant takes the same usage, pulls it into a separate schedule, and works to make sure what was billed and what was earned tie out before the books close.
Usage-based billing software takes over the first half of that work by turning usage into invoices, and the strongest tools carry it all the way through to ASC 606 revenue recognition. Numeric's Billing and Revenue product is built that way. It runs usage billing and revenue recognition on the same contract for SaaS and AI companies that charge by usage, so the invoice and the revenue schedule come from one record and stay in sync as the contract changes.
Usage-based billing software takes in records of what each customer consumed, prices that consumption using the terms in the customer's contract, and produces invoices at the end of each billing period. The unit of usage depends on the business. An AI company might bill per token or per API call, while a payments platform might bill per transaction processed. Whatever the unit, the software has to know which customer generated each event, which contract and rate apply, and how the charge should appear on the invoice.
Most usage pricing falls into one of three models.
AI companies have pushed this category forward quickly. Billing per token produces a high volume of usage events every day, and enterprise AI contracts often carry pricing negotiated customer by customer. Subscription companies feel the same pressure on a smaller scale when they add a usage tier to seat pricing, because the accounting team suddenly needs a reliable monthly usage file before it can invoice anyone.
We compared these tools on how well each one carries usage from the warehouse through invoicing and ASC 606 revenue recognition.
The right tool depends on the problem the team is solving and how much of the path from usage to revenue it wants in one system. Usage billing sits inside the broader market for accounting automation software, and the options group naturally by where each one starts and stops.
The deciding question is whether the team wants billing and revenue recognition to share one contract record or is comfortable maintaining the reconciliation between two.
.png)
SaaS and AI companies that want usage billing and ASC 606 revenue recognition on one contract record, with NetSuite or Numeric's Financial Data Platform as the accounting system.
In Numeric's Billing and Revenue product, billing tracks what the customer owes, and revenue recognition tracks what the company has earned, both from one record that holds the contract terms, the usage, and every change along the way. Teams can keep NetSuite as the accounting system, with invoices and revenue entries exported to it each period, or run their accounting on Numeric's Financial Data Platform.
Deal terms come in from Salesforce or HubSpot, and each contract is captured in the platform with its full terms before the first invoice goes out. AI reads the signed contract and checks it against the deal booked in the CRM, catching errors before the first invoice. On the billing side of the product, usage events from a warehouse like Snowflake or Databricks come into the platform, and Numeric matches each one to the right contract and turns it into invoice line items. Subscription and usage pricing sit on the same contract.
With the revenue recognition capability, revenue schedules build automatically from invoices or usage. Bundled deals are allocated by SSP the way ASC 606 requires, and revenue updates when a customer upgrades, renews early, cancels, or receives a credit. Every revenue number traces back to the original contract and the usage behind it, which gives auditors a clear trail for each sample they pull.
That record covers each of the five jobs a usage-based billing system needs to handle.
Built Technologies, an AI-powered real estate finance platform, bills its customers on a usage-based model. In early 2026, Built moved its accounting, including billing and revenue, onto Numeric's Financial Data Platform. Before the move to Numeric, Built's legacy setup kept only a few fields from each transaction, and assembling billing data took several days with people across multiple departments. Today the team has freed two FTEs' worth of bandwidth from billing and revenue work and delivers invoices to customers four business days earlier. The team also sees live data every day of the month, well before invoicing begins. Controller Asia McKnight put it this way. "Today is the second day of the month, and I already have events live for this month coming in." McKnight's team looks into variances as they appear instead of waiting for close.
Teams can also start smaller, with Billing and Revenue on its own, and move the rest of their accounting onto the Financial Data Platform once the case for it is clear.
Numeric prices Billing and Revenue based on contract volume and company size. Schedule a demo to get a quote.
Numeric's team sets up every connection for the customer. HubSpot connects directly, while Salesforce data and warehouse usage from Snowflake or Databricks arrive through a shared Amazon S3 folder, usually daily. Anrok, Stripe, and bank feeds connect for sales tax and payment matching, and invoices and revenue entries export to NetSuite as files or stay in Numeric for teams running on the Financial Data Platform.
Schedule a demo to walk through how your team bills and recognizes usage revenue today.
.png)
AI and infrastructure companies with high-volume usage and frequent pricing changes.
Metronome is a usage billing platform built to process large event volumes and price them against flexible contracts, including commits and customer-specific rates. Stripe completed its acquisition of Metronome, and it now operates as part of Stripe. Revenue reporting is available, and allocating price across bundled deals under ASC 606 usually happens in a separate revenue system or a workbook the revenue accountant maintains.
Metronome doesn't publish pricing. Quotes typically reflect event volume, a platform fee, and billings.
Usage events are sent to Metronome through its API, and the engineering team usually owns setup and pricing changes.
.png)
Product and engineering teams that change usage pricing often and want to preview changes before rolling them out.
Orb ingests raw usage events and lets teams define and revise pricing on top of them, with tools to see how a price change affects invoices before it ships. It supports hybrid subscription and usage plans. Revenue reports are available, and the full ASC 606 schedule, including SSP allocation for bundled deals, typically runs in a separate system that receives Orb's invoice data.
Orb offers Core, Advanced, and Enterprise plans with custom pricing, quoted mainly on billings and event volume.
Usage events flow in through Orb's API. CRM, ERP, and warehouse sync come with the Advanced plan and add integration work.
.png)
Companies that already collect payments through Stripe and want usage billing in the same place.
Stripe Billing records usage and bills it on subscription invoices, with payments, sales tax through Stripe Tax, and collections in the same account. Stripe Revenue Recognition is a separate add-on that builds revenue schedules from Stripe billing data. Teams with bundled deals or frequent contract amendments should test how SSP allocation and modifications are handled before relying on it for the close.
Stripe Billing costs 0.7% of billing volume on pay-as-you-go pricing, on top of payment processing fees. Stripe Revenue Recognition is priced separately.
Teams already on Stripe get started fastest, since usage pricing, invoices, and payments live in the same account. Usage is reported through Stripe's API.
.png)
Subscription businesses adding a usage component to plan-based pricing.
Chargebee handles subscription management, invoicing, and usage charges on top of plans, with a large library of payment gateway and CRM integrations. Revenue recognition runs in Chargebee RevRec, a separate product, so the revenue team works from data synced between the two. The monthly tie-out of billed to earned revenue happens across both products.
Chargebee offers a free Starter plan, a Performance plan from $599 per month billed annually, and custom Enterprise pricing. RevRec is a separately priced add-on.
Plans, usage charges, and payment gateways are configured in the app. RevRec is set up as a second product with data synced from billing.
.png)
B2B SaaS finance teams that want billing, revenue recognition, and SaaS metrics in one platform.
Maxio formed from the merger of SaaSOptics and Chargify and covers subscription and usage billing, revenue recognition, and reporting on metrics like ARR and churn. It's built with finance teams in mind and connects to accounting systems like NetSuite and QuickBooks. Teams with high-volume usage or heavily negotiated AI contracts should check how usage arrives from the warehouse and how contract amendments flow into revenue.
Maxio's Grow plan starts at $599 per month billed annually, with custom pricing for the Scale plan.
Maxio is built for finance teams to configure, with connections to accounting systems like NetSuite and QuickBooks.
.png)
Large enterprises with complex product catalogs and global billing needs.
Zuora is one of the longest-standing subscription billing platforms, with support for usage, tiered, and hybrid pricing at enterprise scale. Revenue recognition runs in Zuora Revenue, a separate product built for ASC 606 and IFRS 15. The pairing covers a lot of ground for large teams, and implementation timelines and cost tend to match that scope.
Zuora pricing is custom, and Zuora Billing and Zuora Revenue are quoted separately.
Implementations run at enterprise scale, typically with a dedicated internal team or an implementation partner.
.png)
Teams that want revenue recognition to live inside NetSuite.
Advanced Revenue Management is NetSuite's revenue add-on, and it builds revenue schedules from NetSuite transactions with support for SSP allocation and contract modifications. Usage billing usually comes from SuiteBilling or an outside billing tool that feeds NetSuite.
NetSuite ARM pricing is custom, and the add-on is quoted with your NetSuite license.
ARM is configured inside NetSuite, often with a NetSuite partner, and usage billing comes from SuiteBilling or an outside billing tool.
.png)
Teams that want to keep their current billing tool and add a dedicated revenue subledger.
RightRev automates ASC 606 revenue recognition, including SSP allocation and contract modifications, and pulls data from billing and CRM systems. Because it handles revenue without billing, it relies on a data feed from whichever system sends the invoices.
RightRev pricing is custom.
RightRev connects to existing billing and CRM systems, including a Stripe connector added in 2026.
Five jobs sit between a raw usage event and a paid invoice. A tool that handles all five keeps invoicing on the accounting calendar.
Usage data usually lives in a data warehouse like Snowflake or Databricks, well outside the billing and accounting systems. The first job is getting those usage events into the billing tool on a regular schedule and matching each one to the right customer and contract.
Matching gets harder when a customer has two active contracts or a rate that changed partway through the month. Each of those cases needs a clear rule for which contract the usage belongs to, and the best tools apply that rule the same way every period. A setup the finance team can maintain on its own keeps invoicing moving when the data team is busy.
Once usage is matched, the system applies the contract's pricing. That might be a flat per-unit rate or a tiered schedule where the rate steps down at volume thresholds, often with a platform fee on the same invoice. A contract priced at $0.004 per call for the first 10 million calls and $0.003 per call after that needs the system to know where each customer sits on the tier at every point in the month. The system then totals the charges for each customer, assembles a draft invoice, and routes it for review before it goes out.
Invoice accuracy depends on the contract terms in the billing tool matching what the customer actually signed. Deal terms usually start in the CRM, and a discount entered incorrectly in Salesforce or HubSpot carries onto every invoice that follows. A finance review of each new contract's terms before the first invoice catches those errors while they are still easy to fix.
Every usage event should end up on an invoice, and the events that match no contract are the ones most likely to slip past. A new product SKU that has no rate yet, or a customer ID that changed during a system migration, can leave billable usage sitting in the warehouse with nothing pointing it to a contract.
Good tools flag unmatched usage before month-end, while there is still time to look into it, assign it to the right contract, and bill it in the correct period. Catching it during the month keeps it out of the close.
Usage contracts change often. Customers upgrade to a higher tier, renew early at new rates, add a product, cancel part of a deal, or receive a credit for a service issue. Each change affects the next invoice, and it also affects the revenue already recognized and the revenue still to come.
The difference shows up in how a tool records the change. A system that applies the change to the original contract on its effective date keeps the history intact and updates billing from that point forward. When the change lives only in the billing tool, the revenue accountant has to hear about it, work out the accounting treatment, and update the revenue schedule separately.
After the invoice goes out, a few more pieces close the loop. Sales tax has to be calculated correctly for each customer's location, usually through a dedicated tax engine. Incoming payments from Stripe or the bank have to be matched to the right open invoices, a step known as cash application. Credit notes and refunds also need to flow back through tax and revenue so every record agrees.
These steps make up the back half of the order-to-cash process, and they go fastest when every payment can be traced to the invoice and contract it settles.
A billing tool generates invoices, and ASC 606 needs a recognition schedule. The invoice tells the customer what it owes, while the revenue schedule tells the auditor what the company has earned and in which period. For a simple monthly usage charge the two numbers often match, but bundled deals and mid-term contract changes pull them apart quickly.
Three parts of ASC 606 carry most of the weight for usage-based companies.
SSP allocation for bundled deals. When a contract bundles distinct pieces, like a subscription and an implementation project, ASC 606 splits the price between them by standalone selling price (SSP). Take a $120,000 deal with a $100,000 subscription and a $20,000 implementation fee. At SSPs of $110,000 and $40,000, $32,000 of revenue goes to implementation. The invoice says $20,000, so billing and revenue disagree from the first month.
Variable consideration for usage. Most teams recognize a monthly usage charge as they bill it. Committed minimums, tiered discounts, and credits can break that link, so the team has to estimate what it will earn and book only the amount that's unlikely to reverse.
Contract modifications. An upgrade or early renewal can be treated as a separate contract, as a fresh start on the remaining term, or as a catch-up to revenue already booked. Which one applies depends on whether the added and remaining services are distinct, and whether the added services are priced at SSP. Each path produces a different revenue schedule from the same invoices.
When billing and revenue live in separate tools, each of these steps runs through a handoff. The revenue accountant exports invoices and usage from the billing tool, redoes the allocation in a workbook or revenue system, and posts entries to bring the ledger in line. Each month someone ties billed revenue to earned revenue and explains the movement in deferred and unbilled balances. When an auditor samples a transaction, the team pulls the contract, usage, invoice, and revenue entry from different systems and lines them up by hand.
Teams that already run a billing tool next to a separate revenue system can measure the cost of that setup by counting the days of tie-out between the two each month. Our guide to revenue recognition for SaaS covers the five-step model and each modification treatment, and revenue recognition automation explains how schedules can build from contract data.
Run every tool on the shortlist through the same criteria. Each row names a criterion, why it matters for a usage-based business, and a question to put to the vendor on a demo call.
The most revealing demo uses one of your own contracts. Take a 12-month deal with implementation, a subscription, and usage, then amend it at month six with added seats and a lower usage rate. Ask each vendor to apply the change on its effective date, keep the original history, update billing and revenue from that point forward, and explain every difference between the schedule before and after the amendment.
Numeric fits SaaS and AI teams that want usage billing and ASC 606 revenue recognition on one contract record. Metronome and Orb suit engineering-led teams focused on pricing flexibility, Stripe Billing fits companies already on Stripe, and Zuora fits large enterprises with dedicated implementation teams.
The contract test from the evaluation section is the quickest way to narrow the list. Run the same amended deal through every finalist and ask each one where a single revenue number came from.
If your team bills by usage, schedule a Billing and Revenue demo and walk one of your own contracts from the warehouse event to the revenue entry.