Google Cloud Marketplace Agency Model Explained

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 tax duties Google’s agency terms assign to you. 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. Google’s agency-model page already reaches past this table: its note on separate invoicing adds, “This also applies to customers in Hong Kong.” The split-invoicing page gives Hong Kong no entry or start date, so the table doesn’t either.

---

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 Google’s terms make a tax yours, as they do for customers in Australia, Israel and Switzerland, 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’s Marketplace Agency Jurisdictions terms, which the Marketplace Vendor Agreement references, make you responsible for any applicable GST or VAT when the customer is located in Australia, Israel or Switzerland, and otherwise have Google collect and remit applicable taxes.

Corrected October 7, 2026: an earlier version said Google names one seller tax duty, GST for domestic Australian sellers. Google’s agency terms also make you responsible for applicable Israeli and Swiss VAT, and this section, the tax FAQ answer and the takeaways now follow those terms.

The three clauses use the same words, one tax each:

• Australia. “If the Customer purchasing Your Product is located in Australia, You will be responsible for determining, charging, and remitting to the appropriate authorities any applicable Australia GST with respect to such transactions.”
• Israel. “If the Customer purchasing Your Product is located in Israel, You will be responsible for determining, charging, and remitting to the appropriate authorities any applicable Israeli VAT with respect to such transactions.”
• Switzerland. “If the Customer purchasing Your Product is located in Switzerland, You will be responsible for determining, charging, and remitting to the appropriate authorities any applicable Swiss VAT with respect to such transactions.”

Canada has a provision of its own. If you have a Canadian GST/HST or Quebec Sales Tax (QST) ID, you “must complete required joint agency election forms as part of the Marketplace enrollment process,” and Google Cloud Canada Corporation “assumes the exclusive role of the ‘distribution platform operator’” for sales of your products to customers within Canada. Everywhere else, the default applies: “Unless otherwise specified below for a specific jurisdiction, for transactions for Your Products on the Marketplace, Google (or its Affiliate) will collect, subject to Section 3.6.4 of the Agreement, any applicable Taxes required to be collected from Customers for such transactions and will remit such Taxes to the appropriate authorities, unless the Customer provides a valid exemption certificate to Google (or its Affiliate).”

The split-invoicing page puts the Australian case in document terms. If you are located in Australia, your customer gets a Request for Payment without GST, and you are “responsible for invoicing the customer directly for any applicable taxes (GST)”; if you are located outside Australia, your customer instead receives a standard Google Cloud Marketplace Invoice, which “includes Google-assessed taxes.”

That difference between the document and the duty 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 your side of an agency transaction in the UK, Germany, France, or any other listed country without a seller clause in the terms is a question for your own tax advisors against your registrations, not something to infer from Google’s document layout. This is a reading of Google’s terms, not tax advice.

Two fictional cases make the split concrete. Globex, an Australian seller with 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 — the duty both of Google’s pages state. Initech, selling to a customer in France, sees the same no-VAT Request for Payment but finds no France clause in the terms, so the default rule applies, and Initech takes its own VAT position to its advisors rather than assuming the document tells it what to do.

---

How Fours keeps agency and first-party revenue straight

Platforms like Fours reconcile each marketplace transaction to a revenue record. Because Fours 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 Fours.

---

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’s Agency Jurisdictions terms list 16 jurisdictions: the United States (Nevada customers excepted), Canada, Hong Kong, Australia, Israel, Switzerland, the UK and nine EU members. Split invoicing was phased in for 13 of them, from the UK, Germany and France in February 2025 to Australia in 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?

Google’s agency terms make you responsible for determining, charging and remitting any applicable GST or VAT when the customer is located in Australia, Israel or Switzerland. Otherwise, the terms say Google collects and remits applicable taxes. This is not tax advice, so confirm your position with your 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’s agency terms make you responsible for any applicable GST or VAT when the customer is in Australia, Israel or Switzerland, and otherwise have Google collect and remit applicable taxes. Treat any VAT question on the other 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 Fours’ billing and revenue operations are built to do.