Cost Allocation and Tagging Standard Template (FinOps, FOCUS 1.4)

Cost Allocation and Tagging Standard: [Organisation name]

Organisation standard for allocating cloud and technology cost to the teams, products and business units that cause it: the allocation hierarchy, mandatory tags and allowed values, tag governance and policy-as-code enforcement, treatment of untagged and untaggable cost, shared-cost split rules, showback and chargeback, the mapping to FOCUS 1.4 columns, compliance KPIs, exceptions and review. Based on the FinOps Open Cost and Usage Specification (FOCUS) 1.4 (ratified 2026-06-04) and aligned with the Allocation and Invoicing & Chargeback capabilities of the FinOps Framework (2026 update), both published under CC BY 4.0. Replace every [bracketed] value and every row marked Example. Worked examples use the fictional SaaS company "Corvid Commerce".

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Roles and responsibilities
3. Allocation hierarchy
4. Mandatory tags and allowed values
5. Policy statements
6. Tag governance and enforcement
7. Untagged and untaggable cost
8. Shared cost allocation rules
9. Showback and chargeback
10. Mapping to FOCUS 1.4
11. Compliance measurement
12. Exceptions and risk acceptance
13. Review cycle and related documents
14. Glossary and references

1. Purpose and scope

Purpose: make every unit of technology cost attributable to an accountable owner, so that teams can see and manage what they spend, finance can budget and report by business dimension, and leadership can compare cost with the value each product delivers.

Objectives:

• every charge in the cost dataset is allocated to a cost centre, an owning team and a service, either directly by tag or by a documented rule;
• allocation is reproducible from the normalised billing data by anyone with access, without manual spreadsheets;
• the share of unallocated cost stays below the target in section 11.

Scope:

2. Roles and responsibilities

R = responsible, A = accountable, C = consulted, I = informed.

3. Allocation hierarchy

Cost rolls up through the hierarchy below. The upper levels come from the account structure; the lower levels come from tags.

Account registry: keep one record per account, subscription or project with business unit, default cost centre, default owning team and default environment. The account vending process in the Landing Zone Design (architecture/landing-zone-design) MUST create the registry record before the account is handed over.

Allocation precedence: when sources disagree, use the first that applies:

1. for an allocated charge from a data generator-calculated split cost allocation (the FOCUS term; AllocatedResourceId is not null): the mandatory keys in AllocatedTags, falling back to Tags for keys not present there;
2. resource tag on the charge (FOCUS Tags);
3. account registry defaults for the SubAccountId;
4. a shared-cost rule from section 8;
5. the unallocated bucket owned by the FinOps team.

Split rows come first because, on an allocated charge, Tags carries the tags of the origin resource (for example the cluster node), and FOCUS does not repeat those tags in AllocatedTags. Ranking Tags first would send every split row back to the node owner and undo the split.

4. Mandatory tags and allowed values

4.1 Tag dictionary

4.2 Format rules

• Keys and values MUST be lowercase, using letters, digits and hyphens only. Some providers accept only lowercase label keys; one format avoids per-provider mapping.
• Values SHOULD be at most [63] characters (Example, chosen to fit the strictest provider in use; check the current limits of each provider).
• Keys MUST NOT carry a provider-reserved prefix. FOCUS requires provider-defined tags to carry a provider prefix, so user-defined keys without one remain distinguishable in the Tags column.
• Values MUST come from the source of truth named in 4.1. Free-text values are rejected by enforcement.
• Tags MUST NOT contain secrets or personal data: tag values are visible in billing exports to everyone who can read cost data.

4.3 Changing the dictionary

Request new keys or new allowed values through [FinOps intake]. The FinOps team decides within [10 business days] after consulting finance and the platform team. New mandatory keys take effect no earlier than [60 days] after approval, with audit-mode enforcement during that period.

5. Policy statements

6. Tag governance and enforcement

6.1 Rollout of enforcement

1. Audit mode for [60 days]: policies report but do not block. Publish the list of failing resources per team weekly.
2. Deny in new production deployments once audit findings for production fall below [5%] of resources.
3. Deny everywhere except sandbox after a further [30 days].
4. Remediate the remaining backlog with registry defaults and team tickets; track in the monthly report.

6.2 Example policy as code

Example only: an Open Policy Agent rule (Rego v1 syntax) that checks a Terraform plan in JSON form (terraform show -json) for the mandatory tags and the environment values. It evaluates the effective tags, not only the tags written on the resource: with the AWS provider default_tags block (the usual way to implement CAT-POL-005 inheritance), the merged set appears in tags_all and tags may be null. Adapt attribute names per provider (some use labels).

package corvid.tagging

import rego.v1

required := {"cost-center", "owner-team", "service", "environment"}

allowed_environments := {"prod", "staging", "dev", "sandbox", "shared"}

# Provider default tags from the plan configuration (AWS provider
# default_tags block); empty when the provider sets none.
default_tags := dt if {
	some block in input.configuration.provider_config.aws.expressions.default_tags
	dt := block.tags.constant_value
} else := {}

changed contains rc if {
	some rc in input.resource_changes
	some action in rc.change.actions
	action in {"create", "update"}
}

# A tag attribute can be null or absent (unknown until apply).
as_map(x) := x if {
	is_object(x)
} else := {}

attr(rc, name) := as_map(object.get(rc.change.after, name, {}))

# Effective tags: provider defaults, then the merged tags_all attribute
# where the plan already knows it, then resource tags (right side wins).
effective_tags(rc) := object.union(
	object.union(default_tags, attr(rc, "tags_all")),
	attr(rc, "tags"),
)

