DV360 Invoice Reconciliation: Billing Report Walkthrough

DV360 invoices stack five fee components: Media Cost, Platform Fee, Platform Add-On Fee, Data Fees, and Third-Party Fees. The last two were split out from a unified "Other Fees" line on invoices issued from October 2024 onward, so any third-party walkthrough that still describes a four-component stack is partially out of date. DV360 invoice reconciliation joins the monthly PDF invoice to the Billing Report Template on Insertion Order ID and billing period, then walks each fee component when totals don't tie.

The work happens in two artifacts. The invoice arrives as a PDF, downloaded from the DV360 UI under Billing or pulled programmatically through advertisers.invoices.list. The Billing Report comes out of DV360 → Insights → Offline Reporting as a CSV with a column per fee component. Both have to end up in spreadsheet form before any join is possible, which means the PDF has to be extracted into structured line items keyed by IO before the report's daily-granularity rows can roll up against it.

When the totals don't tie, the variance almost always lives in two places: data-fee segment timing (third-party audience providers post their usage to DV360 days after the impression) and third-party verification-fee posting timing (IAS, DoubleVerify, and similar partners push fees through DV360 on their own invoice cycles). Most $500–$2,000 monthly discrepancies are timing artifacts, not errors. The reconciliation's job is to identify which artifact each variance is and either accept it, accrue it to the right period, or escalate it.

This article walks the workflow end to end: the anatomy of each fee component, the exact path to the Billing Report Template, the extraction step that turns the PDF into a joinable spreadsheet, the three-part join key and the daily-versus-monthly granularity gotcha, a worked example of a $1,200 variance traced through the fee stack, the advertisers.invoices.list route for advertisers running enough entities to justify automation, and the multi-entity rollup pattern for monthly close. The Display & Video 360 invoice reconciliation steps are the same whether you're a single in-house programmatic team or an agency closing DV360 across a roster of clients; only the scale changes.

The five fee components on a DV360 invoice

A current DV360 invoice carries five distinct fee lines. Each appears as its own line item on the PDF, each has a corresponding column on the Billing Report Template, and each has its own variance profile.

Media Cost is the impressions purchased on publishers' inventory. It is the largest line item on most invoices by an order of magnitude, often 80–90% of Billable Cost. The money flows through DV360 to the publisher (or to the SSP that auctioned the inventory). On the report it surfaces as the Media Cost column.

Platform Fee is Google's percentage take for running the DV360 auction, targeting, and serving infrastructure. It is calculated as a deterministic percentage of Media Cost, set in the advertiser's billing profile. Because it derives algorithmically from media cost, it almost never causes variance on its own; if Platform Fee is off on the report, Media Cost is the upstream cause. It surfaces as the Platform Fee column.

Platform Add-On Fee covers opt-in DV360 features that Google charges separately for: the Advanced Creative Fee for dynamic and rich-media formats, the Seller ID Blocklist Fee for inventory-quality controls, and the App Mediation Partners Fee for in-app inventory routed through mediation networks. These appear only when the advertiser has opted in, and the rates differ from the base Platform Fee. On invoices issued from October 2024 onward, Platform Add-On Fees appear as their own column on the report and their own line on the invoice.

Data Fees are the per-impression charges from third-party audience data providers — LiveRamp, Lotame, Oracle Data Cloud, Adobe Audience Manager, and similar segments licensed through DV360's audience marketplace. The provider charges per impression where the segment was used. Data fees are a classic source of monthly variance: providers post their segment usage to DV360 with their own latency, so a segment used on the 28th may post on the 2nd of the next month and land on next month's invoice instead. The column is Data Fees.

Third-Party Fees are verification, brand-safety, and ad-serving costs from partners DV360 routes through its billing — Integral Ad Science (IAS), DoubleVerify, Shoplocal, and others. Like data fees, they lag because the verification partner's invoice cycle and DV360's billing cycle don't synchronize cleanly; a verification fee for impressions late in a month may not surface until the next DV360 invoice. The column is Third-Party Fees.

