← Agent Frameworks 🕐 22 min read

Agent Frameworks

AI Cost Chargeback and Showback Models for Enterprise (2026)

1. The Core Problem: AI Costs Are Invisible Until They Are Not · March 2026

Enterprise AI spend has a characteristic failure mode. During the pilot phase, costs are absorbed into a central innovation or IT budget. The usage is modest. No one complains.

Enterprise AI spend has a characteristic failure mode. During the pilot phase, costs are absorbed into a central innovation or IT budget. The usage is modest. No one complains. Then a business unit embeds an LLM into a workflow that runs 40,000 times a day, and the monthly bill for that single workflow exceeds what the entire experimental budget used to be. At that point, whoever owns the central bill has a problem with no good options: absorb a cost they cannot justify, or retroactively institute a chargeback that teams experience as a surprise tax.

The correct time to design cost allocation is before the first production workload goes live — not after the first bill arrives. This note covers the full implementation stack: the decision between showback and chargeback, the methodologies for cost attribution, the tooling layer, the finance integration, and the governance to prevent the system from being gamed.

The primary infrastructure covered: AWS Bedrock (Application Inference Profiles, Cost Explorer, Cost Categories), LiteLLM (SpendLogs, virtual keys, budget enforcement), and the organizational process layer that makes the numbers mean something to a CFO.

2. Showback vs. Chargeback: Decision Framework

These two models are frequently conflated. They have different purposes, different organizational readiness requirements, and different failure modes.

2.1 Definitions

Showback allocates costs to business units on paper — teams see what they would have been charged, but no money moves. The central AI budget absorbs the actual cost. The goal is visibility and behavioral change through transparency, not financial accountability.

Chargeback transfers actual cost from a central budget to a business unit’s cost center. Money moves. The business unit’s P&L is affected. Spending decisions must be justified to that unit’s leadership, not just to central IT.

2.2 When Showback Is the Right Model

Showback is appropriate when:

AI infrastructure is new and teams are still learning what usage patterns are reasonable. Charging for behavior that teams do not yet understand how to control produces resentment, not accountability.
The organization has not yet established a baseline for what AI work costs. You cannot set fair allocation rates without 3–6 months of usage data.
Business unit leadership does not yet have AI cost as a budget line item. Chargeback into a budget that has no allocated headroom forces teams to absorb AI costs by cutting something else — which creates pressure to underuse AI, defeating the purpose.
The AI platform team is still maturing the cost attribution tooling. Billing disputes over inaccurate allocation data destroy trust in both the cost system and the platform team.

Showback with a concrete sunset date is better than indefinite showback. Teams should know 6 months in advance when costs will start moving.

2.3 When Chargeback Is the Right Model

Chargeback is appropriate when:

Business units have had 3–6 months of showback data and understand their usage patterns.
Finance has approved AI cost as a recognized budget line item in department cost centers.
The attribution methodology has been audited and teams accept its accuracy.
There is executive sponsorship at the CFO level — without finance ownership, chargeback becomes an internal IT policy that departments can simply ignore.
The platform team has a dispute resolution process. Without it, the first contested allocation becomes a political crisis.

2.4 Common Failure Modes of Premature Chargeback

The phantom budget problem. Finance approves chargeback before allocating budget to receiving departments. Teams are billed for costs they have no approved budget to cover. Resolution requires emergency reforecasting, which consumes management time and creates permanent hostility toward the AI program.

Inaccurate initial rates. Early chargeback rates are set on pilot data that does not represent production usage. When production workloads are 10x heavier than the pilot, teams receive bills they consider fraudulent. The correct response to this pattern is: pilot rates are showback-only; chargeback begins only after a full production quarter has been observed.

Ungameable attribution without gaming controls. As soon as chargeback is in place, teams have an incentive to misattribute usage. If tagging is manual, teams under-tag their usage and over-attribute to shared pools. If tagging is automated but application IDs are self-reported, teams create misleading application hierarchies. See Section 6 for controls.

