How to Reconcile SSP Payout Statements to GAM

Publishers reconcile SSP payout statements with GAM by comparing three ledgers: GAM ad-server reporting, the SSP's reporting view, and the payout or remittance statement finance books against. The records are related but not interchangeable, so each partner statement needs a common schema, aligned reporting windows and currency, explicit fee treatment, and a comparison to GAM at the right grain.

This is a month-end finance process, not just an AdOps troubleshooting exercise. For a practical escalation rule, the IAB guidance on 10% as a material discrepancy threshold identifies 10% as a material discrepancy threshold and recommends monitoring third-party numbers during the campaign. A one or two percent gap may be timing, filtering, or fee treatment; a persistent variance above that threshold needs documented investigation before close.

The clean workflow is straightforward even when the documents are messy: pull each SSP statement into a common ledger, standardize the month, currency, fee columns, and placement identifiers, join that dataset to the matching GAM view, then separate harmless timing differences from payout gaps that affect accruals or disputes. That is different from agency-side media billing reconciliation, where teams match media delivery to client billing rather than verifying what exchanges and monetization partners owe the publisher.

Where a GAM vs SSP revenue discrepancy actually comes from

Most monthly variances are created upstream of the payout statement. By the time finance sees a remittance total, the number has already passed through delivery counting, exchange logic, filtering rules, fee calculations, and payment adjustments. That is why a useful diagnostic model starts by separating measurement differences from payable differences.

• Counting methodology: GAM and an SSP may not count the same event at the same moment. One system may log the served impression while the other logs a won auction, rendered impression, or billable event after additional checks. Those differences show up first in impression and gross revenue comparisons.
• Quality and policy filters: Invalid traffic, viewability thresholds, brand-safety exclusions, or post-auction quality filters can reduce what the SSP recognizes as payable revenue even when GAM recorded the opportunity earlier in the chain.
• Commercial math: Gross revenue, exchange fees, rev-share terms, buyer-side deductions, data costs, or ad-serving charges do not always surface in the same place. Finance needs to know whether a mismatch is gross-to-gross, net-to-net, or a gross-versus-payable comparison disguised as a discrepancy.
• Time and currency alignment: A month in GAM is only comparable to a month in an SSP statement if both systems are using the same cutoff, time zone, and exchange-rate logic. Late adjustments or cross-border settlements can make a clean-looking monthly comparison false.
• Statement-level adjustments: Credits, debits, clawbacks, make-goods, and prior-period corrections often appear only on the remittance side. If those lines are not isolated, the team may assume the current month's delivery is wrong when the real issue is a separate accounting adjustment.

The other trap is reconciliation grain. Some issues need an ad-unit or placement comparison because the variance is tied to a specific inventory segment, deal type, or geography. Other issues only reconcile at partner-month level because the statement does not expose detailed dimensions. A publisher that tries to force every discrepancy into the same level of detail usually wastes time chasing missing granularity instead of validating what the statement can actually support.

In practice, the useful question is not "Why do the numbers differ?" It is "At which layer did they start to differ, and does that layer affect what we expect to be paid?" That shift turns a vague GAM vs SSP revenue discrepancy into a solvable reconciliation problem.

Build a common reconciliation ledger before you compare anything

A publisher cannot compare partner statements reliably until every statement is translated into the same ledger structure. Different SSPs label the same idea differently, collapse detail into different columns, and present gross, fees, and payable in inconsistent ways. If the team compares native exports side by side, it usually creates false variance before the real analysis begins.

The minimum viable reconciliation ledger should capture:

• Period fields: revenue month, statement date, and the reporting window the partner used
• Partner identity: SSP name, entity, and any relevant account or remittance identifier
• Inventory grain: placement, ad unit, site, app, country, or deal identifier when available
• Operational metrics: impressions and eCPM
• Financial metrics: gross revenue, SSP fee or rev-share amount, adjustments, net payable, and currency
• Workflow fields: variance percentage, status, owner, and dispute flag

