Every resource carries an owner label, yet much of the bill still groups as unattributed — where is the label being lost?

## The inventory is not the bill The common mental model is that labelling every resource labels the bill. It does not, because the report is assembled from charge lines and a charge line is not a resource. A single resource can generate several lines under different charge units; a managed service generates lines for things you never explicitly created; and some lines have no resource behind them whatsoever. Every one of those is a place a label can fall off. ## Where the label goes missing 1. **Charges from resources created on your behalf.** Ask a managed data service for an instance and the platform may create storage, a backup set, a reserved address and telemetry alongside it, each billed separately. Whether the parent's labels propagate to those children is a platform design decision, and platforms differ: some copy labels down at creation, some copy them only for certain resource families, and some do not copy them at all. This is usually the largest single leak, because it scales with how much managed service you buy — exactly the direction most estates are moving. 2. **A label key that is not a reporting dimension yet.** On many platforms a label exists on the resource from the moment you apply it, but only appears as a grouping column in the detailed cost report once the key is explicitly enabled for cost reporting. Until then the labels are real and invisible, and enabling it is forward-only — it does not populate the column for periods already closed. 3. **Key drift.** `owner`, `Owner` and `owner-team` are three separate columns, each partly populated. The grouping is done on the exact string, so a case difference is not a near-miss: it is a different key, and one team's spend arrives as several buckets that each look like someone else's gap. 4. **A stale value.** A label naming a team that was dissolved is technically coverage and practically unattributed, because the report resolves it to nobody who can act. Coverage measured as `has a label` overstates attribution; coverage measured as `has a label resolving to a current owner` is the number worth tracking. 5. **Charges with no resource.** Account-level and support fees, third-party software purchased through the provider, the unused portion of a commitment bought centrally, adjustments and credits. There is nothing to label. These belong with the shared-cost pool and an agreed rule, not with the labelling backlog. ## Diagnosing it in the right direction The instinct is to re-audit the inventory, which is the wrong end. The inventory is where you already looked and found everything labelled. Work from the bill instead: - Total the attributed spend and subtract it from the invoice. That difference is the real problem statement. - Group the remainder by whatever complete key you have — the account it was billed to, and the charge unit — and rank the buckets by spend. - Read the top bucket and ask which of the five causes above it is. The answer is usually obvious once you are looking at a charge line rather than at a resource list. | Symptom in the remainder | Likely cause | |---|---| | Storage and backup lines next to a labelled managed instance | Child resources did not inherit the parent's label | | A key you know is applied everywhere is simply absent as a column | The key is not enabled as a reporting dimension | | One team appearing under two or three near-identical values | Key drift in spelling or case | | Lines with no resource identifier at all | Account-level fees, third-party purchases, commitment remainder | ## Fixing it, and what cannot be fixed For propagation gaps, the durable fix is to make whatever creates the resource apply labels to everything it creates, rather than relying on the platform to copy them — that keeps the behaviour the same wherever you run. For the reporting-dimension gap, enable the keys once, early, and treat the enablement date as the start of your attributable history. For drift, converge on one spelling and validate at creation, because validating later only fixes the future. For stale values, join the label value against a current team directory and report the mismatches as unattributed rather than counting them as covered. What cannot be fixed is the past. Every one of these repairs is forward-only, which is the same property as every other labelling repair, and it is why the honest report says *attributable from this date* rather than implying the history is clean.