The October 2024 split is what makes a current article necessary. Google's Display & Video 360 fees and billable cost reference confirms that on Display & Video 360 invoices issued from October 2024 onward, the single line item labeled "Other Fees" was split into Platform Add-On Fees and Third-Party Fees as separate invoice line items. Older third-party content describing a four-component stack with a unified "Other Fees" line is reconciling to a fee schema that no longer matches the invoice.

Two other quantities round out the document. Refunds & Adjustments appear as their own line on the invoice and reduce the amount payable; the most common driver is invalid-traffic refunds, which DV360 processes on a delay. Taxes and surcharges sit downstream of Billable Cost and don't appear on the report. They are calculated from the totals, not reconciled against report rows.

DV360's umbrella term for the invoice's reconcilable subtotal is Billable Cost: the sum of all five fee components. Aggregate Billable Cost on the Billing Report should equal Invoice Total minus Refunds & Adjustments minus Taxes. That is the single arithmetic identity the rest of this workflow exists to prove.

Running the Billing Report Template that matches your invoice

The DV360 Billing Report Template is the report the rest of the reconciliation joins against. It exists as a Standard report specifically built for invoice matching, and it is the right tool for this job. Custom reports can produce columns that look similar but won't map cleanly to the invoice fee components — column-mapping mismatches between custom report output and the invoice line structure are a common source of false variance.

The path is DV360 → Insights → Offline Reporting → Standard reports → "Billing Report". From the Standard reports list, select Billing Report, set the date range to match the invoice's billing period (not the calendar month — the two often differ by a few days), and run. The report can be returned at campaign level or Insertion Order level depending on selection. Insertion Order level is what reconciliation against an invoice grouped by IO needs.

