“Why does our proxy usage not match the task log?” Before renewal, do not force client telemetry to equal an invoice. First decide whether the declared meter and your job log are comparable enough to discuss a difference. This guide gives an operations owner a bounded, reproducible ledger for that conversation. It does not estimate a payable invoice, compare prices, or claim an IPHTML billing rule.

Freeze the measurement boundary

Record one nonblank account or sub-account, route, declared meter period and unit, meter basis, export time, and client interval. State whether the client’s body capture and the declared meter basis have independent written alignment; an unknown or headers-inclusive meter cannot be treated as a body meter. Use the half-open interval [start, end): include an attempt at start; exclude one at end. Count excluded out-of-window rows separately. If the provider closes in another timezone, do not silently call the periods equal. Without a documented conversion, the conclusion is HOLD.

RecordIt establishesIt does not establish alone
Declared meter exportOne stated usage total for its account, unit and period.A payable invoice or why a task log differs.
Attempt ledgerObserved executions, retry IDs and captured byte fields.Every byte the supplier meters.
Job ledgerWhich attempts belong to one job and whether it eventually passed.That retries were free or irrelevant.

Keep jobs, attempts, and bytes separate

A job can have several legitimate attempts. A success for job-7 is one business outcome; it must not erase body bytes from an earlier retry. Store an immutable attempt_id, job_id, timestamp, route/account label, and captured upload/download body bytes. Reject a duplicated or conflicting attempt_id import—not several rows for the same job.

AttemptJobBody bytes
a-1job-750 + 400 = 450
a-2job-7 retry50 + 300 = 350
a-3job-850 + 400 = 450

All rows are synthetic, from the same account/route and body basis. Times are integer seconds on one fictional clock in [100,200): 2 jobs, 3 attempts, 1,250 bytes. A 1,300-byte meter with independently evidenced 50-byte adjustment reconciles; with a 25-byte adjustment it leaves 25 bytes to investigate; an unknown adjustment is HOLD. Even when the meter is 1,250 bytes, an evidenced +50-byte adjustment means the expected total is 1,300, so the remaining −50 bytes still require investigation.

curl documents size_upload and size_download as body bytes excluding headers. size_header is an HTTP/1-style header representation, not wire overhead; compressed output can differ from transferred content. These fields are useful client telemetry, not a provider-meter definition. Confirm applicable treatment of headers, protocol/TLS overhead, compression, failed transfers, rounding and retries from the actual terms.

Only reconcile comparable evidence

client body estimate = Σ(upload_body + download_body)
                      for unique attempt_id in [start, end)
residual = declared meter bytes − client body estimate

Label the sum body estimate, never invoice or invoice forecast. Convert a declared unit only by its definition: 1 GB is 1,000,000,000 bytes; 1 GiB is 1,073,741,824 bytes. A residual is not proof of bad billing or bad telemetry. It may reflect a different time boundary, a failed transfer the client did not capture, or a different capture/meter boundary.

VerdictRequired evidenceAction
RECONCILEAccount, period, unit and attempt coverage align. With an evidenced adjustment, the residual must equal it; without one, there must be no unverified adjustment and the residual must be zero.Attach definitions and evidence to the renewal handoff.
INVESTIGATEComparable complete evidence remains, but residual differs from an independently declared adjustment.Ask for the meter boundary and preserve original exports.
HOLDScope, unit, period, identity or completeness is missing; or a residual has no independent explanation.Repair the evidence boundary; do not fill unknown overhead with zero.

Run the synthetic ledger, then prepare a support-ready handoff

Download the offline reconciliation fixture; it is Python 3.9+ standard library only and makes no network requests.

python3 proxy-billing-telemetry-reconciliation.py

It proves that two attempts for one job both remain counted; it rejects a duplicated attempt import and wrong-account row; it checks an end-boundary-only row, blank account and unknown meter basis. It returns two synthetic RECONCILE cases, two INVESTIGATE cases with complete comparable evidence, and five HOLD cases. It models no price, tax, discount, commitment, renewal cost, or real meter.

  1. Send a dated, redacted meter export; account scope; unit definition; close boundary; and written meter-boundary explanation.
  2. Send a redacted attempt ledger with job IDs, unique attempt IDs, retries, capture fields, timezone, and explicit excluded/unknown rows.
  3. State the verdict and residual without alleging its cause. Ask a supplier to explain its meter; do not present a client body estimate as an invoice.
  4. Keep the decision narrow: evidence sufficient for a renewal conversation, or HOLD. Review commercial terms separately.

For an authorized workload that may need a residential route, review residential proxies. For a scoped measurement-definition question, use contact; do not send credentials or sensitive targets.

Related work, not substitutes

Use billing comparison for pre-purchase terms, workload sizing for forecasts, traffic budget control for admission decisions, and monthly usage review for a broader operating decision. None turns local body bytes into an invoice.

Sources checked November 12, 2026: curl manpage for client field boundaries and NIST for SI/binary units. Values and cases are synthetic. No IPHTML billing, price, speed, discount, customer, payment, renewal, or savings result is claimed.