Billing Authority

​

Overview

1. Whose number is authoritative? Different deals name different parties — the seller’s ad server, a buyer’s third-party ad server, or a named measurement vendor like Nielsen or IAS.
2. Has that number stopped moving? Telemetry settles over hours, days, or weeks (broadcast C3 → C7 DVR accumulation, digital post-IVT scrubbing, podcast 30-day downloads, conversion dedup). Final numbers are billable; provisional numbers are not.

​

Naming authority

​

Declaring how the billing count is built (experimental)

• Billing count only. It lists the mechanisms whose events enter the billed number. Mechanisms used only for audit or cross-check are not listed. If several are listed, the merge rule is not encoded; the seller describes it in its methodology. Provenance on individual reported vendor values is vendor_metric_provenance, which shares the vocabulary. Neither field is measurement_source, which names the provider.
• A claim, not a probe. It is a claim by the declaring party, enforced through the contract (vendor, max_variance_percent, makegood_policy) rather than tested by AdCP. A count that materially differs from what was declared is handled like any other variance under those terms.
• Absence means undeclared. Never read an absent field as server_logs or any other default. It is declared alongside vendor; a seller that omits billing_measurement declares nothing.
• Self-counting sellers SHOULD declare it. When the seller (or its ad server) is the named vendor, declare counting_mechanisms[]. Buyer-attested and third-party vendors describe their own method in their measurement-agent catalog and MAY omit it.
• Negotiable like any other term. On a product it is the seller’s default; on a package request it is a buyer’s proposed term; the seller accepts, adjusts, or rejects with TERMS_REJECTED. In practice a seller will rarely agree to a different method for its own count, so treat it as a handshake more than a lever.
• A set. Order carries no meaning and values MUST NOT repeat.
• Airing evidence is not a counting mechanism. Broadcast as-run logs and station affidavits prove that a spot ran; they are not a mechanism for audience measurement and have no value in this vocabulary. Delivery reports carry as-run data in by_spot[], separate from the audience rows that counting_mechanisms[] and vendor_metric_provenance describe.

{
  "measurement_terms": {
    "billing_measurement": {
      "vendor": { "domain": "streamhaus.example" },
      "counting_mechanisms": ["server_logs"],
      "max_variance_percent": 10,
      "measurement_window": "post_ivt"
    }
  }
}

​

Marking numbers as final

​

On get_media_buy_delivery

• is_final: boolean — row-level finality, equivalent to all packages in the row being final for the same window.
• finalized_at: string (date-time) — present iff is_final: true. Anchors any deadline declared in billing_measurement.finalization_deadline_hours.
• Per-package: by_package[*].is_final, by_package[*].finalized_at, by_package[*].measurement_window, by_package[*].supersedes_window.

​

On report_usage

• final: boolean — absent means unknown. Set true only when the reporter has actually settled the numbers (e.g., post-SIVT month-end close). Set false for preliminary records (daily pacing pushes, intra-period progress). When measurement_terms.billing_measurement names this reporter as authoritative, the receiver MUST NOT invoice on final: false or absent — request a final record first. For 3.0-style usage with no billing_measurement and for non-media-buy variants (signals, governance, creative, brand — domains with no provisional state concept), receivers MAY treat absent as final, preserving existing behavior.
• finalized_at: string (date-time) — present iff final: true.
• measurement_window: string — SHOULD be set when the buy’s billing_measurement.measurement_window is set, so the receiver reconciles against the correct stage.

​

Distinguishing webhook finality from row finality

​

How a seller produces an invoice

​

Seller-attested (default)

billing_measurement absent, or vendor names seller's own ad server

​

Buyer-attested (3PAS)

