Google Ads Invoice to Excel: Bulk Extraction & API Guide

Converting a Google Ads invoice to Excel has four working routes, and the right one depends entirely on whether you run one account or a manager hierarchy covering hundreds.

1. Native download from Billing → Documents — one PDF per month per account, downloaded by hand, then parsed or keyed into a spreadsheet.
2. The 2026 Google Ads Billing report — an in-product export to CSV, Excel, or PDF with line-by-line account, campaign, usage, and payment detail.
3. The Google Ads API InvoiceService — returns a short-lived pdf_url for each invoice issued under a consolidated billing setup, suitable for scripted retrieval.
4. An MCC bulk extraction pipeline — InvoiceService paired with a PDF extraction API that turns every downloaded invoice into structured JSON or Excel across dozens to thousands of sub-accounts.

Paths 3 and 4 only work if the Google Ads account is on monthly invoicing (consolidated billing). Accounts on automatic credit-card or manual-payment billing never generate the tax invoices that InvoiceService exposes, so the API simply has nothing to return for them. If you're unsure, check the payment setting under Billing → Settings before committing to an API build.

One disambiguation before the chooser: this article covers Google Ads monthly invoices, the ones an advertiser receives for clicks and impressions bought on Search, Display, YouTube, and Performance Max. It does not cover Google Ad Manager — the publisher-side platform where a site owner is paid out for inventory sold. Ad Manager billing uses a different document, a different API surface, and a different finance workflow.

Which path fits you:

• Path 1 — manual download. Right answer when you run a single advertiser account, receive a handful of invoices a month, and the finance team is content to open a PDF and type or copy-paste. No engineering, no API access, no credits.
• Path 2 — 2026 Billing report. Right answer for single-advertiser reconciliation when you need campaign- and usage-level detail in a spreadsheet and can live with Google's fixed schema. Built into the UI; no engineering. Note upfront that the report is a billing activity export, not a copy of the invoice document itself — the distinction matters for reconciliation and is covered in Path 2 below.
• Path 3 — InvoiceService API. Right answer for finance-ops or analytics engineers with one or a few consolidated billing setups who want invoices pulled on a schedule into storage or a data warehouse. Light-to-moderate engineering: OAuth, a developer token, a loop over list_invoices, and handling of the expiring pdf_url. You still get a PDF at the end; parsing it is a separate problem.
• Path 4 — MCC bulk extraction pipeline. Right answer for agencies and large advertisers running a manager (MCC) account over dozens to thousands of sub-accounts, where the end state is structured data in an ERP, a BI tool, or a client-billing system — not a folder of PDFs. Moderate engineering, because the pipeline combines InvoiceService retrieval with prompt-driven extraction that can carry custom fields (client code, cost-centre, margin markup) the native report cannot produce.

Path 1 — Downloading Each Invoice Manually from Billing → Documents

Inside a single Google Ads account, the invoice lives at Tools → Billing → Documents. Open the account, click the Tools icon in the left navigation, expand Billing, and select Documents. Each finalized monthly invoice appears as a row in that table with a download link for the PDF.

Two separate files post for each billing period, and they are not interchangeable. The PDF statement is the formal tax invoice, the document your AP team posts to the ledger and files for audit. The monthly cost report CSV is a campaign-level cost breakdown Google provides alongside the statement, useful when you need to reconcile platform-reported spend line by line but not acceptable as the invoice itself. The PDF is laid out for human reading, with totals, tax lines, and account identifiers rendered as a printable document. It is not a spreadsheet-shaped artifact. Opening it in Excel gets you a page of wrapped text, not a table you can pivot, sum, or feed into a journal entry.

Timing is the first thing to get right. Google releases each month's invoice into the Documents section around the 5th business day of the following month, once billing for the prior period has been finalized. If your close calendar has AP posting vendor invoices by the 3rd business day, the Google Ads invoice is not yet there to post. Month-end procedures for Google Ads spend need to accommodate that release window, either by accruing the estimate from the cost report and truing up when the PDF arrives, or by shifting the Google Ads posting step later in the close.

