Off-contract spend prediction

Score the request while it is still a request. The job is to put the contracted supplier in front of the requester, or to capture why that path will not work, before anyone cuts a PO.

After the PO, the p-card, or the invoice, the money has moved. That review is maverick spend detection.

A high score is not a finding that the spend is already maverick. Treating a likelihood as posted leakage invents numbers that never hit the ledger, and it trains requesters to argue with the model instead of using the catalog.

The only two honest outcomes of a flag:

• Redirect. The requester takes the preferred supplier or catalog line. The request continues on-contract.
• Justified exception. The requester states why the contracted path fails (OEM sole-source, plant-down, site the catalog does not cover, item not on the agreement). The request routes with that reason attached, not as a silent bypass.

A hard stop belongs to a different control. Use policy pre-check at intake to refuse a named off-list supplier or a channel the category does not allow. Prediction should not freeze a plant-critical buy because a score is high.

The score is useful only if it compares this request to a usable contract in this category, and to how this person has bought in that category, not to a company-wide preferred-vendor slogan.

Resolve, in order:

• Category and item. "Gasket for filler, line 3" is not a category. Run free-text request parsing first so you score a classified buy, not a sentence.
• Contracted suppliers and channels for that category. Legal entity, reseller of record, punchout or catalog, effective dates, company codes. A brand name on an MSA is not coverage.
• Named supplier on the request, if any. Match affiliates, not only the trading name. A local distributor that is not the contracted MRO house is the usual miss.
• Requester history in this category. Repeat free-text POs, repeating p-card merchants, the same off-list supplier. History is a prior. It is not proof this line will go off-contract.
• Whether a preferred path actually exists. If nothing on contract can fill the need, label it a coverage gap, not likely maverick. Send that gap to ai supplier discovery. Prediction is not a substitute for a missing agreement.

If off-contract is likely, show the preferred supplier or catalog on the form and require an exception reason before the request leaves intake. Do not drop a high score into the same approval queue as a clean catalog pick and hope an approver notices.

Intake and guided-buying suites such as Coupa, SAP Ariba, and Zip sit in this class: they hold the request, the preferred-supplier list, and the catalog, which is where a score and a redirect prompt should run. Spend analytics platforms such as Sievo sit one stage later. They explain what already posted. This page does not rank those products. Use whichever system already holds your contract-supplier map. Do not build a parallel intake form just so a model can score a copy of the request.

The following is an illustrative scenario, not a measured result.

A maintenance supervisor at a packaged-food plant submits: "Need Viton gasket for filler head, line 3, OEM spec, today." Parsing puts it in MRO / process-equipment spares. The named supplier is the industrial distributor two towns over, the house this supervisor has used on free-text POs for two years. The contracted path is an MRO punchout that stocks a matching gasket under the manufacturer part number.

What the score should do

The model should fire because three signals line up: the category has a live catalog, the named supplier is not on that contract, and this requester's MRO history is off-catalog. The form then shows the punchout line (part number, contracted house, expected lead time) and asks: use this supplier, or say why not.

If the catalog part matches the OEM spec, the supervisor picks it. The request continues on-contract. That is a redirect. Nobody writes a maverick finding. Nobody puts the supervisor on a leakage slide.

If the punchout SKU is a generic equivalent and only the OEM part is approved on that filler, the supervisor writes sole-source, OEM part required, catalog equivalent not approved. The request routes with that reason. Category can later add the OEM SKU. The buy is not parked for a compliance conversation while line 3 is down.

What must not happen

If the control blocks the request until procurement clears the score, you have turned a prediction into a plant-critical stop. Line-down MRO is where requesters go around you next time: a p-card, the local house on a personal card, a call that says "just invoice us."

If the ticket labels the request maverick, you have treated a prediction as already-posted off-contract spend. The gasket has not been bought. The supervisor used the path the form allowed last year.

If the weekly digest names the supervisor as a repeat offender, you have shamed a requester whose real issue may be that punchout search does not find gaskets by equipment tag. Shame is how the next extract gets worse, not how catalog adoption improves.

The intervention belongs on the request form, in language a plant supervisor can act on, not in a procurement-only queue after "submit."

Write it as a choice:

1. Switch to the preferred supplier or catalog line shown.

2. Keep the named supplier and pick a reason: sole-source OEM, plant-down / breakdown, catalog does not stock, site not on contract, other (short free text).

A free-text "other" with no reason is a bypass with extra clicks. A twenty-field justification is a block dressed as a form. Category leads should review reason codes monthly for patterns (the punchout never has the OEM SKU; one site is missing from the agreement). That review is process design. It is not a hunt for names.

Do not auto-reject on score. Auto-reject is how a true sole-source, a new legal entity, or a breakdown spare sits in limbo. Route exceptions on a faster path than a contested sourcing event. Plant-down and OEM sole-source should not wait behind a quarterly RFP.

Keep requester identity out of the first management pack. Roll up by category, site, reason code, and whether a preferred path was shown and refused. spend analytics and savings tracking can later show whether redirects actually landed on contracted prices. Do not book predicted flags as savings. Savings is a closed PO on the preferred supplier, or a catalog SKU that got used.

A likelihood score is not leakage, and it is not a policy miss.

Three controls get confused because they all mention off-contract suppliers:

• Policy pre-check is a rule: this supplier or this channel is not allowed for this category. Deterministic. Show what is wrong.
• Off-contract prediction (this page) is a likelihood: this request resembles past bypass, even when the requester has not named a banned supplier. Probabilistic. Show the preferred path and ask.
• Maverick detection is a posted-transaction review. The money already left. Quantify priced leakage only where a contracted unit price existed.

Do not feed predicted flags into the CPO maverick total. You will double-count (a redirected request that never posted, plus the historical p-cards that did) or you will count fiction (a flagged request that was never bought).

If the preferred supplier cannot fill the need, stop scoring it as likely maverick. That is a coverage gap. Send it to category, or to supplier discovery, with the exception reason. Calling a coverage gap "predicted maverick" makes the model look precise and the contract file look complete. Neither is true.

Start in categories where the preferred path is actually usable: a catalog or punchout with stock, a known reseller, requesters who currently free-text out of habit. Do not start on true OEM breakdown spares with no catalog equivalent. You will train the plant that procurement blocks work, and they will stop submitting requests you can see.