billing_measurement.vendor.domain = "campaignmanager.google.com" (buyer's CM360)
billing_measurement.max_variance_percent = 10
billing_measurement.measurement_window = "post_sivt"
billing_measurement.finalization_deadline_hours = 240   // 10 days after post_sivt close

1. Buyer’s CM360 settles post-SIVT for the period.
2. The buyer’s operator — in practice a holdco platform (e.g., Choreograph, Annalect, Acxiom) or an in-house agency engineering team that wraps the CM360 export — calls report_usage with the media-buy record: media_buy_id, impressions, vendor_cost, currency, final: true, finalized_at, measurement_window: "post_sivt". Daily pacing pushes (if used) set final: false; only the settled file sets final: true.
3. Seller compares against its own post-SIVT row from get_media_buy_delivery (is_final: true, same measurement_window). If |seller - buyer| / max ≤ max_variance_percent, the seller invoices on the buyer’s numbers.
4. If variance exceeds threshold, the seller proposes a remedy from makegood_policy.available_remedies.
5. If the buyer doesn’t publish a final record within finalization_deadline_hours, the seller MAY invoice off its own seller-attested numbers and treat the late finalization as a breach under makegood_policy.

Today’s reality: monthly 3PAS reconciliation is mostly handled out-of-band via CSV/PDF emailed to the seller’s AR team. This flow is the wire-format upgrade — the first adopters are likely holdco operators with the engineering to wrap CM360 / Flashtalking / Innovid exports in report_usage, working with sympathetic direct publishers rather than RTB SSPs.

​

Vendor-attested (named third party)

billing_measurement.vendor.domain = "nielsen.com"
billing_measurement.max_variance_percent = 5
billing_measurement.measurement_window = "c7"
billing_measurement.finalization_deadline_hours = 528   // 22 days after c7 close

• Seller holds the vendor relationship (the common CTV pattern). The seller pulls C7 numbers from Nielsen (NPower, etc.) on its own schedule and publishes them on get_media_buy_delivery as a row with measurement_window: "c7", is_final: true, and finalized_at set when the C7 window closes plus its internal processing. No report_usage push from the buyer is needed; reconciliation happens against the seller’s row.
• Buyer holds the vendor relationship. The buyer (or its operator) fetches the vendor’s authoritative numbers — e.g., an agency’s iSpot subscription, an in-house IAS dashboard export — and pushes them via report_usage against the buy’s account with final: true, finalized_at, and measurement_window: "c7". The vendor itself does not call AdCP.

Today’s reality: SSPs running RTB will keep being seller-attested for the foreseeable future — their billing systems were never designed for buyer-attested invoice basis and max_variance_percent plus makegood_policy is not enough commercial cover for them to retrofit it. The first real adopters here are CTV direct sellers (e.g., Disney, NBCU, Paramount) whose Nielsen-backed guarantees already invoice on a measurement vendor’s count — for them this PR just describes existing practice in structured terms.

​

Resolving disagreements today

• The buy’s makegood_policy.available_remedies — the menu of remedies (additional delivery, credit, invoice adjustment) the seller has pre-committed to.
• Final records on both sides with finalized_at timestamps — a full audit trail of who said what was final, when.
• The original committed_metrics and measurement_terms captured at create_media_buy — what the parties signed up for.

​

Worked example: buyer-attested 3PAS reconciliation

{
  "measurement_terms": {
    "billing_measurement": {
      "vendor": { "domain": "campaignmanager.google.com" },
      "max_variance_percent": 10,
      "measurement_window": "post_sivt",
      "finalization_deadline_hours": 240
    },
    "makegood_policy": {
      "available_remedies": ["additional_delivery", "credit", "invoice_adjustment"]
    }
  }
}

{
  "media_buy_deliveries": [
    {
      "media_buy_id": "mb_q1_2026",
      "is_final": true,
      "finalized_at": "2026-04-08T18:00:00Z",
      "by_package": [
        {
          "package_id": "pkg_001",
          "is_final": true,
          "finalized_at": "2026-04-08T18:00:00Z",
          "measurement_window": "post_sivt",
          "impressions": 5120000,
          "spend": 51200
        }
      ]
    }
  ]
}

{
  "idempotency_key": "f9b3...e2a1",
  "reporting_period": { "start": "2026-03-01T00:00:00Z", "end": "2026-03-31T23:59:59Z" },
  "usage": [
    {
      "account": { "account_id": "acct_acme_seller" },
      "media_buy_id": "mb_q1_2026",
      "currency": "USD",
      "impressions": 5040000,
      "vendor_cost": 50400,
      "final": true,
      "finalized_at": "2026-04-09T14:32:00Z",
      "measurement_window": "post_sivt"
    }
  ]
}

​

Related

• measurement-terms — schema
• get_media_buy_delivery — seller-side finality flags
• report_usage — buyer-side / third-party finality flags
• Accountability — performance standards, makegood remedies, cancellation
• Reporting capabilities and measurement windows
• Reliable Reporting: implementing reporting.core — the operational delivery contract for the seller-produced feed
• sync_reporting_status — buyer-to-seller consumption status, and why it is not a dispute channel