Direct answer: Build a cost model before adding tags. Separate direct metered costs (tokens, vectors, tools, human review) from shared platform costs (gateway, GPU, logs, evaluation), then attribute by application/tenant/feature/team. Use cost per successful task for business decisions and showback/chargeback for budgets. Splitting the token bill by department is usually wrong.
This guide is for AI owners, product/engineering, SRE/platform, finance/FP&A, procurement and vendor management. It covers how to attribute, allocate, budget and accept Token, Agent, RAG and private-deployment AI costs. Information is current to 31 October 2026. It is public FinOps/cloud documentation and project method, not a price, accounting, tax or audit opinion; cost lines, allocation rules and contracts are governed by company finance policy and actual bills.
A bill that reconciles is not a cost that can be attributed. Meter direct costs; allocate shared platform costs with a documented driver; use showback for POCs and chargeback for production; cost per task/conversation/document is closer to a business decision than price per million tokens.
Why is an AI bill hard to split by department?
AI costs include direct metering (tokens, vectors, tools, human review) and shared platforms (gateway, GPU, logs, evaluation, security). Splitting only tokens by department misses shared costs and failed retries.
A traditional cloud bill has resource tags; an AI bill is often "one platform account + many applications + many teams". A single call chain may include model tokens, embeddings, vector database, tool APIs, cache, retries, safety filters, human takeover and evaluation; private deployment adds GPU idle time, drivers/operations and data-centre costs. Splitting only the token bill by department leaves shared gateways, GPUs and human costs at "headquarters" and may charge failed retries to the wrong business.
| Cost type | Examples | Directly attributable? | How to handle |
|---|---|---|---|
| Direct model cost | Input/output tokens, cache, batch | By app/tenant/API key | Metering + tags |
| Retrieval/vector cost | Embedding, vector DB, retrieval requests | Usually by knowledge base/app | Index/query metering |
| Tool/external API | Search, OCR, maps, payments, email | By tool/app | Tool bill + call logs |
| Human takeover/review | Support, labelling, moderation, inspection | By queue/scenario | Hours/tickets + unit cost |
| Shared platform | AI gateway, GPU, logs, evaluation, security | Usually not | Allocate by driver |
| Private/data centre | GPU depreciation/rental, network, operations | By cluster/business | Capacity/utilisation allocation |
The cost categories are editorial; specific accounts, capitalisation/expense, tax and allocation rules depend on company finance policy.
Which tags are enough without becoming unmanageable?
Tag at least application, environment, team/cost centre, tenant/customer, feature/scenario and model/provider. Tags are the start of attribution, not the cost model; tags without an owner decay quickly.
More tags is not better. Start with the questions that must be answered: which application/tenant/feature is spending? POC or production? Which team/cost centre owns it? Which model/provider? Define a minimum tag set, implement it in the SDK/gateway/deployment template, and inherit automatically; do not rely on manual month-end tagging. Cloud cost-allocation tags often must be activated/configured before appearing in billing reports; AI platforms often require export by API key/workspace/project.
| Tag dimension | Purpose | Example | Acceptance |
|---|---|---|---|
| Application/product | Which AI product is spending | app=kb-assistant | Bill/logs match |
| Environment | POC/test/production | env=poc/prod | Environments not mixed |
| Team/cost centre | Budget/performance/allocation | team=customer-service | Owner/approval |
| Tenant/customer | Multi-tenant/external gross margin | tenant=t-1024 | Tenant isolation/verifiable |
| Feature/scenario | Cost per task/conversation | feature=refund | Stable scenario definition |
| Model/provider | Routing/comparison/retirement impact | model=... | Version traceable |
Tag design is editorial; keys, inheritance, billing export and permissions depend on cloud/AI platform documentation and the company's cost-centre policy. Cost-allocation tags/activation reference AWS cost allocation tags, Azure cost allocation and Google Cloud chargeback principles.
Direct metering, proportional allocation or fixed platform fee?
Attribute what can be metered directly; allocate shared platforms by a documented driver (calls, tokens, GPU hours, storage, human tickets); a fixed platform fee can fit an internal platform, but needs cost transparency and an exit mechanism.
No allocation model fits every company. Direct metering is fair but requires gateways/logs/bills split by app/tenant; proportional allocation is simple but the ratio is disputed; a fixed platform fee is stable but can weaken the platform team's incentive to optimise. Most companies use a hybrid: direct costs attributed directly, shared gateway/GPU/logs allocated by driver, and the platform team keeps a fixed budget + service catalogue. Write down the rule, period, adjustment and dispute process.
| Model | Fits | Pros/risk | Evidence |
|---|---|---|---|
| Direct metering | App/tenant/API key distinguishable | Fair/optimisable; depends on telemetry/bill | Call logs, bill reconciliation |
| Proportional allocation | Shared gateway/logs/evaluation | Simple; ratio disputed | Formula, monthly review |
| Fixed platform fee | Internal AI platform/shared GPU | Stable; weak optimisation incentive | Service catalogue, cost/exit |
| Hybrid | Most enterprises | Fair and stable; complex rules | Rule document, audit |
| No allocation (HQ pays) | Early POC/innovation | Encourages experiments; production can run away | POC term/budget cap |
Allocation models are editorial; specific ratios, periods, service catalogue and finance treatment depend on company policy, contracts and platform capability. FinOps allocation/showback/chargeback definitions reference the FinOps Framework.
How should cost per task be calculated without being misled by token price?
Cost per task = (model + retrieval + tools + retries + human takeover + shared platform allocation) ÷ successful tasks. Define success by scenario and include failures/retries/takeover.
"Price per million tokens" is useful for comparison, not for judging whether a business is profitable. A support conversation may call the model several times, retrieve from a knowledge base, call an order tool, retry on failure and hand over to a human; a document review may include OCR, embedding, model and human review. Add these costs and divide by successful tasks/conversations/documents; failed tasks also cost money, otherwise failure looks "cheaper".
| Cost item | How to meter | Data source | Common omission |
|---|---|---|---|
| Model tokens | Input/output/cache/batch | Vendor bill/gateway log | Retries/failed calls |
| Retrieval/vector | Embedding + query + storage | Vector DB/bill | Index rebuild |
| Tools/external API | Per call/count/page | Tool bill | Failed retries |
| Human takeover | Hours × unit cost | Tickets/roster | Review/sampling |
| Shared platform | By driver allocation | Allocation table | Gateway/GPU/logs |
| Successful tasks | Defined by scenario | Business system/evaluation | Counting failures as success |
Cost per task is an editorial method; numerator/denominator, success definition and labour cost depend on the business, finance and contract. No price or margin is promised.
How should budgets, alerts and showback/chargeback run?
Use showback (show teams their cost) for POCs, then chargeback (budget/performance) for production. Run monthly reconciliation, forecasting, anomaly alerts and dispute handling with an owner—not just a month-end bill review.
AI costs are volatile: a model switch, cache-hit change, Agent retry or campaign traffic can double the bill. Set budgets by application/team/environment and daily/weekly/monthly alerts and anomaly thresholds; reconcile vendor bills, gateway logs, business success volume and the allocation table monthly; use showback to make teams aware of cost, and chargeback to put cost into department budgets/performance. For POCs, use showback + a budget cap to avoid killing experiments; move to chargeback in production.
| Action | What to do | Frequency | Evidence |
|---|---|---|---|
| Budget | Set monthly/quarterly budgets by app/team/environment | Quarterly/monthly | Budget table, approval |
| Alerts | Daily/weekly thresholds, abnormal growth, shared-cost anomalies | Daily/weekly | Alert record |
| Reconciliation | Bill vs gateway log vs business success volume | Monthly | Reconciliation table, variance note |
| Forecast | Rolling forecast by usage/growth/model routing | Monthly | Forecast model, assumptions |
| Showback | Show teams cost and efficiency | Monthly | Report, briefing |
| Chargeback | Put cost into department budget/performance; dispute process | Monthly/quarterly | Rule, sign-off |
| Review | Anomalies, optimisation, model/vendor changes | Quarterly | Review table, actions |
The budget/alert/chargeback process is editorial; finance definitions, approvals and performance rules depend on company policy. No savings percentage is promised.
How should the work be sequenced over 90 days?
Inventory cost lines and data sources, then implement tags/gateway metering, allocation rules, cost per task, budgets/alerts and reconciliation. Do not buy a FinOps tool before the definitions and owner exist.
Pilot one application/team: put vendor bills, gateway logs, business success volume, human tickets and shared platform costs into one table, and run one monthly reconciliation; then replicate to other applications. Tools can come later; definitions and owners come first. The pilot goal is not "accurate to the cent" but to answer which application/team/scenario is spending, what the unit cost is, where anomalies are and how to control next month.
| Phase | Actions | Outputs | Owner |
|---|---|---|---|
| Weeks 0–2 | Inventory cost lines, vendor bills, apps/teams/environments, existing tags | Cost list, data sources | Finance/AI platform |
| Weeks 3–4 | Define minimum tag set, gateway metering, tenant/feature dimensions | Tag spec, instrumentation | Platform/engineering |
| Weeks 5–6 | Define direct/shared allocation and cost-per-task formula | Allocation table, metric definitions | Finance/business |
| Weeks 7–8 | Pilot reconciliation, budgets/alerts, showback report | Reconciliation, report | Pilot team |
| Weeks 9–10 | Expand to more apps; disputes/exceptions; chargeback rules | Rollout plan, rules | Finance/platform |
| Weeks 11–12 | Quarterly review; optimise routing/cache/human; next budget | Review, budget | AI owner |
The 90-day plan is an editorial suggestion; cost lines, allocation, budgets and system implementation depend on finance, platform and vendor schedules.
Acceptance checklist
Accept eight items: bill reconciliation, tag coverage, shared allocation, cost per task, budget alerts, showback/chargeback, audit and documentation. Each needs an owner and evidence; tick before launch.
The checklist can be shared by the AI owner, platform/engineering, finance/FP&A, procurement and business. The pass standard is not "the report looks good" but that the bill reconciles, cost can be attributed, anomalies are visible, budgets can be controlled and disputes have rules.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Bill reconciliation | Vendor bill/gateway/business volume variances explained | Reconciliation, variance note | Add data/fix definition |
| Tag coverage | Key app/environment/team/tenant coverage high | Tag report, missing list | Add instrumentation/inheritance |
| Shared allocation | Rule/driver/period/dispute written | Allocation doc, sign-off | Redefine |
| Cost per task | Numerator/denominator/success fixed; failures counted | Definition, sample | Recalculate/add data |
| Budget alerts | By app/team/environment; threshold and owner clear | Budget table, alerts | Set threshold/owner |
| Showback/chargeback | POC/production rules separate; disputes handled | Report, rules | Add rules/communicate |
| Audit | Bill/tag/allocation/adjustment traceable | Logs, versions | Add audit/access |
| Docs/training | Definitions/tags/rules/tools/contacts discoverable | Docs, training | Add docs/training |
The acceptance checklist is editorial; finance, accounting, tax, audit and contract requirements depend on company policy and professional advice.
Who should read this, who should not, and what decision does it support?
It fits companies with multiple AI apps/teams, growing bills or an AI budget. It does not fit pre-launch teams with one POC, or teams without bills/usage data.
Who should read: AI owners, product/engineering, SRE/platform, finance/FP&A, procurement and vendor management; teams doing AI budgets, department allocation, tenant gross margin, model routing or cost optimisation; anyone deciding where the money goes, who owns it and how to control it. Who should not: pre-launch teams with one POC and no bill/usage/business success data; projects expecting one report to replace finance policy or accounting; teams treating token price as the only cost metric. Decisions supported: cost lines, tags/metering, direct/shared allocation, cost per task, budgets/alerts, showback/chargeback, reconciliation and a 90-day rollout.
Lingyi Information is a website and enterprise AI project services company, not an accounting, tax or audit firm. This article does not replace finance, accounting, tax, audit or contract advice. Scope is confirmed case by case; Lingyi does not promise savings, cost reduction or ROI.
FAQ
Can a vendor token bill be split directly by department?
Only if the bill/gateway/API key distinguishes department/application/tenant. Most companies share one platform account and need gateway logs, tags and business volume for attribution; splitting by headcount or budget ratio usually gets the cost wrong.
How should shared AI gateway/GPU costs be allocated?
Use a documented driver: calls, tokens, GPU hours, storage, active tenants, human tickets, etc.; write down the formula, period, adjustment and dispute process. A fixed platform fee can work, but needs a service catalogue, cost transparency and an exit mechanism so the platform team still has an incentive to optimise.
What is the difference between showback and chargeback?
Showback shows cost to teams without putting it into budget/performance; chargeback puts cost into department budgets/performance under a rule. For POCs, use showback + a budget cap; move to chargeback in production. Follow company finance policy.
How do you calculate cost per task?
Add model tokens, retrieval/vector, tools, retries, human takeover and shared platform allocation, then divide by successful tasks. Define success by scenario and count failed tasks too. Do not look only at "price per million tokens".
Should POC costs be charged to the business?
Not necessarily. Use showback + a budget cap during the POC to encourage experimentation; move to chargeback in production. Have a term, budget and exit condition so the POC does not become an indefinite free resource.
What if the vendor bill has no tags?
Add metering/tags at the gateway/application layer, map calls to application/tenant/feature, then reconcile with the vendor bill. If needed, split by API key/workspace/project or allocate shared cost by driver; do not invent attribution just to have tags.
Bottom line
Build the AI cost model first: direct costs by metering, shared platform costs by a documented driver, tags/gateway/bill reconciled. Use cost per task for business decisions; showback for POCs, chargeback for production; budgets, alerts, reconciliation and dispute handling need an owner. Do not just split the token bill by department.
Method and limits
This article is public FinOps/cloud documentation and project method, not a promise or opinion on any company, vendor, price, accounting, tax or audit. It uses no unpublished client bills, contracts or cost data. Cost lines, tags, allocation, budgets and the 90-day plan are editorial suggestions; finance policy, cloud/AI platform documentation, contracts and professional advice govern.
Sources
Information is current to 31 October 2026; each official/primary page governs its own capability, version and terms.
- FinOps Foundation, FinOps Framework: finops.org. Allocation, showback/chargeback, unit economics and related capabilities.
- Microsoft Azure, Allocate costs: learn.microsoft.com. Shared-cost allocation rules, subscriptions/resource groups/tags.
- AWS, Cost allocation tags: docs.aws.amazon.com. Activating cost-allocation tags and using them in billing reports.
- Anthropic, Usage and Cost API: docs.anthropic.com. Usage/cost data by time, model, API key and related dimensions.
- Google Cloud, Principles for designing a chargeback process: cloud.google.com. Consumer/platform workloads, labels/tags, billing export and chargeback principles.