AI Features Added to Your Software Get Approved on Price Alone

← Back · ACT II · Chapter 8: The Buyer Lifecycle Is Progressive Governance

Most companies have rules for approving a new software charge. Those rules check that the right person signed. They don’t ask what the new feature should deliver, so an added AI feature can be approved with no result anyone can check later.

Most software contracts procurement signs now carry some version of a change-control clause, the rules for adding anything new to a contract. Extra charges need written approval up front, scope changes go through a set process, and somebody with the right authority has to sign before anything new shows up on a bill. When a vendor switches on a feature nobody asked for and the invoice jumps, the first fix people reach for is a tighter version of that clause, and they’re right to reach for it.

It’s worth being clear about what the clause checks, though. It asks whether the charge was authorized and whether the person who authorized it had the standing to do so. It never gets to what the new feature is supposed to do for the business, or how anyone would know a year later whether it did.

How AI Charges Show Up on the Bill

This happens a lot. Zylo’s 2026 SaaS Management Index reports that 78% of IT leaders reported unexpected charges in the past 12 months tied to usage-based or AI pricing. Often an existing plan gets restructured, the AI capability is folded in, and the new price applies at the next renewal or billing cycle.

Australia’s consumer regulator put the mechanics on the record. In October 2025 the ACCC took Microsoft to Federal Court, alleging that Microsoft misled about 2.7 million Australian Microsoft 365 subscribers into thinking they had to accept Copilot and a higher price or cancel. The Personal plan went from A$109 to A$159 a year, a 45% jump. According to the ACCC, a Classic plan without Copilot was still available at the old price, and subscribers could only find it by starting to cancel. Microsoft later apologized and offered refunds to eligible subscribers who switched to Classic. Those were households, not companies, but anyone who manages software spend at work has seen something like it, where the new charge goes through unless someone hunts for the way out.

What the Approver Actually Decides

Now take a well-run version of the same event inside a company. Say the vendor announces an AI assistant for the HR platform. Change control works exactly as written: the request goes to the budget holder, who has the authority, looks at the price, and signs.

Look at what that person actually decided on: a price and a feature description. If the original purchase never recorded what the platform was approved to produce, the assistant has nothing to be weighed against, so the approver is really only deciding whether the money is acceptable. The argument about the invoice just happens a few weeks sooner, and at renewal nobody can say whether the assistant was worth paying for.

I’d close that gap at the point of approval. The person signing off the new charge is the one place where someone could ask what the feature is for, and right now nobody hands them that question.

Add the Expected Result to Every Change Request

Every request to add a paid feature, module or usage tier should carry the result it’s expected to produce, in the same terms as the original purchase, with a date to check it. For the HR platform that might be fewer payroll corrections, or hours given back to the people team, measured against what the system was already doing. The approver signs off on the price and the expected result at the same time. If the vendor can’t say what the assistant will do for these particular users, the company finds that out before anyone signs.

With that line in place, the approver can turn a feature down on evidence, which is a far easier conversation with a vendor than a fight over price. That only holds if the contract lets the company say no and keep what it already bought. If the new feature comes bundled into the platform, or switching it off weakens the parts that were approved, the approver has nothing real to refuse. And at renewal there’s more than a stack of invoices to go on. You can see what was approved, what each addition was supposed to deliver, and what it actually did. There’s a free Purchase Outcome Register on the Guides page for keeping exactly that. It’s the same line a Request for Value asks for on the original purchase, applied to each addition after it.

It also helps with the problem in the Microsoft case, where saying yes is the easy path. If nothing gets approved without a stated result, the vendor is the one who has to do the work to get the charge added.

What a Vendor That Delivers Gets Out of It

A supplier whose assistant really does cut payroll corrections wants that on paper, since a price increase the buyer can trace to a result is much easier to renew than one that showed up on an invoice. The vendors who have trouble with the rule are the ones who can’t say what their additions are for, and most buyers would rather find that out before the charge goes through.

In July I wrote about the AI tax, the extra amount vendors build into renewals on the promise of value nobody has seen yet. Change control is the buyer’s tool for the middle of the contract. Adding the expected result to each request means the approval leaves behind something the business can check at renewal.

References: Zylo, 2026 SaaS Management Index. Australian Competition and Consumer Commission, “Microsoft in court for allegedly misleading millions of Australians over Microsoft 365 subscriptions,” October 27, 2025. Business News Australia, “Microsoft apologises and offers refunds after ACCC Copilot action,” November 6, 2025.

Keep reading: ACT II · Chapter 8: The Buyer Lifecycle Is Progressive Governance