CostMonStart free

Calculator

Who actually spent this?

Your bill is $85,000 a month. Only a fraction of it can be pinned to a real team, project, or customer. Drag in your real numbers to see the dollars you can't attribute, an allocation confidence score, and what it would take to make this bill chargeback-ready.

Why untagged spend is a decision problem

Untagged spend isn't a reporting problem. It's a decision problem

A dashboard that says "$340,000, unlabeled" doesn't tell finance who to talk to, and it doesn't tell engineering what to cut. Every real decision that follows from a cloud bill starts from knowing whose spend it actually is: kill this service, right-size that team's fleet, or put this feature's spend in front of its own budget owner. Without that, the only decision left is company-wide: cut a little everywhere, or cut nothing at all.

That's the real cost of an unallocated bill: not a compliance gap, a decision-making one. A team can't be held accountable for a number nobody can prove belongs to it, and finance can't ask an engineering team to explain a line item it has no way to attribute back to that team in the first place.

Measure coverage by cost, not by resource count

Ninety-five percent of resources tagged and sixty percent of dollars tagged is the normal, misleading case, not an edge case. The untagged five percent of resources are disproportionately the expensive ones: a handful of large databases, load balancers, or committed-capacity purchases that got provisioned by hand, outside the usual infrastructure-as-code path, by whoever was moving fastest that week.

A tagging dashboard that reports "percent of resources tagged" is answering a question nobody asked and will make a team feel further along than it is. The only coverage number worth reporting is percent of dollars tagged, weighted by cost, which is what the scorer below computes. Check that your own provider's tagging report does the same before you trust its number.

What can't be tagged, and who pays for it

Some spend has no owner-shaped answer no matter how disciplined your tagging is: inter-AZ and egress charges, support plans, marketplace fees, shared clusters and databases serving more than one team, and AI API spend, which has no cloud-provider equivalent. An Anthropic or OpenAI invoice has no resource to tag at all; attribution there comes from which workspace or API key made the call, not from a tag on a line item.

That leftover pool still has to land somewhere, and every way of landing it has a real trade-off. Splitting it proportional to each team's share of the bill scales with size but hits the biggest team hardest in absolute dollars. An even split is fairer to a large team but can be a painful, arbitrary hit to a small one. Having the platform team absorb it keeps product teams' numbers clean but removes their incentive to ever help shrink the pool.

Score your bill

See how much of this bill you can actually name

Enter the numbers you already have a rough sense of. Everything below computes in your browser — nothing you type here is sent anywhere.

Your bill
$85,000

Everything you pay across every provider this month, including cloud infrastructure, AI/LLM APIs, and SaaS

Tag coverage
80%

Resources you could tag if you wanted to. Excludes egress and cross-AZ charges, support, marketplace, shared services, and AI API spend, which has no resource tags at all

75%

Share of taggable dollars (not resource count) carrying your full required tag set

90%

Share of tagged spend using an approved value, not a typo, an alias, or the wrong case (Payments vs. payments vs. pmts)

Who it's split across
6

How many teams, cost centers, or products share this bill

Shared/untaggable-cost policy

How the spend that can't be tagged (the gap this calculator is measuring) gets billed back to teams

Who this bill actually belongs toUpdates live
Live
At these numbersYou spend $85,000/mo. 54% of it can be pinned to an owner.$39,100/mo you can't put a name to.
054 / 100100
Attributable
$45,900/mo · $550,800/yr
Unattributable
$39,100/mo · $469,200/yr
Blur per team
$6,517/mo
Gap to chargeback-ready
$34,850/mo
Directionally useful

Good enough to point at, not good enough to bill.

This is the normal, honest middle: solid enough to tell a team roughly where its spend sits and to prioritize the next fix, not solid enough to put a number on anyone's budget. Showback conversations at this level should be framed as directional, not final. Treat every number as a rounded estimate until coverage climbs further.

Read the coverage-to-chargeback path →
Start free

No vendor price table drives this — every dollar figure comes from your own inputs. Computes entirely in your browser; nothing typed here is sent anywhere.

Starter kit

A tag schema and three ways to make it stick

A minimum schema, plus the Terraform default, the AWS Organizations tag policy, and the IAM condition that keep it from drifting. Copy any of it straight into your own stack.

