Two correct counters can count different events
A WordPress counter may record an attempt before a provider accepts it, while a provider dashboard may aggregate completed usage after processing. One can therefore include local failures that the other never saw. Write the event definition for each number before calculating a variance percentage.
Choose the provider invoice or finalized provider usage as the authority for billed amount, while using WordPress records to explain route, source, context, and control decisions. Local estimated USD is an operational signal, not a replacement invoice.
Align the comparison window
Export both systems in UTC for the same inclusive start and exclusive end time. Account for dashboard processing delay, late-arriving usage, and billing-day boundaries. Re-run the comparison after the provider's documented data delay before labeling a temporary gap persistent.
Freeze the exports used for a reconciliation and record retrieval times. A live dashboard viewed on Monday cannot be fairly compared with a WordPress CSV exported on Sunday if late events or adjustments have arrived in between.
Bridge the two denominators line by line
Start with WordPress attempts. Subtract requests rejected before provider submission, then account for integration retries, cache-served responses, and requests whose usage is only estimated locally. Separately add direct SDK, serverless, or other application calls that share the provider account but bypass WordPress.
| Bridge line | Expected direction | Evidence |
|---|---|---|
| Rejected before provider | WordPress greater | local status and no provider ID |
| Provider/SDK retry | Provider greater | multiple provider IDs for one attempt |
| Direct non-WordPress call | Provider greater | provider project/API key attribution |
| Local token estimate | amount differs | final provider usage |
| Reporting delay | temporary either way | retrieval time and provider documentation |
Keep traffic labels out of accounting categories
Do not force every line into Human, Bot, or Unknown. Those traffic signals may inform supported Smart Protection decisions, but they do not explain an internal SDK retry or a direct back-office call. Use source, context, route, model, and provider request ID for reconciliation.
Set a band only after causes are assigned
Calculate the residual after every explainable bridge item, not the raw difference. An acceptable operational band should reflect known rounding, timing, and estimation behavior and should be stated in both absolute usage and percentage terms so small denominators do not create alarming percentages.
Escalate when the residual persists after the lag window, grows across periods, or contains provider calls with no owned source. A recurring exact multiple often points to retries; a model-specific gap may point to stale rate or tokenizer settings; an unknown API key may require credential response.
Publish a reconciliation policy someone can repeat
The expected-variance policy should name systems, event definitions, authoritative billing source, UTC window, lag allowance, bridge lines, thresholds, reviewer, and escalation route. Include one worked month so a new operator can reproduce the result without oral history.
Reject the myth by explaining the residual
The myth is rejected when every difference is neither dismissed nor treated as failure: it is decomposed. Link the privacy policy because reconciliation records can include pseudonymous operational signals and must be retained and shared according to their stated purpose.
Use the expected-variance policy from “Myth: the provider dashboard and WordPress counter should always match” on a real first installation. Download AI Cost Circuit Breaker for free, begin in Monitoring, and move to enforcement only after the expected signals and rollback are verified.