An Expiry That Stops an Order
A register tells you a certificate expired last month. A control stops the order. Almost every organisation has the first and believes it has the second.
Nothing happens when a certificate expires. No email arrives, no screen turns red, nobody is notified. The supplier stays exactly where they were — on the approved list, orderable, and no longer qualified.
That sentence describes almost every organisation that maintains a supplier list, and it is not a discipline failure. It is a structural one: the dates live in one place and the purchasing happens in another, and nothing connects them. Eligibility decays silently because silence is the default behaviour of a spreadsheet.
The distinction worth holding onto is between a register and a control. A register records what is true. A control changes what can happen. Most organisations have built the first and believe they have the second — and the belief is only tested on the day somebody asks why a particular supplier was engaged.
The four failures, and they arrive in order
-
The qualification is all email
Documents arrive as attachments, get reviewed in an inbox, and the decision lives in somebody's sent items. It was a real decision, properly made — and it is now unfindable by anyone except the person who made it.
-
The dates go into a spreadsheet
Which is a genuine improvement and creates the central problem: the dates are now accurate, maintained, and completely disconnected from the system where orders are raised.
-
An expiry passes
The spreadsheet is right. Nobody read it that week. An order goes to a supplier whose qualification lapsed, and nothing anywhere objects.
-
Somebody asks
Not "is this supplier qualified" — they can see the list. "Were they qualified on the date you engaged them?" That is a question about the past, and answering it means reconstructing a state from documents rather than reading a record.
The question is never whether they are eligible today. It is whether they were eligible then — and "then" is a fact almost nobody stores.
What turns the register into a control
One property, and it is unglamorous: the expiry has to have a consequence at the point of use. Not a report, not a dashboard, not a weekly digest — a refusal, at the moment somebody tries to raise the order, where it can still change the outcome.
Everything else follows from that. If the consequence lands at the point of use, the dates have to live where purchasing happens, which means the qualification has to be a process in the system rather than a decision in an inbox, which means the evidence ends up attached to the decision it justified. The whole chain is pulled into shape by one requirement.
| A register | A control | |
|---|---|---|
| When you find out | When somebody reads it | When somebody acts |
| What it produces | A list | A refusal |
| Answers "are they eligible now?" | Yes | Yes |
| Answers "were they eligible then?" | Only by reconstruction | Yes, from the record |
| Survives the person who built it leaving | Rarely | Yes |
What is built, and the one thing that is emphatically not
Unusually for this corpus, the answer here is that the thing the market needs was already built before the page describing the market existed. So the honest section is short on roadmap and long on one boundary.
Prequalification from application to approval
A supplier applies, submits documents, is reviewed, and is approved or refused — with stages and a record, rather than attachments assessed in an inbox.
A qualification date held per supplier
Eligibility as a dated fact on the supplier record. This is what makes "were they qualified then" answerable rather than reconstructable.
An expiry that stops an order being raised
The consequence at the point of use. This is the line between a register and a control, and it is the only item on this list that changes anybody's behaviour.
Documents attached to the decision they justified
So showing why a supplier was eligible at the time is a retrieval rather than a search through email.
Spend by supplier, category and project
Which closes the loop the second failure above opened: the dates and the payments finally live in the same place.
Any form of screening
Not ours, and this is the most important line in the post. We hold what was proved about a counterparty, by whom, and when it expires. We check no list, consult no register, and are not a sanctions or ownership screening service. Treating a prequalification field as though a check had been performed is the single most dangerous misreading available here — the failure mode of a half-built screening feature is a user who stops looking. Buy screening from somebody whose business it is and use this for the evidence trail underneath it.
The test, and it takes one supplier
- Pick a supplier you have paid in the last quarter. What is their qualification status, and where did you look?
- Now ask what it was on the date of the order. Different question, different answer, usually a different place to look.
- If a certificate lapsed tomorrow, what in your process would stop the next order — a person, a report, or the system?
- Where does the evidence of the original approval live? If the answer is an inbox, it lives with a person rather than with the organisation.
- Ask any vendor to show you an order being refused because of an expiry. Not a report of expiries — a refusal. Watch whether they can.
That last one is the whole evaluation in a single request, and it separates products quickly. A great many systems will show you an expiry report. Considerably fewer will show you the order that did not happen.
What is built here, what is not, and what we would decline is on the Guyana market page. The asset-side version of proving a state at a point in time is proving what it was like before.