This path is enough when the conditions are narrow: one advertiser, one Google Ads account, one invoice per month, and a finance process that accepts the PDF as-is for filing. A small business running its own paid search can live here indefinitely.

It stops being enough the moment any of the following is true. You manage an MCC covering multiple sub-accounts and need to download invoices for each one. You are reconciling invoiced amounts against platform-reported spend and need the line items in rows and columns, not prose. You are loading billed amounts into an ERP such as NetSuite, Xero, or SAP. You are allocating spend to client sub-ledgers at an agency and need per-campaign or per-client splits posted as separate journal lines.

The blocking constraint is structural. The Documents view is scoped to a single account, and the download is one file at a time, one month at a time. There is no multi-select, no bulk export across accounts, no API surfaced in this screen. An agency managing 40 client accounts is looking at 40 navigations and 40 downloads every month, and twice that if they also pull the cost report CSV. At 400 accounts it is not a workflow, it is a full-time task. That arithmetic, not any weakness in the UI itself, is why the next three paths exist.

Path 2 — Exporting the 2026 Google Ads Billing Report

For years, the only tabular view of Google Ads spend came from cost reports that reconciled badly against the PDF invoice — different date logic, different rounding, different account grouping. That changed at the start of 2026. According to PPC Land's reporting on Google's January 2026 Billing report launch, Google launched a new Billing report inside Google Ads on January 26, 2026 that gives a line-by-line breakdown of invoices by account, campaign, usage, and payment and exports to CSV, Excel, and PDF, framed by Google as a fix for the long-standing reconciliation gap between marketing and finance teams.

What the Billing Report Actually Surfaces

The report lives inside the Google Ads UI under the Billing section and renders monthly spend as a table rather than a static document. Each row ties a spend line to four reconciliation columns:

• Account — the sub-account the spend posted against, useful for MCC operators splitting costs across clients.
• Campaign — the campaign the cost rolled up from, enabling campaign-level cost allocation without a separate cost report join.
• Usage — the period the spend covers, which is the field that most often explains discrepancies between the invoice and the platform-reported cost.
• Payment — the payment instrument and transaction that settled the line, including credits, adjustments, and tax components.

This is the first time a native Google Ads screen shows the invoice's internal structure in rows rather than burying it inside a PDF. Compared with Path 1, the difference is substantive: the PDF statement forces OCR or manual transcription to recover the same fields, while the Billing report hands them over as structured data.

Choosing an Export Format

All three export formats cover the same underlying rows; the choice is about what happens next:

• CSV — best for analytics ingestion, BigQuery loads, and pandas pipelines. Stable column headers, no merged cells, no formatting baggage.
• Excel — best for finance team review. Comes with the native filter, sort, and pivot affordances that AP and controllers already use for month-end.
• PDF — best as a filing copy attached to the workpapers. It is a report export, not the legal invoice.

That last distinction matters. The Billing report is a reconciliation view of the billing data, not the invoice document itself. It sits alongside the PDF statement from Path 1, not in place of it. For vendor-bill posting, tax documentation, and audit trails, the legal PDF remains the source of record.

Where the Billing Report Still Falls Short

For a single-advertiser finance operator reconciling one account against one invoice, the 2026 report may be the end of the workflow. For everyone else, the gaps are real and worth naming before you invest time in it:

