Supplier Lifecycle Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does qualification get scoped as one questionnaire so often?

Because that is the shape every packaged demo uses, and because nobody in the room knows the real number. Procurement describes onboarding, someone says we need a supplier questionnaire with document upload, and the estimate prices one form with conditional sections.

Then discovery starts and the count arrives. A packaging supplier and a special process supplier are not the same risk and should not answer the same questions. 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 a specific customer requirement flow down. A medical device supplier needs ISO 13485 and a quality agreement. A supplier connecting to your network for engineering data needs a cyber assessment. Everyone needs insurance at limits you specify, a signed code of conduct, tax documentation, and increasingly conflict minerals, REACH and RoHS declarations. Real manufacturers end up with twenty to forty distinct qualification paths by commodity and risk class.

The fix is to count the paths before anyone estimates, by interviewing each commodity manager, and to insist the checklist is data rather than configuration. A commodity plus a risk class should resolve to a required set of documents and steps, so adding a new path is a row rather than a project. This is exactly where licensed suite implementations quietly become eighteen month programmes, because expressing forty paths in someone else's configuration model is the work.

What goes wrong when the vendor master is deduplicated and migrated?

Manufacturers who grew by acquisition carry the same legal supplier under three number ranges, with three different names, one of which is still the pre acquisition trading name. Everyone knows this and everyone underestimates it, because deduplication looks like a matching problem and is actually a decision problem.

The decisions are not automatable. Are these two records the same legal entity or a parent and a subsidiary with separate quality systems? If they merge, which payment terms survive, and which purchasing organisation's blocks carry over? What happens to open purchase orders and to years of goods receipt history that a scorecard will later be computed from? Who signs off, given that vendor creation touches payment and payment touches audit?

Projects that treat this as a fuzzy match run overnight produce a merged master that finance does not trust, and then finance keeps the old records alive in parallel, which is worse than where you started.

The fix is a review queue with a named owner on the client side and a documented decision per merge. Run matching to produce candidates, never to act. Preserve the source identifiers on the merged record so historic receipts still reconcile. And schedule it as a parallel workstream from week one, because everything downstream, scorecards included, waits on it.

Why do ERP block and payment interfaces break after launch?

Because the vendor master is plant shaped and the integration was designed as though it were flat. In an SAP landscape a vendor exists at general data level, again at company code level with its own payment terms and blocks, and 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, by design, because your legal entities are genuinely separate.

• Blocks land at the wrong level. A block written at company code stops payment but not purchase order release, or the reverse, and buyers notice before anyone else does.
• Two directions of travel. If both systems can write supplier data, they drift, and drift means someone eventually pays an invoice to a bank account updated in one place and not the other.
• Second instance surprises. A build tested against one enterprise resource planning instance meets the second one and finds different number ranges, different field usage and a different master data governance process.

The fix is to take a position and hold it: the enterprise system stays master for the commercial record, the custom system masters qualification state, and there is exactly one automated direction of travel. Specify which company codes and purchasing organisations each block writes to, and test the block by actually attempting a purchase order release rather than by checking a status flag.

What happens when document expiry and bank change control are not covered?

Expiry gets handled by reminders, which is the same as not handling it. Certificates do not announce themselves. A certificate of insurance expires on the day a supplier's install crew is due on site. An ISO 9001 certificate lapses during a recertification gap and the supplier does not think to mention it. A quality agreement signed by a plant manager who left four years ago is technically still in force and nobody has read it.

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

The fix for expiry is to change the default: an expired certificate should block a purchase order rather than wait for an auditor to find it, with staged escalation to the supplier at ninety days, the buyer and commodity manager at thirty, and a named exception path that writes an audit record. The fix for bank details is that changes may only be initiated by the supplier in an authenticated portal session, never by email, with the vendor on payment hold until callback verification against a number held on file before the change request, recorded with who called and when.

Should you build custom or configure what you already own?

Some manufacturers should configure and we would tell them so. If you run a single site with a few hundred mostly commodity suppliers and one buyer, a disciplined shared workbook, a document folder with a naming convention and a calendar of expiry dates genuinely holds. Building would be an expensive way to formalise something that already works.

If your organisation has already committed to a procurement platform group wide, your qualification needs are close to standard, and you have a single clean enterprise resource planning instance with governed master data, configure what you bought. SAP Ariba Supplier Lifecycle and Performance and Coupa Supplier Management are real products with real capability. 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. Building alongside any of those duplicates something you are already paying for.

Build when two or more of these hold. You run more than one enterprise instance, or more than four plants with independent approval authority. Your qualification is engineering driven, with process audits and special process accreditation rather than questionnaires. You have had a supplier approved at one plant and blocked at another. You have had, or narrowly avoided, a bank detail fraud. Or your scorecards are argued about rather than acted on, because they are assembled in a procurement spreadsheet rather than computed from receipts and nonconformances.

How do hidden costs get into the quote?

Through counts nobody has and work that is not code.

• Qualification paths. Twenty to forty is normal and one is what gets quoted. This is the single biggest miss in the category.
• The second enterprise instance. Two instances is more than twice the work of one, because the differences are in field usage and governance rather than in the interface.
• Vendor master deduplication, which carries a human review component that cannot be removed.
• Multi language portals. An English only portal quietly fails in Mexico and Vietnam, and it fails by producing bad data rather than no data, which is harder to detect.
• Sanctions and beneficial ownership screening, if you are export controlled, along with the false positive review process behind it.
• Audit scheduling and corrective action tracking, which is a workflow module in its own right and is often assumed to come along with qualification.

Ask for the estimate broken down per qualification path, per enterprise instance and per integration, and ask who on your side owns deduplication.

What separates a build that works from one that fails here?

Whether the block is real. If a failed qualification produces a status field and an email, buyers will route around it within a month and the system becomes a filing cabinet. If it produces a block in the purchasing organisation where the purchase order is released, nobody has to remember anything, and behaviour changes on day one. That is why we tell clients to start with expiry driven blocking on their top two commodity groups by spend and risk rather than with a full portal.

The second marker is where scorecard numbers come from. Compute on time delivery from goods receipt against confirmed dates, quality from nonconformance records and defective parts per million, and responsiveness from corrective action closure times, then show the supplier the underlying receipts behind the number. Suppliers then dispute a specific line rather than the total, and review meetings move to corrective action. Scorecards assembled in a spreadsheet get argued about forever.

When vetting a developer, make them draw the relationship between their system and your vendor master before anything else. Someone who has done manufacturing work asks which enterprise system, how many instances, whether vendors are mastered at company code or purchasing organisation level, and who owns vendor creation today. Someone who says their system will be the single source of truth for suppliers has not met your master data governance team and will be told no in month four.

Then get ownership in writing before kickoff: repository, infrastructure accounts and the right to hire anyone else. 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.