The pricing model: customers pay for what they use. API calls, compute hours, transactions processed, GB stored. No fixed seat count. The bill reflects actual consumption.
The business case is appealing: customers feel pricing matches value, expansion is automatic with usage growth, the floor pricing draws in customers who would not commit to a higher fixed plan. The implementation is the hard part. Usage-based billing on Revenue Cloud involves three discrete subsystems, each with its own pitfalls.
The three subsystems
Metering. Capturing what the customer used. Events flow from the product into Salesforce. A SaaS product reports API calls. A cloud platform reports compute hours. A payments platform reports transactions processed. The metering layer captures these events, deduplicates them, and records them against the customer.
Rating. Converting usage to price. The customer used 1,000,000 API calls this month. What does that cost? The rating engine applies tiered pricing, included allowances, overage rates, and per-customer contract terms to produce a billable amount.
Invoicing. Consolidating rated usage into invoices. Many customers want one invoice per month covering all their usage. Some want per-product invoices. Some want daily invoicing for high-volume usage. The invoicing layer handles consolidation rules.
Each subsystem has its own configuration surface, its own data volume challenges, and its own failure modes.
Metering: capturing usage reliably
The metering pipeline runs continuously. Events arrive at various rates depending on the product. The pipeline must:
- Receive events from the product (API webhook, batch file, streaming connection).
- Validate event format and customer identity.
- Deduplicate events that arrive twice (network retries, replay, double-fire).
- Store the event with timestamp, customer, product, and quantity.
Three common failure modes:
Event loss. The product sent the event but Salesforce did not receive it. Customer's usage is undercounted. Customer is happy but Salesforce loses revenue.
Event duplication. The same event arrives twice. Customer is double-charged. Customer disputes the invoice.
Identity drift. The event references a customer ID that does not match a Salesforce Account. The event is rejected or assigned to the wrong customer.
The fix patterns:
- Idempotency keys on every event. The metering pipeline rejects duplicate IDs.
- Audit logs that track every event from receipt to storage. Discrepancies between expected and actual event counts trigger alerts.
- Customer identity mapping with strict validation. New customer IDs from the product require explicit reconciliation before events from that ID start counting.
Rating: converting usage to price
The rating engine reads the customer's contract terms and the captured usage to produce a billable amount. Common pricing structures:
Flat per-unit rate. Every API call costs $0.001. Total cost = call count x rate.
Included allowance plus overage. Contract includes 100,000 calls per month. Calls over 100,000 cost $0.0008 each. Total cost = max(0, call count - 100,000) x $0.0008.
Tiered. First 100,000 calls free. Next 900,000 at $0.001 each. Above 1,000,000 at $0.0005 each. Total cost = sum of tier amounts.
Volume. Whole-month total drives a single rate per call. 500,000 calls means every call costs $0.0008 (the rate at that volume bracket).
Per-customer custom rates. Enterprise customers have negotiated terms that override the standard pricing.
The rating engine applies these rules. The configuration sits in the product catalog (standard rates) and on individual contracts (customer-specific overrides).
Two common rating bugs:
Tier boundary issues. The 100,000th call costs the wrong amount because of off-by-one logic at the tier boundary. Small impact per call but visible in customer audits.
Custom rate not applied. The customer has a negotiated rate on their contract, but the rating engine reads from the standard catalog rate. The customer pays more than agreed. They notice and dispute.
The fix: rigorous testing of tier boundaries and custom rate scenarios. Unit tests at the rating engine level that cover every documented pricing structure.
Invoicing: consolidation rules
The customer used 100,000 API calls in May. The rating engine produced a charge of $80. What invoice does that show up on?
Options:
Single monthly invoice. All usage across all products on one invoice at month end. Simplest for the customer.
Per-product invoices. Each product line generates its own invoice. Useful when different products have different billing cycles or different accounting treatment.
Threshold-triggered invoices. Usage invoices fire when accumulated usage crosses a threshold (e.g., $1,000 of accumulated usage). High-volume customers get invoiced multiple times per month; low-volume customers get the standard monthly invoice.
Real-time invoicing. Each significant usage event generates its own invoice. Rare and only for very specific use cases.
The configuration: a billing schedule rule that determines when usage rolls up into invoices. The choice depends on accounting policy, customer preference, and operational capacity.
Most B2B SaaS uses single monthly invoice with optional per-product split for accounting reasons. Threshold-triggered is the right answer for high-volume customers but requires more operational handling.
Reporting and reconciliation
Usage billing produces more data than fixed billing. Three reports every implementation should run:
Usage to revenue reconciliation. For a given month, compare metered usage (raw event count) to invoiced amount. The two should map through the rating engine. Drift indicates a metering or rating issue.
Customer usage trends. Per customer, usage over time. Sudden drops indicate the customer reduced consumption (churn signal). Sudden spikes indicate either growth or a bug in the customer's integration.
Contract compliance. For customers with included allowances, the percentage of allowance used. Helps customer success identify customers approaching their limits and customers paying for unused capacity.
These reports are operational, not just analytical. The CSM, finance, and product teams all read from them weekly.
Common implementation mistakes
Five patterns Sapota has seen in usage billing audits:
- Metering without idempotency. Event duplication causes overcharging. Customer disputes.
- Rating tested only on standard pricing. Custom enterprise contracts apply different rates that the engine does not respect. Customer overcharged.
- No reconciliation between usage and revenue. Drift accumulates over months. Discovered at year-end with significant cleanup required.
- Invoice consolidation too aggressive. A customer with seven products gets seven separate invoices each month. AP team complains. Consolidation rule changed mid-quarter, which creates audit friction.
- No customer-facing usage dashboard. Customers cannot see their own usage in real time. They overuse expecting the platform to throttle (it does not), or they underuse expecting a credit (they will not get one). Visibility prevents most disputes.
What good usage billing looks like
A Salesforce Revenue Cloud usage billing setup that holds up:
- Metering pipeline with idempotency keys, deduplication, and audit logs.
- Rating engine with unit tests covering tier boundaries and custom rates.
- Invoice consolidation rule documented and rarely changed.
- Three monthly reports: usage-to-revenue reconciliation, customer trends, contract compliance.
- Customer-facing usage dashboard via Experience Cloud or external portal.
- Quarterly review of metering and rating logic for accuracy.
Usage-based billing rewards getting the implementation right. It punishes shortcuts. Sapota's Salesforce team treats usage billing as a multi-system integration with explicit validation steps rather than as a single Revenue Cloud feature to enable.
Implementing usage-based billing in Salesforce Revenue Cloud? Sapota's Salesforce team holds the Revenue Cloud Consultant credential and handles metering, rating, and consolidation design on production engagements. Get in touch ->
See our full platform services for the stack we cover.