• Regional availability is incomplete. The report is rolling out by market and is not live in every country where Google Ads bills. Agencies with accounts in newer or smaller markets will see it for some invoices and not others.
• Data gaps follow payment profile transitions. Accounts that migrated billing profiles mid-period, consolidated under a new MCC, or switched between monthly invoicing and automatic payments can show incomplete rows for the transition month. The invoice is right; the report is partial.
• The schema is fixed. There is no prompt-driven column derivation. You cannot ask the report for a client name parsed from the account descriptor, a campaign family grouped from naming conventions, or a cost category mapped from campaign to GL code. What you see is what you get.
• There is no direct ERP integration. QuickBooks, Xero, NetSuite, Sage Intacct — none of them consume the Billing report export natively. You still own the CSV-to-ERP plumbing, the vendor mapping, the GL coding, and the duplicate-posting guards.
• It does not replace the legal PDF invoice. ERP vendor-bill posting, tax filings, and audit trails all require the PDF invoice as the document of record. The Billing report is supporting detail, not a substitute.

The honest summary: the Billing report meaningfully improved single-advertiser reconciliation and gave finance teams a tabular view they did not have before. It did not obsolete extraction pipelines for agencies allocating cost across many clients, for MCC operators processing hundreds of invoices monthly, or for anyone routing invoice data into an ERP as a posted vendor bill. Those readers need Path 3 or Path 4.

Path 3 — Pulling Invoices Programmatically with the Google Ads InvoiceService API

The Google Ads InvoiceService API is the right tool when you need to pull invoices via the Google Ads API on a schedule, across months, and in volume. Before writing a line of code, confirm one prerequisite that quietly disqualifies most accounts: InvoiceService only returns data for accounts on monthly invoicing (consolidated billing). If the account pays by automatic credit-card charge, there is no Invoice resource to fetch, period. Monthly invoicing is a credit arrangement with Google that the advertiser has to request and qualify for. If your account is not already on it, this path is closed until billing terms change.

Assuming you are on monthly invoicing, the auth surface is the same one you already use for reporting: a developer token, OAuth2 client ID and secret, and a refresh token tied to a user who can see the billing setup. Nothing new to provision.

The ListInvoices Call Shape

InvoiceService.ListInvoices takes four required fields:

• customer_id, the billing account under which the invoices are issued.
• billing_setup, the full resource name of the billing setup, for example customers/1234567890/billingSetups/9876543210.
• issue_year, a four-digit year as a string.
• issue_month, the month enum (MARCH, APRIL, etc.).

The call returns the invoices issued for that one month. Pick the month, get the invoices — there is no date range, no pagination cursor to babysit.

Consolidated-Billing Return Shape

This is the non-obvious part. Under a consolidated billing setup that covers many sub-customers (the common MCC case), ListInvoices returns one Invoice resource per underlying customer in a single response. If 40 sub-accounts rolled up into that billing setup for March, one call returns 40 Invoice resources. Callers who loop per-customer-id expecting one invoice each are doing redundant work and, worse, are likely to miss that the billing-account-level call already has everything. Call once per billing setup per month, then iterate.

The pdf_url Download Protocol

Each Invoice resource carries a pdf_url field. Three things about it:

1. It is short-lived. Treat it as a fetch-now URL, not a stable identifier. Do not persist it to a database and retry the download tomorrow; grab the bytes in the same run that called ListInvoices.
2. It requires an authenticated GET. A plain curl with no headers returns a 401. Send an Authorization: Bearer <access_token> header using the same OAuth2 access token the Google Ads client is holding.
3. The bytes are the same PDF that appears in Billing → Documents in the UI. No watermark, no variant.

Python

from google.ads.googleads.client import GoogleAdsClient
import requests

client = GoogleAdsClient.load_from_storage("./google-ads.yaml")
invoice_service = client.get_service("InvoiceService")

response = invoice_service.list_invoices(
    customer_id="1234567890",
    billing_setup="customers/1234567890/billingSetups/9876543210",
    issue_year="2026",
    issue_month=client.enums.MonthOfYearEnum.MARCH,
)

access_token = client.credentials.token
for invoice in response.invoices:
    pdf = requests.get(invoice.pdf_url, headers={"Authorization": f"Bearer {access_token}"})
    with open(f"./invoices/{invoice.id}.pdf", "wb") as f:
        f.write(pdf.content)

Node

