Review whether a SaaS meter should sum, count or use the last reading

Start with what the customer agreed to buy: individual requests, total processing units or a measured balance at a particular time. Write that definition before discussing meter settings. An event can contain a quantity, represent one occurrence or report a running total. Applying the same aggregation to those different records produces very different bills.

Ask product and finance to approve the same definition, including what qualifies as a completed unit and what happens when an operation fails. Keep the contract wording, technical event definition and invoice description together. If one says requests and another says tokens, resolve the mismatch before a developer chooses a calculation that seems convenient.

Stripe's meter documentation describes sum, count and last-value aggregation. Test the selected method with a short, deliberately varied event set. Include a period with no events and a correction, as well as ordinary activity. The expected customer bill should be calculated independently of the billing platform, then compared with its output.

For illustration, three events carrying values of 4, 7 and 9 produce a sum of 20, a count of 3 and a last reading of 9. None is automatically the right answer. If each event reports a cumulative balance, adding all three double-counts earlier activity. If each value represents a separate quantity consumed, retaining only 9 loses the other consumption.

Find out whether the source sends individual events, incremental batches or replacement totals. A nightly file containing the full day's usage must not be added again when an updated version arrives. Specify the replacement or adjustment behavior and retain the original batch reference. The finance reviewer needs enough detail to distinguish a corrected total from additional billable activity.

Use the same test set through the complete process: source export, ingestion, aggregation, pricing and invoice. A correct source total can still be misinterpreted during transfer. Check event timestamps and customer mapping as part of the test, then retain the resulting invoice preview. This gives the next reviewer concrete evidence of the intended behavior rather than a statement that the meter was tested.

Choose test records that would produce clearly different results under each candidate method. For illustration, three readings of 4, 9 and 6 produce a sum of 19, a record count of three and a final reading of six when ordered as shown. A dataset containing only one record would conceal the difference and provide weak acceptance evidence.

Ask the product owner which result matches the customer promise and why. If the readings are cumulative rather than separate consumption events, explain that fact before selecting the calculation. Preserve the sample, ordering rule and expected result with the approval so another reviewer can test the same definition after an integration or product change.

If an existing meter uses the wrong calculation, identify affected customers and periods before changing production. Reconstruct valid quantities using retained events, then estimate which invoices need a correction. Confirm whether the platform permits the required configuration change or needs a replacement meter. Preserve the old definition and its effective dates so earlier invoices remain explainable.

Accounting should receive the customer-level impact, approved credit or rebill decisions and the new calculation's acceptance evidence. Schedule a check of the first full billing cycle after the correction. If the change also alters a management usage metric, explain the break in comparability separately from business growth; a new aggregation method can move a chart even when customer behavior has not changed.