deny contains msg if {
	some rc in changed
	missing := required - object.keys(effective_tags(rc))
	count(missing) > 0
	msg := sprintf("%s: missing mandatory tags %v", [rc.address, missing])
}

deny contains msg if {
	some rc in changed
	env := effective_tags(rc).environment
	not env in allowed_environments
	msg := sprintf("%s: environment value %q is not allowed", [rc.address, env])
}

Example limitations to test before switching to deny:

• tags_all is often unknown at plan time and is then absent from change.after; the rule therefore adds the provider default tags read from the plan's configuration section. Default tags set through a variable or an aliased provider (aws.<alias>) appear as references, not constant values, so read them from your own pipeline input instead.
• Run the policy against a plan that relies only on inherited tags and confirm that it passes; a policy that rejects compliant resources is the usual reason a deny rule gets removed.
• Keep the list of resource types that cannot carry tags in the policy repository and exclude them explicitly, so that exclusions are reviewed like any other code change.

7. Untagged and untaggable cost

Untaggable cost rules:

8. Shared cost allocation rules

Choose the method per shared cost:

8.1 Worked example: support plan (SHR-02)

Example (a different month from the section 11 example): support plan charge in the month: USD 18,000. Direct allocated EffectiveCost by business unit: Storefront USD 300,000, Payments USD 150,000, Data USD 150,000, total USD 600,000.

8.2 Worked example: shared cluster with idle capacity (SHR-01)

Example: cluster node cost in the month: USD 120,000. Share of requested CPU hours: checkout 45%, catalog 30%, payments-core 15%; the remaining 10% is idle capacity that no workload requested.

The alternative is to leave idle cost (USD 12,000) with the platform team as a visible efficiency target. Choose one approach, state it in the rule, and report idle cost as its own number either way, so that redistribution does not hide waste.

8.3 Worked example: observability platform (SHR-03)

Example: platform charge USD 30,000 with fixed shares agreed for the year: Storefront 40%, Payments 40%, Data 20%. Allocated: USD 12,000, USD 12,000 and USD 6,000. An even split would give USD 10,000 each, moving USD 4,000 of cost onto Data, the smallest consumer.

9. Showback and chargeback

Decision for this organisation: [Example: Showback for all teams from the effective date; chargeback to business units from [YYYY-MM-DD] once allocation coverage (KPI-02) meets its target in section 11 for three consecutive months. Platform shared capabilities stay centrally funded during platform adoption, as set in the Internal Developer Platform Charter (architecture/internal-developer-platform-charter).]

Dispute process: owners raise disputes within [10 business days] of the report. The FinOps team corrects tags or rules in the next cycle; finance posts corrections only above [USD 1,000] per line (Example threshold).

10. Mapping to FOCUS 1.4

10.1 Custom columns for enrichment

When the organisation adds its own allocation results to a FOCUS dataset, name the added columns with the x_ prefix (required by the Custom Column Handling attribute of FOCUS 1.4) and in Pascal case with Id or Name suffixes (recommended by the same attribute), so that they cannot collide with columns added in later FOCUS versions.

The FOCUS specification also covers data generator-calculated split cost allocation: when a provider splits one charge into allocated charges, the sum of each cost and quantity column across the allocated charges must equal the origin charge. Apply the same rule to internal splits: the sum of allocated amounts per rule MUST equal the source charge, and the monthly report MUST show the reconciliation.

11. Compliance measurement

Example month for Corvid Commerce:

• KPI-01 tag compliance = 571,650 / 618,000 = 92.5% (below the 95% target: action required).
• KPI-02 allocation coverage = (571,650 + 22,000 + 30,000) / 640,000 = 623,650 / 640,000 = 97.4% (below the 98% target).
• KPI-03 unallocated share = 16,350 / 640,000 = 2.6% (above the 2% limit: CAT-POL-010 investigation required).

The Cloud Cost Review (ops/finops-cost-review) reports these KPIs per account each period. This standard owns their definitions.

12. Exceptions and risk acceptance

Request exceptions through [FinOps intake] with the policy statement affected, the reason, the compensating allocation method and an end date. Exceptions are granted for at most [6 months] and may be renewed once; a second renewal needs the platform steering group or the CFO delegate.

13. Review cycle and related documents

Review this standard at least yearly, and also after a reorganisation, a new cloud or SaaS provider, a new FOCUS version, or a quarter in which KPI-03 exceeded its limit twice. The FinOps lead owns the review; finance confirms the hierarchy.

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Based on the FinOps Open Cost and Usage Specification (FOCUS) 1.4, ratified on 2026-06-04, and aligned with the FinOps Framework (2026 update) of the FinOps Foundation, both published under the Creative Commons Attribution 4.0 International licence (CC BY 4.0, https://creativecommons.org/licenses/by/4.0/). FOCUS is © Joint Development Foundation Projects, LLC, FinOps Open Cost and Usage Specification (FOCUS) Series and its contributors. See https://focus.finops.org/ and https://www.finops.org/framework/. FOCUS column names and FinOps capability names are used with attribution; the specification text is not reproduced, and all policy statements, rules, examples and the policy-as-code sample are original to this collection. FinOps capability names change between framework updates: check the current list at finops.org/framework before use. Open Policy Agent and Terraform are trademarks of their owners; this template is not affiliated with or endorsed by them. Corvid Commerce is fictional. Check the current official versions before use. Template licence: MIT.