import { GoogleAdsApi } from "google-ads-api";
import fs from "fs/promises";

const client = new GoogleAdsApi({
  client_id: process.env.GOOGLE_ADS_CLIENT_ID,
  client_secret: process.env.GOOGLE_ADS_CLIENT_SECRET,
  developer_token: process.env.GOOGLE_ADS_DEVELOPER_TOKEN,
});

const customer = client.Customer({
  customer_id: "1234567890",
  refresh_token: process.env.GOOGLE_ADS_REFRESH_TOKEN,
});

const { invoices } = await customer.invoices.list({
  billing_setup: "customers/1234567890/billingSetups/9876543210",
  issue_year: "2026",
  issue_month: "MARCH",
});

const accessToken = await customer.getAccessToken();
for (const invoice of invoices) {
  const pdf = await fetch(invoice.pdf_url, {
    headers: { Authorization: `Bearer ${accessToken}` },
  });
  await fs.writeFile(`./invoices/${invoice.id}.pdf`, Buffer.from(await pdf.arrayBuffer()));
}

Once the PDFs are saved, the next step is extracting invoice data with Python to turn each PDF into structured rows — line items, tax, totals, currency, invoice and service periods.

Path 4 — MCC Bulk Extraction into Structured Excel and JSON

Path 3 gave you one PDF at a time. Path 4 is the shape you actually need if you run an MCC: every sub-account's invoice for the month, parsed into rows that match your chart of accounts, landed in a place finance can query. The pipeline is five steps, and most of the engineering is in the glue between Google Ads and the extraction step.

Step 1: Enumerate the manager hierarchy. Under your manager customer ID, query the customer_client resource to list every sub-customer the MCC covers. This is the canonical way to bulk download Google Ads invoices for an agency footprint — you derive the customer set from the hierarchy itself rather than maintaining a hand-edited list of account IDs. A standard GoogleAdsService.SearchStream query against customer_client under the manager returns customer_client.id, customer_client.descriptive_name, and customer_client.manager for every account in the tree.

Step 2: Call InvoiceService.ListInvoices per billing setup at the consolidated level. If your MCC is on consolidated billing — which is the norm for agencies — one response returns every sub-customer invoice under that billing setup for the target issue_year and issue_month. You do not need a loop over sub-customers for the invoice call itself; one call per billing setup per month is often the whole fetch. This is what makes a Google Ads MCC invoice export tractable at agency scale: the consolidation is already done by Google, and your job is to fan out the resulting invoices.

Step 3: Download each pdf_url to a local directory. InvoiceService.ListInvoices returns metadata plus a pdf_url per invoice. Authenticate the GET with the same OAuth bearer token your Google Ads client uses and write the bytes to disk. A month-partitioned folder like ./invoices/2026-03/ keeps the layout predictable and lets you rerun a single month without disturbing the rest. The reason the PDFs must hit disk first is mechanical: neither the SDK nor the REST API for the extraction step accepts a remote URL — the extraction call reads a local folder.

Step 4: Hand the folder to the extraction step. This is where the Google Ads invoice parser problem stops being a per-PDF script and starts being one call. The folder of downloaded PDFs is then handed to an invoice data extraction platform that accepts a natural-language prompt and returns structured rows in Excel, CSV, or JSON. The platform is purpose-built for this shape — up to 6,000 files per batch session, and the same prompt produces the same column schema across every document in the job. That consistency is the specific gap between this path and pasting PDFs into a general-purpose AI tool: ChatGPT will parse one invoice well and drift on the next; a batch extractor holds the schema across the whole month. For the mechanics of running thousands of PDFs through a single extraction session, see our batch invoice processing API guide.

Step 5: Write the structured JSON into the destination system. JSON is the handoff shape into a warehouse, an ERP, or a spreadsheet ingestion job. Excel and CSV land in the same call for finance review. The destinations themselves are the next section; what matters here is that the extraction step produces all three formats from one invocation.

