Supplier Lifecycle Management Software: Why the Same Vendor Is Approved at Plant 4 and Blocked at Plant 2

Why supplier qualification breaks the moment you have a second plant

A buyer at plant 4 needs a machined housing next week. He finds a supplier in the vendor master, the record looks fine on his screen, and he releases the purchase order. What he cannot see is that plant 2 ran a process audit at that same supplier eleven months ago, found an uncontrolled heat treat process, and put them on containment. Plant 2 recorded this in a quality department spreadsheet and blocked the vendor at their own company code. Plant 4 has a different company code, a different number range, and no visibility of any of it. The parts arrive, they fail at incoming inspection, and the containment conversation restarts from zero with a supplier who now believes your company does not talk to itself.

This is the defining failure of supplier management at multi plant manufacturers, and it is not a discipline problem. Your buyers are not careless. The information they would need to be careful with does not exist in one place. Qualification status lives in a quality spreadsheet. Insurance certificates live in an email folder belonging to one person in legal. Banking details live in the ERP with a change history nobody reviews. Audit reports live on a shared drive named by whoever saved them. Approved supplier lists exist per plant, per commodity, and per programme, and they disagree.

Problem 1: the ERP vendor master is the real system of record and it is plant shaped

This is the technical reality every packaged supplier suite runs into. In an SAP landscape a vendor exists at general data level, then again at company code level with its own payment terms and blocks, then again at purchasing organisation level with its own terms and its own block. A supplier can be perfectly usable in one purchasing organisation and blocked in another, and that is by design, because your legal entities are genuinely separate. Manufacturers who grew by acquisition often carry duplicate vendor records for the same legal supplier under three number ranges, with three different names, one of which still has the pre acquisition trading name.

Any supplier lifecycle system has to decide what it is: a system that owns supplier data and pushes it into ERP, or a system that reads ERP and adds a qualification layer on top. Packaged suites want to be the first. Your finance and master data governance team will not let them, because vendor creation touches payment, and payment touches audit. So the tool ends up as a parallel record that drifts, and drift in supplier data means somebody eventually pays an invoice to a bank account that was updated in one system and not the other.

What a custom build does is take a position and hold it consistently: ERP remains the master for the commercial record, the custom system masters qualification state, and there is exactly one automated direction of travel between them. A supplier who fails qualification triggers a block in the correct company codes and purchasing organisations through the ERP interface, not through a note in a portal. When the block is real in the system that releases purchase orders, buyers stop needing to remember anything.

Problem 2: qualification is not one form, it is a commodity specific checklist

A packaging supplier and a special process supplier are not the same risk and should not answer the same questionnaire. A castings supplier needs a foundry process audit. A heat treat or non destructive testing supplier needs Nadcap accreditation if you are in aerospace. An automotive supplier needs IATF 16949 and probably a specific customer requirement flow down. A medical device supplier needs ISO 13485 and a quality agreement. A supplier who will connect to your network for engineering data needs a cyber assessment. Everyone needs insurance with limits you specify, a signed code of conduct, tax documentation, and increasingly a conflict minerals declaration and REACH and RoHS statements.

Packaged tools handle this with configurable questionnaires, which sounds fine until you count them. Real manufacturers end up with twenty to forty distinct qualification paths by commodity and risk class, and the configuration effort to express those in a licensed suite is where implementations quietly turn into eighteen month programmes. A custom build treats the checklist as data, not configuration: a commodity plus a risk class resolves to a set of required documents and steps, and adding a new one is a row, not a project.

Problem 3: documents expire silently and always at the worst moment

Every certificate you hold has an expiry date and none of them announce themselves. A certificate of insurance expires on the day a supplier's install crew is due on your site. An ISO 9001 certificate lapses during a recertification gap and the supplier does not think to tell you. A quality agreement signed by a plant manager who left is technically still in force and nobody has read it in four years.

What a custom build must include is expiry as a first class property of every stored document, with escalation that means something. Ninety days out, the supplier gets an automated request through the portal. Thirty days out, the responsible buyer and the commodity manager get it. On expiry, the vendor is blocked for new purchase orders in the affected purchasing organisations automatically, with a named exception path that requires a specific person's approval and writes an audit record. The reason this works where reminders do not is that it changes the default. Today an expired certificate does nothing until an auditor finds it. It should stop a purchase order.

Problem 4: bank detail changes are your largest single fraud exposure