KeyRequiredAllowed valuesWhy it exists
ownerYesA team slug or on-call rotation name, never a person's name; people leave, resources outlive themAnswers "who do I ask" the moment a resource looks abandoned, oversized, or unexpectedly expensive.
serviceYesThe service or repo slug the resource belongs to, matching its name in your service catalog or CITies infrastructure cost back to the codebase that provisions it, not just the team that happens to own that codebase.
envYesprod | staging | dev | test (four values, no fifth invented later)Separates spend that has to work from spend that's negotiable; nearly every cut lands in the second bucket.
cost-centerYesThe finance system's actual cost-center code, not a label engineering invented independentlyThe one key that lets a chargeback number land in the general ledger without a manual re-mapping step.
customerOnly if it appliesThe customer or account ID, only for resources dedicated to, or metered by, one customerTurns a usage-based product's shared infrastructure cost into a per-customer margin number.
Terraform: apply the schema by default
provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      owner       = "checkout-team"
      service     = "checkout-api"
      env         = "prod"
      cost-center = "cc-1042"
    }
  }
}
AWS Organizations: enforce allowed values
{
  "tags": {
    "env": {
      "tag_key": { "@@assign": "env" },
      "tag_value": { "@@assign": ["prod", "staging", "dev", "test"] },
      "enforced_for": { "@@assign": ["ec2:instance", "rds:db", "s3:bucket"] }
    },
    "cost-center": {
      "tag_key": { "@@assign": "cost-center" }
    }
  }
}
IAM: require the tag at creation time
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRunInstancesWithoutCostCenter",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": { "aws:RequestTag/cost-center": "true" }
      }
    }
  ]
}

The AWS Organizations tag policy above only enforces case and allowed values on tags that are present — it does not, by itself, block a resource from being created without one. Pair it with the IAM condition to actually require the tag at creation time.

Activation, the coverage-to-chargeback path, and enforcement

The activation trap: tagging the resource isn't enough

On AWS, a user-defined cost allocation tag has to be separately activated in the Billing and Cost Management console before it appears in Cost Explorer or a Cost and Usage Report. Tagging the resource itself doesn't do it. Activation used to be strictly forward-looking with no way back; AWS now lets an account request a backfill of up to twelve months, but only for the stretch where the resource was already, physically, tagged. A tag activated today still can't retroactively create history for a resource that was untagged last year.

That makes activating every tag key you plan to ever use a same-week task, not a someday task. The cost of waiting isn't a delay; it's a hole in the historical record that a backfill request can't fill unless the tag was already there. Other providers carry their own version of the same trap: Google Cloud's labels have no built-in mechanism for a project's labels to propagate down to the resources inside it, and Azure tags don't inherit from a resource group either, unless you deliberately attach the built-in "Inherit a tag from the resource group" policy. In both cases, a tag scoped one level up does nothing for the resource underneath it until something explicit copies it down.

Coverage → showback → chargeback: what each stage needs

The four bands above aren't arbitrary cutoffs; they map to what a number is safe to do. Below 50, the bill can't support any team-level statement at all. Between 50 and 80, it's solid enough to point a team at its rough number and prioritize from there, but not solid enough to put in front of anyone as final. Between 80 and 95, showback holds up. The number is close enough to trust for visibility and behavior change.

Chargeback needs the top band, and that's not caution for its own sake: any team billed off a number built on a meaningful share of unattributed or misattributed spend has a legitimate argument that the bill is wrong, and a chargeback program that loses that argument once loses the trust it needs to run at all. Reaching for chargeback before the coverage supports it turns a FinOps process into a dispute process.

Enforcement that doesn't slow engineering down

The fix that holds is layered, not a single gate: tag defaults baked into infrastructure-as-code so a resource is born tagged instead of tagged later, a narrow IAM condition that blocks resource creation specifically when a required tag is missing, and a recurring drift sweep against the normalized cost view to catch whatever still slips through both of those.

What deliberately isn't on that list is blocking every deploy on a tag-lint failure. A hard gate on every commit turns tagging into an engineering-velocity argument instead of a FinOps one, and it's the kind of control that gets quietly bypassed the first time it blocks an incident fix. A weekly sweep that flags drift and files a ticket keeps the same discipline without ever being the reason a deploy didn't ship.

Where CostMon fits, and where it can't help

CostMon reads whatever tags already exist across every connected provider into the same normalized daily view, so a dollar tagged checkout on AWS and a dollar tagged checkout on an AI provider's workspace land in the same row and can be summed together. Unattributed spend is a first-class number on the dashboard, not buried in an "Other" bucket that hides how large it really is.

CostMon does not create, enforce, or fix a single tag. It reads the provider's billing export exactly as tagged, or not, at the source. The schema, the Terraform defaults, and the IAM condition below are still yours to apply. And for AI API spend specifically, since there's no resource to tag in the first place, CostMon attributes it by connector, workspace, or API key instead: ordinary connector metadata doing the same job a tag would.

Sources

Where the provider-specific claims on this page come from

