On a Google Cloud Marketplace transaction that runs under the agency model, you — not Google — are the seller of record, and your customer’s paperwork changes to match. This post covers which countries moved to that model and when, what documents the buyer receives, and the one tax duty Google states in writing. It is the mechanics for finance and marketplace ops, not tax or legal advice.
A buyer in Germany accepts your Google Cloud Marketplace offer, and a week later their accounts payable team asks why the charge for your product came on its own document, separate from their Google Cloud bill, and why that document doesn’t show VAT the way the rest of their Google invoice does. Nobody on your side asked for that split. Google did, because the transaction ran under its agency model — and under that model, the seller of record is you.
How a marketplace being the seller of record reshapes your books is the wider story in what seller of record means on a cloud marketplace. This post is the Google Cloud piece: which countries run agency transactions, what the buyer receives, and what you actually have to do.
What is Google Cloud’s agency model?
Google Cloud’s agency model is a transaction model in which Google acts as your agent when a customer buys your product through Cloud Marketplace, and you — not Google — are the Merchant of Record for that transaction. In Google’s own words, “Under the agency model, Google acts as an agent for you as you offer your product through Cloud Marketplace,” and “you’re the Merchant of Record for the transaction.”
The seller of record is the entity that legally makes the sale to the buyer: the name the buyer’s paperwork answers to, and typically the party responsible for the transaction’s taxes. On a first-party marketplace transaction that is Google. On an agency-model transaction it is you, which is why the paperwork and the tax handling both change.
The alternative is the Merchant of Record model, where Google is the Merchant of Record. Google decides which model a given transaction uses from the eligibility conditions below — it is not a setting you toggle per deal.
Which countries run agency transactions, and since when?
A transaction runs under the agency model, with split invoicing, once the customer’s Google Cloud payment profile is in a country Google has migrated — and Google has phased those countries in by date. The table below is Google’s published rollout. Read the dates as when each country’s transactions began invoicing separately, not as the “Last updated” stamp on Google’s page, which is a site-wide rebuild date and moves.
| Country | Agency-model split invoicing since |
|---|---|
| United Kingdom | February 1, 2025 |
| Germany | February 1, 2025 |
| France | February 1, 2025 |
| Israel | June 1, 2025 |
| Belgium | September 1, 2025 |
| Italy | September 1, 2025 |
| Luxembourg | September 1, 2025 |
| Netherlands | September 1, 2025 |
| Poland | September 1, 2025 |
| Spain (excluding the Canary Islands) | September 1, 2025 |
| Sweden | September 1, 2025 |
| Switzerland | June 1, 2026 |
| Australia | August 1, 2026 |
The trigger is the buyer’s payment-profile location, so the same product sells as an agency transaction to a customer in one of these countries and, potentially, under the Merchant of Record model to a customer elsewhere. Check Google’s own page for the current list before you rely on any country’s status — Google adds to it, and a summary ages.
What does the buyer’s paperwork look like?
Under split invoicing the buyer stops receiving one combined bill: purchases of your Cloud Marketplace product are invoiced separately from their first-party Google products and Google Cloud usage, and for agency transactions the document for your product is a “Request for Payment” that does not include VAT or other Google-assessed taxes. The exact set of documents depends on the country — a Switzerland transaction produces three documents, and an Australia transaction can produce up to four.
That is the detail finance most often misses. The buyer’s Google Cloud invoice shows Google’s taxes as usual, but the Request for Payment for your product does not, because on that line Google is acting as your agent rather than as the seller. If a buyer’s procurement team asks why one document on their Google bill carries no VAT, this is the answer — and, where any tax is due, why it is yours to handle rather than Google’s.
For finance, the consequence is a reconciliation one. A Google transaction that ran as an agency sale is your revenue at the gross your Request for Payment states; a first-party transaction is not the same shape. Knowing which of your Google transactions ran under the agency model is what keeps your gross-versus-net and your tax trail right — which is the job marketplace revenue reconciliation exists to do.
Who is eligible, and what if you’re not?
A transaction uses the agency model only when three conditions are met; if any one is missing, Cloud Marketplace uses the Merchant of Record model for that transaction and Google is the Merchant of Record instead. Google lists the three conditions:
- Location. “Both you and the customer must be located in a region that Cloud Marketplace supports for the agency model.”
- Agreement. “Your organization must have agreed to the current version of the Marketplace Vendor Agreement.”
- Identity. “Both you and the customer must have verified your identity to Google, if you were requested to by Google.”
Google’s fallback sentence is explicit: “Otherwise, Cloud Marketplace uses the Merchant of Record model for that transaction.” So an unmet condition doesn’t block the sale — it changes who the seller of record is, and therefore whose paperwork and tax obligation the transaction carries. A vendor that lets its Marketplace Vendor Agreement fall out of date, or that hasn’t cleared an identity-verification request, can find the same product selling under two different models to two similar buyers.
For an ISV selling into these markets, the practical read is: keep the current Marketplace Vendor Agreement accepted, clear any identity-verification request Google sends, and confirm both you and the buyer are in a supported region before you count on a transaction running as agency.
What must the seller actually do about tax?
Google states exactly one seller tax duty in this documentation, and it is specific to Australia: a domestic Australian seller is responsible for invoicing the customer directly for any applicable GST, because the Request for Payment the customer receives does not include GST. Google does not, in this documentation, assign the vendor a VAT-collection duty in the European countries on the list — it says the Request for Payment carries no VAT, not that you must charge it.
That distinction matters, and it is where teams over-read. The absence of VAT on the buyer’s Request for Payment is a fact about the document; whether, and how, any VAT is owed on an agency transaction in the UK, Germany, France, or any other listed country is a question for your own tax advisors against your registrations, not something to infer from Google’s document layout. The one duty you can read straight off Google’s page is the Australian GST one.
Two fictional cases make the split concrete. Globex, selling to an Australian customer under the agency model, receives its money via a Request for Payment with no GST on it and invoices that customer directly for GST — Google’s stated duty. Initech, selling to a customer in France, sees the same no-VAT Request for Payment but has no equivalently stated Google duty, so Initech takes the VAT question to its advisors rather than assuming the document tells it what to do.
How Suger keeps agency and first-party revenue straight
Platforms like Suger reconcile each marketplace transaction to a revenue record. Because Suger keeps every Google Cloud agreement, its documents and its disbursements on one record, knowing which Google transactions ran under the agency model — where you were the seller of record and your Request for Payment carried no VAT or GST — stays a property of the data rather than a spreadsheet memory.
That is what keeps the two numbers your auditor cares about right: gross versus net on transactions where you, not Google, made the sale, and a tax trail that reflects who was responsible on each one. See marketplace billing and revenue operations in Suger.
Frequently asked questions
Who is the seller of record on a Google Cloud agency-model transaction?
You are. Google states that under the agency model it acts as your agent and you are the Merchant of Record for the transaction. Google is the Merchant of Record only when the agency-model conditions are not met.
Which countries use Google Cloud’s agency model?
Google has phased split invoicing in by country: the UK, Germany, and France from February 2025; Israel from June 2025; Belgium, Italy, Luxembourg, Netherlands, Poland, Spain (excluding the Canary Islands), and Sweden from September 2025; Switzerland from June 2026; and Australia from August 2026.
Why does my customer’s Request for Payment show no VAT?
Because on an agency-model transaction Google acts as your agent, not as the seller. Google invoices your product separately from its first-party charges, and that Request for Payment does not include VAT or other Google-assessed taxes.
Do I have to charge tax on an agency-model Google Cloud sale?
The one duty Google states is that a domestic Australian seller must invoice the customer directly for any applicable GST. Google does not assign a VAT-collection duty for the listed European countries in this documentation, so take that question to your tax advisors.
What makes a Google Cloud transaction use the agency model?
Three conditions: you and the customer are both in a supported region, your organization has agreed to the current Marketplace Vendor Agreement, and both parties have completed any identity verification Google requested. If any is missing, Google uses the Merchant of Record model instead.
Takeaways
- On an agency-model Google Cloud transaction, you — not Google — are the seller of record; Google is the Merchant of Record only where the eligibility conditions aren’t met.
- The buyer receives your product on a separate Request for Payment that carries no VAT or GST, and the country decides how many documents in total (three in Switzerland, up to four in Australia).
- Google names exactly one seller tax duty: a domestic Australian seller invoices the customer directly for GST. Treat any VAT question on the European countries as one for your advisors, not something the document layout answers.
- Agency eligibility rests on three things — supported region, current Marketplace Vendor Agreement, and any requested identity verification. Keep all three current, or the same product can sell under two different models.
- Knowing which Google transactions ran as agency is what keeps gross-versus-net and the tax trail right at close.
Reconciling agency and first-party Google transactions to one revenue record, with the documents and disbursements attached, is what Suger’s billing and revenue operations are built to do.
Sources
Primary sources for the platform rules cited above. Last verified September 30, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Google Cloud Marketplace: Migration to split invoicing for agency model transactions — The per-country split-invoicing dates, the separate Cloud Marketplace documents each buyer receives, the Request for Payment that carries no VAT/GST, and the Australian domestic-seller GST duty
- Google Cloud Marketplace: Migration to transacting in the agency model — The definition of the agency model, the three eligibility conditions, and the statement that Cloud Marketplace uses the Merchant of Record model where those conditions are not met
Keep reading
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.