That schema matters because reconciliation is mostly a normalization exercise. Month boundaries need to be mapped the same way. Currency needs one consistent treatment. Fee columns need to distinguish what was earned from what was withheld. Naming conventions for placements or partner entities need to be standardized before the GAM join, not after the variance report is already full of noise.

It helps to treat the ledger as two layers at once: a finance layer and an investigation layer. The finance layer answers what should be booked, what was actually paid, and what remains open. The investigation layer answers why the two do not line up. In practice that means preserving both the raw partner labels and the mapped labels, separating current-month revenue from prior-period adjustments, and storing enough context to re-run the match later without opening every original document again.

Teams also benefit from tracking a few fields that do not appear in simple close templates. A gross-basis flag tells the analyst whether the row represents pre-fee or post-fee revenue. A fee-basis note explains whether rev share, buyer fees, or platform charges were explicit or implied. A source-type field distinguishes portal export, PDF statement, remittance advice, or manual adjustment. Those columns sound administrative, but they are what prevent the same mismatch from being reclassified three different ways during review.

For teams still working from emailed PDFs or one-off portal exports, the first real job is to extract payout statements into structured spreadsheets. That ingestion layer is where many lean publisher teams lose time each month. If the statement arrives as a PDF, image, or irregular CSV, someone still has to capture the fields, map them to the ledger, and preserve the source document for review. The same problem shows up in adjacent workflows such as converting partner statements into Excel for reconciliation.

This is where a focused extraction layer can help without pretending to be a full revenue-intelligence platform. Invoice Data Extraction uses a prompt-based workflow to pull structured fields from PDF, JPG, or PNG documents into XLSX, CSV, or JSON output, and each output row includes the source file and page reference for verification. That is useful when a finance or AdOps team needs clean, reviewable rows before the reconciliation model starts. The value is not a prettier dashboard. The value is getting messy partner documents into a ledger that behaves consistently enough for month-end analysis.

A month-end workflow for reconciling Magnite, PubMatic, and other SSP statements to GAM

Once the common ledger exists, the month-end process becomes repeatable. Whether the partner is Magnite, PubMatic, Index Exchange, OpenX, Amazon TAM, or AdX, the sequence should stay stable even if the incoming format changes.

1. Collect the source records. Pull the partner statement, remittance, or export for the close period and capture the matching GAM view for the same inventory scope.
2. Normalize the partner file. Map native fields into the common ledger, standardize currency, isolate fees and adjustments, and stamp the actual reporting window used by the partner.
3. Validate period alignment. Confirm time zone, month cutoff, and any lagging adjustments before the GAM join. Many apparent payout gaps disappear at this step.
4. Join at the right grain. Start with partner-month totals, then move to placement, ad unit, deal, country, or site only when both sides support that level of comparison.
5. Calculate and rank variance. Measure gross-to-gross, net-to-net, and payable-to-accrual comparisons separately so different issues do not collapse into one percentage.
6. Investigate exceptions. Review the outliers first, classify whether they are timing, filtering, fee-treatment, or payment-adjustment issues, and flag the items that cross the team's escalation threshold.

The same ledger structure can live in a spreadsheet, BigQuery, or Snowflake; the order of operations should not change.

For named partners such as Magnite and PubMatic, start with the same test: a period-aligned, currency-aligned, fee-aware ledger entry against the GAM slice for the same inventory scope. The documents differ by partner, but the reconciliation math should not.

Normalize partner-specific statement quirks before you call anything a discrepancy

Partner statements are messy in different ways, and those differences matter more than most discrepancy explainers admit. One SSP may show gross revenue, fee amount, and net payable in separate columns. Another may only expose the payable figure on the statement while leaving gross detail in a portal report. A third may issue a remittance that folds prior-period adjustments into the same total finance is trying to book for the current month.

That is why partner-specific normalization rules belong in the reconciliation model itself. The team needs explicit logic for questions such as:

• Does the statement issue date belong to the same month as the revenue being paid?
• Are adjustments broken out separately, or embedded in the payable total?
• Is placement detail available on the statement, only in an export, or not at all?
• Does the partner present gross and fees, or only net?
• Are entity names, site names, or ad-unit labels stable enough to join directly to GAM?

