Just In
Ideas2IT is now an OpenAI Select Partner - recognized to help enterprises build, deploy, and scale AI with GPT-5, responsibly and at speed.
Read the announcement
You can already tell finance exactly what your AI spend management infrastructure shows this quarter like the dashboard, the team-level tags, the token-usage report on demand.. You built the dashboard, tagged the spend by team, and can pull a token-usage report on demand. And the gross margin on the projects those tools touch looks almost identical to what it looked like a year ago. That gap, between how much you can now see and how little has actually changed underneath, is what AI cost management is supposed to solve, and for most enterprises it hasn't.
According to McKinsey's July 2026 survey of enterprise AI FinOps practices, 93 percent of organizations exceed their AI budgets, and spend increases nearly fourfold as companies move from isolated use cases to adoption across the business.
Plenty of those organizations have already built the reporting layer McKinsey and most AI cost management vendors recommend: attribution by team, by model, by use case. The reporting exists while the bill still doesn't make sense next to the output.
The instinct when a dashboard doesn't produce the expected result is to build a better dashboard. Add more granularity, tag more workflows, route to cheaper models automatically. Some of that helps at the margins, and this piece covers where it genuinely does.
But the core argument here is different: visibility and attribution tell you where the money went. They don't tell you why the work underneath it still costs what it costs, or why your engineering margin hasn't moved even though your reporting has gotten better. That second question is a process question, not a measurement question, and it's the one most AI cost management advice skips past.
The rest of this piece walks through where the spend is actually going, why the usual visibility fixes stop short of the real problem, and what changes when you address the process generating the cost instead of just the report describing it.
Before getting into why visibility falls short, it helps to name what's actually in the number. Enterprise AI spend usually spans:
Most of this doesn't show up as one line item. It shows up scattered across a dozen procurement categories and team-level credit cards, which is a large part of why McKinsey's July 2026 research puts unaccounted AI spend at 20 to 30 percent of the total, even at companies that think they have a handle on it.
Some of this spend is fixed: platform subscriptions, seat licenses, committed infrastructure. Some of it is usage-based and moves with how much your teams actually run: token consumption, inference calls, agent iterations.
The usage-based portion is where most of the surprise lives, because it's the part that scales invisibly with behavior nobody is watching closely. That distinction between fixed and usage-based spend matters more than most cost breakdowns give it credit for, and it's the thread the next few sections pull on.
In Ideas2IT's SDLC engagement work, the fastest-growing and least-tracked category we encounter is agent workloads because iteration cost is invisible until it's already compounded across a quarter. It rarely shows up on a procurement audit because no single team owns it.
Most enterprise AI cost management advice, including McKinsey's own tokenomics framework, centers on a version of the same three moves: get visibility into spend, attribute it to a team or use case, then optimize based on what you find. It's a reasonable framework, and if you have none of it in place, building it is worth doing. The problem is what happens after you've done it.
Attribution answers a specific question well: who spent the money and on what. It doesn't answer a different question that matters more to your margin: why does the underlying work still cost what it costs. A team can have perfect attribution down to the individual API call and still be paying the same amount for the same output six months later, because the thing driving the cost was never the absence of a report. It was how the work got done.
This is the gap most AI cost management content doesn't name directly, and it's the one this piece is built around. Visibility is diagnostic and it tells you where to look. It was never going to be curative on its own, because the cost isn't generated by the absence of a dashboard. It's generated by a process that hasn't changed even though the tools running inside it have.
Once you're looking past the top-line number, the usage metrics that actually drive AI cost are worth naming specifically: token consumption per task, context window size, agent iteration counts, and model calls per workflow. Each of these moves independently, and each can spike without any change in the volume of work your team is actually producing.
The clearest recent examples of how invisible this can get come from DX's 2026 AI coding assistant pricing guide, and none of them were caused by a change in engineering output. Each was caused by usage crossing a pricing boundary nobody was watching
This is what usage metrics are for: catching the moment before the bill does. If you're only reviewing AI spend at the monthly invoice level, you're finding these shifts after they've already compounded for weeks.
Most engineering leaders reading this already know their invoice is climbing faster than they can explain it, and know the explanation isn't going to come from staring at the bill harder.
If your AI bill is climbing faster than you can explain it, Ideas2IT's engineers walk through your actual usage data and identify exactly which workflows are crossing cost thresholds and why. Book the AI-Powered SDLC Workshop with Ideas2IT to get a specific answer instead of another dashboard.
Part of why AI cost management feels hard to defend to a board is that the numbers you're measuring rarely match the numbers you were sold. DX's 2026 research, drawn from more than 400 organizations tracked over 14 months, found a median measured pull request throughput gain of 7.76 percent from AI coding tools, against vendor claims that commonly run from three to ten times that figure.
It's a story about a mismatch between what gets measured and what gets promised. An Infosys report cited by CIO Dive in August 2026 found that 72 percent of organizations have scaled less than a quarter of their AI pilots successfully, two-thirds struggle to measure AI's return on investment at all, and only about half have a balanced set of metrics for evaluating AI's value in the first place. If you can't measure ROI cleanly, you can't tell whether the 7.76 percent gain or the vendor's claimed multiple is closer to your own reality.
The gap exists partly because vendor benchmarks measure individual task speed, not team delivery velocity. What Ideas2IT's engineers see in practice is a net-zero dynamic: time saved generating code is consumed by increased review load, because faster generation also means more code that needs checking. The tool sped up one stage; the rest of the pipeline didn't move.
This is the credibility problem underneath the spend problem. You're not just trying to control a bill. You're trying to give your board a number you can stand behind, and right now most of the numbers in this category come from vendors with an incentive to round up.
Some of the gap between spend and output comes from waste that's straightforward to find once you're looking:
McKinsey's July 2026 research puts a number on the diffuse version of this problem: 20 to 30 percent of enterprise AI spend goes unaccounted for, spread across fragmented vendors and tools that nobody is actively reconciling against usage. That's not a small optimization opportunity. It's close to a third of the bill sitting in categories nobody owns.
The gap exists partly because vendor benchmarks measure individual task speed, not team delivery velocity. What Ideas2IT's engineers see in practice is a net-zero dynamic: time saved generating code is consumed by increased review load, because faster generation also means more code that needs checking. The tool sped up one stage; the rest of the pipeline didn't move.
The instinct here is to treat this as a procurement cleanup project: audit the tools, cut the duplicates, renegotiate the licenses. That's worth doing, and it's real money. But it's also the kind of fix that has to be repeated every few months as new tools get adopted by new teams, because it doesn't touch the underlying reason duplication and unused capacity keep showing up in the first place.
The optimization levers that get the most attention in AI cost management research are real and worth using. McKinsey's research shows that routing tasks to the right-sized model instead of defaulting to the most capable one, combined with prompt caching, can cut repeated input token costs by roughly 90 percent. Sourcing and contract renegotiation typically yield another 10 to 20 percent reduction in unit costs. Setting hard limits on agent iteration counts prevents the kind of runaway loops that quietly inflate a bill without producing proportional output.
All of that is worth implementing, and none of it is the whole answer. The deeper mechanism, the one that actually explains why spend rises without a matching rise in velocity, is that most enterprises hand AI tools to a team without changing how the team's process works. The product manager still writes the spec by hand and uses AI as an individual assist. The agile process underneath the tooling hasn't moved.
Ideas2IT's engineers have found, across enterprise engagements, that real lift only shows up once the process itself changes: AI agents drafting specs and code with a second agent verifying the work before it reaches a human reviewer, rather than AI sitting alongside an unchanged workflow as an optional accelerant. This kind of restructured agile process is what turns raw AI capability into measured output, and it's a process change.
Ideas2IT ran into a version of the same shape of problem in a completely different domain: a cloud communications platform was quietly overbilled by roughly $100 per customer per month because invisible Unicode characters were triggering a more expensive SMS billing mode, with no tooling in place to detect or stop it.
The fix that actually held wasn't a one-time patch to the billing line. Ideas2IT built a permanent two-layer sanitization system directly into the message pipeline, then productized the underlying detection logic into an open-source Unicode Toolkit now used across three countries.
The parallel to AI spend is structural: an invisible, consumption-based cost problem stayed invisible until someone traced it to its actual mechanism, and the fix that stuck was built into the system generating the cost, not layered on top of it as a report.
If your organization is sitting on the same pattern right now, tracking AI spend closely but watching the number climb anyway, the underlying fix is rarely another optimization pass on the dashboard. It's identifying the specific point in your delivery process where AI is being used as an add-on instead of restructured into how the work gets done.
Ideas2IT's engineers can walk through your current SDLC and show you exactly where that point is. You can start that conversation through Ideas2IT's engineering team.
Coding tools deserve their own line of attention because they're usually the fastest-growing and least-understood part of the AI spend picture. DX's 2026 pricing guide puts total cost, seat plus token spend, at $200 to $600 per engineer per month for teams mixing inline suggestions with agentic tools, which means a 100-developer organization can be looking at $400,000 to $600,000 a year before background API usage is even counted.
The productivity case for that spend often doesn't hold up under scrutiny. Research from Microsoft, found that coding itself makes up only about 14 percent of a developer's actual day.
Speeding up the coding portion, even by half, doesn't meaningfully move total throughput if review, integration, and verification are still bottlenecks. That's the same mechanism from the previous section showing up again at the individual tool level: faster code generation without a change to how that code gets reviewed and merged produces close to a net-zero gain, no matter how fast the code itself gets written.
Ideas2IT has seen this pattern across enough enterprise engineering organizations. AI coding tools hit a natural productivity limit when they only address the code-writing portion of the cycle. The teams that break through it are the ones that restructure review, integration, and verification to use AI as well.
If your AI coding tool bill has grown faster than your delivery velocity this year, that Microsoft finding is likely the explanation. The tool sped up one 14 percent slice of the process and left the rest of the pipeline exactly as slow as it was before.
Not every task needs your most capable, most expensive model, and defaulting to one by habit is one of the quieter ways spend grows without a corresponding gain in output. The decision worth making explicit runs on a small set of criteria:
Premium models earn their price on the right column of that table. Making this a documented policy rather than an individual engineer's default choice is one of the more direct ways to control spend without touching adoption at all.
Everything covered so far, visibility, attribution, optimization levers, model selection, only holds if someone owns it on an ongoing basis. Enterprise AI spend management works best as a shared responsibility, split cleanly across three functions:
The organizations getting real value from AI spend management treat it as a loop, not a project: measure spend and usage, attribute it to teams and workflows, identify waste and inefficiency, optimize based on what's found, validate whether the optimization actually moved the ROI numbers, and repeat.
A one-time cost-cutting exercise produces a one-time result. The spend patterns that created the problem in the first place will regenerate within a quarter or two if nobody owns the loop afterward.
If you're building or refreshing your AI spend dashboard now that the process argument is on the table, keep the list of what actually belongs on it short and specific:
None of this replaces the process work covered above. It's the minimum reporting layer that lets you tell, at a glance, whether the process changes you make are actually moving the numbers.
One metric Ideas2IT considers most diagnostic across engagements: cost per sprint story point. It connects AI investment directly to a delivery unit, making it possible to compare spend-to-output ratios across quarters and teams on the same scale. Token usage tells you what was consumed; cost per story point tells you what was actually produced.
Everything in this piece points toward the same conclusion: the fix for AI spend that isn't converting to margin is a change to how your team works, not a better view of what it's currently doing.
That's a delivery problem, and Ideas2IT solves it by embedding engineers directly into your existing environment rather than handing you a framework to implement on your own. Ideas2IT's forward-deployed engineers work inside your stack, your standups, and your existing OKRs from day one, which is what makes the process changes covered in this piece actually land instead of sitting in a slide deck.
Those engineers run the engagement using Anticlock, Ideas2IT's internal delivery accelerator built specifically for restructuring how AI gets used inside an SDLC. Anticlock is the tooling Ideas2IT's own engineers use to implement the maker-checker style workflow described earlier in this piece: one agent drafting specs or code, a second agent verifying the work, and your team reviewing at the plan and final stages instead of every intermediate step.
Ideas2IT has applied this same platform-plus-process approach across its own AI-native transformation work, which is part of why the delivery model holds up inside client environments with real constraints, not just in a demo.
Ideas2IT is an AWS GenAI Specialist Partner and maintains SOC 2 Type II certification, credentials that matter directly here since this kind of engagement touches your production codebase and your existing engineering workflows, not a sandboxed pilot environment.
The entry point for this work is scoped deliberately small: a focused engagement where Ideas2IT's engineers walk through your current AI spend and delivery process, identify the specific point where cost and process are disconnected, and show you what changes when that gap closes. From there, the engagement scales into a broader transformation only if the initial work proves it out.
Start that conversation with Ideas2IT's engineering team.
Didn't find what you were looking for?
