Spend Intelligence vs. Process Mining: How Companies Recover Millions Their Controls Approved

Process mining shows where the workflow broke. Spend intelligence catches the overcharge that never broke anything, which is where the money tends to sit.

A supplier can overbill you 4.9% on every invoice for a year without triggering a single exception. The three-way match passes and the payment clears, because the overcharge sits inside the tolerance band your controls are set to allow. On a $57 million resin contract, that could be $2.8 million.

Nothing broke, so nothing flagged it. Two categories of software claim this problem, and they look for different things.

Spend intelligence is the use of AI to validate every procurement transaction against its contract, testing each invoice line for overbilling, duplicate payments, off-contract spend, and unclaimed rebates. Process mining is a technique for reconstructing how each transaction moved through your systems, built from ERP event logs, to find where the process stalled, skipped an approval, or broke. That $2.8 million is invisible to process mining and the entire point of spend intelligence.

That tolerance band is not an oversight. It exists so accounts payable can clear volume without halting on every rounding difference and bit of FX drift, which is a deliberate trade of precision for throughput. It is also the one place a controls environment is designed not to look.

The reason the gap persists is organizational more than technical. Accounts payable is measured on throughput and days to pay. Procurement books its savings at signature, when the rate is negotiated, rather than at payment, when the rate is applied. Finance explains variance at month end against its own budget. Nobody's job is to check whether the amount billed matched the amount agreed, which is why so many enterprises hire a contingency firm once a year to go do it retroactively. By the reckoning of those firms, roughly $3.5 million in overpayments sits inside every $1 billion of spend.

What process mining is built to see

Celonis and SAP Signavio reconstruct the real path of every purchase order and invoice across your systems, including every handoff and delay, and show where the workflow breaks: a purchase order that stalled for eleven days, an approval that skipped a tier, a payment that went out late. For leakage shaped like a process failure, they are strong. The maverick buy that bypassed the workflow and the discount lost because someone paid on day 45 of a net-30 term with a 2% early-pay incentive are both process-shaped, and process mining finds them.

The platforms built on that technique have also expanded well past it. Most competitive write-ups still describe them as they looked two years ago. In May 2026 Celonis launched the Celonis Context Model, a live model of operations assembled from process data and business knowledge across connected systems, and agreed to acquire Ikigai Labs for planning, simulation, and forecasting. SAP Signavio added agent mining, which traces how AI agents move through a process, what they cost to run, and whether they stay inside policy.

Anyone running Celonis will want to know whether the Context Model already covers this. The expansion is real, and it runs along the process axis. A model of how the business operates, built from operational data, tells you how work flows and where it degrades. Celonis does not position it as reading a contract's pricing terms and testing an invoice line against them, and Ikigai's contribution projects the process forward rather than auditing a transaction backward against an obligation. What separates the two categories is the unit of analysis: process mining reasons about events, and spend intelligence takes the transaction and checks it against what the contract entitled you to.

Where a clean three-way match hides an overcharge

A flat 4.9% every month is the easy version to picture. In practice it's subtler, and it hides in how the price gets set.

Take that packaging resin bought on an index-linked contract, one of the standard pricing structures in the category alongside fixed-price deals, revision-threshold contracts, and spot buys. The price isn't a number in the agreement. It's a formula: a published polymer index, averaged over a defined reference period, less a negotiated discount, reset each quarter. The index falls. The supplier keeps billing off the prior quarter's reference period, so the decrease shows up a month late. Increases, in the same relationship, tend to arrive on time.

That month bills at $1.49 per kilogram against an entitled $1.42. The invoice cites the correct contract, matches the purchase order it was issued against, matches the goods receipt, and the variance sits at 4.9%, inside a 5% band. In SAP that band is a tolerance key, set per company code, and an invoice only blocks for payment once it breaches the upper limit someone configured. The three-way match passes. Every event in the log is clean, because nothing in the process failed.

On 40 million kilograms a year, a seven-cent lag running one month in three is about $930,000. That's one material, on one contract, in one category.

The event log records that a match occurred and that it passed. The entitled price isn't in there, because it's a formula written in prose, pointing at an external index, with a reference period and a discount and a unit of measure that may not match how the invoice states any of them. Testing it means holding the contract terms and the invoice line in the same pass, recomputing what the price should have been, and normalizing between them.

Why purchase price variance doesn't catch it either

