Why Supplier Data Is Procurement's Biggest Unsolved Problem?

Ask any procurement leader what their biggest operational problem is, and the answer is rarely “we need a better sourcing tool.” It is almost always a variant of the same underlying issue: we cannot trust our data. Supplier records are scattered across three ERPs, two spreadsheets, and a CRM that nobody updates. The same supplier appears under four different names across systems. The spend data that should tell us which supplier is providing the most value instead requires three hours of reconciliation before it means anything. At Inity Agency, we have designed procurement SaaS products, including platforms for companies like TealBook ($72M raised) and Cirtuo (acquired by Coupa), where supplier data quality and the UX decisions around it are the product. This post explains why supplier data is procurement’s most consistently underestimated problem, and what it means for the design of procurement software.

What Supplier Data Actually Looks Like in Practice

To understand why supplier data is such a persistent problem, it helps to understand what a typical mid-to-large organisation’s supplier data environment actually looks like.

A procurement team at a company with 5,000 employees and a moderate supply chain might interact with 500–2,000 active suppliers. Those suppliers exist, in some form, across:

• The ERP – financial records of purchases, invoices, and payments. Often, the most complete transactional record, but supplier names and categories are entered by accounts payable staff at invoice processing time. No standardisation. “Acme Corp,” “Acme Corporation,” “Acme Corp Ltd,” and “ACME” are four records for one supplier.
• The sourcing platform – RFP and RFQ records showing which suppliers were invited to source events, what they submitted, and what contracts resulted. Separate system, separate supplier identifiers.
• The contract management tool – executed agreements. May have a different supplier name than the ERP record it maps to, because the legal entity name differs from the trading name.
• Spreadsheets – the universal backstop. Supplier contact lists, performance scorecards, compliance tracking, and preferred supplier lists. Updated by individuals, not governed, not integrated with anything.
• The CRM or supplier portal, in organisations that have one. Supplier self-reported data may be months out of date.

This is the supplier data landscape that procurement teams actually work in. No single system has the complete picture. Every system has an incomplete, partially inconsistent, partially outdated version of the same supplier record.

Why This Matters More Than It Sounds

The downstream consequences of fragmented supplier data are significant and consistently underestimated.

Spend analysis is unreliable. The fundamental procurement question – “what do we spend with whom, and are we getting value?” – cannot be answered reliably when the same supplier appears under multiple names and identifiers across different systems. Spend analysis that consolidates data across systems requires manual deduplication, which is time-consuming, error-prone, and produces outputs that procurement teams do not fully trust. Teams that do not trust the data do not use it to make decisions.

Supplier risk is invisible. Understanding whether a supplier is financially stable, geographically concentrated, or facing compliance issues requires a single, unified supplier record that can be enriched with external risk data. When the supplier record is fragmented, risk intelligence cannot be reliably applied to it. A supplier in financial distress may not be flagged because their record in the risk monitoring system does not match its record in the ERP.

Contract compliance is unverifiable. Preferred supplier agreements and volume commitments are meaningless if procurement cannot verify that spend is flowing to the contracted supplier rather than to an uncontracted alternative. When data from spend and contract data live in different systems with different supplier identifiers, compliance checking is manual and incomplete.

AI produces unreliable output. Procurement AI tools: spend analytics, anomaly detection, category intelligence, supplier risk scoring – are only as strong as the data they operate on. Feeding inconsistent, fragmented supplier data into an AI model produces insights that procurement teams cannot act on, because the underlying data does not support confidence in the output. As one procurement data expert put it: “Feeding inaccurate, incomplete, or fragmented data to an AI is like washing a window with a bucket of mud.”

Why the Problem Persists Despite Available Technology

Supplier data management is not a new problem, and it is not unsolvable. Master data management (MDM) systems, supplier portals, and data enrichment platforms exist and have existed for years. So why does fragmented supplier data remain the number one operational complaint in enterprise procurement?

Three reasons.

1. The governance problem. Supplier data quality is not primarily a technology problem – it is a process problem. Data degrades because there is no governed process for how supplier records are created, updated, and maintained. Anyone with ERP access can create a new supplier record. Nobody is responsible for deduplicating them. Nobody checks whether the contact details are current. A technology solution that does not change the underlying process produces a clean dataset that degrades immediately.

2. The integration problem. Supplier data lives in multiple systems that were not built to interoperate. Connecting an ERP to a sourcing platform to a contract management tool to a risk intelligence feed to a supplier portal requires custom integration work that is expensive, brittle, and typically scoped as “phase 2” — meaning it either never happens or happens years after the systems were deployed.

