AI Cost Allocation: Models That Work in Indian Production

The conversation usually starts when someone in finance pulls the cloud bill for the quarter and realises 40% of it is AI consumption sitting in a single line item called “Technology” with no breakdown by team, product, or use case. Nobody owns the trade-off, nobody optimises, the bill keeps growing. Then someone proposes “let’s allocate it across BUs” and the next two months go into a methodology debate that produces no actual change.

AI cost allocation is the practice of distributing AI/cloud spend across business units, products, projects, or teams — assigning costs to the consumers driving them rather than holding spend in a centralised IT line. It’s a core FinOps Inform-phase capability and increasingly material as AI spend grows. Done well, it creates accountability and pressure for optimisation. Done badly, it creates organisational friction without changing decisions.

This post walks through the models, the dimensions, the technical foundation, the Indian regulatory overlays, and the pitfalls that derail otherwise-sensible allocation work.

I’m Ravi. I run three production AI SaaS solo (Prism, Citare, BatchWise) and do advisory work on cost allocation via rikuq services. The framework below is what I use when finance teams ask “how do we actually allocate this AI spend?”

TL;DR

Element	What it means
Showback	Costs reported back to BUs for visibility; no money actually moves
Chargeback	Costs moved across cost centres; consuming BU’s P&L bears the spend
Primary allocation dimensions	Model/provider, product feature, business unit, project, environment
Technical foundation	IAM Tag Enforcement Policies — required tags or resource creation fails
Indian overlays	Ind AS 108 segment reporting, Section 92 transfer pricing, GST/RCM mechanics
Maturity arc	Most entities start with showback, graduate to chargeback after 12-18 months

Why allocation matters

Three direct consequences of having (or not having) a working AI cost allocation methodology:

Accountability. When AI/cloud spend sits in a single shared cost centre, no business unit owns the trade-off between consumption and value. With allocation, the BU using a foundation model API sees the cost of that consumption, creating natural pressure to optimise. The “who pays for this?” question forces the consumer to ask “is this worth it?”

Optimisation pressure. FinOps Optimize-phase techniques (model tiering, prompt caching, batching, retry hygiene) only get applied if someone is responsible for the bill. Allocation creates the responsibility. Without it, optimisation work has no organisational sponsor and decays.

Tax and regulatory compliance. In multi-entity groups, especially cross-jurisdiction, allocation methodology is a transfer pricing matter under Section 92 IT Act plus OECD TP Guidelines Chapter VII. Without defensible allocation, the entity carries TP audit risk and exposure to adjustments-plus-interest-plus-penalty.

Per Gartner, 80.8% growth in generative AI model spending in 2026 plus 98% of global FinOps practitioners now tasked with managing AI spend (up from 31% in 2024) — the discipline of allocating that spend defensibly across the organisation is the operational hinge that determines whether AI investment scales sustainably or hits a budget ceiling.

Showback vs chargeback — the two operating models

Model	What it means	When to use
Showback	Costs reported back to BUs / teams so they can see what they consume, but no money actually moves between cost centres	Early-stage FinOps maturity; before budget responsibility is formally devolved to BUs
Chargeback	Costs actually moved across cost centres — the consuming BU’s P&L bears the AI spend	Mature FinOps practice; BUs have budget responsibility and ability to make trade-off decisions

Most Indian mid-market entities start with showback (visibility without budget reorganisation) and graduate to chargeback once internal financial discipline catches up. The transition typically takes 12-18 months.

The trap is jumping straight to chargeback before the BUs have the levers to act on cost signals. When a BU is told “your AI bill is ₹40 lakh this quarter,” that information has to translate into an action — switch to a cheaper model, add prompt caching, reduce experimental workloads — and the BU has to have the engineering capacity and authority to do so. Chargeback without operational levers creates organisational tension without producing better decisions.

The five common allocation dimensions

A working AI cost allocation methodology typically tracks spend across multiple dimensions simultaneously:

• By model / provider — GPT-4 vs Claude vs Gemini vs Llama, etc. Enables efficiency comparison across providers and surfaces model-substitution opportunities.
• By product feature — chatbot vs summarisation vs code assist vs document analysis. Enables product-team cost-per-feature analysis and feature-level unit economics.
• By business unit — Finance, Operations, Sales, Engineering, etc. Enables BU-level accountability for the spend they drive.
• By project / use case — specific AI initiatives within each BU. Enables ROI tracking per initiative and helps kill experiments that don’t pay back.
• By environment — production vs staging vs experiment. Helps catch experimental AI workloads creeping into the production bill (a surprisingly common pattern as teams move fast on AI features without environment hygiene).

Most organisations cannot allocate cleanly across all five dimensions simultaneously. The tag taxonomy and instrumentation effort is non-trivial. Mature FinOps practice prioritises the 1-2 dimensions that drive the biggest spend decisions for that organisation’s context, then adds more dimensions as the tag enforcement discipline matures.

For most mid-market entities the priority sequence is:

1. Business unit + environment first (drives accountability and catches experimental drift)
2. Product feature second (drives unit economics conversations)
3. Model/provider third (drives optimisation pressure)
4. Project/use case fourth (drives ROI conversations)

Trying to do all four simultaneously from day one usually produces fragile allocation that breaks under any tag drift.

Technical foundation — IAM tag enforcement

Cost allocation is structurally dependent on IAM Tag Enforcement Policies: every resource creation must carry cost-centre, environment, and workload tags or the resource is rejected at creation time. Without enforcement, retroactive cost allocation becomes a manual reconciliation exercise that nobody completes consistently.

The pattern that works:

1. Define the tag taxonomy — agree on the required tags, the allowed values, and the responsible owner per tag
2. Configure IAM enforcement — Service Control Policies on AWS, Azure Policy, GCP Organization Policy. Block resource creation without required tags
3. Layer allocation logic on top of the tagged data — the cost data already arrives properly attributed
4. Audit tag drift quarterly — even with enforcement, edge cases creep in (legacy resources, untagged manual creations during incident response)

The 2026 FinOps Foundation working group on Generative AI Cost and Usage Tracker provides a reference implementation pattern that’s worth following rather than inventing your own. For AI spend specifically, the gateway layer (if you have one — see why LLM gateway attribution is harder than cloud FinOps) is where attribution should happen for token-based costs that don’t map cleanly to cloud resource tags.

Indian context — three regulatory layers

1. Internal segment reporting under Ind AS 108

For Indian entities required to report by segment under Ind AS 108 (Operating Segments), AI cost allocation directly affects segment-level P&L disclosed in financial statements. The allocation methodology must satisfy the standard’s reporting requirements and audit defensibility.

A material misallocation can trigger restatement risk in subsequent audits. The audit-readiness work involves:

• Documented allocation methodology with clear logic per dimension
• Consistent application across reporting periods (no methodology drift mid-year)
• Defensible mapping from technology cost categories to operating segments
• Clear treatment of unallocated technology spend in the segment reconciliation
• Senior management sign-off on the allocation approach as part of financial reporting controls

For SEBI-listed entities this becomes part of the broader AI disclosure work that’s increasingly material in audit committee discussions.

2. Cross-entity transfer pricing (Section 92)

Where AI / cloud spend is incurred at the group or parent entity level and consumed across subsidiaries — especially across jurisdictions — the cost allocation methodology is a transfer pricing matter. Under Section 92 IT Act plus Rule 10A-10F plus OECD TP Guidelines Chapter VII (Intra-Group Services):

• The receiving entity must derive an economic or commercial benefit from the allocated cost. Pure cost-pass-through without benefit fails the arm’s-length test.
• The allocation key (usage-based, headcount-based, revenue-based) must reflect benefit received. Different allocation keys are appropriate for different cost categories.
• A mark-up of 5-10% over cost is typically defensible for routine support services centralised in a cost centre, under Safe Harbour Rules plus comparables analysis. Pure cost-sharing arrangements (no mark-up) are permitted only in limited cost-contribution-arrangement structures.
• Documentation under Section 92D plus Rule 10D is required; Master File and Country-by-Country Report obligations under Section 286 apply if thresholds are met.

