Almost every "AI for sales" feature points the same direction: order more, add this item, don't forget the upsell. There is a commercial logic to that, and it is also why those features are easy to ignore. A suggestion that always says yes carries no information.
The signal we are proudest of shipping says no. When a buyer adds a line to a purchase order, xMatix checks whether the stock pipeline already covers that item — and if it does, it says so, shows the arithmetic, and offers a corrected quantity in one click.
The problem it solves is boring and expensive
Consider an item with 40 units on hand and a reorder point of 65. A buyer reviewing stock sees 40, sees 65, and orders. That is the correct reading of the numbers in front of them, and it can still be wrong.
What the screen does not show is that 30 units are already in transit, 25 are on an unreceived purchase order raised last week by a colleague, and 15 are committed against an open requisition. The true position is not 40 — it is 95, comfortably above the reorder point. The order is unnecessary, and nobody involved made a mistake. The information was simply spread across four places.
Repeat that across a few hundred SKUs a month and it becomes one of the least dramatic ways a distribution business ties up working capital. There is no incident, no argument, no obvious failure — just stock arriving that did not need to.
What the signal actually computes
When a purchase order line is saved, the provider nets the full position for that item:
- stock on hand
- plus in-transit shipments
- plus quantities on other pending purchase orders
- minus open requisitions
- minus unfulfilled sales orders
It compares the result to the item's reorder point — lead time multiplied by average consumption, plus the minimum order quantity — and produces one of two findings. Either the pipeline already covers the item, and the line may not be needed at all; or the quantity being ordered would still leave the item below its reorder point, which is the same mechanism catching the opposite error.
Both come with the full evidence attached: each component of the netting, the reorder point, and the suggested quantity. And both come with an action — applying the correction patches the line directly rather than sending the buyer back to re-derive it.
Why it is arithmetic, not a language model
This is the design decision most worth explaining, because it looks like a step backwards. The netting is deterministic C#. No model is invoked to decide whether the pipeline covers the line.
Three reasons, in order of importance.
It has to be right every time. A recommendation that changes a purchase order is a financial instruction. A rule that nets five quantities and compares them to a threshold is correct by construction, testable, and identical on every run. A model asked to do the same arithmetic over the same five numbers is usually correct — and "usually" is the wrong standard for something a buyer accepts in bulk.
It has to be explainable. The nudge earns trust by showing its working: on hand 40, in transit 30, on order 25, committed 40, net 95, reorder point 65. A buyer can check that in ten seconds and either accept it or spot the stale lead time behind it. An explanation generated after the fact is a different thing from the calculation itself, and only one of them can be audited.
It has to be cheap enough to run always. This fires on every purchase order line save. Deterministic evaluation is effectively free, so it can run on everything. A model call per line has a cost that scales with the exact usage you want to encourage.
So where is the AI?
In the delivery, not the decision — which we think is the right division of labour, and it took us a while to say it plainly.
The nudge engine produces structured signals with evidence attached. Sense Assist surfaces them in context, explains them in plain language when asked, answers follow-up questions against the same data, and carries the one-click action under the user's own permissions with the change written to the audit trail. Ask "why is this flagged?" and you get an answer grounded in the evidence the provider computed — not a fresh guess at the same question.
This is a general pattern rather than a special case. Nine signal providers ship today across inventory, schemes, receivables and service, and each is deterministic in the same way: a scheme gap that shows the shortfall to the next slab, an overdue receivable, an order delivered but not yet invoiced, a customer who has gone quiet against their own pattern. The intelligence in the product is mostly in choosing what to compute and when to say it.
The honest limitation
The netting is exact. The reorder point it compares against is not, because it depends on lead time and average consumption held as item attributes — values a person maintains. If a supplier's lead time changed six months ago and nobody updated it, the comparison will be confidently wrong, and it will look authoritative while being so.
That is worth stating clearly rather than hiding, and it is also why the evidence is shown rather than summarised. A buyer who can see lead time 14 days, average consumption 3/day can recognise a stale assumption. A buyer shown only a conclusion cannot.
Improving those inputs — computing consumption and classification from observed movement rather than relying on maintenance — is the obvious next step, and it makes every downstream calculation better at once.
What we would tell another team building this
Find the decision where your users lack information rather than judgement. Buyers do not order badly because they cannot do arithmetic; they order badly because the five numbers they need are in four places. Closing that gap needs no model at all — and once the signal is trustworthy, an assistant on top of it becomes genuinely useful rather than decorative.
Then let it say no. A system that only ever encourages the transaction is not advising anyone.
Related: What is a reorder point? · Suggested order quantity · Sense Assist