Atlas tag taxonomy for showback and chargeback
Parent: Atlas Pricing Programs, Cost Governance and TCO · Published reference · snapshot 2026-10-21 · skill ranked-3d355de6
↓ Facts as markdownall context files
Source-anchored research for Atlas tag taxonomy for showback and chargeback. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Atlas resource tags are key-value metadata that can be applied to projects and clusters. Atlas invoice CSVs add a `Tag/<key>` column for each tag key, and Atlas documents a `Tags` field in its FOCUS billing report, so the taxonomy can flow into invoice and downstream cost analysis. (high confidence) [source]
- FinOps defines showback as reporting consumption for awareness and visibility; chargeback posts consumption to organizational P&L budgets through financial processes, and chargeback reporting typically follows the finance accounting taxonomy. A practitioner article recommends validating attribution and agreeing on unallocated-cost and dispute handling before moving from showback to chargeback, because misattributed charges damage trust. (medium confidence) [source]
- Atlas invoice CSVs and Admin API responses reflect resource tags as configured when the CSV is generated or the API is invoked. If tags change during a billing cycle, Atlas says the invoice reflects only the latest configuration. Historical showback or chargeback therefore needs dated tag snapshots or a maintained mapping history outside the current resource tag state. (high confidence) (verified as of 2026-10-18) [source]
- A practical showback and chargeback taxonomy uses separate dimensions for finance ownership (such as cost-center or billing-unit), application or workload, and environment. Add team or product dimensions only when stakeholders need those separate views. This design combines Atlas's suggested tags with FinOps and AWS guidance to map spend to organizational groupings. (medium confidence) [source]
- Showback presents and reports costs attributed to an entity to increase awareness; chargeback recovers the expense through internal financial accounting. Use the same Atlas attribution dimensions for both, but apply chargeback through a separate finance process. (high confidence) [source]
- FOCUS distinguishes resource Tags from AllocatedTags: AllocatedTags describes tags applicable to charges created by data-generator-calculated split allocation and must not repeat resource tags already present in Tags. Keep source resource labels separate from derived recipient labels when a downstream chargeback process splits shared Atlas costs. (medium confidence) (verified as of 2026-10-21) [source]
How-to and procedures
- Use Atlas hierarchy as a coarse allocation layer when it matches the organization: MongoDB says an Atlas organization often maps to a business unit or department, while a project often maps to an application and environment. Atlas billing data can be viewed at organization and project level, with line-item usage details carrying project information. Resource tags can then supply dimensions that the hierarchy does not represent. (high confidence) [source]
- Use Atlas organization and project fields as structural allocation dimensions, then use resource tags for customer-specific dimensions. Atlas invoices are billed at the organization level and can be examined by project; the Atlas FOCUS mapping identifies BillingAccount as the organization and SubAccount as the Atlas project. (high confidence) [source]
Problems, failure modes and limitations
- Tags identify resource metadata but do not establish a policy for dividing a shared Atlas charge among several teams or products. The FinOps Framework treats shared-cost strategy as a separate allocation activity and describes fixed, proportional, proxy-metric, and centrally funded approaches. An Atlas cost article also notes that a project can serve multiple teams, so one resource tag cannot by itself express every beneficiary's share. (high confidence) [source]
Comparisons and alternatives
- MongoDB's invoice-tag announcement, updated March 11, 2025, says tags appear on cluster line items associated with a tagged deployment, untagged cluster line items have blank tag cells, and line items not billed at cluster level are not eligible for tags. This scopes the coverage claim: measure tagged spend against total Atlas spend and route blank or non-resource charges through an explicit allocation rule instead of assuming tag coverage is complete. (medium confidence) (verified as of 2025-03-11) [source]
- Do not put PII or PHI in Atlas resource tags. MongoDB says Billing and integrations can access cluster tags, so treat tags as operational metadata rather than private fields. (high confidence) [source]
Facts and statements
- A compact Atlas taxonomy should answer who owns the spend, what application or service incurred it, where it runs, and which finance unit receives the cost. MongoDB suggests `application` and `environment` for each resource, and lists `team`, `owner`, `cost-center`, and `billing-unit` as useful keys. AWS cost-allocation guidance also frames tags around owner, workload, and environment. Choose one canonical owner key and one canonical finance key, then keep their values aligned with the accounting taxonomy. (high confidence) [source]
- Atlas tag keys and values are case-sensitive. MongoDB recommends one standardized format across resource types and supports programmatic tag management through the Atlas Administration API, CLI, and Terraform provider. The FinOps Framework recommends enforcing ownership metadata in provisioning workflows and automating compliance checks, which helps prevent inconsistent values from accumulating in showback data. (high confidence) [source]
- Atlas documents the FOCUS `Tags` field as resource tags. FOCUS 1.3 separately defines conditional `AllocatedTags` for tags associated with charges produced by data-generator-calculated split allocation. A resource tag should therefore not be interpreted as proof that a shared charge has already been split; confirm Atlas support for `AllocatedTags` before relying on that field. (medium confidence) (verified as of 2026-10-21) [source]
- Atlas resource tags are key-value pairs that can be applied to projects and clusters. MongoDB recommends standardized, case-sensitive keys and suggests application and environment tags, with cost-center or billing-unit keys for cost allocation. (high confidence) [source]
- Atlas invoice CSVs add a Tag/<key> column for each resource tag key, and the Atlas Admin API returns resource tags in line-item data. Atlas's FOCUS report includes a Tags field and maps SubAccountName to Project, allowing external reports to group Atlas costs by tags and project. (high confidence) (verified as of 2026-10-19) [source]
- Tags do not determine how shared costs should be distributed. Define a separate policy for each shared or untaggable cost category, such as central funding, fixed allocation, proportional allocation, or allocation by a usage proxy, and document the method before using tagged costs for chargeback. (high confidence) [source]
- MongoDB's billing-tag announcement, updated March 11, 2025, says invoice tags typically appear within 48 hours, line items without an associated tag remain blank, and line items not billed at the cluster level were not eligible for tagging at that time. Track tag coverage and route uncovered costs through an explicit allocation policy. (low confidence) (verified as of 2025-03-11) [source]
Children
- Atlas invoice tag coverage and cost export reconciliation (frontier)
- Shared-cost allocation rules for managed database services (frontier)
- Atlas tag enforcement through Terraform and APIs (frontier)
Frontier under this node: Atlas invoice tag coverage and cost export reconciliation, Atlas tag enforcement through Terraform and APIs, Shared-cost allocation rules for managed database services