Missing the shared infrastructure allocation. Direct attribution covers usage that maps cleanly to a single team. It misses the 20–40% of AI infrastructure costs that are genuinely shared: the model serving layer, the API gateway, logging and observability infrastructure, security controls, and the platform team’s headcount. A chargeback model that only allocates direct usage leaves a structural hole in the budget.

3. Cost Allocation Methodologies

Three methodologies apply to enterprise AI, often in combination.

3.1 Direct Attribution

Direct attribution assigns costs to the team or application that incurred them, at the point of incurrence. This is the most accurate and the easiest to defend in a dispute.

AWS Bedrock: Application Inference Profiles

Application Inference Profiles (AIPs) are the primary Bedrock mechanism for direct attribution. An AIP is a configuration object that copies a foundation model’s invocation settings and attaches a mandatory applicationId tag. Any invocation through an AIP automatically inherits the tag — attribution is structural, not dependent on caller discipline.

Creating an AIP per business unit or product team:

aws bedrock create-inference-profile \
  --inference-profile-name "finance-reporting-gpt4" \
  --description "Finance BU — reporting automation workloads" \
  --model-source copyFrom="us.anthropic.claude-3-5-sonnet-20241022-v2:0" \
  --tags key=BusinessUnit,value=Finance \
           key=CostCenter,value=CC-1042 \
           key=Product,value=ReportingAutomation \
           key=Environment,value=Production

The ARN for this profile is what finance teams pass to their applications. Calls made through the profile surface in Cost Explorer under the applicationId tag without any additional instrumentation.

A single AWS account can have up to 100 AIPs. For organizations with more than 100 teams or products, a hierarchy is required: top-level AIPs per business unit, with application-level attribution handled by LiteLLM (Section 3.3) or a custom API gateway layer that appends secondary tags.

AWS Cost Explorer tag filtering

Once AIPs are in place with consistent tag schemas, Cost Explorer produces business-unit-level breakdowns natively:

Group by BusinessUnit tag → total AI cost per BU per month
Group by CostCenter tag → ready for GL code mapping (Section 7)
Group by Product tag → cost per product, usable in product P&L

Cost Explorer data has a 24-hour lag. For real-time budget enforcement, pair with AWS Budgets alerts per tag group.

3.2 Activity-Based Allocation

Activity-based allocation assigns costs proportional to a measurable unit of activity — most commonly tokens consumed. This is appropriate when direct attribution is impractical (e.g., a shared prompt engineering platform used by many teams without per-team API paths).

Token-based formula:

BU_share = (BU_tokens / total_tokens) × total_infrastructure_cost

The numerator (BU_tokens) comes from LiteLLM SpendLogs or Bedrock model invocation logs. The denominator (total_infrastructure_cost) must include not just model fees but also:

API gateway compute (typically 8–15% of model cost at scale)
Observability stack (Langfuse, Helicone, or equivalent) — 2–5%
Vector database infrastructure if shared — varies widely
Security and compliance tooling — 3–8%
Platform team headcount allocated to AI infrastructure — often 20–30% of total when properly accounted

The overhead multiplier in practice ranges from 1.3x to 1.6x model spend. Organizations that charge only for model tokens systematically under-recover infrastructure costs and build structural budget deficits into the AI program.

3.3 LiteLLM as Chargeback Infrastructure

LiteLLM Proxy’s SpendLogs table is the most operationally practical source of truth for multi-team AI chargeback in organizations that route inference through a central proxy.

Virtual keys as cost attribution units

Each team or application receives a distinct virtual key. LiteLLM tracks spend, token counts, and request counts per key in the LiteLLM_SpendLogs table. A team-level budget can be enforced at the key level:

# Creating a virtual key for the Finance BU with a monthly budget
import litellm
from litellm.proxy.proxy_server import generate_key_fn

key_response = await generate_key_fn(
    duration="30d",
    key_alias="finance-reporting-prod",
    team_id="team_finance",
    metadata={
        "business_unit": "Finance",
        "cost_center": "CC-1042",
        "product": "ReportingAutomation"
    },
    max_budget=2500.00,  # USD monthly limit
    budget_duration="monthly",
    soft_budget=2000.00,  # alert threshold
    models=["claude-3-5-sonnet", "gpt-4o"]  # permitted models
)

