Deal terms checklist: does the live deal match the agreement?
Part of Curated deals and PMPs
The short answer
A deal terms checklist compares what the buyer and seller agreed with what each system actually holds, field by field, before any money is spent. It covers the deal ID, buyer seat, price and currency, auction type, formats, geography, dates and status, names who confirms each one, and records the result so a later change can be traced.
Key takeaways
- Compare three records for each term: the written agreement, the seller's setup and the buyer's platform entry.
- Deal ID, exchange and format can be locked once saved in a buying platform, so an error there means a new entry, not an edit.
- Currency and dates hide quiet mismatches: OpenRTB and the Deals API default currency to USD, and Deals API dates are UTC timestamps.
- Each term needs one named confirmer on each side, and a wrong term is fixed at its source before the line item spends.
- Record the confirmed values with a date and a version, and keep the platform's change log beside them.
How can the desk compare intended deal terms with the live setup?
A deal exists in at least three places: the agreement, such as an email or an insertion order; the seller's system, where the deal was created; and the buying platform, where the trader entered or accepted it. The comparison works when each term is read from all three, using the field names the systems themselves use. The IAB Tech Lab Deals API 1.0 (opens in a new tab), released as version 1.0 on February 6, 2026, gives a shared vocabulary for the seller side, and the OpenRTB 2.6 Deal object (opens in a new tab) shows what reaches the bid request.
| Term | Deals API 1.0 field | OpenRTB 2.6 field | Display & Video 360 entry |
|---|---|---|---|
| Deal ID | id, in the origin's namespace | Deal.id | ID, locked once saved |
| Buyer seat | wseat or bseat | Deal.wseat | Advertisers with access; the partner's seat on the exchange |
| Price | dealfloor; guidance unless pricetype is Fixed | Deal.bidfloor | Rate, as CPM (fixed) or CPM (floor) |
| Currency | cur, default USD | Deal.bidfloorcur, default USD, not inherited from the impression | Set by the seller; confirm on the entry |
| Auction type | pricetype: 0 dynamic, 1 first price, 2 second price plus, 3 fixed | Deal.at: 1, 2, or 3 for the agreed deal price | Fixed or auction, which cannot be switched after saving |
| Formats | adtypes: 1 banner, 2 video, 3 audio, 4 native | Banner, Video, Audio or Native object in the impression | Inventory format, locked once saved |
| Geography | countries | Device or User Geo object | Line item geography targeting |
| Dates | startdate and enddate, UTC timestamps in ISO 8601 | Not carried | Start date and optional end date |
| Status | sellerstatus 0 to 4 | Not carried | Negotiation status, such as Action required or Completed |
Display & Video 360's form for adding an inventory source (opens in a new tab) is the source for the right hand column. Other buying platforms may name these fields differently; the comparison is the same: one row per term, three values side by side.
Which deal fields drift from the agreement, and why?
The sources checked for this page do not rank how often each field goes wrong, so this section names the fields where the mechanism for drift is documented. Each mechanism points to a specific check.
| Field | How it drifts | Source of the mechanism |
|---|---|---|
| Currency | A price agreed in CAD is entered without a currency and read as USD | OpenRTB 2.6 and the Deals API both default to USD |
| End date | A date entered as UTC midnight ends the deal on the evening before in North American time zones | Deals API dates are UTC timestamps |
| Any synced term | The seller edits the deal and the synced entry updates with the exchange's latest details | Display & Video 360, synced deals |
| Any manual term | The seller edits the deal, but a manually entered ID does not sync, so the buyer's copy is stale | Display & Video 360, synced deals |
| Deal ID | A changed negotiation produces a new deal automatically, and the old ID stays on the line item | Display & Video 360, negotiating a deal |
| Sites | The domain list changes after launch on a dynamic deal | Deals API dinventory value 2 |
What is the full pre-spend terms checklist?
Agreement against live setup, before the line item spends
- The deal ID on the line item was copied from the seller's system, not retyped from an email, and matches the agreement.
- The exchange on the buying platform entry is the exchange the seller created the deal on.
- The seller's allowed seat list includes the seat the buying platform bids with, and the advertiser on the entry is the client's.
- The price on the entry matches the agreement, and the rate type matches the agreed auction type.
- The currency is stated in all three records, and a CAD price is not read as USD anywhere.
- The format on the entry matches the format families the deal sells.
- The countries on the seller record match the line item's country targeting, code for code.
- Start and end dates match once converted from UTC to the advertiser's time zone.
- The seller status is active and the buyer side shows the deal accepted.
- For a guaranteed deal, units and total cost match the agreement.
Display & Video 360 shows troubleshooting data in the advertiser's time zone, according to its troubleshooter for deals (opens in a new tab), which is a second reason to convert dates before comparing. The deal hub covers activation once the terms match.
Who confirms each term?
Each term has a side that owns its value and a side that checks it. Writing both names down avoids the case where each side assumes the other has looked. The split below follows who can see and change each record.
| Term | Owns the value | Checks it | What the checker looks at |
|---|---|---|---|
| Deal ID and exchange | Seller | Trader | The entry on the buying platform |
| Buyer seat | Trader, who supplies it | Seller | The allowed seat list on the deal |
| Price, currency, auction type | Both, in the agreement | Trader and seller each | Their own system against the agreement |
| Formats | Seller | Trader | The entry's format and the creatives assigned |
| Geography and languages | Planner, from the brief | Seller and trader | Deal countries and line item targeting |
| Dates | Both, in the agreement | Trader | Both systems, in one time zone |
| Site list | Planner | Seller | The domain count uploaded to the deal |
Seat setup can need a third party. Display & Video 360's page on managing exchanges (opens in a new tab) says some exchanges require the partner to contact its support team to set up or update a seat ID, so add that contact to the sheet when it applies. Our guide to the buyer seat ID explains how seats are matched.
What should happen when a term is wrong?
Correcting a wrong term before spend
- Hold the spend. Keep the line item paused or without budget until the term is fixed.
- Find which record is wrong. Compare the agreement, the seller's setup and the buyer's entry to see which one departs.
- Fix it at the source. A seller side error goes back to the seller; in Display & Video 360 a buyer can propose changes on the negotiation, which may need another review or generate a new deal, per its page on negotiating a deal (opens in a new tab).
- Replace locked entries. If the ID, exchange or format on the buying platform is wrong, create a new entry and archive the old one, since those fields cannot be changed once saved.
- Re-run the full checklist. A new deal can carry a new ID, so check every term again, not only the one that was wrong.
- Record the change. Note what was wrong, who fixed it and when, on a new version of the sheet.
The Deals API notes that version 1.0 does not support deal revisions and that implementers should discuss which attributes may change after a deal goes live. Ask the seller that question while the terms are being checked, so a mid-flight change has an agreed route.
How should the confirmed terms be recorded?
The confirmed terms belong on the curated deal sheet as a dated block: each term, its three values, who confirmed it and when. The buying platform keeps its own log. Display & Video 360's event history (opens in a new tab) shows the time, date, description of each change and the user who made it, accepts notes, and downloads as a CSV file.
What does a terms check catch on a real deal?
Fictional example
A maple syrup producer checks its fall deal in northern New England
An unnamed maple syrup and specialty food producer wants display ads beside food, recipe and regional travel content in Maine, New Hampshire and Vermont, in English, for a fall gifting flight. Its agency agrees a USD private auction with a curator, with fixed start and end dates.
The trader reads the seller record through the curator's deal details and compares it with the buying platform entry. The deal ID, exchange and format match. The seller record lists the countries as USA, matching the line item. The end date is stored as midnight UTC on the last day, which is the evening before in Eastern time, so the trader asks the curator to move it to the end of the day in Eastern time.
The curator's change generates a new deal ID. The trader adds a new entry, archives the old one, re-runs the checklist and records both IDs, the reason and the date on version 2 of the sheet.
How does PlacementGraph help fix the planned terms before the check?
Frequently asked questions
Is a screenshot of the deal setup enough evidence?
It is weak evidence on its own. A synced deal in Display & Video 360 updates with the exchange's latest details, so a screenshot can be out of date within days. Keep the values on a dated sheet version and the platform's downloadable change history, which shows who changed what and when.
Should the terms be re-checked after the deal goes live?
Yes, once the first requests arrive. The Deals API warns that deal criteria are not guaranteed to appear in bid requests, so read the incoming geography, formats and deal ID in live data. After that, re-check whenever either side reports a change to the deal.
What if the agreement and the seller's record disagree, and both sides insist they are right?
Go back to the signed or emailed agreement and treat it as the reference, then ask the seller to change its record or both sides to amend the agreement in writing. Keep the line item paused until one value is agreed, and note the outcome on the sheet.
Does a fixed price deal need the same checks as a private auction?
Mostly yes, with one addition. In OpenRTB 2.6, Deal.at set to 3 means the floor value is the agreed deal price, and the Deals API treats dealfloor as binding only when pricetype is Fixed. Confirm the auction type in both records as well as the number itself.
Sources
- Deals API Specification version 1.0 (opens in a new tab)IAB Tech Lab, deal-api repository
- Deal API 1.0 release (1.0-202602), published February 6, 2026 (opens in a new tab)IAB Tech Lab, deal-api repository
- OpenRTB 2.6 specification: Pmp and Deal objects (opens in a new tab)IAB Tech Lab, OpenRTB repository
- Add an inventory source to Display & Video 360 (opens in a new tab)Google, Display & Video 360 Help
- About synced deals (opens in a new tab)Google, Display & Video 360 Help
- Negotiate a deal in Display & Video 360 (opens in a new tab)Google, Display & Video 360 Help
- Managing exchanges (opens in a new tab)Google, Display & Video 360 Help
- Troubleshoot your deals and line items (opens in a new tab)Google, Display & Video 360 Help
- Event history (opens in a new tab)Google, Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.