The prompt is where the agency custom columns live

A generic PDF-to-Excel tool gives you the fields that are printed on the invoice. That is not the shape finance wants. The printed "Account ID" on a Google Ads invoice is a ten-digit number; your chart of accounts wants a client name, a campaign family, and a cost category. Those are not on the PDF — they are derived from your naming conventions.

The prompt is where that derivation happens. A natural-language instruction like:

"Extract invoice number, invoice date, service period, account ID, account name, net amount, tax, and total. Derive a 'Client' column from the account name prefix before the first hyphen. One row per account on the invoice."

produces a table with the derived Client column populated from the account naming convention. The same pattern extends to campaign family (derive from a campaign prefix), cost category (classify from an internal taxonomy), or payment priority (conditional on net amount and client tier). This is the concrete shape of prompt-driven custom fields, and it is what separates a pipeline that automates Google Ads invoice processing from one that merely digitizes PDFs.

Choose output_structure="per_invoice" when you want one row per sub-account invoice — the typical finance-ops shape. Use "per_line_item" when you need one row per line item on the invoice (useful if you reconcile at the campaign-spend level rather than the account level). "automatic" lets the platform pick based on the prompt.

Pipeline shape in ~30 lines

from google.ads.googleads.client import GoogleAdsClient
from invoicedataextraction import InvoiceDataExtraction
import requests, os

gads = GoogleAdsClient.load_from_storage("./google-ads.yaml")
ide = InvoiceDataExtraction(api_key=os.environ["INVOICE_DATA_EXTRACTION_API_KEY"])
os.makedirs("./invoices/2026-03", exist_ok=True)

invoice_service = gads.get_service("InvoiceService")
response = invoice_service.list_invoices(
    customer_id="1234567890",
    billing_setup="customers/1234567890/billingSetups/9876543210",
    issue_year="2026",
    issue_month=gads.enums.MonthOfYearEnum.MARCH,
)
token = gads.credentials.token
for invoice in response.invoices:
    pdf = requests.get(invoice.pdf_url, headers={"Authorization": f"Bearer {token}"})
    with open(f"./invoices/2026-03/{invoice.id}.pdf", "wb") as f:
        f.write(pdf.content)

result = ide.extract(
    folder_path="./invoices/2026-03",
    prompt=(
        "Extract invoice number, invoice date, service period, account ID, "
        "account name, net amount, tax, and total. Derive a 'Client' column "
        "from the account name prefix before the first hyphen. One row per "
        "account on the invoice."
    ),
    output_structure="per_invoice",
    download={"formats": ["json", "xlsx"], "output_path": "./output"},
)

The shape is: Google Ads client loads, extraction client loads, invoices enumerate under one billing setup, PDFs land on disk in a month-partitioned folder, extract() handles the upload, submit, poll, and download in a single call. The download.formats list can include any combination of xlsx, csv, and json in one invocation, so the JSON you send to the warehouse and the XLSX you send to finance come from the same extraction run. API credits are shared with web usage, so there is no separate API plan to provision — the same account works for both.

One production note: the Google Ads OAuth token above is shown inline for shape. In a real pipeline, refresh it through the Google Ads client's credential object rather than capturing a single .token at script start, and keep the INVOICE_DATA_EXTRACTION_API_KEY in your secrets manager rather than the process environment of a long-running job.

---

What's Actually on a Google Ads Invoice (and Why Those Dates Disagree)

A Google Ads monthly invoice is a structured document with a predictable header, a per-customer cost breakdown, a credits block, and a tax block. The fields below are the ones finance needs to capture if the extracted data is going to survive a reconciliation meeting.

Invoice-Level Header Fields

Every Google Ads monthly invoice carries the same header fields, regardless of whether it belongs to a single billing account or a consolidated MCC.

