The Usage Ledger: Finance and Sales on the Same Page

Consumption-based pricing breaks the contract between Finance and Sales. Finance forecasts from commitments. Sales sells from usage. The Usage Ledger is a…

The Usage Ledger is a shared data architecture that reconciles Finance and Sales perspectives on consumption-based revenue by connecting billing events, usage telemetry, and contract terms into a single queryable system. The shift to consumption-based pricing is not a billing problem. It is an alignment problem. Finance and Sales have always operated from different models of reality. Subscription pricing masked the divergence because the contract was the forecast. Consumption pricing exposes it because the contract is merely a floor. Finance forecasts from commitments. Contracts, minimums, annual agreements are the instruments that produce predictable revenue. Sales sells from usage. Adoption curves, expansion triggers, feature uptake are the signals that indicate willingness to spend more. In a subscription model, these two views converge at renewal. In a consumption model, they diverge continuously. The conflict shows up in forecasting meetings. Finance presents a number derived from contracted minimums plus a historical growth factor. Sales presents a pipeline derived from usage signals and expansion conversations. The numbers disagree. The meeting becomes a negotiation between two legitimate perspectives, neither of which has sufficient data to win the argument. Most organizations respond by building dashboards. A dashboard does not solve a structural problem. It visualizes it. The Finance team builds a dashboard showing contracted versus actual consumption. The Sales team builds a dashboard showing usage trends and expansion readiness. Neither team trusts the other's dashboard because the underlying data sources, definitions, and aggregation logic are different. The Usage Ledger sits between the billing system and the CRM. It normalizes consumption data into units that Finance can forecast and Sales can sell against. The architecture has three layers. The ingestion layer captures raw usage events from the product telemetry system and billing events from the invoicing platform. These events are normalized into a common schema that defines consumption in terms both teams understand. Not API calls or compute minutes, but business-meaningful units like 'active workflows processed' or 'documents classified.' The reconciliation layer maps normalized usage against contract terms in real time. For each account, the ledger maintains a running view of: contracted commitment, actual consumption to date, projected consumption at current trajectory, and the gap between commitment and actual. When a customer is tracking below their commitment, Finance sees the risk. When a customer is tracking above, Sales sees the opportunity. Both see it at the same time, in the same units, from the same source. The signal layer generates actionable triggers. An account approaching their committed tier fires an expansion signal to Sales and a forecast adjustment to Finance simultaneously. An account declining in usage fires a retention signal to CS and a revenue risk flag to Finance. The signals are not alerts. They are decision inputs that feed the Orchestration layer of the Revenue Architecture. Forecast accuracy improves because Finance is modeling from real consumption, not contracted assumptions. Expansion velocity increases because Sales sees the signal before the customer articulates the need. Retention improves because usage decline triggers a response before the renewal conversation. The weekly forecasting meeting shortens from 90 minutes to 20 because the data argument has been settled before the meeting starts. We deployed this architecture in a B2B platform company transitioning from subscription to consumption pricing. The finance-sales forecast gap was running at 23 percent quarterly. After deploying the Usage Ledger, the gap narrowed to under 5 percent within two quarters. Expansion conversations started an average of 6 weeks earlier because Sales had real-time visibility into usage approaching commitment thresholds.

More notes · Map an operational workflow · AI systems