Approve the Ceiling, Not the Seat: Usage-Based AI Tools in Slack

Someone posts in #purchasing: "Can I get the team plan for this AI coding tool? It's $40 a seat." The approver checks the budget, sees five seats, and says yes. Three months later the bill is four times what anyone approved, and nobody did anything wrong. The tool just stopped charging by the seat.

That pattern is getting common. Pleo's finance team points out that GitHub Copilot moved to usage-based AI Credits billing on June 1, and that Anthropic restructured Claude enterprise pricing into separate pools for interactive and agentic use (Pleo). When the price depends on how much people use the tool, approving the tool tells you very little about what you'll pay.

Why a "yes" on the tool isn't a yes on the spend

A seat-priced subscription has one number to approve. A metered tool has a rate, a usage level that nobody knows yet, and often a ceiling that can be set in the vendor's admin console or left wide open.

How fast that goes wrong is real, not hypothetical. One CTO writing in Forbes describes an integration that normally cost under $1,000 a month going past $10,000 in a single month, with no change in the team's work, because something was calling an API far more often than it should have (Forbes Tech Council). The same piece notes that departments outside engineering now buy usage-priced AI tools without IT or procurement in the loop.

If the Slack approval only captured "AI tool, $40/seat, approved," finance has nothing to compare that bill against when it lands in QuickBooks or Xero.

Approve a ceiling, an owner, and a re-approval trigger

The fix isn't to make AI requests harder. It's to ask for three things a seat-based request never needed.

A monthly ceiling. Ask the requester for an expected monthly spend and a hard maximum. The approval covers the maximum, not the estimate. If the vendor supports a spend limit or budget cap in its admin settings, note on the request that it's set and at what amount.

A named owner for the spend. The Forward View argues that every material AI workflow needs a named budget owner, with a title and a cost center, and that this is a separate question from whether the tool is safe to use (The Forward View). In practice that's the person who gets asked when the bill jumps. It isn't the tool, and it isn't "engineering."

A trigger to come back. Decide on the request what change sends it back for approval. The Forward View describes a mid-market SaaS company whose monthly AI spend went from $18K to $47K in two months; it set tiered approval thresholds where anything above 25% month-over-month growth needed a named sign-off, and spend was flat six weeks later (The Forward View). Twenty-five percent isn't magic. The author calls it arbitrary. What matters is having a number the approver agreed to.

What to add to the Slack request

For any tool billed by usage, credits, tokens, or "overage," add these fields to the request:

• Pricing type: per seat, usage-based, or hybrid (seats plus metered usage).
• Expected monthly spend and approved monthly maximum.
• Vendor-side cap: set, not set, or not available.
• Budget owner: a person, plus the department or class you'll code it to in QuickBooks, or the tracking category in Xero.
• Re-approval trigger: the dollar amount or percentage jump that sends it back.
• How it's paid: card, invoice, or reimbursement, so the approval can be matched to the right transaction.

The hybrid case is the one people miss. Pleo warns that vendors are increasingly bundling AI features with separate metered components that sit outside core seat pricing (Pleo). A familiar tool that's been approved for years can start carrying a usage line at renewal. So treat a renewal that adds metered AI as a new request, not a rubber stamp.

Check the bill against the approval, every month

Usage-based spend doesn't get approved once. When the bill posts in QuickBooks or Xero, compare it to the approved maximum on the original Slack request:

• Under the maximum: book it and move on.
• Over the maximum, under the trigger: flag it to the budget owner in the same thread.
• Over the trigger: it needs a new approval before next month's usage runs, not after.

Keeping the request, the ceiling, and each month's actual in one thread means the person who approved the spend sees how it actually went, and finance isn't the only one who notices.

Don't over-correct

Clamping down too hard has its own cost. One finance leader quoted by Pleo put it this way: if you add too many guardrails, "people will either stop using them or use personal licences, which is a much greater risk" (Pleo). Personal licences mean spend that comes back as a reimbursement with no approval, no ceiling, and no owner.

So keep the request short. A small experiment under your normal approval threshold can go through with a low ceiling and a 30-day review. Save the heavier review for tools that get near real money.

The short version

• Ask whether a tool is priced per seat, by usage, or both before approving it.
• Approve a monthly maximum and a named owner, not just the tool.
• Write the re-approval trigger on the request.
• Set the vendor's spend cap when there is one, and say so on the request.
• Compare each month's bill in QuickBooks or Xero to the approved maximum, in the same Slack thread.
• Treat a renewal that adds metered AI as a new request.