• Invoicing entity. The Google subsidiary responsible for billing varies by country. UK-billed advertisers receive invoices from Google Ireland Limited; US-billed advertisers receive them from Google LLC; advertisers in India are billed by Google India Private Limited; Brazilian advertisers by Google Brasil Internet Ltda. The entity drives the tax ID, the registered address, and the tax treatment on the invoice.
• Billing account ID. The 10-digit identifier for the billing setup (format: XXX-XXX-XXXX). One billing account can cover multiple Google Ads customer IDs underneath it.
• Invoice number. Google's own sequential identifier for the document. This is the value AP should use as the vendor invoice reference.
• Invoice date. The date the invoice was issued by Google.
• Service period. The start and end dates of the calendar month during which the ads ran. Printed on the invoice as a date range, typically the first through the last day of a month.
• Tax ID. The VAT, GST, or equivalent registration number for the invoicing entity, and the advertiser's own tax ID where the jurisdiction requires it on the invoice face.
• Payment terms. Net-30 is the default on monthly invoicing, though the terms block states the exact due date.
• Billing currency. The currency in which the invoice is denominated and payable.
• Total before tax, tax amount, total. The three-line financial summary at the document level.

Line-Item Structure

The body of the invoice breaks spend by underlying Google Ads customer ID under the billing setup. For a direct advertiser with a single account, that is one cost row. For an MCC (manager account) on consolidated billing, the invoice lists one row per sub-customer for base ad spend, plus separate rows for taxes and credits. A 40-row consolidated invoice is 40 sub-customers inside one document, each typically one line per service period for the base ad spend.

Each line carries the customer ID, the customer name (the account label as it appears in the Google Ads UI), the service period, and the cost. Any extraction that collapses these into a single invoice-total row discards the per-account detail finance needs for cost allocation.

Ad-Account Currency vs Billing Currency

An ad account can transact in a currency different from the billing currency. A UK-billed advertiser running a USD-targeting account is a common case: the account is set up in USD inside Google Ads, the ads are served and clicks are charged in USD, but the billing account is GBP, so the invoice is denominated in GBP.

On the invoice, the per-account cost breakdown often shows the ad-account currency figure alongside a converted billing-currency figure, and only the billing-currency figure feeds the invoice total. This is the single most common source of "why doesn't my invoice match my platform spend" confusion. The Google Ads UI reports Cost in the ad account's own currency at the conversion rates applied in-platform. The invoice applies Google's end-of-period conversion to produce a billing-currency figure. The two numbers will not tie to the penny, and the gap widens as the FX rate moves across the month.

Promotional Credits

Promotional credits — activation credits, Google-issued goodwill credits, coupon redemptions — are listed separately from the per-account cost breakdown, typically as a line near the bottom of the invoice above the tax block. They reduce the invoice total. They do not reduce the per-account Cost figure that the Google Ads UI reports.

The implication for AP is direct: a reader treating platform Cost as the amount owed will miscalculate AP by exactly the credit amount. A structured extraction must capture credit lines as their own rows, tagged as credits, so that invoice total equals sum-of-account-costs minus credits plus tax.

Service Period vs Invoice Date vs Charge Date

Three dates appear on or around every Google Ads invoice, and they disagree by design.

• Service period. The calendar month the ads actually ran. March 1 to March 31 for a March invoice.
• Invoice date. Typically the 1st or 2nd business day of the following month, when Google issues the invoice. For a March service period, expect an April 1 or April 2 invoice date.
• Charge date. When payment is due or settled, driven by credit terms. Net-30 on an April 2 invoice date puts the charge date at May 2.

Which date goes into the general ledger depends on what is being posted. The service period is the expense-period posting date — March ad spend belongs in the March P&L regardless of when the invoice arrives. The invoice date drives AP aging and is the document date on the payable. The charge date is a cash-flow event and the settlement date on the bank reconciliation. Posting the invoice date as the expense-period date pushes March spend into April, which is the single most common close-cycle error on platform invoices.

Regulatory Tax Lines