SpendLogs as monthly invoice source

SpendLogs records every request with: startTime, endTime, model, api_key, user, team_id, request_id, spend, prompt_tokens, completion_tokens, metadata.

Monthly invoice generation from SpendLogs:

SELECT
  metadata->>'business_unit'         AS business_unit,
  metadata->>'cost_center'           AS cost_center,
  DATE_TRUNC('month', startTime)     AS billing_month,
  SUM(prompt_tokens)                 AS total_prompt_tokens,
  SUM(completion_tokens)             AS total_completion_tokens,
  SUM(spend)                         AS raw_model_cost_usd,
  SUM(spend) * 1.40                  AS fully_loaded_cost_usd,  -- 1.40x overhead multiplier
  COUNT(*)                           AS total_requests
FROM "LiteLLM_SpendLogs"
WHERE startTime >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
  AND startTime  < DATE_TRUNC('month', CURRENT_DATE)
GROUP BY 1, 2, 3
ORDER BY 1, 3;

The 1.40 overhead multiplier should be calibrated quarterly against actual infrastructure costs. In the first year, treat it as a variable reviewed monthly.

Team-level dashboard

LiteLLM’s built-in UI exposes per-team spend dashboards. For organizations that want to give business unit finance teams self-serve access to their own consumption data without access to other teams’ data, LiteLLM’s team-scoped API keys can be used to gate dashboard access — each team’s finance contact receives a read-only key scoped to their team’s data.

3.4 Proportional Allocation for Shared Infrastructure

Some infrastructure costs cannot be attributed to any specific team. The central model serving layer, the security controls, the platform team’s time spent on model evaluation and procurement — these are genuinely shared overhead.

Standard approach: allocate shared overhead proportionally to direct usage share.

Team_overhead_allocation = (Team_direct_cost / Total_direct_cost) × Total_shared_overhead

This means a team that drives 30% of direct model costs also absorbs 30% of shared infrastructure overhead. This is the same logic that drives product-line overhead absorption in traditional manufacturing cost accounting.

Document the overhead allocation methodology and present it to finance for sign-off before the first chargeback cycle. If finance does not approve the methodology, the first disputed invoice has no resolution path.

4. AWS Cost Categories for AI Chargeback

AWS Cost Categories provide a mechanism to define custom allocation rules that surface in Cost Explorer, Cost and Usage Reports, and AWS Budgets. They can be applied retroactively up to 12 months, which makes them useful for retrofitting chargeback onto existing deployments.

4.1 Mapping to Business Unit Cost Centers

A Cost Category rule maps one or more tag conditions to a named cost category value (the business unit). Example structure:

