Agentic Maverick Spend Detection: Catching Off-Contract Purchases Before the PO Cuts
written by Cooter:Labs
published on September 12, 2026
Introduction
Most companies with a negotiated supplier base still bleed a meaningful share of spend outside it. A plant manager needs a part today and orders it from whatever distributor shows up first on a search instead of the contracted vendor. A department head expenses a SaaS subscription through a corporate card instead of routing it through the preferred reseller with the negotiated rate. An engineer specs a component from a supplier they've used before at a previous job, unaware the company already has a volume agreement with a competitor for the same part. None of this is fraud — it's maverick spend, purchases that happen outside the negotiated catalog, preferred-supplier list, or approved buying channel — and most ERP systems have no mechanism to catch it before the money moves. The requisition looks completely normal: a valid GL code, a reasonable price, an approver who signs off without knowing a better option existed. The leakage only becomes visible months later, when someone runs a spend-by-category report and finds 15% of a category everyone assumed was fully on-contract.
Most procurement teams already know roughly how much maverick spend they have, because someone runs a quarterly or annual analysis comparing actual purchases against the contracted supplier list. That analysis is useful for building a business case, but it's after-the-fact accounting — the spend already happened, the PO already cut, and redirecting it now means renegotiating a relationship or eating the cost difference. Catching a requisition before it becomes a purchase order is a fundamentally different operation: it requires checking the request against catalog and contract coverage in the seconds between when someone submits it and when it gets approved, not in a spreadsheet built weeks later.
An agent with read access to the active supplier contracts, punchout catalogs, and preferred-vendor lists can check a new requisition's category, item description, and requested supplier against what's actually covered the moment the requisition is submitted — not after it's been approved and turned into a PO. For a punchout or catalog item, this is close to exact-match: either the item exists in the catalog under a contracted supplier or it doesn't. For a free-text or non-catalog requisition, the match has to work off category codes and item description similarity, since the requester rarely types the exact SKU or contract line a matching engine would want. The output isn't a block — it's a flag: this line has contract coverage from a different supplier at a different price, surfaced to the requester or approver before the PO exists.
Not every off-catalog requisition is maverick spend in the sense that matters — sometimes the negotiated supplier genuinely doesn't carry the item, is out of stock with a lead time the requester can't absorb, or the category has no contract at all yet. An agent that only flags "not on the preferred list" without checking whether a real alternative exists just generates noise that gets ignored after the second false positive. The check needs to confirm the contracted supplier can actually fulfill the specific item, quantity, and timeline requested before treating the requisition as redirectable — and when it can't, the right output is a note that this is a genuine coverage gap worth flagging to the category manager for a contract, not a compliance flag on the requester.
When coverage does exist, the agent should surface the on-contract alternative to the requester at the point of submission — same item or a comparable substitute, at the negotiated price, through the correct catalog or punchout link — rather than let the requisition proceed and note the deviation in a report someone reads next quarter. Some organizations want this as a hard stop requiring the requester to justify the exception before it routes to an approver; others want it as a soft nudge that still lets the requisition through if the requester has a real reason. Which posture is right depends on the category and the company's risk tolerance, and that's a procurement-policy decision the agent should be configured to follow, not one it should make unilaterally by blocking things on its own judgment.
A single off-contract purchase tells you little. A pattern — the same cost center repeatedly buying a category off-contract, or a category where flagged requisitions keep going through despite an on-contract alternative — tells you either the contract terms aren't actually competitive (so requesters are routing around them for a reason) or a specific team needs a different buying workflow than the standard catalog path. An agent that logs every flagged requisition with its outcome (redirected, exception approved, genuine gap) gives the category manager a dataset to renegotiate contracts or fix a broken buying process, instead of a single spend-leakage number with no way to act on it.
Looking Ahead: Challenges and Innovations
Free-text requisitions are the hardest and most common case
Catalog and punchout purchases are the easy win because the match is close to exact. Most maverick spend, though, shows up in free-text requisitions — a description typed by a requester in whatever words they used, with no SKU, no standard unit of measure, and often a category code chosen more or less at random from a dropdown. Matching that reliably against contract coverage means working from item description similarity and category, which will sometimes miss a real match and sometimes flag something that isn't actually covered. The practical answer is to tune for fewer false positives even at the cost of missing some real maverick spend, since a system that cries wolf gets ignored within a few weeks, and an ignored control catches nothing at all.
The contract repository has to actually be current, and often isn't
This entire mechanism depends on the system of record for active contracts and catalog coverage being accurate — which supplier is contracted for which category, at what price, through what channel. In practice, contracts lapse without the record being updated, get renegotiated with new pricing that doesn't make it into the catalog for weeks, or get replaced by a new supplier while the old one is still marked active. An agent checking against a stale contract record will confidently redirect a requester to a supplier relationship that no longer exists at the terms shown, which is worse than not checking at all because it actively misleads someone. This is a case where the agent's output is only as good as a data source it doesn't own, and that ownership gap needs a real fix, not a workaround inside the matching logic.
Redirecting someone isn't free, and the friction has a real cost
Every flagged requisition that gets redirected costs the requester time, and if the on-contract alternative genuinely takes longer to arrive or has a worse fit for the actual need, forcing the redirect can cost the business more than the maverick spend it prevents. Deciding how hard to push back — a hard stop, a soft nudge, or just a visibility flag with no friction at all — is a judgment call about the specific category's risk and cost profile that belongs with procurement leadership, not something to standardize identically across every spend category by default.
The metaverse
As more procurement organizations move spend through structured punchout catalogs and centralized supplier portals rather than free-text requisitions, the matching problem this depends on gets easier by construction — an item pulled from a live catalog already carries the contract, price, and supplier identity that a free-text description has to be inferred from. That shifts maverick-spend detection from a probabilistic matching exercise toward something closer to a real-time compliance check, which is the same direction most other agentic procurement and finance workflows are heading: catching the deviation at the moment of commitment instead of reconstructing it from a report after the fact.
Conclusion
Maverick spend is rarely a discovery problem — most procurement teams can already estimate how much of it they have with a quarterly analysis. It's a timing problem: by the time anyone sees the number, the purchase order has cut, the money has moved, and redirecting it means renegotiating a relationship instead of just picking the right one at the start. An agent that checks a requisition against real contract and catalog coverage before it becomes a PO, distinguishes a genuine coverage gap from a requester who didn't check, and routes the exception back through the negotiated channel doesn't replace the procurement policy that decides how much friction is worth applying. It changes whether that policy actually gets enforced at the one moment it can still change the outcome, instead of only showing up as a line item in next quarter's spend report.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.