A Google Cloud billing account is the thing that pays: every project is linked to exactly one, the account accrues the costs of all its projects and settles them through a payments profile, either self-serve, charged automatically to a card or bank account, or invoiced, paid by transfer against a monthly invoice once Google has approved the account for it; a partner-billed account is paid through the reseller. The organisation and its folders are where projects live and where tags are inherited, the project is the unit every line of cost belongs to, and labels and tags are the two ways to mark resources for allocation, both of which the billing export carries. On the bill, the billing account type changes the payment terms and nothing else, while the project is what every cost line, every budget and every export is keyed by.
Pricing dimensions
Billing accounts, projects, labels and tags cost nothing; what each changes is where a cost lands and what it carries. Every cost line still has its SKU and its price; the table lists the mechanisms around it.
| Mechanism | What it is | What it changes on the bill | Where it is optional |
|---|---|---|---|
| Self-serve billing account | An online account with a payments profile, charged automatically to a card or bank account at the end of the month or when a threshold is reached | Eligible for sustained use discounts; the monthly statement, no invoice terms | The default for new accounts |
| Invoiced billing account | An offline account approved by Google for invoiced billing, paid by check or transfer against monthly invoices sent by mail or electronically | Invoice terms and a credit line; no sustained use discounts; the invoice as the document finance reconciles | Yes, on eligibility |
| Partner-billed account | A billing account owned by a reseller, with the customer as a sub-account | The reseller's price and invoice; the export shows the customer's usage at the reseller's rates, or at list where the reseller withholds them | Yes |
| Payments profile | The legal entity, address, tax status and payment instrument behind the account; business profiles for companies | The currency and the taxes on the invoice; VAT handling for a German entity | No |
| Project | The container every resource belongs to, linked to one billing account; a project without a billing account cannot use paid services | project.id on every cost line; the unit of budgets, quotas and exports | No |
| Organisation and folders | The hierarchy above the projects, with the organisation as the root; a project's ancestors in the export | The structure allocation follows without a single label; where tags are inherited from | Yes, no organisation for individuals |
| Labels | Key-value pairs set on a resource by the service that owns it, up to 64 per resource; on the project as well | labels and project.labels on the cost lines of the labelled resource; the per-team attribution that needs no hierarchy | Yes |
| Tags | Key-value pairs bound to an organisation, folder, project or resource through Resource Manager, with IAM control over the keys and values, inherited down the hierarchy | tags on the cost lines, with tags.inherited where the binding came from an ancestor; the allocation that follows the hierarchy | Yes |
| Credits | Promotional, free tier, sustained use, committed use and spend-based credits applied to the lines they belong to | credits.type and credits.amount as negative amounts beside the list price; promotional credits drawn down until they expire | Yes |
| Purchase option | None; the account structure carries no discount of its own |
The billing account is an administrative object, not a cost one: it owns the payments profile, the currency, the invoice and the budgets, and the projects it pays for can sit anywhere in the organisation's hierarchy, which is why one organisation can have several billing accounts, one per legal entity or cost centre, and why moving a project between billing accounts moves its future costs without touching the project. The account type matters in two places: an invoiced account has payment terms and a credit line and gets no sustained use discount, a self-serve account gets the discount and pays automatically; the prices are the same. Labels and tags are the allocation keys, and they differ in who may set them and where they apply: a label is set on a resource by anyone who can edit it and applies to that resource alone, a tag is a Resource Manager object with its own permissions, bound once to a folder or project and inherited by everything below, which makes tags the key for ownership and labels the key for workloads. The export carries both, so a cost line can carry the project's labels, the resource's labels and the inherited tags at once. The mechanics across all three providers are in billing accounts and hierarchies; how accounts, subscriptions and projects serve allocation, in allocation by account, subscription and project; what labels do and do not do, in tags and labels.
Invoices, exports and APIs
Invoices. A self-serve account receives a monthly statement and a transaction history in the console; an invoiced account receives one invoice per billing account per month, in the payments profile's currency, with the taxes of the profile's country, and the invoice's lines are per project and service. The invoice month is the calendar month of usage, and invoice.month in the export is the key that ties a line to it; a credit note or an adjustment appears as a line with cost_type adjustment in the month it is issued, not the month it corrects. Costs in a currency other than USD carry currency_conversion_rate, and cost divided by the rate is the USD amount the prices are published in. How a credit, a refund or a correction lands is in credits, refunds and corrections; what the currency does to the number, in invoice currency and exchange rates.
Exports. The billing export to BigQuery is per billing account, in three forms: the standard usage cost export with one row per SKU, project and hour, the detailed export that adds resource.name and resource.global_name, and the pricing export that lists every SKU's list price; the exports start from the day they are enabled and never backfill, which makes enabling them the first step of a new account. Every row carries billing_account_id, project.id, project.number, project.name, project.ancestry_numbers for the folders above it, project.labels, labels, system_labels and tags with key, value, inherited and namespace; cost_type separates regular from tax, adjustment and rounding error, and credits carries every discount and credit with its type. A sub-account under a reseller sees its own usage. The structure is described in the Google Cloud billing export and the columns' meaning in FOCUS columns, where BillingAccountId, SubAccountId for the project, Tags and ChargeClass map the same facts.
APIs. The Cloud Billing API lists billing accounts and the projects linked to them and moves a project between accounts; the Cloud Billing Catalog API lists SKUs and their prices, which is how the sku.id of a row maps to a list price; the Resource Manager API creates projects, folders, labels and tag bindings. A budget's scope, an export's dataset and a reseller's view are all keyed by the billing account id. What the console's reports show on top of the export is in Google Cloud billing reports.
Levers
Configuration: the first lever is the project structure, because every cost line carries its project and a project per team and environment allocates without a single label; the second is the tag hierarchy, because a tag bound to a folder reaches every project below it and the export carries it as inherited, which is how ownership follows the organisation chart; the third is the labels on resources for what the hierarchy cannot express, the workload, the customer or the cost centre of a shared project, with a tagging policy that names the keys. Enable the detailed export on day one, because resource-level attribution exists only from then on.
Purchase option: none; the account type decides the payment terms, and invoiced billing is a question of the finance process, not of price, except that it forgoes the sustained use discount.
Architecture: one billing account per legal entity that must receive its own invoice, and as few as that, because budgets, exports and committed use discounts are per account and a commitment in one account does not cover projects in another; folders by team or business unit with a tag per folder; and a project per environment within a team, so development and production separate in the export without a label. What the AWS and Azure structures do instead is in Organizations and consolidated billing and Azure billing accounts: EA, MCA and CSP.
Where it goes wrong
- The export was enabled in month three. The BigQuery export starts on the day it is enabled and never backfills; the first two months exist only in the console's reports. The first action on a new billing account is the export.
- Two billing accounts, one commitment. A committed use discount bought under one billing account covers only the projects it pays for. Projects moved to another account lose the coverage.
- The label is on the project, not the resource.
project.labelscarry the project's labels on every line,labelsthe resource's; a report that reads only one misses the other. Allocation rules read both. - The tag was bound after the fact. Tags apply to cost from the day they are bound, not backwards. The month before the binding has no tag in the export.
- The reseller withholds the rates. A partner-billed sub-account can see usage at list price while paying the reseller's price. The invoice, not the export, is the source for what was paid.
- The invoiced account lost the sustained use discount. Moving from self-serve to invoiced billing ends the automatic discount on N1 and N2 instances. Commitments replace it.
- Projects without a billing account. A project whose billing account was detached stops its paid services; a project linked to the wrong account bills the wrong team. The project list by billing account is the monthly check.
Example
Facts and figures, read on 2026-10-22 from the Cloud Billing documentation, without list prices because the structures carry none: a self-serve billing account is charged automatically when its usage reaches a payment threshold or at the end of the month, an invoiced account has a monthly invoice with payment terms, and both pay the same list prices in USD or the currency of their payments profile.
An organisation with three legal entities in Germany, France and the United States keeps three billing accounts, one per entity, each with its own payments profile and invoice currency; its 40 projects sit in folders per business unit under one organisation, with a tag business-unit bound to each folder and inherited by every project, and a label env on every project for development, staging and production. In the export, a line for an instance in the project payments-prod carries billing_account_id of the German entity, project.id payments-prod, project.ancestry_numbers with the folder of the payments unit, tags with business-unit: payments and inherited: true, project.labels with env: production, and labels with whatever the instance itself carries, such as team: checkout; a report by tag gives the business unit, by project label the environment, by resource label the team, and by project the service, without any of the four having to be set twice. A committed use discount bought under the German account covers the German projects only; the French entity's instances pay list price until it buys its own. The example shows that the hierarchy and the tags allocate the whole bill without a resource label, that labels add the dimensions the hierarchy cannot, and that commitments and budgets stop at the billing account.
Sources
Read on 2026-10-22. Documentation: Cloud Billing concepts and account types, manage your Cloud Billing account, export Cloud Billing data to BigQuery, structure of the standard Cloud Billing data export, tags overview.