Your database counts events. Your customer budgets for 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. Change all three at once and you cannot tell which one caused the buyer’s objection.
Stripe documents flat-rate, per-seat, tiered and usage-based pricing, including a fixed fee with overage. Those mechanisms can represent a counting contract; they cannot establish that its unit reflects buyer value. Stripe’s usage-based billing overview covers provider billing options, not the commercial rules proposed below.
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.
Reconstruct a fictional invoice from ten entries
All entries and dollar amounts below are invented teaching arithmetic. They are not PBT prices, recommended prices, actual charges or tax advice.
The proposed unit is one accepted client file per billing period. Here, accepted means the file has passed the agreed processing checks and its usable output is available. File A remains the same file when delivered twice; another attempt on file B is still B. The buyer’s file reference, acceptance record and any reversal must be enough to explain the count.
The hypothetical package: $12 USD for software access and two accepted files, then $4 per additional file, with a $24 software subtotal cap. Work that would require a sixth accepted file is held before processing until a new offer is explicitly agreed.
- Period and cutoff
- August 2026 UTC, from 1 August at 00:00 inclusive to 1 September at 00:00 exclusive. A file must be received and accepted within that window to count here. A receipt at or after the cutoff belongs to the next period and still needs acceptance to become a unit.
- Retries and duplicates
- A failed attempt contributes zero. Successful acceptance contributes one; repeating a delivery or processing attempt for the same file adds nothing.
- Reversals
- One reversal recorded within the period removes that file’s accepted unit before closure. Keep both entries so the subtraction is visible. A later reversal needs a separately agreed adjustment rule; this example does not silently reopen a closed period.
- Service boundary
- Manual cleanup is separately scoped and unpriced here. It contributes no software unit and is not promised as free work.
These are local proposal terms, including the cutoff and reversal treatment. They are not Stripe rules. Tax, credits, currency conversion, fractional-unit rounding and service charges are excluded from the demonstration; all units and dollar amounts are whole numbers. A real agreement needs to settle those items before an amount is payable.
Scroll to follow each entry’s effect on billable units.
| Entry | Client file | What happened | Unit change |
|---|---|---|---|
| 01 | A | Accepted | +1 |
| 02 | A | Duplicate delivery of the same file | 0 |
| 03 | B | Failed attempt | 0 |
| 04 | B | Accepted after retry | +1 |
| 05 | C | Accepted | +1 |
| 06 | C | Reversed within August, before closure | −1 |
| 07 | D | Accepted | +1 |
| 08 | E | Accepted | +1 |
| 09 | F | Received after the cutoff; next period | 0 this period |
| 10 | No file unit | Manual cleanup service, outside software usage | 0 |
The sample invoice’s software subtotal
Ten journal entries leave four billable units: A, B, D and E. C nets to zero. F has not entered August’s count, and cleanup is outside it. The buyer can reconstruct the subtotal without paying for the duplicate or the failed attempt:
- Base with two files included
- $12
- Files above the allowance
- 4 accepted units − 2 included = 2 overage units
- Overage amount
- 2 × $4 = $8
- Software subtotal
- $12 + $8 = $20 USD
Use the count after in-period reversals. Subtract the included allowance, with a minimum of zero overage units, then multiply by the rate and add the base. Enforce the cap before taking on more work, not by trimming a bill for work already done.
Check quiet and spike periods under the same terms
Quiet: no accepted files
Zero accepted units create zero overage. The software subtotal is still $12 for the agreed access. That makes the base commitment visible even when no report is produced.
Spike: seven requested files
Five files are accepted: $12 + (5 − 2) × $4 = $24. The remaining two are held before any processing until a new offer is explicitly agreed. The cap buys neither seven completions nor unlimited unbilled work.
A service-heavy month raises a separate scope question. Entry 10 records cleanup without inventing a fee for it. If useful output routinely depends on that service, a file allowance alone may be a poor description of what the buyer is purchasing.
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 receipt or late record?
- A file arriving after the cutoff differs from a delayed record of work already completed. Which period counts each case, and how will you correct a closed bill? The example assigns late receipts to the next period; it does not settle every late-record case.
- 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?
The example settles retries, duplicates and in-period reversals for one proposed contract. Another job may need different rules. A file unit hides some cost variation: one accepted file might need much more processing than another. If that difference makes the promise unaffordable, bound the supported input or separate the service rather than quietly counting attempts as extra files.
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. |
Next decision: 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, documentation checked 2026-09-14. Documents Stripe’s model families, not the best model for your SaaS.
- Stripe usage-based billing, documentation checked 2026-09-14. Describes provider billing options; it does not validate the fictional counting contract or establish invoice predictability. Check the current documentation for your integration before configuring billing.