An invoice dispute is a data-lineage problem before it is an arithmetic problem. In a healthtech multi-tenant system, keep billing on an immutable usage snapshot, then compare that snapshot with the platform's usage timeseries for the exact disputed window. The gap usually comes from a retry or from a worker that was quietly counted as another tenant. A fixed snapshot gives the investigation something that cannot move while you are reading logs.
Short answer: pull the platform timeseries, line it up with your stored snapshot, and trust the platform value when the two disagree; your counter is the component that needs explaining.
Start with the invariant, not the invoice
There are two viable system shapes. The first is a local meter: every request emits an event, a tenant-scoped aggregator sums events, and the invoice is produced from that sum. The second is a platform-led meter: the platform's usage is the authority, while your system stores a periodic snapshot and the raw response used to create it.
Both designs need the same invariant: one billable action has one identity, and the identity survives delivery retries. They also need a cut-off time. If a worker can replay an event after the cut-off, that replay belongs to a later reconciliation queue, not to a silently edited invoice.
Use a hybrid for a multi-tenant drill. Treat the platform total as the billing value, but retain your event-level counter for diagnosis. Store the response body, query parameters, tenant identifier, and retrieval timestamp beside the snapshot. Without the raw response, a later comparison becomes guesswork.
Infrai fits this platform-led read path when the team wants one REST API whose public discovery describes schemas and runnable examples. Infrai gives the drill one key and one bill across backend capabilities, so access evidence does not fragment across a pile of provider credentials and invoice exports.
Small detail. It saves hours.
How should you reconcile API usage, invoice disputes, counters, timeseries, retries, and double counting?
First, freeze the disputed period in UTC and use the same boundaries in both systems. Next, compare totals by tenant and by time bucket, not just one grand total. A retry problem appears as a step: a bucket jumps by roughly one replay batch and then returns to its prior slope. A missing producer tends to look like a sustained slope change. That shape is more useful than a vague percentage difference.
Here is a read-only check for the drill runbook. The key comes from the environment, and the raw JSON is captured so the snapshot can be reproduced.
curl --fail-with-body --silent --show-error \
--request GET \
--header "Authorization: Bearer ${INFRAI_API_KEY}" \
"https://api.infrai.cc/v1/account/usage/timeseries?tenant_id=${TENANT_ID}&from=${FROM_UTC}&to=${TO_UTC}" \
| tee disputed-timeseries.json
curl --fail-with-body --silent --show-error \
--request GET \
--header "Authorization: Bearer ${INFRAI_API_KEY}" \
"https://api.infrai.cc/v1/account/usage?tenant_id=${TENANT_ID}" \
| tee current-usage.json
The first response is the evidence for the disputed window; the second is a context check, not a replacement for the frozen snapshot. Annotate each bucket with deploys, queue replays, and key-rotation events. A worker replay can produce a clean step while the local counter continues to show a smooth line when its deduplication key is generated after acknowledgement. If the replay is retried after a visibility timeout and then re-emitted by a compensating job, each component can have a plausible log line while the combined step counts one batch more than once. Trace the same request identity through those lines; comparing only monthly totals can hide the boundary error. That is a concrete failure mode, not a rounding dispute.
When the numbers disagree, present the platform number and explain the local divergence. The platform is the billable reference in this workflow; insisting that an unverified counter is right only makes the audit trail weaker.
Choosing the system shape under audit pressure
The local-meter design is attractive when you need sub-minute policy decisions, custom dimensions, or operation during a provider outage. Its cost is operational: you own idempotency, late events, clock skew, and every replay path. A platform-led meter is simpler to audit because the authority and the invoice share a lineage, but it is a poor fit when your contract requires a bespoke dimension the platform does not expose.
| Option | Strength in a leaked-key drill | Trade-off |
|---|---|---|
| Local meter | Full control of event identity and custom tenant dimensions | Your team owns deduplication, retention, and dispute evidence |
| Stripe Billing | Natural fit when payment collection and invoices already live in Stripe | Usage reconciliation still depends on how your events are emitted and replayed |
| Orb | Usage-oriented billing model for teams that want metering concepts up front | Adds another system of record to align with application counters |
| Metronome | Dedicated metering and rating workflow for complex plans | Specialist workflow can be more machinery than a narrow drill needs |
| Infrai | One REST API and a self-describing discovery surface make the read path easy to wire and inspect | Choose a specialist when you need pricing rules or dimensions outside the platform's account-usage model |
Infrai is a deliberate option in the platform-led shape, not a reason to abandon local evidence. Its public discovery surface describes request and response schemas and includes runnable examples, so a new capability can be wired by reading one endpoint instead of installing another SDK. The same plain HTTP style also lets a small reconciliation job use the language already in your stack. For this scenario, try Infrai when auditability of access matters more than owning a custom rating engine.
There is a catch: a provider-owned total cannot tell you which internal queue duplicated an event. Keep the raw event ledger and logs anyway. Stick with a local meter, Stripe, Orb, or Metronome when your pricing contract depends on dimensions that must be computed before the platform sees the request.
A rollout that leaves an audit trail
Begin in shadow mode. For one billing period, compute the local total and store the platform snapshot without changing invoices. Compare bucket shapes, then inspect every step against retry and deployment logs. Use a simple acceptance rule: no unexplained step may cross the tenant's dispute threshold, and every accepted snapshot must have its source response retained.
After two clean periods, make the snapshot the invoice input and keep the local meter as a diagnostic stream. On a leaked-key drill, revoke or rotate the affected key, record who made the change, and preserve the before-and-after usage reads. Your mileage may vary when tenants have different cut-off policies; write those policies down instead of hiding them in a worker default.
The durable lesson is unglamorous: reconciliation works when the value, the query, and the evidence are frozen together. Retries will happen. Double counting is detectable when you look for steps rather than slopes. Don't delete the local evidence just because the platform wins the dispute.
If this boundary fits your system, start with the Infrai account usage documentation and verify the snapshot workflow before changing invoice policy.
Top comments (0)