{
  "Name": "AI-BusinessUnit",
  "RuleVersion": "CostCategoryExpression.v1",
  "Rules": [
    {
      "Value": "Finance",
      "Rule": {
        "And": [
          {"Tags": {"Key": "BusinessUnit", "Values": ["Finance"]}},
          {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Bedrock"]}}
        ]
      }
    },
    {
      "Value": "Engineering-Platform",
      "Rule": {
        "And": [
          {"Tags": {"Key": "BusinessUnit", "Values": ["Engineering"]}},
          {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Bedrock"]}}
        ]
      }
    },
    {
      "Value": "Untagged-AI",
      "Rule": {
        "And": [
          {"Not": {"Tags": {"Key": "BusinessUnit", "Values": ["Finance", "Engineering", "Marketing", "Operations"]}}},
          {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Bedrock"]}}
        ]
      }
    }
  ],
  "SplitChargeRules": [
    {
      "Source": "Untagged-AI",
      "Targets": ["Finance", "Engineering-Platform", "Marketing", "Operations"],
      "Method": "PROPORTIONAL"
    }
  ]
}

The SplitChargeRules section handles the untagged-or-shared bucket — it distributes unattributed costs proportionally to the tagged buckets. This eliminates the “what do we do with the untagged usage” problem that breaks most first-generation chargeback implementations.

4.2 Retroactive Application

Cost Categories can be applied retroactively to the previous 12 months of billing data. This is operationally significant: it means an organization can design the allocation methodology, get finance sign-off, and then apply it to historical data before the first chargeback invoice is sent. Business units receive a retroactive view of what they would have been charged — which is effectively 12 months of showback — and can use that data to negotiate their forward budget allocation.

Retroactive application does not change actual charges for past months. It only changes how existing charges appear in Cost Explorer and CUR. Actual money movement begins on the first chargeback billing cycle after finance approval.

4.3 CUR Integration

Cost and Usage Reports (CUR) with Cost Category columns enabled provide the data file that finance systems ingest. The relevant columns for AI chargeback:

CUR Column	Chargeback Use
`line_item_usage_account_id`	Maps to AWS account; useful for multi-account orgs
`line_item_resource_id`	The Bedrock model ARN or AIP ARN
`resource_tags/user:BusinessUnit`	Primary allocation key
`resource_tags/user:CostCenter`	GL mapping key
`cost_category/AI-BusinessUnit`	The Cost Category value — use this as the definitive allocation
`line_item_unblended_cost`	Actual AWS charge
`line_item_usage_amount`	Token counts (in Bedrock: reported as input/output units)

CUR files are exported to S3 daily. The standard pipeline: S3 → Athena → finance system ETL (Section 7).

5. Internal Transfer Pricing for AI

When chargeback is in place, the rate at which costs transfer matters as much as the methodology. Setting internal prices per 1M tokens that are either too low (does not cover overhead) or too high (teams avoid AI to manage budget) creates the wrong incentives.

5.1 Setting the Internal Price

Cost components in the internal price:

Model cost (passthrough): The AWS/Anthropic/OpenAI rate for the model. This is the floor.
Infrastructure overhead: API gateway, observability, vector DB, networking. Typically 15–25% of model cost at scale.
Security and compliance overhead: Data loss prevention scanning, audit logging, access control infrastructure. 5–10%.
Platform team allocation: Engineering headcount supporting the AI platform. Compute this as: (Platform team annual cost × AI infrastructure fraction) / projected annual token volume.
Governance and risk overhead: Model evaluation, red-teaming, incident response. 3–7%.
Desired margin or reserve: A buffer for model price volatility, surprise usage spikes, and model upgrades. 10–15%.

Illustrative internal price calculation for Claude 3.5 Sonnet:

Component	Per 1M input tokens	Per 1M output tokens
AWS Bedrock list price	$3.00	$15.00
Infrastructure overhead (20%)	$0.60	$3.00
Security overhead (7%)	$0.21	$1.05
Platform allocation (8%)	$0.24	$1.20
Governance overhead (5%)	$0.15	$0.75
Reserve (10%)	$0.30	$1.50
Internal price	$4.50	$22.50

The resulting internal markup is 1.50x list price. This is within the typical enterprise range of 1.3x–1.6x. Markups below 1.2x tend to underfund the platform team; markups above 1.8x tend to suppress usage.

5.2 Rate Review Cadence

Internal prices should be reviewed quarterly for the first year, then semi-annually once stable. Model providers change list prices with moderate frequency (Anthropic has reduced prices on Sonnet variants twice in 18 months). An internal price that is not reviewed becomes progressively misaligned with actual costs.

Announce rate changes 60 days in advance with a detailed breakdown of what changed. Surprise price increases — even when justified — damage trust in the chargeback system.

5.3 Model-Tier Pricing Strategy

Consider differential pricing by model tier to steer usage toward cost-appropriate models:

Small/fast models (Haiku, GPT-4o-mini): Pass through at list + 1.2x overhead. Low barrier to adoption for high-volume, lower-complexity tasks.
Standard models (Sonnet, GPT-4o): Pass through at list + 1.4x overhead. The primary workhorse tier.
Large/reasoning models (Opus, o1, o3): Pass through at list + 1.6x overhead, plus a per-request governance review fee for batch workloads exceeding 10,000 requests/month. The higher overhead reflects the disproportionate impact on shared infrastructure.

This pricing structure nudges teams toward right-sizing their model selection without prohibiting the use of powerful models for workloads that require them.

6. Avoiding Gaming

When money moves, incentives change. Teams that were indifferent to AI costs during showback become creative accountants once chargeback begins.

6.1 Common Gaming Patterns

Tag manipulation. Teams that control their own tagging can misattribute requests to shared or lower-cost pools. Control: make tagging mandatory at the infrastructure layer (AIPs with required tags, LiteLLM virtual keys with enforced metadata) rather than optional in application code. Applications that invoke Bedrock without a valid AIP should be blocked by an SCP.

Application segmentation abuse. A team might split one large workload into many nominally distinct “applications” to stay under per-application budget thresholds that trigger scrutiny. Control: budget thresholds should apply at the team/BU level, not the application level. Application-level granularity is for attribution, not for budget enforcement.

Prompt stuffing. If input tokens are cheaper than output tokens (as with most frontier models), teams may pad prompts with redundant content to shift cost toward the input tier. This is genuinely rare in practice but worth monitoring. Control: output a ratio of output tokens / input tokens per application monthly; flag applications where this ratio is unusual (below 0.1 suggests padding; above 10 suggests misconfigured prompt structure).

Shadow procurement. Teams that find internal prices too high may route workloads to consumer-grade API keys or personal accounts, bypassing the central platform. Control: SCP blocking direct Bedrock API access from non-platform accounts; endpoint blocking for openai.com and anthropic.com API endpoints from corporate networks; quarterly audit of expense reports for AI API charges.

Cache poisoning. If prompt caching reduces billed tokens, teams may engineer artificial cache hits by pre-seeding the cache from a shared-cost account. Control: cache utilization should be attributed to the account that originally populated the cache entry, not exclusively to the account that reuses it.

6.2 Structural Controls

Control	Implementation	What It Prevents
Mandatory AIP enforcement	SCP denying `bedrock:InvokeModel` without AIP ARN in request	Direct invocation without attribution
LiteLLM key required	API gateway blocks requests without valid virtual key	Untracked usage
Budget hard stops	LiteLLM `max_budget` + AWS Budgets action to deny	Runaway spend
Monthly reconciliation	SpendLogs vs. AWS CUR comparison	Discrepancies between proxy and cloud bill
Quarterly tagging audit	AWS Config rule checking for required tags	Tag drift over time
Expense report scanning	Finance policy + automated flag	Shadow procurement

7. Finance System Integration

Getting AI costs into ERP/accounting systems is where most enterprise chargeback programs stall. The technical data is available; the integration into GL systems is not.

7.1 GL Code Mapping

Every AI cost category needs a GL account code. Typical mapping:

AI Cost Category	GL Account Type	SAP Example	Oracle Example
Direct model inference	Cost of Goods Sold or Operating Expense	6200100	5010.5200
Shared infrastructure overhead	IT Overhead Allocation	6700200	6050.1100
Platform team headcount	G&A or IT Headcount	7100300	7010.2200
AI governance and compliance	Compliance Operating Expense	7500100	7080.3300

The GL mapping must be approved by the Controller before the first chargeback cycle. Without this approval, the chargeback has no accounting home and cannot be reflected in department P&Ls.

7.2 Data Pipeline Architecture

S3 → Athena → ETL → ERP:

AWS CUR to S3: Daily export, parquet format, partitioned by date and account.
Athena views: Pre-built views that apply Cost Category mappings and join with LiteLLM SpendLogs for enrichment (application-level detail not available in CUR).
Monthly ETL job: Runs on the 2nd business day of each month, processes the prior month’s data, produces a journal entry file in the format required by the ERP system.
ERP ingestion: Journal entries are posted to each business unit’s cost center with the AI-specific GL codes.
Finance review: Controller or accounting team reviews and approves the journal entries before posting. This review step is non-negotiable — automated journal posting without human review creates audit risk.

For NetSuite: The standard approach is a saved search in Athena that produces a CSV matching NetSuite’s journal entry import format, uploaded via SuiteScript or the CSV import tool.

For SAP S/4HANA: Use the BAPI_ACC_DOCUMENT_POST interface. The Athena ETL produces an IDoc or flat file compatible with SAP’s document interface.

For Oracle Fusion: REST API journal import (/fscmRestApi/resources/11.13.18.05/journals) accepts JSON journal entry batches directly.

7.3 Accrual Timing

AI costs are variable and continuous, but accounting periods are monthly. The 24-hour lag in Cost Explorer and the 48-hour lag in CUR means month-end costs are not final when books close.

Standard practice: accrue AI costs at the last-known monthly run rate on the final business day of the month, then true up in the first week of the following month when final data is available. The true-up entry reverses the accrual and posts actuals. This requires two journal entries per month but eliminates the alternative: closing the books without accruing material AI costs.

8. Executive Reporting

The CFO and board do not want to see token counts. They want to see cost-per-outcome.

8.1 Cost-Per-Outcome Metrics

Every AI workload should have an associated business outcome metric that can be denominated alongside cost. The goal is a unit economics view that a CFO can immediately interpret.

Workload	Cost Metric	Outcome Metric	Unit Cost
Contract review automation	Monthly AI cost	Contracts reviewed	$ per contract
Support ticket deflection	Monthly AI cost	Tickets deflected	$ per deflection
Code generation assistant	Monthly AI cost	Developer hours saved	$ per saved hour
Financial report drafting	Monthly AI cost	Reports generated	$ per report
Customer churn prediction	Monthly AI cost	At-risk customers identified	$ per customer identified

Producing these metrics requires joining AI cost data (from LiteLLM or CUR) with operational data (from the application or CRM). This join is almost always an engineering task, not a finance task. Platform teams should build it as a standard reporting output, not a one-off analysis.

8.2 CFO-Level Dashboard

Monthly CFO AI report structure:

Total AI spend: Month, QTD, YTD vs. budget. One number per period.
Spend by business unit: Bar chart, current month and 12-month trend. Identifies which BU is driving growth.
Cost-per-outcome by top 5 workloads: Table with month-over-month change. Identifies efficiency gains and regressions.
Model mix: Percentage of spend on small vs. standard vs. large models. Trend toward larger models without corresponding outcome improvement is a yellow flag.
Budget utilization: Each BU’s spend vs. approved AI budget. BUs above 80% of monthly budget get flagged for reforecast conversation.
Disputed charges: Open disputes, dollar value, aging. Should be zero or near-zero if the methodology is sound.

8.3 Board-Level AI Cost KPIs

For quarterly board reporting, three KPIs are sufficient:

AI cost as % of revenue: Benchmarks efficiency at scale. Should decline as workloads mature and prompts are optimized.
AI cost per employee: Normalizes for headcount. Useful for comparing productivity investment across quarters.
ROI on AI spend: (Cost savings from AI workloads + revenue attributable to AI) / AI spend. Requires outcome data from Section 8.1. Target: > 3x within 18 months of production deployment.

9. Disputed Charges Process

Disputes are inevitable. The question is whether the organization has a process that resolves them in days or weeks.

9.1 Common Dispute Types

Misattribution disputes: A team is billed for usage that was not theirs. Caused by tag misconfiguration, shared API keys, or application bugs that route traffic through the wrong AIP.

Rate disputes: A team disagrees with the internal transfer price or the overhead multiplier applied to their usage. Usually a sign that the rate-setting methodology was not communicated clearly.

Timing disputes: A team is billed for usage in a month they claim the workload was not running. Caused by zombie processes, scheduled jobs that were not decommissioned, or deferred billing from a prior month.

Allocation disputes: A team disagrees with their proportional share of shared infrastructure overhead.

9.2 Resolution Workflow

Day 1: Team submits dispute ticket to the AI platform team with: billing month, disputed amount, reason for dispute, and supporting evidence (application logs, deployment records).

Day 1–3: Platform team pulls SpendLogs and CUR data for the disputed period, filters to the team’s virtual keys and AIPs, produces a transaction-level reconciliation report.

Day 3–5: If the dispute is valid (misattribution confirmed), the platform team issues a credit in the following month’s billing cycle and root-cause-analyzes the tagging error. If the dispute is not valid, the platform team provides the reconciliation data with explanation.

Day 5–7: If the team does not accept the explanation, escalate to a joint review with the team’s finance business partner and the AI platform’s finance liaison. At this level, disputes are almost always resolved — the data is either accurate or it is not.

Day 7–14: If unresolved after joint review, escalate to the Controller for binding arbitration. The Controller’s decision is final. This escalation should be rare (< 2 per quarter in a well-run program).

9.3 Dispute Prevention

The best dispute process is one that is never invoked. Prevention requires:

Publishing detailed methodology documentation before chargeback begins, in plain language.
Giving teams self-serve access to their own SpendLogs data so they can audit their own charges before the invoice arrives.
Sending each team a preview of their invoice on the 25th of the month, before the final invoice is issued on the 1st, with 5 business days to raise concerns.
Running monthly tagging audits and proactively correcting misattribution before invoicing.

10. Graduated Chargeback Rollout: 6-Month Implementation Plan

The fastest way to make AI chargeback fail is to announce it and implement it in the same month. The following plan produces a functioning, trusted chargeback system in 6 months.

Month 1: Instrumentation

Goals: Every AI request is tagged and logged. No money moves.

Actions:

Deploy LiteLLM Proxy with virtual keys for each team and application.
Create AIPs for all Bedrock-using teams with required tag schema (BusinessUnit, CostCenter, Product, Environment).
Implement SCP blocking direct Bedrock invocation without AIP.
Configure CUR export to S3 with Cost Category enabled.
Set up Athena workspace with CUR tables.
Baseline 30 days of tagged data before proceeding.

Exit criteria: 95%+ of Bedrock spend is tagged. SpendLogs reconciles to within 2% of CUR. Tagging audit shows no untagged production workloads.

Month 2: Showback Launch

Goals: Teams see their costs for the first time. Build familiarity with the numbers.

Actions:

Publish first monthly showback report to all teams. Include: spend by application, top 5 workloads by cost, comparison to prior month.
Hold 30-minute “AI cost review” sessions with each business unit’s finance business partner.
Document questions and objections — these are the disputes that will arrive when money starts moving.
Announce the chargeback timeline: hard chargeback begins Month 7 (one month after this plan ends).
Publish the internal pricing methodology for comment. 30-day comment period.

Exit criteria: All BUs have reviewed their showback data. Finance business partners are familiar with the attribution methodology. No unresolved methodology objections.

Month 3: Rate Finalization and Budget Allocation

Goals: Internal prices are approved. Business units have AI budget.

Actions:

Finalize internal transfer prices based on 60 days of actual infrastructure cost data (Month 1 + Month 2).
Submit internal price schedule to Controller for approval.
Begin formal budget process: each BU submits an AI budget request based on Month 1–2 showback data plus expected growth.
Finance allocates AI budget to each BU’s cost center.
GL code mapping completed and approved by Controller.

Exit criteria: Signed-off internal price schedule. Each BU has an approved AI line item in their cost center budget. GL codes mapped and tested.

Month 4: Soft Chargeback (Shadow Billing)

Goals: The full chargeback process runs end-to-end but journal entries are not posted to the GL.

Actions:

Run the full monthly billing cycle for Month 3 data as if it were a live chargeback.
Produce journal entries in ERP format and have the Controller review without posting.
Send teams their Month 3 invoice alongside their Month 3 showback report. They should match.
Resolve any discrepancies between the showback report and the invoice before going live.
Run the first dry-run of the dispute process: any team with a discrepancy > 5% submits a mock dispute ticket.

Exit criteria: Dry-run journal entries reviewed and approved by Controller. No discrepancies > 5%. Dispute process tested end-to-end.

Month 5: Hard Chargeback — First Live Cycle

Goals: First real money movement. GL entries posted. BU P&Ls reflect AI costs.

Actions:

Issue Month 4 invoices. Money moves.
Post journal entries to GL after Controller approval.
Publish the dispute resolution process to all BU finance contacts.
Send preview invoices on the 25th (for Month 5 billing, due Month 6 Day 1).
Platform team holds weekly office hours for the first 4 weeks of live chargeback to handle questions.

Exit criteria: Month 4 invoices issued and accepted. Journal entries posted. No open disputes older than 7 days.

Month 6: Steady State and Optimization

Goals: Process is routine. Teams use cost data to optimize their workloads.

Actions:

Run first quarterly review: cost-per-outcome trends, model mix analysis, top spenders vs. top value generators.
Publish the CFO dashboard (Section 8.2) for the first time.
Begin model-tier pricing differentiation if not already in place.
Identify the top 3 workloads with declining cost-per-outcome — highlight as AI program success stories.
Identify the top 3 workloads with increasing cost-per-outcome — schedule engineering review.
Plan the first semi-annual rate review (Month 9).

Exit criteria: CFO dashboard published. Quarterly review completed. Rate review scheduled.

11. Key Policy Templates

11.1 AI Chargeback Policy — One-Page Version

AI Infrastructure Chargeback Policy

Effective: [Date]

Scope: All business units using centrally managed AI infrastructure (LiteLLM Proxy, AWS Bedrock, shared vector databases).

Attribution method: Direct attribution via Application Inference Profiles and LiteLLM virtual keys. Shared overhead allocated proportionally to direct usage share.

Internal prices: Published quarterly at [internal URL]. Current rates effective [Date].

Billing cycle: Monthly. Preview invoices distributed on the 25th. Final invoices issued on the 1st of the following month.

Disputes: Submit to [ticket queue] within 10 business days of invoice date. Resolution within 14 business days per Section 9.2.

Budget overruns: Teams that exceed their approved AI budget by > 10% in any month will receive an automated alert. Overruns > 25% require reforecast approval before the following month’s spend can continue at the elevated rate.

Questions: [Platform team contact] for technical questions, [Finance business partner] for billing questions.

11.2 Tag Schema Standard

Required tags for all AI infrastructure resources:

BusinessUnit:     [Finance | Engineering | Marketing | Operations | Legal | HR | IT-Platform]
CostCenter:       CC-NNNN  (4-digit cost center code from finance system)
Product:          [product name or "shared" for shared infrastructure]
Environment:      [Production | Staging | Development | Research]
WorkloadType:     [Interactive | Batch | Realtime-API | Analytics]
DataClassification: [Public | Internal | Confidential | Restricted]

Tags are validated at resource creation by an AWS Config rule. Resources failing tag validation are flagged in the weekly tagging audit report and, after 30 days of non-compliance, subject to automatic shutdown by a Lambda function with SCP backing.

12. Common Pitfalls Summary

Pitfall	Symptom	Fix
No finance sign-off before launch	Chargeback exists in IT but not in GL	Get Controller approval before Month 5
Overhead not included in internal price	Platform team has structural budget deficit	Compute full-stack cost; use 1.3–1.6x multiplier
Manual tagging	20–40% untagged usage	Move to AIP + LiteLLM key enforcement
Showback with no sunset date	Teams never take costs seriously	Announce Month 7 chargeback date in Month 2
No preview invoice	Disputes arrive after posting	Send preview on 25th, 5 business days to object
Rates not reviewed	Internal price diverges from actual cost	Quarterly review Year 1, semi-annual thereafter
No dispute process	First contested invoice becomes a political crisis	Publish process before first live invoice
Token counts to CFO	CFO disengages	Translate to cost-per-outcome (Section 8.1)
Budget without allocation	Teams receive bills with no approved budget	Budget allocation must precede chargeback
Shadow procurement	Spend bypasses platform, loses visibility	SCP + network controls + expense report scanning