Three Requests, One Purchase

It is the oldest move in public procurement and it is not usually malicious. A department needs something, the open-tender process takes eleven weeks, the ceiling for a quotation-based purchase sits somewhere below what they need, and a purchase that should have been one becomes three. Sometimes it is corruption. More often it is a director trying to get chairs into a classroom before term starts. Both look identical in the data, and that is exactly the problem an audit is trying to solve.

So the reasonable question to ask any procurement system is whether it can see the pattern. Our answer is no, and this post explains precisely why, because the reason turns out to be more useful than the answer.

A procurement request in our system carries no money

This is the fact everything else follows from, and it surprises people who assume the request is where the value lives.

The procurement request record holds a reference number, a department, a description, a status, a warehouse and location, and the chain of people who raised, submitted, approved or rejected it. There is no amount on it. Not a total, not an estimate, not a ceiling. The value of a request exists only as the sum of its line items — each line carrying a quantity and a price — and that sum is never computed onto the request, never stored, and never compared to anything.

That single design decision is the whole story. Splitting is a comparison between a value and a threshold. If the record where the split happens has no value on it, there is nothing to compare at the moment it matters.

Splitting is a comparison between a value and a threshold. The record where the split happens carries neither.

And the department on a request is free text

There is a second structural fact worth knowing, because it affects any attempt to spot the pattern by hand.

There is a real departments table in this product, with real records, and requests for quotation and purchase orders both carry a proper reference to it. Those references were added deliberately, later, and they work. The procurement request predates them and stores its department as a plain string typed into a field.

So "Health", "health", "Health Dept" and "Dept of Health" are four departments as far as a grouped query is concerned. If you set out to review every request from one department over a quarter, you are relying on whoever typed the field to have typed it the same way each time. That is not a control; it is a hope.

Reading down that table tells you where the audit trail firms up. It firms up after the decision that a split would have distorted.

There is no procurement threshold anywhere in the product

This is worth stating flatly because thresholds sound like the kind of thing every procurement system must have, and evaluators often assume it rather than ask.

There is no procurement method field, no value band, no ceiling above which a different process is required, and no configuration screen where you would enter one. Searching the application for procurement thresholds returns nothing.

Value thresholds do exist elsewhere in the product, and two of them are real controls — but neither is a procurement ceiling.

• Stock adjustments have a genuine value threshold, and it refuses. Set a figure and an adjustment at or above it cannot be approved by someone without the elevated permission, and — separately, and not satisfiable by any permission grant — it cannot be approved by the person who raised it. That is a real segregation-of-duties control with a hard block behind it.
• Asset movements can require approval above a value you set, alongside a per-asset flag and a per-action policy.
• An approval run can carry a consensus threshold, which is how many approvers must agree. It counts people, not money.
• An approval step carries a field called a threshold, and this one is worth being precise about because the name invites the wrong reading: it is read only as a consensus vote count. It is not a monetary limit and nothing compares a value to it.

So the product does know how to refuse something above a figure — it does it for write-offs, which is the classic fraud route, and it does it properly. That control was simply never extended to purchasing.

What the system does watch, and why it is a different thing

The procurement insights are real and they are worth describing, because a reader could easily assume they cover this and they do not.

• Cost spikes. An item quoted above its usual price by more than a configurable multiplier — a fifth above, by default — is flagged. This catches paying too much.
• Vendor concentration risk. How much of your spend is going to how few suppliers. This catches dependence, and it is the insight closest in spirit to the one you would want, because a split purchase usually lands with the same supplier three times.
• Stale requests for quotation. Anything sitting without a quotation past a configurable number of days, seven by default. This catches process drift.
• On-time rate, lead times and supplier reliability. These catch a supplier who does not deliver.

Each of those is a genuine control and each answers a different question from the one this post is about. A split purchase can be perfectly priced, delivered on time, by a reliable supplier. Every insight above stays green.

Why this is genuinely hard, and not just unbuilt

It would be easy to present this as a straightforward missing feature. It is worth being more honest than that, because the difficulty shapes what a sensible fix looks like.

Splitting is defined by intent and by a ceiling that lives in legislation rather than in software. Three requests for chairs in one week might be one purchase broken up, or they might be three schools that each asked separately, or a first order that turned out to be short. A rule that flags all of them will flag mostly innocent activity, and a control that cries wolf gets switched off inside a month. A rule tuned to flag almost nothing catches almost nothing.

The workable version is not automatic blocking. It is surfacing: show a reviewer, at the moment of approval, what else the same department has bought in the same category recently, and let a person make the judgement. That is a modest piece of software and a real control, and it is the shape we would build if a public entity asked for it.

1. Store the request value

   Total the line items onto the request when it is submitted. Everything downstream depends on the request having a number on it.

2. Make the department a real reference

   Point the request at the department record the way requests for quotation and purchase orders already do. Free text cannot be grouped reliably and no detection survives that.

3. Hold your ceilings as configuration

   The figures come from your regulations and change over time. They belong in a settings screen, dated, not in code.

4. Aggregate over a rolling window

   Same department, same category, same supplier, some number of days. Compare the total to the ceiling, not each request to the ceiling.

5. Surface, do not block

   Put the related purchases in front of the approver with the running total. A person with the context decides. That is the control an auditor can actually see working.

What you can do today, honestly described

Nothing above is available as a feature, so here is what a diligent officer can actually do with what exists.

Purchase orders carry a proper department reference, a supplier, a date and line totals. So a spend review by department and supplier over a period is possible from purchase order data, and that is the level at which a split becomes visible — three orders, one supplier, one department, one fortnight, same category. It is a review you run yourself, by eye, on a report. It is not a flag and nothing raises it for you.

The vendor concentration figure is worth watching alongside it, not because it detects splitting but because a supplier receiving an unusual share of a department's orders is the same evidence viewed from a different angle.

The questions to ask, including of us

Procurement systems are usually evaluated on whether the workflow exists rather than on whether the controls bite. These questions get at the second, and they work on any vendor.

The third question is the one that separates a procurement workflow from a procurement control. Almost every product will pass the first two. Very few will show you anything at all on the third, and a vendor who says "the system would flag that" should be asked to demonstrate it rather than describe it.

A public entity is not usually asked whether its software has a procurement module. It is asked to evidence specific controls, one at a time, to someone whose job is to find the gap. The useful thing a vendor can do is tell you in advance which of those questions it answers and which it does not, so that the gap is a decision you made rather than one you discovered.