On this page · 11 sections
- The problem the dimension actually solves
- The 4 limitations, ranked by how much they cost you
- Configuring the report in five minutes
- Why your bill shows a dollar a day
- Pair it with a spend cap budget, not just an alert
- What this means for your allocation model
- India-specific considerations
- A 7-step rollout
- FAQ
- How eCorpIT can help
- References
Summary. On 7 August 2026 Google Cloud added an Originating products filter and Group by to Cloud Billing Reports, so AI consumption can finally be traced back to the product that caused it. It solves a specific problem: Gemini Enterprise subscription costs are categorised under the Vertex AI Search service, service ID 74B1-77CF-C302, where they sit alongside unrelated search spend. The new dimension pulls them out cleanly, and a preset report called Gemini Enterprise costs by SKU configures it in one click. Then come 4 limitations, and the fourth one decides your project plan: the Originating products field has not been added to the BigQuery export schemas, so the dimension exists in the console and nowhere else. Cost forecasting is disabled while it is applied. It is absent from the Cost table and Cost breakdown reports. Gemini Cloud Assist cannot build a report with it. Meanwhile 98% of the 1,192 practitioners in the FinOps Foundation's February 2026 survey now manage AI spend, up from 31% two years earlier. This guide covers what the dimension does, where it stops, and the spend cap budget you should configure alongside it.
The problem the dimension actually solves
Until this month, Gemini Enterprise spend on a Google Cloud invoice was hard to isolate. Google's own documentation says why: "Costs for Gemini Enterprise subscriptions are categorized under the Vertex AI Search Service (service ID: 74B1-77CF-C302) which can lead Gemini Enterprise costs to be grouped with other related service costs."
That is the shape of the AI attribution problem in general. A product a business unit bought generates consumption inside a different technical service, and the bill records the service, not the buyer. The Cloud Billing release notes for 7 August 2026 describe the fix: "Originating products are Google Cloud products that cause usage in another product. For example, Gemini Enterprise is an originating product when it causes usage in the Gemini Enterprise app."
The dimension groups related SKUs and services into product suites and logical product families, independent of the underlying technical service. So you filter on the thing you bought rather than the thing it happened to run on.
Two settings do the work:
The Originating products filter narrows the report to a logical product. Search for and select the Gemini Enterprise entries, which include Gemini Enterprise and Gemini Enterprise Agent Platform, then apply.
The Group by Originating Product setting summarises each row as an Originating Product plus Product suite combination. That gives you three readable buckets: the Gemini Enterprise app, everything under the Gemini Enterprise Agent Platform product suite, and AI developer tools such as Antigravity sitting under the Gemini Enterprise product suite.
You need Full billing account permissions to open Reports at all, which in practice means the FinOps owner does this, not the team being charged back.
The 4 limitations, ranked by how much they cost you
| Limitation | What breaks | Workaround today |
|---|---|---|
| Not in the BigQuery export schemas | The Generate query button is disabled; no automated chargeback, no Looker Studio model, no join to your allocation tables | Keep allocating on project, label and folder in BigQuery; use the console dimension for manual review only |
| Cost forecast disabled | You cannot forecast the AI line you just isolated, which is the line most likely to overrun | Forecast on the underlying service, then reconcile monthly against the Originating products view |
| Absent from Cost table and Cost breakdown reports | Invoice reconciliation and savings analysis still see the old service-level grouping | Reconcile at SKU level inside Reports; expect a manual mapping step at invoice time |
| Gemini Cloud Assist cannot build the report | The natural-language path to a report does not work here | Start from the Gemini Enterprise costs by SKU preset, then adjust filters by hand |
The first row is the one to take to your steering committee. Every mature GCP chargeback model runs on the BigQuery billing export, either the Standard export table gcp_billing_export_v1_<BILLING_ACCOUNT_ID>, the Detailed export, or a FOCUS export. If a dimension is not in those schemas, it cannot enter your allocation logic, your showback dashboards, or your monthly close. Google states the constraint plainly: "The Originating products field hasn't been added to the BigQuery export schemas, so the Generate query button is disabled when using the Originating products dimensions."
So the honest description of what shipped on 7 August is a reporting view, not an attribution model. It is useful. It is not the thing that lets you invoice a business unit automatically. Budget the work as analyst time this quarter and pipeline work whenever the schema catches up.
Configuring the report in five minutes
The fastest path is the preset. In the Google Cloud console, open the Reports page for the Cloud Billing account linked to your Gemini Enterprise subscriptions, then pick the preset report Gemini Enterprise costs by SKU from the saved reports carousel or the All reports page. That preset sets three things for you: time range by charge period for the current month, Group by SKU, and a filter on all Gemini Enterprise Originating products.
Grouping by SKU is what separates the two cost types you care about. Subscription SKUs show the daily prorated subscription cost. Overage SKUs show usage-based charges incurred beyond your subscription seat limit. Anything you are about to argue with a vendor about is in that second set.
To match what your Gemini Enterprise console shows on the Usage and Spending page, switch Group by to Originating Product and set the Time range filter to Charge period, Last 30 days. The console's Billing tab summarises overage and pay-as-you-go usage across enabled features and tools over the last 30 days, broken out by Gemini Enterprise app, Gemini Enterprise Agent Platform and AI developer tools, so the two views only agree when the window matches.
One naming note that trips people up during handover: the Time range setting formerly called Usage date is now called Charge period. Old runbooks still say Usage date.
Why your bill shows a dollar a day
If you are new to seat-based AI billing on GCP, this is the first support ticket you will file. Google's FAQ answers it directly: Cloud Billing uses daily proration for subscriptions, so "A monthly seat fee of $30 is billed at approximately $1 per day."
That matters for anomaly detection more than for accounting. A daily-prorated subscription produces a flat line, and a genuine overage produces a step in a separate SKU on top of it. If your alerting treats the whole Vertex AI Search service as one series, you cannot see the step. Splitting by SKU under the Originating products filter is what makes the step visible.
For an Indian team costing this in rupees, note that the subscription is priced and invoiced in US dollars unless your billing account is set to a local currency, so a seat count multiplied by $30 is the starting point and the currency conversion sits with your billing account configuration.
Pair it with a spend cap budget, not just an alert
The reporting change landed alongside a control that does something about the number. Spend cap budgets went to Preview on 27 July 2026, and they behave differently from the budget alerts most teams already have.
A spend cap budget is enforced when your usage costs exceed 100% of the budget amount, at which point usage of the specified service is automatically paused until you manually lift the cap. Alert emails go to billing administrators and project owners at 50% and 80% on the way there, and again at 100%.
The mechanics that decide whether this is usable in your environment:
| Property | Spend cap budget behaviour |
|---|---|
| Scope | One project and one eligible service per budget; folders, organisations, labels and multi-project budgets are out of scope |
| Eligible services | Gemini API, Gemini Enterprise Agent Platform (formerly Vertex AI), Cloud Run, Cloud Run functions |
| Period | Monthly only, starting on the first day of each month; not editable |
| Cost basis | Gross estimated costs, excluding savings and credits, for faster enforcement |
| What pauses | New usage of that service, including usage covered by CUDs and Provisioned Throughput; in-flight requests complete |
| What does not pause | Persistent resources such as compute and storage, and Gemini Enterprise subscription costs |
| Recovery | Manual lift only; services may take up to one hour to fully resume |
Read the cost-basis row twice. Enforcement runs on estimated gross costs so it can act faster than billing reports, which typically publish actual costs within a day and sometimes longer than 24 hours. Google's guidance follows from that: "Consider setting your budget slightly below your absolute limit. You remain responsible for any overage costs accrued due to reporting latency."
Two more sharp edges. You cannot convert an existing alerts-only budget into a spend cap budget; you delete it and create a new one. And if a project with an enforced cap moves to a different billing account, the cap is automatically lifted and charges resume, which is a real risk during a re-org or an acquisition integration.
The realistic pattern for most teams is a spend cap on the non-production project first. Pausing a production Gemini API path because a batch job misbehaved on a Saturday is a worse outcome than the overage, and the cap only lifts when a human with the right role does it.
What this means for your allocation model
Google shipped a console dimension, and your chargeback model runs on BigQuery. That gap defines the work.
Keep your existing allocation keys doing the load-bearing work. Project, folder and label remain the only attribution signals that reach the billing export, so the discipline that matters has not changed: one project per team or product where you can manage it, a mandatory label taxonomy where you cannot, and an owner recorded against every project. A team that has not done that groundwork gains nothing from the new dimension, because there is still nobody to send the number to.
Use the Originating products view for the questions the export cannot answer yet. Which logical product drove this month's Vertex AI Search line. Whether a spike is subscription or overage. Whether an AI developer tool such as Antigravity is material. Those are monthly review questions, and a console report answers them fine.
Instrument the AI-specific signals separately. Cloud Billing added early anomaly signals for AI workloads on 24 July 2026, using near-real-time estimates for the Gemini API and Vertex AI, and there is an AI Cost Summary Agent in the billing console. Both are faster than the export, which is the point: the billing export is a monthly close tool, not an incident detector. Our AI cost attribution and ownership playbook covers the ownership half of this, and the Gemini Enterprise governance and token cost controls piece covers the platform-side levers.
The FinOps Foundation's February 2026 data explains why the sequencing keeps slipping. Among 1,192 respondents representing more than $83 billion in annual cloud spend, 98% now manage AI spend, up from 31% two years earlier, and 78% of teams report to the CTO or CIO. J.R. Storment, Executive Director of the FinOps Foundation, put the pressure this way: "As companies pursue transformation via AI, with the resulting increases in AI costs, FinOps practices will be critical to enable c-level decisions about multi-year strategic technology investments across infrastructure types."
India-specific considerations
Indian enterprises and GCCs hit two variations on this.
The first is currency and reconciliation. Gemini Enterprise seat costs arrive as a daily prorated dollar figure, and if your billing account bills in INR the conversion happens before the number reaches your close. Finance teams reconciling a rupee invoice against a dollar-denominated report should agree the rate source up front, because a $30 seat priced at roughly ₹2,600 a month at a rate near ₹87 to the dollar will not tie to the paise. Fix the method, not the number.
The second is the chargeback chain in a GCC or an offshore delivery model. When an Indian entity runs the Google Cloud billing account and recharges an overseas parent or client, an attribution dimension that cannot be exported is not just inconvenient, it is an audit gap: your intercompany recharge has to be reproducible from data, not from a screenshot of a console report. Until the field reaches the BigQuery schema, keep the recharge on project and label allocation and treat the Originating products view as management information rather than the basis of the invoice.
Third, DPDP does not regulate billing data, but the projects generating this AI spend usually process personal data. A team standing up per-product Gemini Enterprise attribution is usually the same team that needs project-level data residency answers, and it is cheaper to decide both at the same time. The FinOps practices Indian teams use across AWS, Azure and GCP apply here without modification, because the allocation keys are the same three.
A 7-step rollout
- Confirm who holds Full billing account permissions. Nobody else can open these reports.
- Open the Gemini Enterprise costs by SKU preset and record this month's split between subscription SKUs and overage SKUs. That number is your baseline.
- Re-run the report with Group by Originating Product, Time range Charge period, Last 30 days, and reconcile it against the Gemini Enterprise console's Usage and Spending page. If they disagree, the window is wrong.
- Leave your BigQuery allocation model alone. The dimension is not in the schema, so nothing downstream changes yet.
- Audit label and project coverage on every project generating AI spend. This is the work that actually produces chargeback.
- Create a spend cap budget on a non-production project for the Gemini API or Agent Platform, set slightly below your true limit, and rehearse lifting it. Confirm someone with Billing Account Administrator or Project Owner can do it out of hours.
- Diarise a schema recheck. The dimension is new and the BigQuery gap is the stated limitation, so this is the thing most likely to change.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based, ISO 27001:2022 certified engineering organisation, and our senior engineering teams build the allocation layer that makes AI chargeback work on Google Cloud: project and label taxonomy, BigQuery billing export models, and spend cap and anomaly response runbooks your on-call can actually execute. We design applications aligned with DPDP requirements, which matters when the same projects carrying your AI spend also carry personal data. If your Gemini Enterprise line is growing faster than your ability to explain it, talk to our cloud and FinOps team. Our cloud FinOps guide for Indian teams sets out the wider model this fits into.
References
Last updated: 9 August 2026.