The output structure mirrors the invoice. Each row represents an Insertion Order (or campaign rolled up across IOs, if that's the level selected) for a given day in the date range. Columns include Insertion Order ID, Cost Type, and one column per fee component — Media Cost, Platform Fee, Platform Add-On Fee, Data Fees, and Third-Party Fees — plus a Billable Cost column that sums the fee columns for that row.

The reconciliation arithmetic on this side is straightforward. Aggregate Billable Cost on the report — summed across all rows for the billing period — should match Invoice Total minus Refunds & Adjustments minus Taxes. Refunds & Adjustments are themselves a line on the invoice that reduces the payable amount; subtract them before comparing. Taxes are calculated downstream of Billable Cost and don't appear on the report at all, so they are subtracted from the invoice side rather than added to the report side.

Not every user has direct access to Offline Reporting. DV360 billing-profile setups vary — some agency holding companies provision client logins without report permissions, and finance ops at advertisers sometimes inherit invoice access without report access. For users in that situation, Google's billing team accepts requests directly: email [email protected] with the advertiser ID, billing profile, and billing period, and the team returns a billing report within a 48-hour SLA. This route is documented in DV360's help articles but rarely surfaced in third-party workflow content, and it is the right answer when the report-access barrier would otherwise block the close.

Turning the monthly PDF into a joinable line-item spreadsheet

The Billing Report comes out as CSV. The DV360 invoice arrives as a PDF — a 10–30 page document with line items grouped by Insertion Order under each campaign, with sub-rows for each fee component within an IO and a billing-period subtotal at the bottom of each campaign block. A CSV cannot be joined to a PDF. The reconciliation can't move forward until the invoice's line items become rows in a structured spreadsheet, with one row per IO + cost type combination and columns for Insertion Order ID, billing period, cost type, fee component, and amount. That column shape is what the join key against the Billing Report requires.

The default workflow at small scale is manual: open the PDF, type the IO ID, the cost type, the amount into a spreadsheet, repeat for every line item. It works for one or two advertiser entities a month. It scales badly — a 25-page invoice with sixty IOs and five fee components per IO is three hundred line items to transcribe, and the typos in that transcription introduce variance the reconciliation then has to chase. An IO ID mistyped by a single digit on the invoice side won't match the report; the reconciler spends an hour finding a discrepancy that isn't real.

This is the operational gap every other DV360 reconciliation walkthrough skips. Google's docs say "create a billing report and compare to your invoice." The agency blogs explain what each fee means. None of them describe how the PDF becomes a comparable artifact, because the PDF-to-spreadsheet step sits outside the DV360 workflow proper. It is also where the fee-transparency context lands. Industry attention to DSP fee structures — the K2 transparency report, the Publicis-commissioned audit of TTD that established the effective take-rate calculation now standard for TTD statement reconciliation — has raised the bar on advertisers' ability to defend each fee line to a client or an internal auditor. Without an extracted, structured spreadsheet of invoice line items, fee-line audit isn't possible. You can compare totals; you can't audit a Data Fees line that exists only inside a PDF.

That precondition is where AI invoice data extraction for programmatic media bills earns its place in this workflow, and it's a step that applies broadly across ad-platform invoices — the same PDF-to-spreadsheet pattern is what Meta Ads invoice download and reconciliation walks through for Meta's billing. The interaction model is the same as a modern AI tool: upload the DV360 PDF (or a batch of them), describe the columns the reconciliation needs in a natural-language prompt, and download an Excel, CSV, or JSON file with one row per line item.

For DV360 specifically, the prompt names the columns directly. Something on the order of:

Extract one row per invoice line item. Columns: Insertion Order ID, Insertion Order Name, Billing Period, Cost Type, Fee Component (one of: Media Cost, Platform Fee, Platform Add-On Fee, Data Fees, Third-Party Fees), Amount, Currency. Skip cover pages and summary totals. Format Billing Period as YYYY-MM.

The output is a spreadsheet keyed by IO + Cost Type + Fee Component, ready to join against the aggregated Billing Report. The same prompt processes a single invoice or a batch of up to six thousand documents — the multi-advertiser-entity rollup later in this article relies on that consistency, because each entity's PDF runs through the same prompt and produces rows that stack cleanly into a consolidated workbook. Rows in the output also carry a reference back to the source file and page number, which is what makes a fee-line audit defensible: every amount on the spreadsheet traces back to a specific page of a specific invoice.

A prompt that names the current fee components also absorbs schema shifts cleanly: when DV360 split "Other Fees" into Platform Add-On Fees and Third-Party Fees in October 2024, an extraction prompt referencing those names by their current labels needed no maintenance to follow the change.

The Insertion Order join key and the daily-versus-monthly gotcha

With both sides in spreadsheet form, reconciling DV360 invoice with reporting comes down to a join. The key is three parts: Insertion Order ID + Billing Period + Cost Type. Joining on Insertion Order ID alone produces duplicates on the report side, because a single IO often has multiple Cost Type rows (Media Cost, Platform Fee, Data Fees each appear as separate rows when the report is in long format). All three parts are necessary to land each invoice line on exactly one report row.

The column mapping is direct. On the extracted invoice spreadsheet, the Insertion Order ID column maps to the report's Insertion Order ID. The invoice's Cost Type column maps to the report's Cost Type. The invoice's Billing Period — typically the invoice issue month, in YYYY-MM format — maps to the report's date column aggregated to that same month.

The mismatch that catches first-time reconcilers is granularity. The invoice rolls up to billing-period totals: one row per IO + Cost Type per month. The Billing Report can come back at daily granularity by default: one row per IO + Cost Type per day in the date range. A naive VLOOKUP from invoice rows into the report will land on the first matching daily row and miss every other day's contribution. The totals don't tie not because of a real variance but because the lookup undercounted.

The fix is to aggregate the report to billing-period granularity before joining. In Excel, a SUMIFS across the Billable Cost column grouped on Insertion Order ID, Cost Type, and the months in the billing period works for one or two entities. In a query layer (BigQuery, Looker Studio, a spreadsheet pivot), GROUP BY Insertion Order ID, Cost Type, with SUM(Billable Cost) filtered to the invoice's billing period gives the same result more cleanly. Either way, the report's daily rows collapse to one row per IO + Cost Type for the period, matching the invoice's granularity.

There's a second column mapping subtlety worth noting. The report's Billable Cost column is the sum of the per-fee-component columns for that row. Reconciling at the per-fee-component level — Media Cost, Platform Fee, Platform Add-On Fee, Data Fees, Third-Party Fees individually — means joining on the fee component column rather than the aggregated Billable Cost. The extraction in the prior section produced one row per IO + Cost Type + Fee Component on the invoice side, which lines up with the report's long-format per-fee rows. If the report came back in wide format (one row per IO + Cost Type per day with a column per fee), unpivot it before joining.

A concrete example. After aggregation, a single Insertion Order shows the following on each side for the April 2026 billing period:

Fee Component	Invoice	Report
Media Cost	$4,800	$4,795
Platform Fee	$720	$720
Platform Add-On Fee	$0	$0
Data Fees	$240	$240
Third-Party Fees	$80	$75
IO Total	$5,840	$5,830

Two variances surface: Media Cost is off by $5, Third-Party Fees is off by $5. The IO total is off by $10. Both are below any reasonable error threshold for a single IO, but across the sixty or more IOs on a typical enterprise invoice the same per-IO drift compounds into a high-three-figure or low-four-figure discrepancy that finance won't post.

Walking a $1,200 variance across the fee stack

Take a single April 2026 invoice with Invoice Total minus Refunds & Adjustments minus Taxes equal to $82,000. The aggregated Billing Report shows $83,200 in Billable Cost for the same period. The report is $1,200 higher than the invoice. Most third-party content treats this as a binary check: totals tied or didn't. The DV360 invoice variance investigation that actually closes the month is a fee-component drill-down ranked by where variance most often hides, not a checklist.

The order to drill is the order of variance probability, highest to lowest.

Media Cost variance — usually reporting-window-versus-invoice-window timing. The single most common cause of an invoice-versus-report mismatch is that the report was run for the calendar month while the invoice covers an issue month with slightly different start and end dates. DV360's billing cycle aligns with calendar months for most billing profiles but not all; invoice-issue dates can shift by a day or two when month-end falls on a weekend or holiday. The fix is to re-run the report for the exact date range printed on the invoice header — not the calendar month. Frequently the entire variance lives here. In our worked example, re-running the report for the invoice's actual range — March 31 through April 30 rather than April 1 through April 30 — moves the report Media Cost down by $850. The variance drops from $1,200 to $350.

Platform Fee variance — almost never the source. Platform Fee is calculated as a deterministic percentage of Media Cost from the billing-profile rate. If Platform Fee on the report doesn't match the invoice, it's because Media Cost upstream didn't match — find that variance, and the Platform Fee follows. In the worked example, after the Media Cost reporting-window fix, Platform Fee on both sides matches at $11,400. No further drill needed here.

Data Fee variance — segment usage timing on the data provider's side. The DV360 data fees vs third-party fees distinction matters here, because data fees and third-party fees lag for different reasons and the fixes differ. A third-party data provider posts segment usage to DV360 with its own latency. A LiveRamp segment used in impressions on April 28 may post to DV360 on May 2 and appear on May's invoice rather than April's. Equally, a segment for impressions on March 30 may have posted on April 1 and landed on April's invoice — making the report (which reflects the impression date) and the invoice (which reflects the posting date) disagree. Identify the segment, check the provider's posting timestamp, and decide whether to accrue: if the impression date is in April and the segment is on May's invoice, the right move is to accrue the cost to April even though it hasn't billed. In the worked example, $250 of the remaining $350 is a Lotame segment that posted late and will appear next month — accrual to April handles it. Variance now $100.

Third-Party Fee variance — partner posting timing. Verification and brand-safety partners surfaced through DV360 — IAS, DoubleVerify, Shoplocal — push their fees through DV360 on their own invoice cycles. A DoubleVerify charge for impressions on April 30 may not land on DV360's invoice until May or June. The mechanism is the same as data fees, the fix is the same: identify the partner, check the partner's invoice cycle, accrue rather than chase. In the worked example, $100 is an IAS verification fee for late-April impressions that will hit May's invoice. Accrue to April. Variance now $0.

Invalid traffic refund timing — the variance that runs the other way. DV360 refunds invalid traffic (IVT) on a delay; an IVT refund processed in early May for impressions in April reduces the May invoice for April-period impressions. If your reconciliation flagged an invoice running lower than the report, IVT timing is the likely cause — confirm refunds appear in the right month's adjustment column on both the invoice and the report. This isn't relevant to our $1,200 example (the report was higher than the invoice, not lower), but the pattern is worth knowing for the months when the direction flips.

The $1,200 in the worked example resolves as: $850 Media Cost reporting-window timing (fix the date range), $250 Data Fee segment timing (accrue to April), $100 Third-Party Fee posting timing (accrue to April). Zero of the variance is an actual error. All of it is timing.

That is the underlying lesson worth holding on to. Most monthly DV360 variance is timing, not error. The reconciliation's job is to attribute each variance to its timing source and decide whether to accept it (on a small dollar amount within tolerance), accrue it to the correct period (so finance posts the right number this month and the next month's invoice ties out), or escalate it to Google or a partner (when the variance is unattributable and persists across investigation). Treating every variance as an error and bouncing the invoice back to Google's billing team wastes a week and earns nothing — Google's response will identify the same timing artifact you could have found in an hour with the report drilled to the IO + Cost Type + Fee Component level.

