Search for a supplier master data management platform and you get a shortlist: GEP SMART, Ivalua, Informatica, Profisee, Reltio, Semarchy, Kodiak Hub, Stibo Systems. Every one of those pages describes centralising vendor data into a single trusted record, and every list presents them as alternatives to each other. They are not. Two of those products cannot do what a third does, and a third solves a problem the first two never touch.
I have watched this go wrong in the same direction twice now. A team with a duplicate-riddled vendor master buys a sourcing suite, spends nine months configuring qualification questionnaires, and arrives at go-live with the original duplicates intact and a new system to keep in sync. The software worked. It was answering a different question.
Three categories, one phrase
Sort the shortlist by what the product is built around and it falls apart cleanly into three groups.
Procurement suites
GEP SMART, Ivalua, Coupa, Kodiak Hub
Built around The onboarding process
You want supplier qualification, risk scoring, sanctions screening and RFQ in one place. The vendor record is what the workflow produces on the way through.
The record is a byproduct. If your suppliers are already onboarded and the problem is that four systems disagree about them, this buys you a fifth opinion.
Enterprise MDM platforms
Informatica, Reltio, Stibo Systems, Profisee, Semarchy
Built around The match-merge engine
Hundreds of thousands of vendor records across a dozen source systems with no shared identifier. Probabilistic matching and survivorship rules are doing real work at that size.
Six to twelve months and an implementation partner, whatever the row count. The machinery does not scale down, and a three thousand row vendor master pays for capability it will never exercise.
Focused master data tools
Primentra, SQL Spreads, and a long tail of niche tools
Built around The governed record
A model you define, validation at entry, an approval step before a change lands, an audit trail, and a way to publish the result. Days to deploy rather than quarters.
No probabilistic matching, no supplier portal, no sourcing workflow. If you genuinely need to reconcile a million unkeyed records, this is the wrong shelf.
The categories overlap at the edges. Stibo and Informatica both ship supplier portals, and several procurement suites have added matching. But each product is still shaped by the thing it was built around, and that shape decides what the implementation costs you.
The question that picks the shelf
Is your problem the process, or the record?
The process problem sounds like this: onboarding a new supplier takes three weeks, the qualification questionnaire lives in email, nobody can prove the sanctions check was run, and procurement wants a portal so vendors maintain their own details. That is a sourcing workflow, and a procurement suite is the right purchase for it.
The record problem sounds different: ACME Corp appears four times, the ERP and the procurement system disagree about the payment terms, and nobody can tell you how many active suppliers the company has. Those vendors are already onboarded. No workflow in front of the creation screen touches records that were created in 2014.
Once you are on the record side, one more question splits it: how big, and how keyed? Probabilistic matching pays for itself when you are reconciling hundreds of thousands of rows across systems with no shared identifier. Vendor masters are rarely that. They run to a few thousand rows and they carry a tax registration number, which is a deterministic key. Blocking a duplicate at creation with a unique constraint is cheaper and more reliable than scoring it afterwards and asking a steward to adjudicate.
Six things the category label will not tell you
Feature matrices all say yes to the same rows. These six are supplier-specific, and they are where products actually differ. Take them into the demo and make someone click.
One row per supplier, or one per address?
Ask the demo to add a second remit-to address to an existing vendor. If the answer is a new supplier row, the tool has no site entity, and every duplicate you clean up will grow back the next time procurement onboards a second warehouse.
Is a duplicate blocked at creation, or found afterwards?
These are different products. Blocking means a unique constraint on tax number scoped to country, refusing the save. Finding means a match score, a review queue, and a steward deciding next Tuesday. Most platforms sell the second while lacking the first.
Who approves a bank account change?
Changing payment details is the most exploited path in the vendor master. A log tells you who to blame after the payment run. Ask instead whether the tool can hold the new IBAN as a pending change until someone signs it off.
How does one company hold four VAT numbers?
A supplier trading in four EU countries has four tax registrations. A single tax field forces a steward to pick a favourite, and the other three end up in a note field where no validation will ever see them.
Where does the ERP vendor number live?
You are not replacing the vendor master in SAP. You are governing the layer above it, which means the platform has to hold the mapping from its own identifier to the vendor numbers already in every downstream system.
How does the data get back out?
A view, a REST endpoint, a file drop, a message on a bus. Ask which, and ask whether the consuming system joins on an internal row number or on the code it already recognises. Answering this late is expensive.
The first one catches the most products. A vendor is one legal entity with several sites, several bank accounts, and a tax registration per country, so the model underneath needs child tables rather than a wide row. Tools that flatten it end up encoding the difference in the name, which is how you get ACME Corp, ACME Corp ROTTERDAM, and ACME Corp NEW BANK 2024 sitting in the same list. The same applies to what you buy from them: supplier item data belongs to neither master and needs a table keyed on both.
Number three deserves more weight than it gets. The requester and the approver being the same person is the entire vulnerability, so ask whether the tool can force them to be different people, and whether it can do that on the bank account field alone rather than on the whole record. Nobody wants a second signature on a phone number. That distinction is what stops an invoice redirection attempt from reaching the payment run.
Number five is the one teams discover late. You are not ripping the vendor master out of SAP. You are governing the layer above it, which means the platform has to hold the mapping between its identifier and the vendor numbers each downstream system already uses. A platform without that mapping produces a clean list nobody can join to.
The timeline comes with the category
Enterprise MDM platforms configured for the supplier domain land at six to twelve months from kickoff to a working system, and most of those vendors recommend a certified implementation partner rather than a DIY configuration. That is not a criticism. A platform that has to serve customer, product and supplier data across a large estate carries a configuration model deep enough to need specialists.
But you inherit that six months by picking the shelf, not by running the project badly. A team with three thousand suppliers cannot manage its way to a six-week rollout of a platform designed for three hundred thousand. If the estimate looks wrong for your size, the fix is usually a different shelf rather than a tighter plan. And if none of the three shelves fits, that is the build versus buy question, which is worth answering honestly before a fourth demo.
Where we fit, and where we do not
Primentra sits in the third category. You define the supplier model, including the child entities for sites, bank accounts and tax registrations. Validation runs at entry, an approval step sits in front of every change, each edit lands in the audit trail, and downstream systems read the result through integration views or the REST API. It runs on your own SQL Server and deploys in about a day.
What it does not have: a probabilistic matching engine, a supplier self-service portal, sanctions screening, or a sourcing workflow. If your vendor master is a million unkeyed rows spread across a dozen acquisitions, buy from the second category and budget for the partner. If procurement wants suppliers maintaining their own certificates through a portal, buy from the first. Those are real requirements and we do not cover them. Our 2026 alternatives comparison lists the wider field with the pricing attached.
Common questions
What is a supplier master data management platform?
Software that holds the authoritative version of each vendor record and controls how it changes. The phrase covers three categories: procurement suites, multi-domain enterprise MDM platforms, and focused master data tools. They differ more than their marketing pages suggest.
Procurement suite or MDM platform?
Decide whether the problem is the process or the record. Three weeks to onboard a supplier is a process problem, and a sourcing suite is built for it. Four systems disagreeing about a supplier that already exists is a record problem, and no onboarding workflow will fix it.
Do I need probabilistic matching?
Usually not. It earns its cost merging hundreds of thousands of records that share no identifier, which is more often the customer domain. Most vendor masters run to a few thousand rows and carry a tax number, which is a deterministic key strong enough to block duplicates at creation.
What should I ask on the demo?
Add a second remit-to address to an existing supplier. Change a bank account. Store four EU VAT numbers on one company. Show the mapping to the vendor numbers already in the ERP. Four questions, and they separate the products faster than any feature matrix.
How long does implementation take?
Enterprise MDM platforms run six to twelve months and usually a certified partner. Procurement suites land in a similar range because supplier data rides along with a broader rollout. Focused tools deploy in days. The timeline belongs to the category, not to the project.
Try the six questions against Primentra
Sites and bank accounts as child entities, a unique constraint that refuses the duplicate at save, approval in front of a payment-detail change, and a cross-reference to the vendor numbers your ERP already uses. On your SQL Server, €7,500 per year flat with unlimited users. The 60-day trial includes everything, so you can run the list yourself rather than take our word for it.