Large SSPs such as Magnite, PubMatic, Index Exchange, and OpenX often provide richer exports, but even those partners do not present data in identical shapes. One partner may make the finance statement the payable source while the detailed operational breakdown lives elsewhere. Another may expose placement-level detail in reporting, but only partner-level totals on the remittance. Amazon TAM and AdX comparisons often add another layer because the payment-facing record and the GAM-side operating view do not always expose the same dimensions at the same stage of the transaction.

That is where partner notes become part of the process, not tribal knowledge. A strong reconciliation model keeps a short rule set for each partner: which file is the payable source, which file provides drill-down, which columns define fees, and which labels need translation before matching. Without those notes, the close file slowly turns into a pile of one-off fixes that only make sense to the analyst who last touched it.

Long-tail exchanges, reseller relationships, Criteo-style partner arrangements, and emailed PDFs are usually where ingestion becomes more painful than variance math. Keep the schema stable enough that each partner-led revenue source can be normalized and audited on its own terms; otherwise the team ends up arguing with document structure rather than economics.

What a dispute-ready variance package should include

When a variance crosses the team's materiality threshold, the next step is not another screenshot from a dashboard. It is an evidence package that lets the SSP see exactly what was compared, how it was normalized, and why the publisher believes the payable is off.

A strong package usually includes:

• The original partner record: the payout statement, remittance advice, or export used for the comparison
• Normalized ledger rows: the mapped fields that show revenue month, partner, placement detail, gross, fees, net payable, and adjustment treatment
• The matching GAM comparison: the report slice used on the ad-server side, with the same reporting window and inventory scope
• Assumption notes: time zone, currency handling, exchange-rate timing, and any logic used to map placement or partner labels
• Variance summary: the exact amount and percentage difference, plus the subset of rows driving it
• Source traceability: file names, page references, and analyst notes so the investigation can be repeated later

This structure matters because not every mismatch deserves escalation. A small variance tied to reporting lag or a known adjustment may only need annotation in the close file. A persistent gap, a partner-month discrepancy that crosses the team's threshold, or a payable that no one can explain deserves a cleaner handoff. The SSP should not have to guess whether the issue is invalid-traffic treatment, fee logic, a period mismatch, or an actual payout shortfall.

The best dispute packages are prepared before the dispute exists. If the team stores normalized ledger rows, preserved source references, and a consistent comparison table every month, then escalation becomes a packaging exercise rather than a reconstruction exercise. That is especially valuable when the variance surfaces late in close, when a partner questions the publisher's math, or when finance needs to explain why an accrual was adjusted after the initial close view.

A practical package usually has two views. The first is the executive summary for the partner contact: month, partner, amount in question, variance percentage, and the reader's conclusion about the likely cause. The second is the analyst backup: the detailed rows, mapping assumptions, and source references that let both sides reproduce the comparison. When those two views are separated, the escalation stays professional instead of turning into a data dump.

A weak dispute package usually means the close process did not preserve enough source detail, mapping logic, or variance evidence upstream.

When to stay in spreadsheets, when to use an extraction layer, and when to buy revenue-ops software

Spreadsheets are still enough when the partner mix is small, statements are predictable, manual cleanup is tolerable, and disputes are infrequent. The failure point is not the spreadsheet itself; it is the amount of document normalization the spreadsheet has to absorb.

An extraction layer makes sense when partner files arrive in mixed formats, column names drift, PDFs have to be re-keyed, or the same team handles multiple monetization workflows at once. That is the narrow role for Invoice Data Extraction: convert messy statements into structured XLSX, CSV, or JSON rows so finance and AdOps can spend time on variance analysis instead of transcription.

Buy a fuller revenue-ops platform when the bottleneck is monitoring, connector coverage, and cross-team workflow. If the real pain is getting partner statements into a stable ledger, add an extraction layer; if neither problem is large enough yet, keep the spreadsheet, formalize the schema, and tighten the close checklist before adding more software.