Pulling invoices programmatically with advertisers.invoices.list

Manual invoice download from the DV360 UI works fine when you operate one to three advertiser entities. Above that, every month's close starts with ten or more PDFs to download, save, rename, and feed into the extraction step — a chore that justifies the engineering setup of the DV360 advertisers.invoices.list api route. The honest break-even is around ten advertiser entities. Below that, the UI download is the right answer; above it, the API pays back its setup cost within two or three close cycles.

The endpoint is advertisers.invoices.list, scoped to a single advertiserId. The required parameter is issueMonth, which must be in YYYYMM format and corresponds to the month the invoice was issued, not the period the invoice covers. DV360 issues invoices early in the month following the service period, so the invoice covering April 2026 impressions is typically issued in early May 2026 and carries issueMonth=202605. The same convention holds for adjustments and reissues: the issue month of the document is what the API filters on, not the period of the underlying spend.

The response returns a list of Invoice objects. Each Invoice carries metadata — invoice ID, issue date, total amount, currency, billing-profile reference — and a pdfUrl field with a pre-signed URL to the PDF. The PDF is the same document a user would download from the UI, with the same five-fee-component layout and the same line-item structure. From there, the extraction step from earlier in this workflow runs identically: feed the PDF into a prompt that produces one row per IO + Cost Type + Fee Component.