3. The UX problem. Most supplier master data is entered by humans in systems with poor data entry UX – no validation, no duplicate detection, no standardisation guidance. The data quality problem is partly a downstream consequence of interfaces that make bad data entry easy and good data entry hard. A form that allows “Acme Corp,” “Acme Corporation,” and “ACME” without flagging potential duplicates will produce all three records. The UX of the data entry interface is the origin point of the data quality problem.

What the UX of Supplier Data Interfaces Needs to Do

The design of supplier data interfaces in procurement software determines whether the data that enters the system is clean or dirty. Most procurement SaaS products do not treat this seriously enough. Here is what good supplier data UX requires:

Duplicate detection at the point of entry. When a procurement user creates a new supplier record, the interface should immediately surface potential duplicates – similar names, matching email domains, and matching registered addresses. This does not require sophisticated AI; it requires a well-designed search and match function built into the record creation flow. Preventing the duplicate is orders of magnitude cheaper than deduplicating it after the fact.

Standardised field validation. Supplier name fields should enforce capitalisation standards. Legal entity type should be a validated dropdown. Country should be a standardised field, not a free-text entry that produces “UK,” “United Kingdom,” “U.K.,” and “England” as four values for the same thing. The UX should make standardised entry the path of least resistance.

Supplier self-service with guided flows. Supplier portals that ask suppliers to maintain their own records reduce the data maintenance burden on procurement teams – but only if the portal is well-designed enough that suppliers actually use it. A confusing, burdensome supplier portal produces incomplete, outdated records. A well-designed supplier onboarding flow produces rich, accurate records from the start.

Data freshness indicators. Every supplier record should show when it was last updated and by whom. Records that have not been touched in 18 months should be flagged for review. Data freshness is invisible in most procurement systems, which means outdated records persist without anyone knowing.

Enrichment prompts. When a procurement user is working with a supplier record that is missing key information: no risk score, no sustainability data, no contact details – the interface should prompt them to complete it, with a clear explanation of why the missing data matters.

What TealBook Solved and What It Taught Us

TealBook, a supplier intelligence platform that Inity helped design, is built specifically around the supplier data problem. Its core value proposition: a unified, enriched, continuously maintained supplier data foundation that procurement teams can actually use for analysis, sourcing, and risk management.

The design challenge was significant. The data TealBook processes comes from fragmented, inconsistent sources. The users who need to act on it have varying levels of data literacy. The interface needed to make the data trustworthy, visible in its sourcing, transparent in its completeness, and actionable in its presentation — without overwhelming operational users with data science complexity.

The key UX decisions: data confidence indicators that show users how complete and fresh each supplier record is, source attribution so users can see where each data point came from, and guided data completion flows that make enriching a record feel like a productive task rather than an administrative burden.

The lesson: supplier data is a product problem, not just a technical problem. The interface around the data determines whether procurement teams trust it, use it, and maintain it.

What Procurement SaaS Products Need to Get Right

If you are building a procurement SaaS product where supplier data is part of the core workflow: sourcing, supplier management, spend analysis, risk monitoring – the supplier data architecture needs to be a first-class design concern from Discovery Week.

Specifically:

• How does a supplier record get created? What validation and duplicate detection is built into that flow?
• What is the canonical identifier for a supplier across the system? How does the system handle the same supplier appearing under different names from different data sources?
• Who is responsible for maintaining supplier records, and what does the interface do to support that maintenance?
• How is data freshness tracked and surfaced to users?
• What does the interface communicate about data confidence? How complete is this record? How recently was it updated? How should the user weigh it in their decisions?
• When AI or analytics features are built on top of supplier data, how does the interface communicate the confidence level of the output to users who may not understand the underlying data quality?

These are design questions that need answers before wireframes are drawn. The supplier data architecture shapes the information architecture of the product at every level.

Conclusion

Supplier data is procurement’s most consistently underestimated problem, not because the technology to address it does not exist, but because the governance, integration, and UX design requirements to sustain clean data are underinvested in almost every organisation. The consequence shows up in spend analysis that cannot be trusted, supplier risk that cannot be monitored, contract compliance that cannot be verified, and AI insights that produce outputs nobody acts on. Building a procurement SaaS product that actually solves this problem requires treating supplier data architecture as a product design problem, one that determines the interface, the onboarding flow, the validation logic, and the confidence indicators that tell users whether the data they are looking at is worth acting on.

→ Building a procurement SaaS product and working through the supplier data architecture? Inity has designed procurement platforms for companies that have raised $90M+  Book a call.