Sponsored and in Partnership with
Click here to be a future partner or sponsor.

FinOps & Beyond is what engineering, finance, and IT leaders read to understand FinOps, and what it means for operating models, accountability, and spend decisions.

30 Issues. Wow. I can’t believe.

I started this because I got tired of watching FinOps get sold as a tooling problem when it's a change management problem, and I'm still on that hill.

But this week I want to do something I haven't done here yet: put two vendors next to each other, in public, and let you see where they agree and where they don't.

For the last 3 issues I've been arguing that tagging is configuration, that a model call gets one shot at being attributed, and that the tag has to live on the credential and not the call. That argument came out of watching the AI-native, gateway-first crowd. This week I read a report from Ramp, and I read through FinOpsly's product pages more closely. Different audiences, different starting assumptions, same underlying problem. I think looking at both at once tells you something neither one tells you alone.

The Problem Has Two Doors

AI spend doesn't walk into your company through one door.

Door one is procurement. Someone on marketing signs up for a $20/month AI writing tool on a corporate card. Someone on sales expenses a ChatGPT Plus subscription. A team lead approves a vendor because the free trial worked. This spend looks exactly like SaaS sprawl looked 5+ years ago, because it is SaaS sprawl, just with a different logo on the invoice.

Door two is the API. A developer gets an Anthropic or OpenAI key, wires it into a product feature, and now your application is making a few hundred or a few million model calls a day. This door I've spent three issues on: the one where the spend has no invoice to sit on, fires in milliseconds, and is gone before anyone can go back and fix the metadata.

Most companies I talk to have both doors wide open at once, and they're trying to solve door two's problem with door one's tools, or the other way around.

Ramp: Attribution From the Finance Side

Ramp's report on managing AI spend ("3 Steps to Manage AI Spend") opens with an interesting stat: business AI spend is up roughly 4x year over year, and most of it is unmanaged. They call it a trillion-dollar blind spot and the problem is directionally what I see with clients.

Their three steps are built for door one.

Step one is visibility. Audit every AI vendor already in the building, no repercussions, so people actually tell you the truth. Put every payment through one platform. Use corporate cards so the transaction detail exists at the moment of purchase instead of showing up as a mystery line item forty-five days later (of course Ramp). And give AI spend its own category in the chart of accounts instead of burying it inside "software," which is the accounting equivalent of a wiki page nobody updates.

Step two is control without a wall. Give teams a real budget for AI experimentation so they're not sneaking around procurement to try something. Issue virtual cards (again, great marketing Ramp) with merchant restrictions and caps baked in. Set tiered approvals so a $40 tool doesn't need the same sign-off as a $4,000 one. Their line on this is one I'd steal: cumbersome process is what creates shadow AI, not curious employees.

Step three is turning the spend into a negotiating edge. Build an ROI plan, not after finance asks about it. Review usage against payment on a real cadence, because AI pricing moves fast enough that a quarterly review is already stale. Route requests to the cheapest model that clears your quality bar instead of defaulting to the most expensive one out of habit.

Notice what this is. It's a finance and procurement model, applied to a new category of spend. It's exactly right for door one, and it has almost nothing to say about door two. Nowhere in the three steps is there a mechanism for attributing a single API call to a team, a customer, or a feature. That's not a knock. It's not the problem they're solving.

FinOpsly: Attribution From the Engineering Side

FinOpsly's approach starts from the other door. Their approach is one model and one policy set across AI tokens, cloud compute, and data warehouse spend, attributed all the way down to the individual user, not just the team or the account.

Their framework runs four steps, and they've named all four with verbs instead of nouns, which I appreciate:

Plan. What will this cost before we build it. This is a pre-deployment cost estimate that shows up in the IDE while an engineer is still writing the code, not after the bill arrives.

Explain. Where did every dollar go. This is cost-to-serve: joining token spend, compute, and data into one line per user, per app, per customer, with a natural-language interface sitting in Teams or Copilot so a PM can ask the question without filing a ticket to a data team.

Act. How do you keep it in bounds, fast. Budgets, caps, and guardrails that are supposed to be reversible, so a control doesn't turn into an outage.

Prove. What did you actually save. Chargeback accuracy and forecast variance against the real invoice, which is the step most vendors skip because it's the one that can make you look bad.

This is a door-two approach. It assumes the spend is happening inside your own application, generated by your own calls, and it's trying to answer the exact question I raised in issue 29: how do you attribute a model call at the moment it fires, before it disappears. Explain is their version of "the tag belongs on the credential." Act is their version of the gate and the rail.

Where They Agree, and Where the Real Answer Lives

Strip the branding off both and you get the same three moves in a different order: see the spend, put a boundary around it before it gets out of hand, and check afterward whether the boundary actually worked. Visibility, control, proof. Plan and Explain, Act, Prove. Its the same.

Where they split is the moment they're built to catch. Ramp is built to catch the moment someone decides to buy something. FinOpsly is built to catch the moment code decides to call something. Those are different events, owned by different people, moving at completely different speeds. A procurement decision takes days and leaves a paper trail. A model call takes milliseconds and leaves an amount.

This is the part I got wrong in my own head for longer than I should have. I kept looking for the one right way to attribute AI spend, the way I spent my career looking for the one right way to tag a cloud resource. There isn't one, for the same reason there was never one for cloud. A three-person startup buying five AI tools on a company card has a Ramp problem. A platform team routing forty million model calls a day through their own product has a FinOpsly problem. A 200-person company with both a marketing team expensing tools and an engineering team shipping AI features has both problems running at the same time, and needs both kinds of control, and neither vendor's homepage will volunteer that they only solve half of it.

If you take one thing from putting these side by side: don't ask which framework is right. Ask which door your spend is coming through, because that tells you which framework even applies.

The Job

Three moves this week, and you can do the first one this week without buying anything.

Move One. Sort your last quarter of AI spend into the two doors. Card and vendor-invoice spend in one column, API and token spend in the other. Most finance teams can pull the first column today. Most engineering teams have never been asked for the second one. That gap could be interesting.

Move Two. Match the control to the door, not the vendor pitch. If door one is where the mess is, you want budgets, tiered approvals, and a real AI line item in the chart of accounts, the Ramp playbook. If door two is where the mess is, you want key issuance discipline and a gateway or proxy in the request path, what I've been discussing since issue 27 and what FinOpsly is selling toward from the other direction.

Move Three. Ask any vendor, including the ones I write about, which door they actually solve. Not which door they say they solve. Ask them to show you a customer who had the other kind of spend problem and what they told that customer to go buy instead. A vendor who claims to solve both is usually solving one well and waving at the other.

I've said before that FinOps is mostly a change management problem and not a tooling problem. This is the same argument from a different angle. The tool you pick has to match the shape of the spend you actually have, and most of you have two shapes, not one.

Written with the help of AI. All the ideas expressed are mine and mine alone.

FinOps Company Spotlight

Category: Software

What They Do: FinOpsly is an AI-native Value-Control platform helping enterprises map cloud, data, and AI spend to business value and automate cost control through agentic AI

Why It Matters: Cost governance is becoming critical in the AI era

Reply

Avatar

or to participate