Anyone in finance will point out that standard costing already exists for this. Purchase price variance is the difference between what you paid and your standard price, multiplied by quantity, posted to a variance account every month. A persistent overbill of this size should light up PPV.

Sometimes it does, and the teams catching leakage today are usually working from PPV. Where it stops short comes down to how the baseline gets set and what the number lumps together.

Standard cost is a baseline someone sets, normally once a year in a costing run and often from recent actuals. A price that was already drifting when the standard was struck gets absorbed into the standard, and from then on there's no variance left to see. The overbill becomes the expected cost.

Even when PPV does run unfavorable, it arrives as one aggregate number covering index movement, freight, FX, mix shift, and missed volume tiers together. Unfavorable PPV on a resin line tells a controller the number moved, which for an index-linked material is the normal state of affairs. It doesn't separate the part that was the market from the part that breached the agreement, and it doesn't produce anything you can put in front of a supplier. PPV measures against a baseline you set yourself. What the supplier was obligated to charge is a different reference point, and it's the only one that turns a variance into a claim.

What each one catches

"Not the job" marks a division of labor rather than a gap: the work isn't what that category was built to do.

The line item this replaces

Process mining is rarely what gets displaced. Teams already running Celonis or Signavio keep running them, and the two sit side by side without much overlap. The annual recovery audit is the line item under pressure, because it's the workaround enterprises adopted for the ownership gap in the first place.

The limit on that model is decay rather than a deadline. A standard right-to-audit clause runs through the contract term and for two years after it ends, so an old claim is rarely time-barred. What falls is the probability of collecting. The cleanest recovery is an offset against a live invoice while the volume and the relationship are both active, and a claim raised eighteen months later argues against a supplier's own records, a different account team, and a budget that closed.

Continuous validation moves the check upstream. The same test that builds a recovery claim after payment can flag an above-contract line at the approval gate, while the invoice is still in the queue and the money hasn't moved. Finding the overcharge is the smaller half of the work either way, since the claim still has to be raised, and asking for an offset on the next invoice is a different conversation from asking for a check.

Where Tellius fits

Tellius gives procurement and finance teams an AI worker that runs this validation as a Mission: a multi-step investigation that pulls every invoice line with its matched contract price, normalizes currency and unit of measure into a common base, computes the variance against the tolerance band, filters to what's claimable, then clusters the results by supplier, site, and category and assigns each a root cause.

What that looks like on a Monday: the packaging category manager opens a brief listing the suppliers with above-contract lines from the prior quarter, ranked by recoverable amount, each with the clause it breached and the reference period it should have priced from. The resin lag is at the top. They forward the claim pack for the largest three to supplier management and hold the rest for the next business review.

The second stop is finance, and it's the one that decides whether any of it counts. The controller who saw this same overbill last quarter as unfavorable PPV on a resin line now has the market movement separated from the contract breach, with every claim tied to an invoice line and the clause it broke. That's the version that holds up in an audit and books as recovered margin instead of a variance somebody explained in the close meeting. Nobody built a report to get either view.

It reads the invoice, PO, and receipt data your ERP already holds along with the agreements sitting in your contract repository, so standing it up is a connection rather than a migration.

The Missions are deterministic, so the same question returns the same answer on every run and each claim traces to a specific invoice line and the clause it breached. That's what makes the number survive a CFO or an auditor asking where it came from. Because the reasoning and domain model come pre-built, the first read on a quarter of spend happens in weeks rather than a build cycle, and your own context, including the tolerance bands, index references, and category rules your team applies, is learned on top and carries into every later run.

Where it's harder than it sounds. The contract side is the part that takes work. Pricing terms arrive as amendments layered on a master agreement, sometimes with side letters, and establishing which version governed on the date of a given invoice is genuine effort rather than a parsing step. Categories with clean, current, centrally held agreements validate quickly. Categories where the terms live in a folder someone maintained by hand take a pass to get right, and that belongs in the scope before anyone promises a number.

Tellius does not run the buy-and-pay workflow. It issues no purchase orders, pays no invoices, and is not a supplier network or a system of record. You keep Coupa, you keep SAP Ariba, you keep your process-mining platform, and Tellius reads what they produce and checks whether the result was correct. Your team decides what to claim. Tellius does the work that gets the claim ready.

‍

‍

‍

‍

‍

‍