Your database counts events. Your customer plans client files. Billing on events may be easy to meter and impossible to forecast; billing on files may sound clear until retries and corrections appear. The decision is not “usage-based or flat?” It is which count survives an invoice review.
Value metric, package and price are different decisions
The value metric is the unit that changes the amount or the plan boundary. The package says what is included. The price point assigns money to that package. Mixing all three makes a failed invoice impossible to diagnose.
Stripe documents flat-rate, per-seat, tiered and usage-based pricing, including configurations that combine a base amount with measured usage. These are billing mechanisms available in Stripe. They are not recommendations for a particular SaaS or proof that measured usage represents customer value.
Start with nouns the buyer already owns: active locations, managed clients, completed filings, processed orders. Database fields belong on the candidate list only after you can translate them into the customer’s work.
The candidate-unit scorecard
Mark each candidate strong, workable or weak. This is a proposed comparison method, not a benchmark and not a prediction of revenue or retention.
| Question | What to inspect | Weak-unit warning |
|---|---|---|
| Connection | Does more of the unit accompany more completed customer work? | The count rises while useful output does not |
| Forecastability | Which customer-owned record estimates the next period? | The bill depends on invisible system activity |
| Auditability | Can both sides reconstruct what counted? | Support must interpret raw logs by hand |
| Cost exposure | Which usage pattern creates processing or service work? | A quiet and an expensive account look identical |
| Expansion behaviour | What changes when the customer expands the job? | The unit discourages the action the product supports |
| Operational simplicity | Can exceptions follow written rules? | Every invoice needs founder discretion |
A per-seat unit might be easy to forecast and only loosely tied to completed work. That does not automatically disqualify it. The scorecard makes the compromise visible so package design can carry it honestly.
Put the unit through three fictional invoices
Illustrative scenarios only — no PBT prices, usage, invoices or customer results. Insert your own approved amounts and histories. Do not treat these shapes as recommended tiers.
Quiet period
Model zero or low usage. Decide whether a base commitment exists and what ongoing access it covers.
Expected period
Use a real historical workload if authorised. Check whether the buyer can predict and audit the count.
Spike period
Model a plausible peak. Inspect overage, cap or commitment behaviour without assigning a universal limit.
Service-heavy period
Separate migration, cleanup and custom handling from the software unit instead of hiding labour inside usage.
Formula boundary
For an allowance model, one explicit representation is:
invoice subtotal = base fee + billable usage above allowance × overage rate
Define every variable. State the billing period, included quantity, billable event, aggregation rule and any cap. Taxes, credits, minimums, rounding, currency and timing are outside that simple representation and need their own rules. The formula describes mechanics; it recommends no amount.
The edge cases decide whether the metric is real
- Retry
- Does another attempt create another billable unit, replace the first attempt or count only after useful completion?
- Duplicate
- How is accidental duplication detected, reviewed and corrected?
- Reversal
- What happens when work is deleted, refunded or reversed?
- Late event
- Which period receives usage recorded after the underlying work?
- Shared access
- Does the unit still describe value when one operator manages several entities or several people share a workflow?
- Manual work
- Which service line must remain outside the usage meter?
There is no universal rule that retries must or must not count. Define how each state affects billable usage, justify it against the customer job, and make the record inspectable before exposing the rule.
Do not implement metering, overages, caps and prepaid credits just because the billing platform supports them. First test one candidate unit on quiet, expected and spike histories. If several exceptions are needed to rescue every candidate, the package may be combining software, onboarding and custom service.
Close the candidate log
| Decision field | Record |
|---|---|
| Unit | The customer’s name for it, not the event-table column. |
| Counting rule | Start, completion, retry, reversal and late-arrival treatment. |
| Invoice evidence | Quiet, expected and spike histories used in the test. |
| Known weakness | The scorecard compromise the package must carry. |
| Decision | Choose, reject or gather one missing piece of evidence. |
Bottom line: reject any unit you cannot explain on a sample invoice. Once the unit survives the edge cases, return to the offer-version log to test the package—without changing the unit and the price at the same time.
Definitions and pricing limits
- Stripe pricing models, observed 2026-07-28. Documents Stripe’s model families, not the best model for your SaaS.
- Stripe usage-based billing, observed 2026-07-28. Documents Stripe metering and usage-based configurations; it does not establish buyer value or invoice predictability. Check the current pages before configuring billing.