CFO Support for Usage-Based SaaS Pricing
Article Summary
Usage-based SaaS pricing needs a CFO review that defines the billable event, costs it fully and reconciles meter to invoice before any discount. At $0.03 per transaction, a million transactions produce $30,000 of revenue against $24,000 of delivery cost, leaving $6,000 before fixed costs. With $0.024 of variable cost per completed task and a chosen 60% contribution target, the undiscounted price floor is $0.06 per billable task. A 20% enterprise discount cuts contribution to 50%, so the discount must be justified by lower cost, minimum volume or an accepted margin.
At $0.03 per transaction, a million transactions produce $30,000 of revenue. They can also produce $24,000 of delivery cost. That leaves $6,000 before account support, development, sales, and overhead.
Volume doesn't fix that equation. A CFO review should establish which event earns revenue, which event creates cost, and how those events reconcile before anyone discounts the million-unit contract.
This matters for a $1M–$15M SaaS business moving from seat pricing to consumption, especially when AI processing, data services, or third-party APIs make cost move with use.
Define the unit everyone is selling
A transaction might mean an accepted request, a completed task, a successfully delivered result, or a bundle of calls. Choose one definition for the contract, product display, meter, and invoice.
The cost unit may differ. One billable task can require several internal calls, retries, and reviews. An unsuccessful request may consume paid infrastructure without creating a billable event.
Current Stripe documentation on recording usage explains that its basic Billing Meters process events asynchronously, so recent events may not immediately appear in summaries or upcoming invoices. Stripe currently recommends its Metronome approach for most new integrations. The financial control remains the same across implementations: reconcile product activity to the billing system before relying on the number.
Don't let a platform choice become the pricing policy. Engineering can confirm that the event arrived; finance and the customer contract decide whether it should be charged.
A floor built from delivered work
Here is a hypothetical monthly customer cohort:
| Item | Assumption |
|---|---|
| Billable completed tasks | 1,000,000 |
| Processing cost, including failed attempts and retries | $12,000 |
| Other variable data and infrastructure | $6,000 |
| Variable support and payment costs | $6,000 |
| Total variable delivery cost | $24,000 |
The cost per completed billable task is $0.024. If management chooses a 60% contribution target for this product, the undiscounted floor is:
$0.024 ÷ (1 − 60%) = $0.06 per billable task.
At $0.06, revenue is $60,000 and contribution is $36,000 before fixed costs. The 60% here is a chosen product assumption. It is not proof that every SaaS product should have the same target, nor that contribution equals operating profit.
A 20% enterprise discount reduces the price to $0.048. At unchanged cost, contribution falls to 50%. The sales discount has to be justified by something concrete: lower cost, dependable minimum volume, lower acquisition expense, or an explicitly accepted margin.
Find leakage before changing the price
Reconcile four quantities for the same customer and period: actual completed work, eligible billable work, accepted meter events, and invoiced units.
Differences should have reasons. Free trials, included allowances, refunds, duplicate suppression, cutoff timing, and support credits are legitimate when documented. Missing events and unexplained manual adjustments are not a pricing strategy.
In the hypothetical cohort, missing 3% of otherwise billable tasks at $0.06 means $1,800 of unbilled revenue. The associated delivery cost has already happened. Recovering that leakage can be more useful than negotiating another infrastructure discount.
If consumption is growing faster than cash, a free 20-minute Profit & Tax Leak Check can help identify the first pricing or margin assumption to validate. Rough revenue and delivery-cost figures are enough; no documents are required.
Stress the expensive customer
A blended average can conceal a customer who uses the most expensive feature or triggers unusually high retry rates. Calculate cost by meaningful cohort: workload, service tier, region where relevant, support pattern, and contract.
Then test a high-use month. A minimum commitment may protect revenue while an unlimited allowance exposes cost. A prepaid balance improves cash only until the obligation to provide service consumes it.
For each proposed tier, show contribution at low, expected, and high usage. Include the cost of included units. State whether overages are automatic, capped, or require customer approval.
There is a customer-trust question too. A correct invoice can still be a surprise. Put usage visibility, alerts, and the process for challenging charges into the rollout budget. An invoice dispute delays cash even if the meter is technically correct.
What CFO support should change
A useful engagement leaves the business with a documented price floor, discount authority, a meter-to-invoice reconciliation, and a cash forecast driven by usage and payment dates.
It should also clarify ownership. Product owns the event definition. Engineering owns reliable measurement. Finance owns pricing economics and invoice reconciliation. Sales owns adherence to approved commercial terms. Exceptions return to a named decision-maker.
The existing SaaS accounting guide covers the broader accounting foundation. The SaaS financial-planning framework connects product economics to the company plan. Neither replaces a customer-level consumption model.
For SaaS businesses, fractional CFO services should connect those pieces before a large contract fixes the wrong price.
Take the next enterprise quote and calculate its cost at the heaviest credible usage. If the result makes the advertised margin disappear, start a Profit & Tax Leak Check with that decision in mind.
Frequently asked questions
What is the first CFO question for usage-based SaaS pricing?
Which event earns revenue and which activities create cost? A transaction might mean an accepted request, a completed task, or a bundle of calls. The contract, product display, meter, and invoice should all share the same billable-unit definition, even if the internal cost unit differs.
Should failed requests be included in usage-based SaaS unit cost?
Yes, include the costs of failures and retries when they are necessary to deliver the completed billable work. One billable task can require several internal calls, retries, and reviews, and an unsuccessful request can consume paid infrastructure without generating any revenue.
How is a usage-based price floor of $0.06 per task calculated?
In the hypothetical cohort, $24,000 of variable delivery cost across 1,000,000 completed tasks is $0.024 per task. Dividing $0.024 by 1 minus the chosen 60% contribution target produces $0.06. At that price, revenue is $60,000 and contribution is $36,000 before fixed costs.
Does a 60% usage-pricing contribution target guarantee 60% company gross margin?
No. The 60% is a chosen product assumption in the example, not proof that every SaaS product should use it. Fixed delivery cost, product mix, and accounting classifications may produce different company results, and contribution is not the same as operating profit.
What does a 20% enterprise discount do to usage-based SaaS margin?
In the example it reduces price from $0.06 to $0.048 per task. With cost unchanged at $0.024, contribution falls from 60% to 50%. The discount should be justified by something concrete: lower cost, dependable minimum volume, lower acquisition expense, or an explicitly accepted margin.
Which usage quantities should finance reconcile before invoicing SaaS customers?
Compare actual completed product work, eligible billable units, accepted meter events, and invoiced units for the same customer and period. Differences need documented reasons, such as trials, included allowances, refunds, or cutoff timing. In the example, missing 3% of billable tasks at $0.06 means $1,800 of unbilled revenue.
Can recent Stripe meter events be missing from a usage summary?
Yes. The cited Stripe documentation says basic Billing Meters process events asynchronously, so recent events may not immediately appear in summaries or upcoming invoices. Stripe currently recommends its Metronome approach for most new integrations. Either way, reconcile product activity to the billing system before relying on the number.
What should CFO support for usage-based SaaS pricing leave behind?
A documented price floor, discount authority, a meter-to-invoice reconciliation, contribution at low, expected, and high usage by customer cohort, and a cash forecast driven by usage and payment dates. It should also name owners: product for event definition, engineering for measurement, finance for pricing economics, and sales for approved terms.