How to Reconcile SSP Payout Statements to GAM

To reconcile SSP payout statements to GAM, publishers need to compare three different ledgers: GAM's ad-server reporting, the SSP's own reporting, and the payout or remittance statement that finance ultimately books against. Those records are related, but they are not interchangeable. Reconciliation works when each partner statement is extracted into a common schema, reporting windows and currency are aligned, fee treatment is made explicit, and the normalized ledger is compared to GAM at the right grain.

That distinction matters because publisher ad revenue reconciliation is a month-end finance process, not just an AdOps troubleshooting exercise. GAM helps explain delivery and monetization. SSP dashboards explain what the exchange counted and filtered. The payout statement tells finance what the partner is actually paying. If those layers are blended too early, teams end up disputing the wrong number or booking revenue against a figure that was never meant to serve as the payable.

The authority cue here is not vague. 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 to avoid material discrepancies at invoice time. For publishers, that threshold is useful because it creates a practical escalation rule. A one or two percent gap may be timing, filtering, or fee treatment. A persistent variance that crosses a materiality threshold usually deserves a documented investigation before close.

The financial stakes are larger than a reporting cleanup exercise. Close teams use these numbers for accrual support, cash expectation, and partner follow-up. If a payable is understated, the publisher needs to know before the month is locked. If the gap is explainable, the close file needs a clear note so the same question does not reappear next month. Reconciliation is what turns operational revenue data into something finance can defend.

The clean workflow is straightforward even when the underlying documents are messy. Pull each SSP's statement, remittance, or export into a common ledger. Standardize the month, currency, fee columns, and placement identifiers. Join that normalized dataset to the matching GAM view. Then separate harmless differences, such as reporting windows or invalid-traffic treatment, from payout gaps that actually affect accruals or partner disputes.

This is also a different problem from agency-side media billing reconciliation. Agency teams are matching media delivery and client billing. Publisher teams are verifying what exchanges and monetization partners owe them. The mechanics overlap, but the source documents, counterparties, and escalation path do not.

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.

That is what a practical SSP monthly statement import should support. Spreadsheet-driven teams often keep one tab per partner, one normalized ledger tab, and one exception view for review. Warehouse-backed teams push the same structure into BigQuery or Snowflake so joins, exception rules, and historical comparisons are easier to automate. The tooling changes, but the order of operations does not.

If a team needs to reconcile Magnite payout figures, the useful first comparison is rarely a raw statement total against a generic GAM revenue export. The useful comparison is a period-aligned, currency-aligned, fee-aware ledger entry against the GAM slice that reflects the same inventory scope. The same logic applies when the goal is to reconcile PubMatic payout data. Named partner workflows feel different because the documents differ, not because the reconciliation math changes.

The operational win is consistency. A publisher monthly statement reconciliation workflow should not depend on who happens to be on close duty that week. It should produce the same ledger, the same variance logic, and the same exception queue every month, even when partner formats and adjustment lines are inconsistent.

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.

The friction gets worse with long-tail exchanges, reseller relationships, Criteo-style partner arrangements, or emailed PDFs from finance contacts. Those are the documents that create manual re-keying, naming drift, and quietly broken formulas in close spreadsheets. They are also the cases where the ingestion problem becomes more painful than the variance math itself.

Publishers also rarely reconcile ad revenue in isolation. Teams that are already managing affiliate, sponsorship, or other partner-led revenue streams will recognize the same normalization challenge in adjacent workflows such as consolidating affiliate network payouts in QuickBooks or Xero. The point is not to blend unlike revenue sources into one table. The point is to keep the schema stable enough that each source can be normalized cleanly and audited on its own terms.

If a discrepancy is declared before these quirks are normalized, the team is usually arguing with document structure rather than economics. Clean reconciliation starts with making each partner's statement intelligible on common terms.

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.

In other words, a dispute package is not an extra deliverable. It is the final expression of a well-run reconciliation process. If the package is weak, the monthly workflow upstream is usually weak too.

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

Spreadsheets are still enough for some publishers. If the partner mix is small, the statements are predictable, the team can tolerate manual cleanup, and disputes are infrequent, a well-designed ledger plus a disciplined month-end checklist can be completely adequate. The failure point is not the spreadsheet itself. It is the amount of document normalization the spreadsheet is being asked to absorb.

An extraction layer makes sense when the statement-ingestion step is what keeps breaking the process. That is usually the case when partner files arrive in mixed formats, column names drift, PDFs have to be re-keyed, or the same team is handling multiple monetization workflows at once. In that middle ground, the goal is not a full revenue-intelligence stack. The goal is to turn messy documents into structured rows fast enough that finance and AdOps can spend their time on variance analysis instead of transcription.

That is the narrow, credible role for Invoice Data Extraction. Its prompt-based workflow converts financial documents into structured XLSX, CSV, or JSON output, supports large mixed-format batches, and also offers an API for teams that want to plug extraction into a broader pipeline. That makes it a practical fit when the reconciliation model already exists but the incoming documents are still too inconsistent to feed it cleanly by hand.

Full revenue-ops platforms such as Adomik, Staq, Tercept, or Pubstack are better fits when the publisher needs broader monitoring, centralized dashboards, deeper connector coverage, and non-technical workflows across a larger organization. Those tools solve a wider operating problem. They also come with a different implementation and cost profile than simply fixing document ingestion.

The dividing line is usually operational maturity, not publisher size alone. A smaller team with ten messy partners and frequent manual adjustments may feel the ingestion problem before it feels the dashboard problem. A larger team with stable connectors and a warehouse may be past document cleanup, but still need stronger monitoring, alerting, and cross-platform visibility. That is why build versus buy is the wrong frame if it collapses everything into one decision. The better question is which layer of the process is actually breaking.

The clean decision rule is this: if your biggest pain is analysis and cross-platform visibility, buy a fuller platform. If your biggest 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.