Google Cloud Billing Accounts, Budgets, Alerts, and BigQuery Export

A Cloud Billing account pays for projects: one billing account can fund many projects, and each project links to at most one billing account at a time. The billing account holds no resources itself — it is a payment configuration connected to a Google payments profile, which carries the payment instrument, tax and invoicing details. A billing account is a resource with its own IAM policy, separate from any project's policy, and it belongs to one organization (or stands alone for individual users).

The link between a project and a billing account is independent of the resource hierarchy. A billing account owned by organization A can pay for projects that live in organization B, and moving a project between folders does not change who pays for it. Who pays (the billing link) and where a project lives (organization and folder) are separate questions.

Because invoices follow the billing link, the billing account is also the unit of invoicing. Labels and projects let you split costs in reports, but every project linked to one billing account appears on that account's invoice. If two departments need genuinely separate invoices, their projects must be linked to separate billing accounts; labels alone never produce a second invoice.

Billing accounts come in two types:

For an engineer, both types behave the same for linking projects, budgets and exports; only the payment side differs.

You create a self-serve billing account in the Console's Billing section: choose Create account, name it, pick the country and currency and attach a payment method. Currency is fixed at creation, so a different currency or legal entity means a separate billing account. The person who creates a billing account automatically becomes its Billing Account Administrator.

Inside an organization, creating a billing account needs the Billing Account Creator role (roles/billing.creator), granted on the organization. When an organization is first created, Google grants Billing Account Creator and Project Creator to everyone in the domain by default. To control who can open billing accounts (and so stop employees attaching company projects to personal cards), remove that domain-wide Billing Account Creator binding and grant the role only to a small billing team.

An organization can hold several billing accounts. Good reasons to create more than one are a different currency, a different legal entity or payment source, or a hard need for separate invoices per subsidiary. For everyday team structure Google recommends the opposite: few billing accounts with many projects, with costs sliced by project and label in reports and budgets scoped to the projects you care about.

Invoiced accounts are not self-service: the business applies, and Google provisions the account with invoice terms once approved. The Billing Account Creator role cannot create one.

From the command line, gcloud billing accounts list shows the billing accounts you can see, with their IDs (XXXXXX-XXXXXX-XXXXXX), display names and an OPEN column that tells you whether each account is active. gcloud billing accounts describe ACCOUNT_ID shows one account.

Linking a project to a billing account is one operation that needs permission on both sides:

• On the billing account — permission to spend from it (billing.resourceAssociations.create), carried by Billing Account User or Billing Account Administrator.
• On the project — permission to change its billing, carried by Project Billing Manager. Project Owner also carries these project-side billing permissions; project Editor does not.

A project with no billing link cannot use paid services: VMs will not start and billing-dependent APIs such as Compute Engine refuse to be enabled. When a developer hits this in a sandbox project they own, the least-privilege fix is Billing Account User on the one billing account that should pay, not a broad role on the organization.

Neither side alone is enough, by design: a Project Owner cannot attach their project to a billing account they have no role on, and a Billing Account User cannot pull arbitrary projects onto the company account. The usual pattern grants Billing Account User to a small group or to the project-creation automation. A person who creates a project becomes its Owner, so a self-service create-then-link workflow needs Project Creator (on the folder or organization) plus Billing Account User on the billing account.

Useful commands:

• gcloud billing projects link PROJECT_ID --billing-account=ACCOUNT_ID — links a project, or re-points it to a different billing account.
• gcloud billing projects unlink PROJECT_ID — disables billing on the project.
• gcloud billing projects describe PROJECT_ID — shows billingAccountName and billingEnabled. gcloud projects describe does not show the billing link.
• gcloud billing projects list --billing-account=ACCOUNT_ID — lists the projects a billing account pays for.

Changing versus unlinking is the distinction that matters most:

So the safe order for retiring a billing account is: move every project to the new billing account first, and close the old one only when nothing is linked to it. When you change a project's billing account, Google's permission table covers both the current and the target billing account, so make sure whoever performs the move holds the right role on both.

To protect a critical project from accidental unlinking, lock the project's billing link (Billing, Account management, Actions, Lock billing). While locked, nobody can disable billing on the project or move it to another billing account until it is unlocked. A lock does not protect against the billing account itself being closed or suspended. Do not confuse it with a Resource Manager lien, which only blocks deleting the project.

Billing has its own predefined IAM roles, granted on a billing account, a project or the organization, and least-privilege questions depend on matching each task to the right one.

To pick the minimal role, reduce the task to its verb: link a project — Billing Account User plus Project Billing Manager; view charges — Billing Account Viewer; run budgets and cost exports without touching payments — Costs Manager; change the payment method or billing IAM — Billing Account Administrator; open a new billing account — Billing Account Creator.

Separation of duties uses the billing account's own IAM policy. Finance gets Billing Account Administrator, Costs Manager or Viewer on the billing account and no project roles: it controls and audits money without touching resources. Engineers get project roles but no billing-account roles. Give engineers Editor rather than Owner when they must not move a project to another billing account or turn billing off, because Owner carries the project-side billing permissions. Billing roles are additive: when one job spans two verbs (for example running budgets and also linking projects), grant the minimal role for each verb rather than reaching for Administrator.

A standard Cloud Billing budget compares spend with a target amount and sends alerts; it is alerts-only and never stops usage or spending. However many thresholds fire, resources keep running and charges keep accruing. (A separate, narrow feature — spend cap budgets, covered in the next section — can pause one eligible service.)

You create budgets under Billing, then Budgets and alerts. Each budget has:

• Scope — the whole billing account, or filtered to specific projects, services, labels and other dimensions. One billing account can carry many budgets, so tracking a subset of projects needs a budget filter, not another billing account.
• Credits — by default the budget measures cost after credits (promotions, discounts). If credits are absorbing spend, alerts stay quiet while usage grows; exclude credits from the budget to alert on gross usage.
• Amount — a specified amount, or last period's spend, which adjusts the target automatically each period.
• Threshold rules — percentages of the amount (by default 50%, 90% and 100%), each evaluated on actual or forecasted spend. A forecasted threshold warns that you are trending past the amount before the money is spent.

Who gets the emails. By default, threshold emails go to the Billing Account Administrators and Billing Account Users of the billing account. A budget scoped to a single project can also email that project's owners (an option you turn on; a Preview feature at the time of writing). To reach anyone else, link up to five Cloud Monitoring email notification channels to the budget. Budgets accept only email channels — Slack, webhooks, SMS or ticketing systems need programmatic notifications.

Programmatic notifications publish budget messages to a Pub/Sub topic for automation. These messages are status updates sent several times a day, whether or not a threshold has been crossed, carrying fields such as costAmount, budgetAmount, the cost interval and the last threshold exceeded. Code that subscribes must compare the values before acting; threshold rules shape the email alerts, not the Pub/Sub stream.

Budgets run on delayed data. Cost data reaches Cloud Billing some hours after usage, so an alert can arrive well after spend actually crossed a threshold, and spend keeps rising in the meantime. Even a correctly configured budget lets spend overrun its amount before anyone is told.

A spend cap budget is a budget that pauses new usage of one service when its cost passes the amount. It exists only for a few API-based services: the Gemini API, Gemini Enterprise Agent Platform, Cloud Run and Cloud Run functions. Its limits are strict:

• One budget covers exactly one project and one eligible service — not several projects, folders, the organization or labels.
• The period is fixed to the calendar month.
• Enforcement uses gross estimated cost; credits and savings are not deducted.
• When the cap is enforced, new requests to that service in that project are blocked while in-flight requests finish. Other services keep running, the billing link stays, and resources and data are kept; ongoing fixed charges for persistent resources are not paused.
• The block lasts until someone lifts the cap manually or the next monthly period begins. After a manual lift, the service can take up to about an hour to return to normal, and the cap will not trigger again for the rest of that budget period unless you edit the budget to raise its amount.
• Because cost reporting lags, enforcement is not instantaneous, and you pay for any overage accrued before the cap took effect.
• Configuring one needs billing.budgets.configureSpendCap on the billing account (included in Billing Account Administrator) plus billing.resourcebudgets.configureSpendCap on the project (for example through a custom role, or Editor combined with the billing-specific permissions).

Because enforcement is scoped to one service in one project, an enforced cap looks different from a billing problem: losing the billing link stops every paid service in the project, while an enforced cap blocks new requests to the capped service only and leaves the billing link in place. Check the budget's spend cap state before investigating billing.

For services that spend caps do not cover (Compute Engine, Cloud Storage, BigQuery and most others), a hard stop still has to be built: subscribe a function to the budget's Pub/Sub topic, check the cost against the budget in the message, and disable billing on the project — accepting that this shuts the workload down. For an eligible service, a spend cap budget gives the hard stop without that collateral damage.

Cloud Billing export to BigQuery writes your billing data into BigQuery tables automatically through the day, so you can query it with SQL, join it with other data and build dashboards (for example in Looker Studio). It is opt-in and configured per billing account under Billing, then Billing export, with a project and BigQuery dataset as the destination. BigQuery is the supported export destination.

The main export types are:

Cloud Billing also offers a usage cost export in the open FOCUS format for teams that standardise on it; the three above are the core ones to know.

Permissions and setup:

• Usage cost exports (standard and detailed): Billing Account Costs Manager or Billing Account Administrator, plus BigQuery User on the dataset's project. The BigQuery API must be enabled there.
• Pricing export: Billing Account Administrator, BigQuery Admin on the dataset's project, and the BigQuery Data Transfer Service API enabled in that project.

How much history you get depends on the dataset location. With a US or EU multi-region dataset, the usage cost exports backfill from the start of the previous month (the backfill can take a few days). With a single-region dataset they contain data only from the day you enable export. The pricing export is never backfilled. Either way, older history is not available — enable export, in a multi-region dataset, on day one. Create the dataset first and choose its location deliberately, because a BigQuery dataset's location cannot simply be changed later.

Cost analysis starts in the billing account's built-in Reports page: filter and group spend by project, service, SKU, region or label, and compare time ranges. Labels such as team=checkout or env=prod flow through to billing line items in reports and in the BigQuery export, which makes "which team spent this?" answerable. Labels split reports; they do not change which billing account is invoiced. Adding labels later does not relabel past spend.

A new organization typically sets up billing once, in this order:

1. Restrict Billing Account Creator (remove the domain-wide default), then create or apply for the billing account.
2. Grant billing IAM: Billing Account Administrator to the platform or finance team, Costs Manager or Viewer to finance analysts, Billing Account User to the project-creation automation, Project Billing Manager to project-owner groups that manage their own links; engineers get project roles (Editor where they must not change billing).
3. Link projects with gcloud billing projects link, and lock the billing link on critical production projects.
4. Enable the standard and detailed usage cost exports to a US or EU multi-region dataset in a dedicated billing project.
5. Create budgets: an account-wide budget with actual and forecasted thresholds, tighter per-project budgets for sandboxes, Pub/Sub notifications for automation, and spend cap budgets for eligible services such as Cloud Run or the Gemini API where a hard stop is wanted.
6. Define and enforce a label taxonomy so reports and exports group meaningfully.