A well written email arrives from a supplier's accounts department with a new bank account, referencing a real invoice number and using a lookalike domain. Somebody in accounts payable updates the vendor master. The next payment run sends real money to a criminal. This is the most common serious loss at manufacturers we work with, and it is entirely a process and system problem.

The control is straightforward and it belongs in the supplier system, not in a training slide. Bank detail changes may only be initiated by the supplier through an authenticated portal session, never by email. Any change puts the vendor on payment hold until callback verification is completed against a phone number already on file before the change request, not one supplied in the request. The verification is recorded with who called, which number, and when. Then and only then does the change flow to ERP. This one workflow has, on its own, justified the build in more than one client conversation.

Where Ariba, Coupa, Jaggaer, Ivalua and GEP actually stop

These are real enterprise products with real capability, and for a services heavy organisation with a clean single ERP instance and fairly standard qualification needs, SAP Ariba Supplier Lifecycle and Performance or Coupa Supplier Management is a sensible purchase. Jaggaer and Ivalua both have genuine depth in supplier management and Ivalua in particular is unusually configurable. GEP SMART is strong on the sourcing side. We would not tell a client they are bad products.

The pattern we see is different. First, they assume they own the supplier record, and in a manufacturer with multiple ERP instances, plant specific number ranges and post acquisition duplicates, that assumption forces a master data project you did not budget as part of the software. Second, their qualification models are questionnaire shaped, which fits indirect procurement but strains under twenty to forty commodity specific engineering qualification paths with audits, process approvals and special process accreditations attached. Third, the cost of change is high enough that adding a new commodity checklist becomes a ticket to a system integrator rather than an afternoon. Fourth, connecting the scorecard to your actual goods receipt and nonconformance data usually turns out to be a custom integration anyway, at which point you are paying licence fees for a shell around your own data.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering supplier onboarding with commodity specific qualification paths, document management with expiry driven blocking, and the ERP block interface runs $70,000 to $150,000 and ships in 12 to 16 weeks. A full platform adding a supplier self service portal, audit planning and findings with corrective action tracking, scorecards built from receipt and quality data, risk and sanctions screening, and bank detail change control runs $180,000 to $450,000 phased over 6 to 14 months.

What drives cost up specifically here: the number of ERP instances, because two instances is more than twice the work of one. Vendor master deduplication, which is a data project with a real human review component and cannot be fully automated. Multi language and multi region supplier portals, because your suppliers in Mexico and Vietnam will not use an English only portal properly. Sanctions and beneficial ownership screening if you are export controlled. And the count of distinct qualification paths, which is the number nobody knows until you ask each commodity manager.

What keeps cost down: starting with your top two commodity groups by spend and risk, one ERP instance, and expiry driven blocking, because blocking is the feature that changes behaviour on day one.

Build versus buy, and when buying is the right call

Buy if you are a single site manufacturer with a few hundred active suppliers and mostly commodity purchases, where a shared workbook and a calendar genuinely works. Buy a packaged suite if your organisation is already committed to one procurement platform group wide, your qualification requirements are close to standard, and you have a single clean ERP instance with governed master data. In that situation building is duplicating something you have already paid for.

Build when two or more of these are true. You run more than one ERP instance or more than four plants with independent approval authority. Your qualification paths are engineering driven with audits and special process accreditation, not questionnaires. You have had a supplier approved in one plant and blocked in another. You have had, or narrowly avoided, a bank detail fraud. Your scorecards are argued about rather than acted on.

The tipping point is plant autonomy. One plant is a filing problem. Four plants with their own quality managers and their own purchasing organisations is a coordination problem, and coordination problems are what custom systems are actually for.

How to choose a developer for supplier lifecycle software

Ask them to draw the relationship between their system and your vendor master before anything else. A developer who has done manufacturing work will ask which ERP, how many instances, whether vendors are mastered at company code or purchasing organisation level, and who owns vendor creation today. A developer who says the system will be the single source of truth for suppliers has not spoken to your master data governance team and is about to be told no in month four.

Ask exactly how a failed qualification stops a purchase order. If the answer is a status field and an email, buyers will route around it within a month. The block has to be real and it has to live where the purchase order is released.

Ask how they will handle duplicate vendor records for the same legal entity, because you have them and pretending otherwise sinks the project. The right answer involves a review queue with a human deciding, not a fuzzy match run overnight.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. A system that gates your purchase orders is not something to be locked into a single supplier over.