The pdfUrl has a 7-day TTL. The pre-signed URL is valid for seven days from generation, then expires. Operationally this means pull and store: fetch the PDF immediately when the list call returns, save it to your own object storage (S3, GCS, Azure Blob), and reference it from there going forward. Storing the pdfUrl itself and trying to fetch it later is a recurring failure mode — by the time the close runs the next week, the URL is dead. Bulk pulls running across many advertiser entities should download each PDF inside the same job that lists invoices, in a loop or with parallel requests, then close out the listing job once every PDF is local.

The API's Partner-billing-profile limitation is the gotcha that catches agency holding companies hardest. Invoices generated by billing profiles set to a Partner invoice level are not retrievable through advertisers.invoices.list. Many agency setups consolidate billing at the partner level — a single invoice at the holding-company partner covering all client advertisers underneath, rather than separate invoices per advertiser entity. In that configuration, the API returns nothing useful. The UI download (or the 48-hour [email protected] route from earlier in this article) is the only path. This limitation is mentioned in passing in the API reference but rarely surfaced in workflow content; agencies that build their close around advertisers.invoices.list and then migrate a client to Partner-level billing discover the gap mid-month-end. Check the billing profile's invoice level before scoping the automation.

Authentication is OAuth 2.0 via a Google Cloud service account with DV360 access provisioned for the advertiser. The Python and Node Google client libraries wrap the call cleanly; a working integration is fewer than fifty lines once authentication is in place.