Regulatory taxes — VAT, GST, digital services tax, and country-specific equivalents — appear as separate line items in the tax block. The applicable rate and the specific tax type depend on the invoicing entity and the customer location: a UK customer billed by Google Ireland sees VAT under the reverse-charge mechanism with a 0% rate and a reverse-charge note; an Indian customer sees GST with IGST, CGST, or SGST components depending on the state. Digital services taxes apply in jurisdictions that have enacted them and appear as their own line where they apply.

The complexity is real and varies per advertiser. For structured extraction, the rule is simple: preserve each tax line as a distinct row with its rate, type, and amount, rather than rolling them into a single net figure. Rolled-up tax destroys the audit trail the tax team needs.

Landing the Structured Data Where Finance Actually Uses It

Path 4 produces structured rows — header-level fields and, where the invoice carries them, line items broken down per account or per campaign. The job now is making sure those rows stop being a file on disk and start being operational data inside the systems your finance team already runs. The same pipeline shape that handles Google Ads monthly invoices works across invoice formats generally; see our deeper walkthrough on converting invoice PDFs to structured JSON for the general mechanics. What follows is where the Google Ads rows specifically tend to land.

QuickBooks Online. Each extracted invoice maps to a Bill via the QBO Bills API (Create Bill). Vendor is the Google billing entity shown on the invoice (Google LLC, Google Ireland Limited, or the relevant regional entity), Bill Number is the invoice number from the header, and the bill lines come from the per-account or per-campaign breakdown. Promotional credits that appear as negative lines are typically posted as a Vendor Credit rather than squeezed into the Bill itself, which keeps the matching clean when you later apply the credit against a payment.

Xero. Same shape, different endpoint: a bill import through the Xero Accounting API using POST /Invoices with Type=ACCPAY. Contact is the Google billing entity, InvoiceNumber is the invoice number from the JSON header, and LineItems come directly from the structured rows, with the account code on each line driven by your chart-of-accounts mapping for paid media.

NetSuite. A Vendor Bill created through SuiteTalk (REST or SOAP, depending on which your integration team has standardised on). Entity mapping depends on how Google is configured — a single top-level vendor, or one vendor record per subsidiary for multi-entity groups. Custom segments usually do the real work here: client code, campaign family, or market attribution ride on the bill lines so the rebill and internal-reporting cuts fall out of the same posted bill.

BigQuery and Snowflake. For engineering-owned stacks, the raw JSON lands in stage tables — typically something like google_ads_invoice_header and google_ads_invoice_line_item — and dbt models (or direct SQL) join those stages against the agency's client-account mapping table. From there, BI dashboards surface month-over-month spend by client, by campaign family, or by billing entity without anyone touching a PDF. This is also where anomaly checks live: flagging a month where spend against a specific account jumped beyond a threshold, or where the invoice total doesn't tie to what was pulled from the Google Ads reporting API.

Google Sheets. For controllers who live in Sheets rather than an ERP, the extraction's XLSX output imports directly — one row per invoice for header-level summaries, or one row per line item when the per-campaign breakdown is what matters. No integration work; just open the file or push it to a shared Drive folder on a schedule.

Agency client-rebill. One extraction run produces the source data; a downstream step derives the per-client invoice — base spend plus agency fee plus applicable taxes — and posts it into whatever client-invoicing system the agency runs. The prompt-driven client-name derivation set up in Path 4 is what makes this a one-step operation rather than the older pattern of exporting, manually tagging each account to a client, then re-importing. Extract Google Ads invoice data once, with client attribution already on the rows, and the rebill job reads from structured input instead of from a human's tagging pass.

Once invoiced spend is sitting in the ERP or the warehouse, the next finance question is almost always the same one: does the amount Google billed match what actually ran on the platform? That's a separate workflow — matching invoice line items against campaign-delivery data from the Google Ads reporting API or Ads Data Hub — and it's covered in our guide on reconciling media vendor invoices against campaign delivery.