What belongs on a curated deal sheet, and who fills it in?
Part of Curated deals and PMPs
The short answer
A curated deal sheet is the document that travels with an approved site list to whoever builds the deal. It states the brief summary, geography, languages, list size, each site's sellers on each exchange, ad formats, price terms and setup steps, with a version number, so seller, buyer and client read the same terms.
Key takeaways
- Write each field in the terms the standards use, such as ISO region codes, BCP 47 language tags and OpenRTB price types.
- Each part of the sheet has one owner: planner, client, trader, or the seller or curator who returns the deal ID.
- Show sellers per site and per exchange, with the ads.txt account ID, DIRECT or RESELLER, and the sellers.json seller_type.
- An unverified seller is a status with a reason, not a silent deletion and not proof the site is bad.
- Every sheet carries a version, a date and the list version it matches.
What information belongs on a curated deal sheet?
Definition
- Curated deal sheet
- A short document that goes with an approved site list and states what the deal builder needs: purpose, geography, languages, sites and sellers, formats, terms and setup steps.
Write each field the way downstream systems will read it. IAB Tech Lab's Deals API specification (opens in a new tab), finalized on February 6, 2026, defines how deal terms move from the system that created a deal to the one that bids on it, and its fields make a good skeleton: dates, countries, floor and currency, price type, ad types and, for a fixed set of sites, domains and seller IDs. The OpenRTB 2.6 specification (opens in a new tab) supplies codes for language and region.
| Sheet field | What to write | Standard term it matches |
|---|---|---|
| Brief summary | Product, audience, topics wanted and topics to avoid, in two or three sentences | Deals API desc, best kept to 250 characters |
| Geography | Countries, then provinces or states if the deal is narrower | Deals API countries; OpenRTB Geo region in ISO 3166-2, such as CA-NB |
| Languages | Each language the sites publish in, with regional tags where they matter | OpenRTB Content langb in BCP 47, such as en-CA and fr-CA |
| List size and version | Number of sites, list version, approval date | Deals API inventory sitedomains, for a static list |
| Sellers per site | Exchange, account ID, DIRECT or RESELLER, seller_type | ads.txt fields 1 to 3; sellers.json seller_id and seller_type |
| Ad formats | Banner, video, audio or native, with sizes or durations | Deals API adtypes 1 to 4 |
| Price terms | Price model, floor or fixed price, currency | Deals API pricetype, dealfloor and cur; OpenRTB Deal at, bidfloor and bidfloorcur |
| Dates | Start and end, or evergreen | Deals API startdate and enddate, with a blank end date for evergreen deals |
| Buyer seats | Seat ID on each exchange, and advertiser domains if restricted | Deals API wseat; OpenRTB Deal wseat and wadomain |
| Setup steps | Upload format, who creates the deal, where the deal ID goes | Exchange documentation for domain list uploads |
Who fills in each part of the deal sheet?
A deal sheet goes wrong when one person fills every field from memory. Assign each block to the person who holds the evidence for it, and have each owner initial their block, so the sheet shows who to ask when a field is questioned.
| Block | Owner | Evidence they attach or cite |
|---|---|---|
| Brief summary, geography, languages | Planner | The confirmed brief the client signed |
| Site list, list size, version | Planner | The approved list file and its approval date |
| Client approval | Client or account lead | Written approval of that list version |
| Sellers per site | Planner or ad operations | ads.txt and sellers.json as read on a stated date |
| Formats, price terms, dates, seats | Trader | The agreed terms and the seat IDs from the buying platform |
| Deal ID and setup confirmation | Seller or curator | The exchange's confirmation of the deal and its ID |
Seat IDs need a named owner because a stale one blocks bids under the deal. OpenRTB says seat IDs, and the buyer's customers they refer to, must be coordinated between bidders and the exchange in advance. Our OpenRTB deal object guide shows where wseat appears in a bid request.
How should sellers per site be shown on the sheet?
Show one row per site per exchange. A site sold through three exchanges has three selling paths, and the deal runs on one. Each row takes its values from the site's ads.txt and the exchange's sellers.json.
The ads.txt 1.1 specification (opens in a new tab) gives three required fields per line: the domain of the advertising system, the publisher's account ID, which must contain the same value used in OpenRTB bid requests, and the account type, DIRECT or RESELLER. The sellers.json specification (opens in a new tab) says its seller_id is the same ID that appears in an ads.txt file, and its seller_type says whether that account is a PUBLISHER, an INTERMEDIARY or BOTH. Our guides to ads.txt and sellers.json explain each file.
Fill one seller row
- Name the site and the exchange. Use the site's root domain and the exchange's domain as it appears in ads.txt field 1.
- Copy the account ID. Take field 2 exactly; this is the value the exchange will send as publisher.id.
- Record the account type. Write DIRECT or RESELLER from field 3, as the site declares it.
- Look up the same ID in sellers.json. Write the seller_type, and the seller name and domain unless the entry is confidential.
- Date the row. Write the day both files were read, since either file can change after the sheet is sent.
What should the sheet say about unverified sellers?
Some rows will not confirm cleanly. Rather than delete those sites or leave the cell blank, give each row one status from a fixed list, with the reason. A blank cell reads as either fine or forgotten.
| Status on the sheet | What was found | What the sheet asks for |
|---|---|---|
| Confirmed both ways | The ads.txt line and the sellers.json entry name the same account ID | Nothing further |
| Listed by the site only | The ads.txt line exists, but the exchange's sellers.json has no matching seller_id | The seller to confirm the account before the site is uploaded |
| Confidential seller | The sellers.json entry sets is_confidential to 1, so name and domain may be omitted | The seller to confirm the account is the publisher's or its authorized reseller |
| No ads.txt found | The site's root domain has no readable ads.txt on the date checked | A manual check, or the site held out of this deal version |
| Not sold on this exchange | Neither file shows a path for this site on the deal's exchange | The site removed from this deal's upload, kept on the list for others |
The sellers.json specification requires every seller to appear even if confidential, so a confidential entry still confirms an account exists, though not who is paid. The Deals API specification adds that without a site ID or app bundle matching the publisher's ads.txt, a seller's authorization cannot be validated, and such deals should be used rarely and closely monitored.
How should the sheet be versioned?
Version the sheet with the list. Deals API 1.0 does not support deal revisions, and its dinventory field exists because some deals change their sites after going live and some do not. Say which kind this deal is, and give every list change a new sheet version.
Versioning rules for a curated deal sheet
- The sheet carries a version number and date, and names the list version it describes.
- The sheet states whether sites may change after launch, matching the deal's dinventory setting where the exchange uses it.
- A change log lists sites added and removed, with the reason and the date for each.
- The version uploaded to the exchange is recorded with the upload date and the deal ID it produced.
- Old versions are kept, so a served domain report can be compared with the version live at the time.
What is the full fill in checklist for a curated deal sheet?
Curated deal sheet, complete before it is sent
- The brief summary names the product, audience, topics wanted and topics to avoid in under 250 characters.
- Geography lists countries, then provinces or states, using codes such as CA-NB.
- Languages are written as tags, such as en-CA and fr-CA, and match the languages the listed sites publish in.
- Every site has one seller row per exchange with account ID, DIRECT or RESELLER, seller_type and the date read.
- Every row that did not confirm carries a status from the fixed list and its reason.
- Price model, floor or fixed price and currency are stated, with CAD written out for Canadian deals.
- Buyer seat IDs per exchange and any advertiser domains are filled in by the trader.
- Setup steps name the upload file, who creates the deal and where the deal ID is sent.
What does a filled in deal sheet look like?
Fictional example
A bilingual eyewear deal for New Brunswick
A fictional optical retail chain with stores in Moncton, Saint John and Fredericton wants display and short video beside local news, health and family content in New Brunswick, in English and French, priced in CAD. Its planner approves a list of regional and provincial sites and opens a deal sheet at version 1.
The planner writes geography as CAN with region CA-NB, languages as en-CA and fr-CA, and the list size and approval date. Each site gets a row per exchange. Two sites show RESELLER paths only, recorded as such. One French language site has no readable ads.txt on the day checked, so its row reads No ads.txt found and it is held out of version 1.
The trader adds the price model, floor and currency in CAD, the seat ID and the flight dates. The seller returns the deal ID, recorded against version 1. When the French site publishes an ads.txt file two weeks later, the planner re-reads every seller row and issues version 2.
How does PlacementGraph produce a deal sheet?
Frequently asked questions
Should the deal sheet include the price?
Yes, as terms rather than a quote. State the price model, the floor or fixed price, and the currency. The Deals API treats its floor as guidance unless the price type is fixed, and OpenRTB reads a deal floor as USD when no currency is given, so writing CAD or USD removes a source of mismatch.
Does a deal sheet replace the seller's deal confirmation?
No. The sheet is what the buyer asks for; the seller's confirmation is what the exchange set up. Keep both and compare them field by field when the deal ID arrives, especially seats, currency, dates and the number of sites uploaded.
Can one deal sheet cover several exchanges?
It can describe them, but each exchange builds its own deal with its own ID and seat. Keep every exchange's seller rows on one sheet, with one setup block per exchange for its upload file, deal ID and seat, so a change on one is not applied to another.
Should French and English sites be on separate deal sheets?
Only if they will run as separate deals. One deal can cover both languages, with the sheet listing en-CA and fr-CA and which sites publish in each. If the creative differs by language, separate deals keep reporting cleaner, each with its own sheet.
Sources
- Deal Sync API specification 1.0 (opens in a new tab)IAB Tech Lab
- OpenRTB 2.6 specification: Geo, Content and Deal objects (opens in a new tab)IAB Tech Lab
- ads.txt specification version 1.1 (opens in a new tab)IAB Tech Lab
- sellers.json specification (opens in a new tab)IAB Tech Lab
- Deals API (opens in a new tab)IAB Tech Lab
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.