Skip to main content
Reliable Reporting 1.0 / RC1 additions — unreleased source contract. This task is experimental and belongs to the optional Reconciled Billing tier: only sellers advertising media_buy.reporting_delivery.reconciled_billing: true implement it, and its presence is declared through receipt_task. Core-tier sellers never implement receipts. Sellers implementing it declare media_buy.reporting_delivery in get_adcp_capabilities.experimental_features.
sync_reporting_receipts closes the knowledge gap between “the seller published a report” and “this consumer independently observed matching data.” It is a batched, idempotent write. It does not acknowledge mere webhook delivery. A receipt reconciles immutable billing-purpose reporting evidence and control totals only. It does not create, approve, modify, or settle invoices; calculate taxes or FX; authorize accounting entries; transfer funds; or determine legal payment obligations. accepted means the digest, version, row-count, and control-total evidence matches; it is not invoice/price/fee approval, a dispute waiver, posting authorization, or a payment due. rejected means an evidence discrepancy only. An external billing system MAY retain reporting_revision_id as supporting evidence. Reliable Reporting 1.0 / RC1 addition: If the source is corrected, the seller publishes a separate accounting-only reporting adjustment into a period derived from its pinned billing calendar and correction policy; that metadata does not authorize reopening books or altering invoices. The consumer recomputes the adjustment’s canonical_adjustment_sha256 and submits an adjustment_receipts[] accepted or rejected result. Reconciled Billing does not treat the correction as agreed until that exact adjustment digest has an accepted receipt. For example, a buyer can retain reporting_revision_id next to a monthly external billing-system record while reconciling a spend control-total delta. Acceptance only records matching reporting evidence; that billing system still decides whether any invoice action is appropriate.
The schema links below describe the published RC0 baseline. Fields and behavior explicitly labeled Reliable Reporting 1.0 / RC1 below are unreleased source contract and will publish with RC1. RC0 does not support changes_after, adjustment_receipts, receipt replacement semantics, or any other RC1-only addition.
Request schema: sync-reporting-receipts-request.json Response schema: sync-reporting-receipts-response.json
Reliable Reporting 1.0 / RC1 additions: adjustment_receipts[], post-official adjustment reconciliation, and receipt replacement/supersession and append-only-history semantics below are unreleased. RC0 already supports the batched revision materialization receipts[] form; it must not be read as supporting these RC1 additions.
The authenticated transport identity, not a payload field, identifies the buyer or governance consumer. The seller accepts a receipt only for that principal’s account-bound obligation and materialization. Unknown, unauthorized, cross-account, and cross-caller identifiers return indistinguishable failures. Reliable Reporting 1.0 / RC1 reconciliation semantics: reconciliation is immediately due once the revision and verified materialization are readable; Reliable Reporting does not define a separate receipt SLA. A missing current revision receipt produces action_required / RECEIPT_REQUIRED; a missing adjustment receipt produces ADJUSTMENT_RECEIPT_REQUIRED, both assigned to the consumer. A current rejected receipt produces RECEIPT_REJECTED or ADJUSTMENT_RECEIPT_REJECTED, assigned to the seller for evidence investigation/remediation. Every current revision receipt and every applicable adjustment receipt must be accepted before the obligation is accepted. Publishing a new adjustment reopens an accepted obligation to pending/action-required. An accepted receipt always carries independently observed row count and control totals. Its selected verification profile adds one of:
  • native_commit: the exact provider-native immutable version;
  • manifest_checksums: the digest-valid manifest whose file checksums were verified; or
  • canonical_digest: the digest of canonical logical content, required for billing.
If evidence differs, consumers submit status: rejected with stable rejection codes. Reliable Reporting 1.0 / RC1 replacement semantics: A receipt records exactly one materialization evidence attempt. Materializations are attempts within one current authenticated-consumer + obligation + revision replacement chain, not independently reconciled materialization chains. A receipt ID is immutable. Exact retries are unchanged; reuse with different content is an idempotency conflict. A new immutable receipt ID may name supersedes_reporting_receipt_id only for the same current rejected leaf; accepted current leaves are terminal. The revision-receipt replacement chain is scoped to one authenticated consumer plus obligation and revision, and its replacement may name a corrected materialization for that same revision. Sellers retain the append-only history, while status counts derive the one current leaf per authenticated consumer and obligation/revision (or adjustment). Sellers return received_at and expose the durable receipt through get_reporting_status, allowing the consumer to read back that agreement. One canonical revision may fan out to several destinations or principals. Each consumer has its own replacement chain, and one consumer’s receipt never counts as another consumer’s acceptance.