Google Cloud Projects and Billing Accounts: How They Relate

Two objects, one relationship

Google Cloud separates the place where you build from the place where you pay. The place where you build is a project. The place where you pay is a Cloud Billing account. They are different resources, with different owners, different permissions and different lifecycles, and they are joined by a single link that you can create, change or remove.

Once that separation clicks, a lot of Google Cloud behavior becomes predictable: why an API refuses to enable, why a Compute Engine instance stops when a card expires, why a colleague can see your project but not its costs, and why the trial credit belongs to one object and not the other. This article explains both objects, the link between them, the hierarchy above them, and the exact roles and commands involved.

If you are comparing Google's model with a rival's, the AWS versus Google Cloud comparison and the Azure versus Google Cloud comparison both touch on how each platform draws the line between organizational and financial containers.

What a project actually is

A project is the fundamental unit of organization on Google Cloud. Every Compute Engine VM, Cloud Storage bucket, Cloud Run service, service account and enabled API belongs to exactly one project. IAM policies are most often set at project level, quotas are tracked per project, and the audit logs for a resource are found in the project that owns it.

Each project carries three identifiers, and it is worth knowing which is which because tools ask for them inconsistently.

Because the project ID cannot be changed, pick a naming scheme before creating anything important. A short application name plus environment plus a random suffix is the common pattern, since IDs are unique across all of Google Cloud and the obvious ones are taken.

Projects also isolate API enablement. The Compute Engine API, Cloud SQL Admin API and hundreds of others are switched on per project. A fresh project has almost nothing enabled, which is a feature: it means a compromised project has a smaller surface, and it makes cost attribution cleaner.

What a billing account actually is

A Cloud Billing account is a resource that tracks charges and holds the instructions for paying them. Behind it sits a Google payments profile, which is the object that stores the payment instrument and the legal entity name. One payments profile can back multiple billing accounts, and each billing account can fund many projects.

Billing accounts come in two types. Self-serve accounts are opened online and paid automatically by card or bank debit. Invoiced accounts are arranged with Google or a reseller, receive monthly invoices, and are typical for larger organizations. Promotional credits, including the trial credit on a new account, are attached to the billing account rather than to any project, which is why understanding how cloud credits are applied starts with knowing which billing account a project is linked to.

A billing account may live inside a Google Cloud organization or stand alone. When a project belongs to an organization, an organization policy can restrict which billing accounts its projects are permitted to use, preventing someone from quietly linking production to a personal card.

How the link works, and what happens when it breaks

A project is linked to at most one billing account at a time. Linking is what turns a project from a free container into something that can consume paid services. Without a link, you can still create the project, set IAM and enable a few free APIs, but any request to create billable resources fails with a clear message that billing is not enabled.

Changing the link is a routine operation. Moving a project from a trial billing account to a company one, or from one department's account to another, takes a single action and does not touch the resources. Charges accrue to whichever account is linked at the time of usage.

Breaking the link is the part that surprises people. If billing is disabled for a project, whether by an administrator, by a closed billing account or by a payment failure that leads to suspension, Google Cloud stops the services that require billing. Running VMs are shut down and other billable resources become unusable until billing is restored. Data is generally retained for a period, but the outage is immediate. Treat the billing link as a dependency of production, and monitor it like one.

Organizations and folders above the project

Projects can exist on their own, which is how personal and small-team usage often starts. Businesses generally add two levels above them. The organization resource is the root, created automatically when a Google Workspace or Cloud Identity domain is associated with Google Cloud. Folders sit between the organization and projects, and can be nested to represent departments, teams or environments.

IAM policies and organization policy constraints set at the organization or folder level are inherited by every project beneath. A common design places all production projects under one folder with tight constraints, all development projects under another, and gives each team a folder in which they can create their own projects. The official resource hierarchy documentation explains inheritance rules and the special role of the organization administrator.

Billing accounts are not part of this tree in the sense that projects do not inherit them from folders. Every project is linked individually, even if an organization uses one billing account for everything. The general concept of a tenant or organization root across providers is discussed in What Is a Cloud Account?.

Who can do what: the billing IAM roles

Because billing accounts have their own IAM policy, someone who is an Owner of a project can still be unable to see its costs or change its billing account. The roles below are the ones that matter.

Linking a project requires rights on both sides: Billing Account User (or Administrator) on the account, and Project Billing Manager or Owner on the project. Grant Billing Account User to the group that creates projects, and keep Administrator to a handful of people. The billing account management guide lists every permission behind these roles.

A worked gcloud session

The following commands create a project, find a billing account, link the two and enable the first API. Run them from Cloud Shell or a workstation with the Google Cloud CLI installed and authenticated.

1. gcloud projects create web-store-prod-31904 --name="Web Store Production" creates the project; add --folder=<folder-id> or --organization=<org-id> to place it in the hierarchy.
2. gcloud billing accounts list shows the billing accounts you can use, with their IDs in the 0X0X0X-0X0X0X-0X0X0X format and an open or closed status.
3. gcloud billing projects link web-store-prod-31904 --billing-account=0X0X0X-0X0X0X-0X0X0X creates the link.
4. gcloud billing projects describe web-store-prod-31904 confirms billingEnabled: true.
5. gcloud config set project web-store-prod-31904 makes it the default for subsequent commands.
6. gcloud services enable compute.googleapis.com switches on Compute Engine, which now succeeds because billing is active.

To detach later, gcloud billing projects unlink web-store-prod-31904 removes the link, with the consequences described above. If you are starting from a Google Cloud account supplied through AllCloudShop, the first thing to check is exactly this relationship: which billing account the initial project uses, and who holds the billing roles on it. The Google Cloud account listing describes the available variants by name, and the support channels can confirm specifics.

Budgets, exports and liens

Three features protect the billing relationship once it is set up. Budgets are defined on the billing account, optionally scoped to particular projects or services, and send email or Pub/Sub notifications at thresholds you choose. They alert; they do not cut off spending unless you wire a Cloud Function to the Pub/Sub topic to disable billing yourself. The budget alerts article covers the wiring.

Billing export streams detailed usage and cost rows into a BigQuery dataset, which is the only way to get line-item detail with labels for analysis. Enable it early, because export is not retroactive.

Liens are a lesser-known Resource Manager feature: placing a lien on a project blocks deletion until the lien is removed, which is a sensible safeguard for anything production-grade.

Key takeaways

• Projects hold resources, IAM and quotas; billing accounts hold payment instructions and credits. They are separate resources joined by one link.
• A project links to at most one billing account; a billing account funds many projects; changing the link does not move resources.
• Disabling billing stops billable services immediately, so monitor the link and the payment method as production dependencies.
• Grant Billing Account User to project creators and keep Billing Account Administrator rare; linking needs rights on both the account and the project.
• Use folders and organization policies to control which billing accounts projects may use.
• Turn on budgets, BigQuery billing export and project liens before the first real workload runs.