Failure to satisfy these requirements creates TP audit exposure. Adjustments, interest, and penalty compound quickly.

See the AI tax recovery framework sub-domain 5 for the full TP analysis approach.

3. GST input credit and RCM implications

When AI spend allocated across entities crosses GST registration boundaries, additional layers apply:

• Charging an allocation cross-entity may constitute a supply of services under GST — making the allocation itself taxable
• If the recipient entity is GST-registered, ITC is available subject to Section 16 CGST plus Section 17 blocked-credit exceptions
• For foreign-vendor AI spend allocated across Indian entities, RCM applies per Section 5(3) IGST Act regardless of allocation methodology — and the RCM cash-flow lands at the entity actually consuming the service

The interaction between transfer pricing and GST on cross-entity AI allocation is one of the most under-managed areas in Indian mid-market AI spend. Treating it as just an internal accounting matter misses the GST cash flow and the TP exposure simultaneously.

The five most common allocation pitfalls

Patterns I see repeatedly in mid-market entity allocation work:

Allocation lag. AI costs allocated quarterly when the spend lifecycle is monthly. BUs receive bills too far after consumption decisions to learn from them. The feedback loop is too slow to drive behaviour change.

Cliff allocation. Central cost-centre absorbs all AI spend until a threshold is crossed, then dumps the entire amount on a single BU. Creates wrong incentives — the BU has no visibility until it’s already over budget, then it’s too late to optimise.

Allocation without benefit substantiation. Allocation key satisfies internal P&L but doesn’t survive TP audit because no defensible benefit case is documented per recipient entity. Common in entities that built internal allocation methodology before cross-entity flows became material.

Mixing showback and chargeback inconsistently. Different BUs face different rules without explicit policy framework. Some BUs get charged, some don’t, the discipline degrades. Either go all showback or all chargeback for AI spend; mixing creates inequity that becomes political.

Tag taxonomy drift. IAM tag enforcement decays over time. New resources slip in untagged during incidents or special projects, retroactive tagging happens informally, allocation becomes increasingly approximate, audit defensibility erodes. Without quarterly tag audits and remediation, even a well-designed allocation system loses fidelity within 12-18 months.

How to actually implement allocation

If you’re starting fresh:

Month 1: Foundation. Define tag taxonomy. Configure IAM enforcement policies. Document the allocation methodology. Pick showback as the operating model. Pick 1-2 dimensions (BU + environment is the standard start).

Month 2-3: Build the data layer. Get tagged cost data flowing into your reporting system. Validate that allocation logic produces accurate results. Fix tag gaps for existing resources.

Month 4-6: Showback to BUs. Start sending monthly cost reports to BU heads. Hold a brief discussion with each BU on what they see and what they’re going to do about it. Document the response.

Month 7-12: Iterate. Refine the allocation as edge cases surface. Add a third dimension (typically product feature) once the first two are stable. Watch the BU behaviour change — or not.

Month 12-18: Consider chargeback. If the BUs have learned to act on cost signals during showback, formal chargeback adds budget accountability on top of behavioural accountability. If they haven’t, fix that first before adding financial pressure.

For entities with cross-entity flows (parent-subsidiary, multi-jurisdictional structure), the TP work runs in parallel from month 1 — don’t defer it because retrofitting TP documentation is materially harder than building it forward.

If you want a written scope proposal for what an allocation diagnostic plus implementation support would look like for your specific situation, the services page has both a Cal.com booking link and a Tally intake form.

What’s next

This post focuses on cost allocation specifically. The adjacent posts that go deeper on related dimensions:

• What is LLM FinOps? — the broader discipline this fits inside
• The FinOps Foundation Framework — where cost allocation sits within Inform phase capabilities
• AI Tax Recovery for Indian CFOs — sub-domain 5 covers the TP analysis on cross-entity allocation
• AI Systems Review framework — Domain 6 covers cost allocation in the broader review context