Every activation, limit, and enforcement claim above is attributed to a named primary source, re-verified as of 2026-08-06.

  • AWS — Activating User-Defined Cost Allocation Tags

    A user-defined tag must be separately activated in Billing and Cost Management before it appears in Cost Explorer or a Cost and Usage Report. Applying the tag to the resource is not enough on its own.

  • AWS — Backfilling Cost Allocation Tags

    A management account can request a backfill of up to twelve months of cost allocation tag data, but only for periods where the resource was already tagged. It does not invent tag data for a resource that was untagged at the time. Backfill requests are repeatable rather than single-use: one at a time, and no more than one every 24 hours.

  • AWS — Tag Policy Enforcement for AWS Organizations

    Verbatim: "Basic compliance rules do not enforce tag compliance on resources that are created without tags... You cannot use this capability to ensure that required or mandatory tag keys are configured at resource creation." A tag policy alone governs case and allowed values on tags that exist; requiring a tag's presence needs a separate control, like an SCP or the IAM condition below.

  • AWS — Controlling Access to AWS Resources Using Tags

    The aws:RequestTag condition key controls what tag key-value pairs can be passed when creating or tagging a resource; paired with a Null condition on the same key, it can deny a creation request that omits a required tag entirely.

  • Google Cloud — Labels Overview

    GCP's equivalent of a resource tag is a label (up to 64 per resource, lowercase keys/values up to 63 characters). Labels are exported to BigQuery and surfaced in billing reports, but the docs describe no built-in mechanism for a label to propagate from a project down to the resources inside it.

  • Microsoft Azure — Tag Resources, Resource Groups, and Subscriptions

    Up to 50 tag name-value pairs per resource, resource group, or subscription (tag name capped at 128 characters on storage accounts specifically, 512 elsewhere; values capped at 256). Tags do not automatically inherit from a resource group to the resources inside it.

  • Microsoft Azure — Azure Policy Built-In Policy Definitions

    "Inherit a tag from the resource group" (definition id cd3aa116-8754-49c9-a813-ad46512ece54) copies a tag down from the parent resource group whenever a resource is created or updated. It's Azure's opt-in answer to the inheritance gap above. A second variant only fills the tag in when it's missing, rather than always overwriting it.

  • Anthropic — Usage & Cost Admin API

    The usage and cost report endpoints group and filter by api_key_id, workspace_id, model, and similar dimensions; there is no free-form tag field anywhere in either schema. Attribution runs through the API key and workspace, not a resource tag.

  • OpenAI — Usage & Costs API

    The Costs endpoint groups by project or line item; the separate Usage endpoints add dimensions like api_key_id. Neither exposes an arbitrary tag field, the same shape as Anthropic's: attribution by project and key, not by a tag on the invoice.

FAQ

Common questions about cost allocation and tagging

Does this scorer need my real tagging data to work?

No. Every input is a percentage or dollar figure you already have a rough sense of: your total bill, roughly how much of it could even carry a tag, roughly what share of that is actually tagged, and roughly how much of what's tagged uses a correct value. It's a modeling tool, not a live integration.

Why does the calculator ask for coverage "by cost" instead of "by resource count"?

Because the two numbers routinely disagree, and cost is the one that matters. A handful of untagged resources (a big database, a load balancer, a large committed-capacity purchase) can carry a disproportionate share of the dollar total even while representing a small share of the resource count. Coverage by resource count can look nearly complete while the dollars say otherwise.

What's the difference between coverage and accuracy?

Coverage asks whether the required tags are present at all. Accuracy asks whether the values on those tags are correct: the approved spelling and casing, not a typo or a team's private alias. A dollar tagged cost-center: Payments when the approved value is payments fails accuracy even though it passed coverage, and it's just as unattributable for reporting purposes as an untagged dollar.

Why is AI/LLM API spend excluded from "taggable share"?

Because there's no resource to tag. A cloud instance or bucket is a thing you can attach a key-value pair to; an Anthropic or OpenAI API call is a metered event with no resource behind it at all. Attribution for that spend comes from which workspace or API key made the call, which is why this calculator treats it as untaggable by construction rather than as a coverage gap to close.

Which shared-cost policy should we actually use?

There's no policy without a trade-off. Proportional scales the unattributable pool with team size but hits the biggest team hardest in absolute dollars. Even split is fairer to a large team but can be an arbitrary, painful hit to a small one. Platform-absorbs keeps product teams' numbers clean but removes their incentive to help shrink the pool that's driving it. Pick based on whether the goal is changing behavior or producing a clean number.

What does "gap to chargeback-ready" actually mean?

It's the dollar amount of spend that still needs to gain correct tags (present and accurate) before the bill crosses a 95 confidence score, the threshold this page treats as safe to bill back. It's expressed in dollars rather than percentage points because a team can act on a dollar figure directly: it's the size of the tagging cleanup left to do.

Is 95 an arbitrary threshold for chargeback-ready?

It's a deliberately high bar, chosen because chargeback only works if the number can survive a dispute. Below that level, a team being billed has a legitimate argument that some real share of the charge isn't theirs, and a chargeback program that loses that argument once tends to lose the trust it needs to keep running.

Does CostMon apply, activate, or enforce any of these tags for us?

No. CostMon reads whatever tags already exist in a provider's billing export and normalizes them across connectors. It doesn't create tags, activate cost allocation tags in a provider's billing console, or enforce a tag policy. The schema, the Terraform default, the AWS Organizations tag policy, and the IAM condition above are yours to apply at the source.

Can I use the Terraform, tag policy, and IAM snippets as-is?

Treat them as a starting shape, not a drop-in final policy: swap in your own key names if they differ from the five-key schema above, and confirm your account's actual resource types and required tag set before applying the Organizations tag policy or the IAM condition. Both can affect resource creation across an entire account or organization.

A total nobody owns, nobody fixes.

An unattributed cost stays unowned. CostMon assigns spend to an owner, so someone can act on it.

Esc