Rolling up across entities, B-Con, and the Google Ads boundary

DV360 advertisers operating multiple entities — typically one entity per region (US, EMEA, APAC) or one per brand within a holding company — receive one invoice per entity. A US national retailer running ten brand-specific advertiser entities receives ten invoices each month, ten Billing Reports, and ten reconciliations. Treated entity by entity, the close is ten copies of the workflow above. Treated as a DV360 multi-advertiser invoice rollup, it collapses into a single consolidated workbook.

The pattern is to add an Entity column to the extracted line-item spreadsheet. The same extraction prompt that handled one PDF handles a batch of ten by including an instruction along the lines of "tag each row with the source filename's entity prefix." The output is a single line-item spreadsheet keyed by Entity + IO + Cost Type + Fee Component, ready to join against the Billing Report runs concatenated across all ten entities (the report can be filtered per-entity in DV360 and unioned in the spreadsheet). The variance investigation flow runs once across the consolidated dataset rather than ten times — and a variance pattern that crosses entities (the same Lotame segment posting late across all ten brands) becomes visible immediately when it would have hidden inside ten separate single-entity drills. The same logic applies more broadly to agency vendor bill allocation across clients and campaigns: the consolidation pattern is identical, and the entity column becomes the client-allocation key when the agency's books need cost split per client.

Google's open-source b-con (Billing Reconciliation) tool sits next to this manual workflow and is worth positioning honestly. B-Con is a developer artifact, published on GitHub under google/b-con. It calls advertisers.invoices.list and the Google Ads invoicing endpoint, joins the responses to reporting data via the DV360 Reporting API and Google Ads API, and produces a reconciliation output. For an engineering team with the bandwidth to deploy, host, monitor, and maintain a Python service against Google's APIs, B-Con is the right answer — the automation is sanctioned by Google, it handles the mechanics correctly, and the codebase is open source. For a finance or AP team without that engineering capability, B-Con isn't a finance tool; it's a service to deploy. The manual UI workflow combined with prompt-driven PDF extraction is what closes the month for that audience. Both answers are legitimate; the question is which one matches the team that owns the close.

The DV360 vs Google Ads invoice question comes up often enough to address directly: they are distinct billing systems with distinct reconciliation. The Google Ads API does not return DV360 data, and advertisers.invoices.list does not return Google Ads data. An advertiser running both runs two reconciliations on two invoices through two workflows. The fee anatomy differs — Google Ads has its own fee structure with no direct equivalent to Platform Add-On Fees. The reporting tools differ — Google Ads pulls billing reports from its own UI under Billing & payments, not from DV360's Offline Reporting. The join keys differ — Google Ads's join is on Account ID + billing period rather than Insertion Order. A separate workflow walks Google Ads invoice to Excel and the InvoiceService API for advertisers who run both platforms.

For agencies, DV360 is one of many media-vendor invoices in the monthly close. Broadcast networks, OOH placements, digital direct buys, other DSPs (The Trade Desk, Amazon DSP), and SaaS vendors all sit alongside DV360 in the AP queue. For marketing finance teams that need to tie DV360 alongside Google, Meta, LinkedIn, TikTok, and other DSP invoices into a single month-end variance flow, the cross-platform ad spend close pattern walks the consolidated schema and timezone-resolution mechanics. The DV360 reconciliation walked here is the DSP-specific layer; the broader pattern of media buying invoice reconciliation across broadcast and digital is its own discipline, with its own join keys, its own variance profiles, and its own delivery-versus-billing reconciliation model. Agencies serious about defending every line item to clients run the DV360 workflow inside the broader media reconciliation framework, not in isolation.