Fixed subscription revenue is predictable. If a customer pays $12,000 for a year of access, you recognize $1,000 every month. Your spreadsheet roll-forward is identical from January to December.
Usage-based revenue destroys that predictability.
When you charge based on API calls, active users, or storage consumed, you do not know the final transaction price until the end of the month. Under ASC 606, this introduces massive complexity around variable consideration. You cannot recognize the revenue ratably, because the performance obligation is satisfied unevenly.
If your finance team is manually downloading CSVs from the engineering team to calculate revenue recognition every month, you have a major operational bottleneck. Here is how modern B2B SaaS companies automate ASC 606 for usage-based models.
The ASC 606 Challenge with Usage Models#
Under ASC 606, you must estimate variable consideration unless the “right to invoice” practical expedient applies. For most B2B SaaS companies, the challenge is not just the accounting standard—it is the data engineering required to apply it.
Complex usage contracts rarely look like a simple “$0.10 per API call.” They involve:
- Minimum Commitments with True-Ups: The customer pays $5,000 a month for 100,000 units, and $0.05 for every unit above that. The base is recognized ratably; the overage is recognized as incurred.
- Prepaid Drawdowns (Wallet Model): The customer pays $50,000 upfront. Revenue is deferred entirely and recognized only as the customer consumes their wallet balance.
- Tiered Volume Pricing: The per-unit price drops as the customer consumes more within a specific billing period.
Running this logic in a spreadsheet means writing nested IF statements and VLOOKUPs that cross-reference a massive export of product usage against a manually maintained sheet of contract terms. It is highly prone to error and takes days to execute.
How to Automate It#
To eliminate the manual work, you need to connect the source of truth for usage directly to the source of truth for contracts. This is where revenue recognition software comes in.
Instead of a manual export process, the workflow should look like this:
1. Ingest Raw Usage Continuously#
Your revenue software should integrate directly with your product database, data warehouse (like Snowflake or Databricks), or a metering platform. Instead of waiting for a month-end CSV, the system ingests event data daily.
2. Codify the Contract Terms#
The platform must act as a rules engine. When a contract is signed in Salesforce, the revenue software codifies the specific minimum commitments, tiers, and drawdown rules.
3. Price and Allocate Automatically#
At the end of the month, the software automatically maps the raw usage data to the specific customer’s contract rules. It splits the minimum commitment from the overage, applies the correct ASC 606 recognition method to each element, and calculates the exact revenue to be recognized for that period.
4. Push Journal Entries to the ERP#
The final step is posting. The software generates the precise debit to Accounts Receivable or Deferred Revenue and the credit to Recognized Revenue, pushing the journal entry directly into NetSuite or your ERP.
Eliminating the Engineering Dependency#
The biggest hidden cost of usage-based revenue is the burden it places on your engineering team. If finance relies on engineers to run custom SQL queries every month just to close the books, both teams lose velocity.
By implementing standalone revenue recognition software, finance takes ownership of the logic. You set the rules once based on the contract, and the system handles the aggregation and calculations automatically.
If your month-end close is delayed because you are waiting on usage data, it is time to build a systemic connection.
See how Enso automates usage-based billing and revenue recognition.
