Why an approved supplier list did not stop a bad order, what an approval must record to be checked at the order line, and three tests to run on any system.
The finding usually reads like this. A buyer raised a purchase order for a material from a supplier on the approved list. The approval on file did not cover that material, or that site, or the certificate behind it had expired months earlier while the status column still read Approved. An auditor found it, or goods-in found it on the day the material arrived, and the purchasing manager has now been asked to find supplier management software so it does not happen again.
The question purchasing wants answered is narrower than the software category suggests: how do we make sure a buyer can only order what we have actually approved, without technical having to sign off every order? Most product pages answer a different question. They describe where certificates are stored, when reminders go out and how suppliers are scored. None of that explains what stops the next bad order, because the approval itself is recorded in a form that no order can be checked against.
This is written for the purchasing manager at a mid-sized food manufacturer working under a GFSI-benchmarked standard such as BRCGS Food Safety, and for the technical or quality manager who owns approval. The two jobs meet on every purchase order, and the record that is supposed to connect them is usually a supplier list with a status column.
Two records that share one field
A supplier approval is a documented decision that the business is willing to buy something from a supplier. It rests on evidence: a certificate, an audit, a questionnaire and an agreed specification. Businesses certified under GFSI-benchmarked schemes such as BRCGS typically keep this record as part of a documented supplier approval and monitoring programme, which is why the list exists and why the auditor reads it.
A purchase order line is where the business commits. It names a material, a quantity, a supplier, a delivery date and a price. It is the smallest unit any check can apply to, because it is the smallest unit the buyer creates.
Put the two side by side. The approval, as most lists hold it, is a row about a supplier with a status. The order line is about a supplier, a material and a date. They share one field, the supplier, so the only question the check can ask is “is this supplier approved?” Everything the approval was based on, which material, from which site, against which specification, valid until when, was known when technical made the decision and was discarded when it was written down as a status. A check can only be as specific as the record it reads, and if the record says Approved, the check can say yes or no about the supplier and nothing about the purchase.
The cases a status cannot see
Three cases produce most findings, and they are exactly the cases the status column cannot tell apart from a routine order.
The first is a new material from an approved supplier. Certificates and specifications describe particular products. A grower approved for whole carrots has not been approved for diced squash, because diced squash has no agreed specification and may be prepared in a different way, in a different place. The status says Approved because the supplier is approved for something.
The second is a second site. Certificates and audits cover a site, not a company. A supplier who subcontracts part of the work, or ships from a second packhouse, is a different source for approval purposes, with different allergens handled on the premises and a different certificate, or none. A row per supplier has nowhere to record this.
The third is a lapsed condition. Approval is time-bounded because its evidence is. A certificate expires, an audit falls due, an allergen declaration ages. Unless someone rereads the expiry column and updates the status, the row keeps saying Approved for as long as the spreadsheet exists.
In each case a person has to compensate for what the record cannot say. The buyer may remember that this supplier was only ever approved for carrots. Technical may review every purchase order before it is sent, which slows every launch and turns approval into a sign-off on ordering. Or nobody catches it until goods-in, when the material is on the dock, its shelf life is running and the launch is scheduled, and the goods-in technician decides with less time and fewer options than anyone else in the chain. The audit finds whatever those people missed, however careful they were, because the record was never capable of catching it.
What a supplier approval must name to be checkable
For an approval to be checked against an order line, it has to be recorded at the level the line is written at. That means the approval is its own record, and it names five things.
The supplier, as before. The material, as a specific item, so that whole carrots and diced squash are two approvals. The site the material comes from, because that is what the certificate covers. The specification version, meaning the agreed description of the material: cube size, shelf life on receipt, allergen status, packaging. An approval without a specification version cannot say what it approved, and goods-in has nothing to check a delivery against. Last, the dated conditions the approval depends on: a certificate expiry, an audit due date, a declaration date. The approval is valid while those conditions hold.
Two further properties come with the record. A risk tier, so that a fresh produce line gets a full approval and outer cases get a lighter one. And a state: proposed, approved, conditional, lapsed, suspended or withdrawn. These are states of the approval, not of the supplier. One supplier can hold an approved record for onions and a lapsed one for stock concentrate at the same time, and both are true.
With the record at that level, one rule connects it to ordering. A purchase order line may only be raised against an approval whose supplier, material and site match the line, and whose conditions are valid on the delivery date, or under a live concession. A concession is a documented, time-limited decision by technical to allow purchase while a condition is not met, with extra checks attached to each delivery. The rule can be applied when the line is written, which is the earliest point anyone commits and the point with the most time to decide something else.
Worked example: Brookmill Soups
The following scenario is illustrative. The company, suppliers, dates, quantities and thresholds are invented for teaching, and nothing in it is customer evidence.
Brookmill Soups makes chilled soups on three lines and buys from about 55 suppliers. Its approved supplier list is a spreadsheet. One row reads: Fenland Fresh, vegetable grower and packer, Status: Approved, approved 12 March 2024 by the technical manager, BRCGS certificate valid to 30 November 2026. The approval was based on whole carrots and whole onions from Fenland’s own packhouse, Site A, each with an agreed specification: carrots CAR-v3, onions ONI-v2. None of that detail is in the row.
A new recipe launches the week of 28 September 2026. On 16 September the buyer needs 400 kg of diced butternut squash delivered on Thursday 24 September. Fenland Fresh can supply it. The dicing happens at a partner prep unit, Site B, which also handles celery, a declarable allergen in the UK. No specification exists for diced squash from Fenland: no cube size, no shelf life on receipt, no allergen cross-contact statement.
The squash order under a status
The check is “is Fenland Fresh approved?” The answer is yes and the PO is raised. On 24 September, 400 kg of diced squash arrives and goods-in has no specification to check it against. QA either accepts it, and the material goes into production without an approval covering it, which is what the auditor later finds, or holds it, and a chilled material with days of shelf life sits in the chill store while the launch stalls. Either way the person deciding is the goods-in technician, on the day.
The squash order under a specific approval
Fenland Fresh holds two approval records. A1 covers whole carrots from Site A against specification CAR-v3, risk tier medium, valid while the Site A certificate is valid, to 30 November 2026, state Approved. A2 covers whole onions from Site A against ONI-v2 under the same conditions, also Approved.
The buyer writes a line for 400 kg of diced butternut squash from Fenland Fresh for 24 September. It matches nothing. The block says why: no approval for diced squash from Fenland, Site B not covered by any certificate on file, no specification. It also shows what does match. Midland Prepared Veg holds approval A7 for diced butternut squash from Site M against specification SQD-v1, certificate valid to 15 May 2027, Approved. The buyer orders the 400 kg from Midland for 24 September.
Separately, a request goes to the technical manager to begin approving Fenland for diced squash at Site B. That needs Site B’s certificate or an audit, a specification and an allergen declaration, and it will take weeks. The decision was made on 16 September with eight days in hand rather than on the dock on 24 September, and the launch has its squash.
A dated condition
Harbour Stock supplies fish stock concentrate to Brookmill under approval A12. Its certificate expired on 31 August 2026. The renewal audit is booked but the new certificate has not been issued.
Brookmill’s rule is a 60-day warning, so A12 entered the technical manager’s review queue on 2 July 2026. From 1 September its state became Lapsed. Technical recorded a concession to 31 October 2026 on condition that each delivery’s certificate of analysis is checked at goods-in. A line for delivery on 24 September is allowed under the concession, and a certificate-of-analysis check task is created for that delivery.
In the spreadsheet version, the status still reads Approved, the expiry column reads 31 August 2026, and nobody has looked at it since March.
Performance on the approval
Between July and September, Fenland delivered carrots 12 times with 2 rejections at goods-in for soft and undersize product, and onions 10 times with none. Brookmill’s review trigger is a rejection rate above 10 percent in a quarter.
Measured at | Deliveries | Rejections | Rate | Above 10 percent |
|---|---|---|---|---|
Fenland Fresh, supplier level | 22 | 2 | 9.1% | No |
A1, carrots, Site A | 12 | 2 | 16.7% | Yes |
A2, onions, Site A | 10 | 0 | 0% | No |
The supplier-level figure never fires and the carrots problem stays hidden. The approval-level figure puts A1 into review while A2 stays clean. The rejections could be recorded against A1 because goods-in checked each delivery against the specification version on that approval, CAR-v3, and a rejection is a statement that the delivery did not meet it.
The 60-day warning and the 10 percent threshold are business rules Brookmill set for itself. Yours will differ.
Lifecycle and performance come with the record
Supplier lifecycle management, vendor performance management and supplier approval are usually sold as separate modules. Once approval is a specific record, they are properties of it.
Lifecycle stages are what happens to an approval over time. Fenland’s diced squash approval starts as proposed while technical gathers Site B’s evidence. It becomes approved when the evidence is complete, conditional if technical grants it with a check attached, lapsed when a condition passes its date, suspended if a serious complaint arrives, withdrawn if the business stops buying. Each transition is a decision about one supplier, material and site combination, and Fenland’s carrot approval carries on unchanged while its squash approval moves.
Performance follows the same logic. A rejection at goods-in is a judgement that a delivery did not meet a specification version, and that specification version belongs to one approval. Writing the rejection on that approval keeps the signal that the supplier total in the table loses. The procurement software article explains what happens after the order, through receipt, acceptance and invoice, and at acceptance there is a comparison against what the approval said would arrive. For materials whose specification is dominated by shelf life, the food batch expiry article follows the shelf-life condition agreed at approval through production and dispatch.
Where this can run
A spreadsheet with discipline works when there are few enough combinations for one person to hold in their head. If you have under about 20 suppliers and the same person both approves and orders, a well-kept list with a row per supplier, material and site, plus a review calendar driven by the condition dates, does the job. The person is the check.
Your current purchasing or ERP system may already be able to hold approval per supplier and material with a site and dated conditions, and to block or warn at the order line based on the delivery date. If it can, configure it first. Test it before you trust it: raise a test order for a new material from an approved supplier, and another for a delivery date after a supplier’s certificate has expired, and see whether either line is stopped and what the system says about why. If your only pain is storing certificates and being reminded of expiry dates, a document tool or a supplier portal is the right size and you can stop reading here.
The third option is to implement the rule in an operations platform. Keel is an operations platform for running the work your business has already decided how to do. For Brookmill’s buyer, that means the ordering screen offers the supplier and material combinations technical has approved for that delivery date, and when a line matches nothing it shows what is missing and who can resolve it, as the diced squash line did. The technical manager works from a queue of approvals coming up for review or awaiting a decision, which is where A12 appeared on 2 July. Goods-in checks each delivery against the specification version on the approval it was bought under, and a rejection at the dock lands on that approval. When Brookmill decides to change its warning period from 60 days to 90, or to add a risk tier, the rule and the screens change together. These are illustrative implementations of what a Keel implementation would build for this business. Keel does not sell a ready-made supplier management module.
The mechanism underneath is short to describe. The approval becomes its own record linking supplier, material, site, specification version, risk tier and dated conditions, and it carries its own states from proposed through to withdrawn. The rule that a line may only be raised against a matching approval valid on the delivery date, or under a live concession, is business logic written in code, so it can say what this business means by valid, including its risk tiers and concession terms, without being limited to a fixed set of configuration choices. Who may approve, grant a concession or override is set in the implementation using the permissions Keel supplies. Reporting reads the same records, so rejection rate per approval is a view of the data and no separate spreadsheet is needed. Code still has to be implemented, tested and maintained.
Keel supplies the data model, the facility to express rules in code, workflow state, permissions, operator screens and reporting. The implementation builds the approval model with your risk tiers, your definition of valid, the concession workflow and the checks it attaches to deliveries, the buyer and technical screens, the goods-in check, and the connection to the finance system that owns purchase orders and invoices. What Keel supplies sets out the boundary between what Keel supplies and what you build in more depth.
Keel fits when your definition of approval has conditions your current system cannot express at the order line, when concessions need checks that follow the delivery, or when approval has to connect to goods-in, production and traceability work you also run in Keel. The inventory management article covers the decision about what to buy and hold that comes before a purchase order. Approval sits between that decision and the order.
A checkable approval costs more to maintain than a status. Every new supplier, material and site combination needs a decision before it can be bought. If the business does not tier by risk, so that outer cases get a lighter approval than fresh produce, and does not give technical a concession route, the rule will block legitimate buying and buyers will find a way round it. Purchasing and technical need to settle both before any system is chosen.
What to test in any software you evaluate
Three tests follow from the explanation, and they work on a spreadsheet, a configured ERP or a platform implementation.
Raise a line for a material your supplier has never supplied you, from a supplier whose status is approved. The system should stop the line or warn on it, and it should say what is missing: no approval for that material, no specification, no site coverage. A system that lets the line through holds approval at the supplier level, whatever its product page says.
Raise a line for a delivery date after a supplier’s certificate expires. Set the delivery date deliberately past the expiry. The system should compare the two dates and either stop the line or route it through a concession that attaches a check to the delivery. A reminder email sent on the expiry date does not pass this test, because it knows nothing about the order.
Record a goods-in rejection and see where it lands. If it lands on the supplier, your rejection rate will hide the carrots problem. If it lands on the approval for that material, from that site, against that specification, the review trigger can see it.
Bring your approved supplier list and your last audit finding. We will talk through how your approval rules would be represented and what an implementation would need to build. Arrange that conversation when you are ready.
