Allocation Score v1.1, methodology
Everything the score does, in full.
A metric whose definition is private cannot be cited, and one whose definition moves silently cannot be trusted, so this page is versioned and every change is listed at the bottom.
The foundation we build on
The backbone is the FinOps Foundation’s published KPI, Percentage of Costs Associated with Untagged CSP Cloud Resources: untagged cost divided by total cost. The Foundation documents a variant restricted to taggable resources, and states that 0% is unattainable because some resources cannot be tagged, so under 10% is the recommended initial goal. We use the taggable-denominator variant and anchor grade A to that 10% target.
A tag on its own does not attribute spend to a team: a Name tag or a cluster tag names a resource, not an owner. The Foundation’s Tagging Policy Compliance KPI asks for the keys your policy requires, so the headline figure, and its comparison with the 10% target, is the share of taggable spend missing a required tag. With no required tags entered it falls back to spend with no tag of your own, and says so. Tags the cloud adds itself are listed apart and never count.
FinOps Foundation material is used under CC BY 4.0. Finitizer is not affiliated with the FinOps Foundation.
The five components
Coverage
40 pointsShare of taggable spend that can be attributed to a team: spend carrying every required tag key. With no required tags entered, spend carrying at least one tag of your own. Tags the cloud adds itself (aws:, goog-, aks-managed-, eks:, kubernetes.io) never count.
Why it is weighted this way: It gets the largest weight because it is the question everything else serves: can this dollar be attributed to a team? A Name tag or a cluster tag names a resource, not an owner, so it does not answer that.
Required-tag completeness
25 pointsShare of taggable spend carrying every tag in your required set (default env, owner, cost-center, app).
Why it is weighted this way: One tag is enough to prove a resource was touched. Showback needs a specific set, and a resource tagged only with "app" cannot be charged to a cost center.
Key hygiene
15 pointsPenalizes keys that exist in more than one spelling (CostCenter / costcenter / cost_center) and keys covering under 1% of spend.
Why it is weighted this way: Variant keys silently split a dimension in two, so every report built on them is wrong in a way that is very hard to see. Orphan keys are usually abandoned experiments adding noise to every group-by.
Value hygiene
10 pointsShare of tagged spend whose value is a placeholder, tbd, test, none, xxx, and so on.
Why it is weighted this way: A tag with a placeholder value passes every coverage check and allocates nothing. It is worse than no tag, because it hides the gap.
Concentration
10 pointsShare of the spend missing a required tag held by the 10 largest resources.
Why it is weighted this way: One $40k untagged node group and four thousand $10 resources can produce identical coverage, and they are not equally bad. The first is one tagging rule away from fixed; the second is a quarter of work. The score reflects that.
Grade bands
| Grade | Score | Reads as |
|---|---|---|
| A | 90+ | Meeting the published target. |
| B | 75 to 89 | Working, with known gaps. |
| C | 60 to 74 | Showback is possible but contested. |
| D | 40 to 59 | Allocation exists on paper. |
| F | 0 to 39 | No usable allocation. |
Taggability rules
Each charge is classified before scoring. Untaggable charges leave the denominator entirely; unknown charges are counted as taggable, which is the conservative choice, and reported so you can see how much rests on it. Credits and discounts (such as AWS EdpDiscount, PrivateRateDiscount and BundledDiscount) are reported with credits, not as untaggable. Marketplace lines are told by the export’s own columns: AWS bill_billing_entity, FOCUS PublisherName and InvoiceIssuerName. Data transfer counts as untaggable only when the line names no resource.
| Matches | Verdict | Why |
|---|---|---|
| cpucredits? | taggable | Burstable CPU credits are billed to the instance, which carries tags. |
| extended ?support | taggable | Extended support is billed per database, cluster or node, which carries tags. |
| ^tax$ | untaggable | Tax is levied on the account, not on a resource. |
| support | untaggable | Support is billed as a percentage of account spend. |
| \bmarketplace\b | untaggable | Marketplace charges carry the vendor's metadata, not yours. |
| data ?transfer|egress|bandwidth | untaggable | Data transfer with no resource ID is billed at the account or lane level. |
| \b(refunds?|credits?|adjustments?)\b | untaggable | Credits and adjustments are account-level. |
| ^aws (cost explorer|budgets|config|cloudtrail)$ | untaggable | Account-level management services. |
| savings ?plan|reserved instance|committed ?use|\bcommitment\b[^:]*\bv\d+: | untaggable | Commitment charges are account-level, not resource-level. |
| ec2|compute engine|virtual machines? | taggable | Instances support tags. |
| \bs3\b|amazons3|cloud storage|blob storage | taggable | Buckets support tags. |
| \brds\b|amazonrds|cloud sql|database|dynamodb|elasticache|docdb|neptune | taggable | Database instances and tables support tags. |
| lambda|cloud functions|cloud run | taggable | Functions and services support tags. |
| bigquery|redshift|snowflake | taggable | Datasets and clusters support labels or tags. |
| kubernetes|eks|gke|aks|amazonecs|amazonecr | taggable | Clusters, node groups and repositories support tags. |
| amazoncloudwatch|amazoncloudfront|amazonvpc|elasticloadbalancing|amazonefs|amazonfsx|amazonsns|amazonsqs|amazonkinesis|amazonsagemaker|amazones\b|opensearch|awsglue|amazonmsk|amazonapigateway|amazonroute53|awsstepfunctions|awssecretsmanager|awskms | taggable | These AWS services bill per log group, distribution, load balancer, queue or similar resource, which carries tags. |
This table is incomplete by nature: cloud providers add services faster than anyone can classify them. If you find a charge we classify wrongly, we want to know.
What this score does not do
- · No benchmark percentiles. We will publish a distribution when we have collected enough anonymized scores to have one. Inventing “the median organization scores 58” today would be a fabrication, and this tool exists partly as a reaction against exactly that.
- · No judgment of your tag values. We can see that a value is a placeholder; we cannot see whether “team-alpha” is a real team.
- · No allocation of shared costs. Splitting a shared Kubernetes cluster across tenants is a genuinely hard problem and is not what this measures.
Changelog
- v1.0
- Initial published version. Five components at 40/25/15/10/10, grade A anchored to the FinOps Foundation’s under-10% target.
- 2026-10-14
- Corrections to v1.0, with weights and bands unchanged. Burstable CPU credits (CPUCredits) count as taggable. An empty required-tags list earns nothing on that component instead of full marks. A file with no taggable spend gets no score instead of 100. AWS CUR 2.0 tag keys drop the user_ prefix AWS adds, as legacy CUR keys already did, and CUR 2.0 costs are amortized per line item type.
- 2026-10-17
- Corrections to v1.0, with weights and bands unchanged. Extended support charges (RDS, Aurora, EKS, ElastiCache, OpenSearch) count as taggable: they are billed per database, cluster or node, and the word “support” had excluded them as account-level support.
- v1.1
- 2026-10-24, weights and bands unchanged. The headline is the share of taggable spend missing a required tag, not spend with no tag at all, and Coverage counts the same thing: only spend carrying every required tag key (any tag of your own when no required tags are entered), so the grade follows the headline. Key and value hygiene are still scaled by the share carrying any tag of yours. Tags the cloud adds itself never count. Concentration is measured on the 10 largest resources, not the five largest service and Region groups, which held all of it on nearly every bill. Data transfer that names a resource is taggable. Discounts are reported with credits. Marketplace lines are read from the billing entity and publisher columns. The CUR 2.0 tags column is read.
Scoring once tells you where you are. Scoring continuously tells you whether you are winning.
Finitizer recomputes allocation on every run and tracks whether NEW spend arrives tagged, the number that says whether your policy is actually working, rather than whether someone did a clean-up sprint last quarter.
See how Finitizer works