Reconciliation

Snapshots are truth, and the reason is structural: the record of an order is its create request, the platform's create-time facts, and an append-only event log, and every snapshot is the platform's own fold of that complete log. A delivery can be dropped or delayed; the fold cannot be, which is why you reconcile against snapshots on a schedule, independent of whether webhooks arrived.

The sweep

Run it on a timer, and again after any deploy or outage:

• Sweep the order book. GET /v1/orders?status=... lists your non-terminal orders; check each against its snapshot so a missed webhook never becomes a stuck order.
• Recover per order. GET /v1/orders/{id} returns the authoritative snapshot including last_seq; GET /v1/events?order={id}&after_seq={n} replays what you missed.
• Recover across every order at once. GET /v1/events/feed?after={cursor} resumes your whole event stream from your last cursor, one call instead of one replay per live order. Keep the cursor with your high-water marks and the sweep gets cheap.

Delivery actuals

Aired counts and delivered impressions come from the seller as delivery_post artifacts on the order: per-unit, per-week actuals in the declared currency, source-tagged. Audience guarantees reconcile against them; the platform carries the numbers, it never computes them.

Posting policy

A shortfall is arithmetic; whether it owes a make-good is policy. A product may state that policy, and then both sides compute the same answer. posting_policy carries aggregation_weeks (the window delivery totals over before shortfall is computed), threshold_pct (delivery at or above this percentage of the guarantee owes no make-good), and exclusions (the product_id references the policy does not cover: the tentpole carve-out). An agreement may override it, resolving as override(product_id) ?? override("*") ?? product.posting_policy ?? unstated. That chain is evaluated once, per line, at order create, and the result is frozen by value with the order, exactly as cancellation_terms and the locked price are: both are agreement terms that decide money, and anything that decides money after the fact is a fact of the create-time record, never a lookup against live data. The frozen value is not hidden state: it is recorded in the create-time record and reads back on both order reads as line_items[].posting_policy ({aggregation_weeks, threshold_pct, exclusions?}; absent when the resolution was unstated, matching how absent terms read everywhere else), derived at create and never accepted on a write. A later change to the product's policy or the agreement's overrides applies to the next order, not to a booked one, and a revision, being a new order, re-resolves at its own create. So what a post reconciles under is what both sides agreed to when the buy was made, and both sides can read it off the snapshot after the live records have moved on.

Evaluation is per line, never order-wide. One order may carry lines from products with different windows, thresholds, and exclusions, so there is no single order-level policy to apply. Mixed-policy orders are legal. For each audience_guaranteed line, independently:

1. Resolve the effective policy for that line's product_id.
2. If that line's product sits in the policy's exclusions, the line is excluded: no automatic determination, and its shortfall goes to the parties. Undecided is reported as undecided, never as "no make-good owed".
3. Total delivered impressions for that line from the order's delivery_post artifacts over that policy's aggregation_weeks, in the line's declared audience currency.
4. Compare against that line's goal. On a catalog line the goal is the booked guarantee, the locked rate entry's guaranteed_impressions times the line's booked units, the same figure the order's totals.impressions sums; on a proposal or document line it is the buyer-named impressions_goal. Satisfied when delivered >= goal * (threshold_pct / 100), inclusive at the edge. Satisfied owes no make-good; not satisfied populates the line's shortfall and the make-good path runs as it does today.

Worked once: a line guaranteeing 1,280,000 hh impressions under {"aggregation_weeks": 4, "threshold_pct": 90} needs 1,152,000 across its four posted weeks. 1,200,000 delivered is satisfied and owes nothing; 1,151,999 is not. Results report per line, exactly as unit acceptance already does: the order is never satisfied or unsatisfied as a whole. Where no policy is stated, behavior is exactly today's: the shortfall is reported and the decision stays with the parties.

Files and EDI

Sellers who live in traffic systems return actuals as the industry's own paper: station-generated EDI invoices and as-run log times land through the file interface and reconcile against orders, so billing stays in the systems both sides already trust.