Define a billable meter aggregation contract

Separate the commercial unit from the event

Stripe’s Create and configure a meter documentation, checked 7 November 2026, distinguishes aggregation from ingestion mode. Pre-aggregated interval reports replace earlier reports within documented UTC windows; raw observations are independent. Verify the actual implementation.

Write the customer’s billable unit in plain language: completed jobs, resources consumed or an observed capacity value, for example. Then describe the event the application can actually produce. An event may represent one job, a batch of jobs or a cumulative reading. The same numeric payload can mean very different things in those cases, so a familiar field name such as usage is not an adequate contract.

Choose a synthetic sequence with competing answers

Create a short sequence of invented observations with timestamps, event meaning and values. Calculate the expected commercial quantity independently. Include values that make counting observations visibly different from adding their payloads, and include a final reading that differs from the sum. This exposes an incorrect aggregation choice without requiring a large dataset or real customer activity.

Keep identity and measurement separate. Identify the fictional customer and service period, then specify the unit and whether values are increments or snapshots. A payload of twelve could mean twelve additional units or a total reading of twelve so far. If the application cannot distinguish those meanings, stop before choosing a meter. A clever aggregation setting cannot repair an undefined upstream observation.

Resolve the reporting-window contract

State whether each transmitted record is independent raw activity or a replacement estimate for a defined interval. For interval reports, include an initial estimate and a later revision for the same window. For raw activity, include two legitimate observations sharing a timestamp. The expected quantity must explain which records remain additive and which supersede another record.

Keep the event timestamp, reporting arrival and billing period visible in the worksheet. A late report can be interpreted differently from a new event occurring later. Have the technical owner identify the configured interval boundaries and treatment of late or corrected data; do not invent those rules from local business hours. The exercise should expose the unresolved rule, not silently decide it in a spreadsheet. Real usage adjustments remain a separate financial operation.

Reconcile the quantity before discussing revenue

Build a quantity bridge from the synthetic observations to the expected meter total and then to a supplied observed total. Classify differences by unit meaning, aggregation choice, interval replacement or unresolved timing. Keep price multiplication downstream. Changing a unit price to compensate for a wrong meter total hides the defect and makes the next customer or period harder to explain.

Have product, engineering and finance review the same small fixture. The product owner confirms the sold unit, engineering confirms event meaning, and finance confirms the billing interpretation. Preserve the fixture with the chosen configuration and its version scope. Acceptance establishes that the measured quantity represents the promised unit for these cases; it does not certify all future bills or authorize creating meters, sending usage, correcting invoices or charging a customer.

Make the reasoning concrete.

A fictional document-processing service promises to bill for completed pages. Its application sends a report containing the pages processed in each batch. A proposed meter counts reports instead of adding page values, while a second integration sends revised daily totals.

The team holds meter approval until the observation meanings and interval behavior are resolved. It sends no usage events and changes no customer invoice.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Unit

   What exactly does the customer buy one of?

2. Observation

   Does each payload describe an increment, batch or snapshot?

3. Aggregation

   Which independently calculated quantity should count, sum or last produce?

4. Window

   Which reports replace earlier interval values rather than add activity?

5. Bridge

   What explains every difference between expected and observed meter totals?

Watch for the wrong conclusion.

• Counting reports when the offer charges for their payload units.
• Adding cumulative snapshots as if they were increments.
• Changing price to disguise a quantity mismatch.

Sources & scope

Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. Synthetic offline planning only; no real financial action or account change is performed.

• Create and configure a meter →Primary platform documentation · Supports: Supports raw versus interval-replacement ingestion and aggregation choices.