Why does the same supplier's catalog data get worse over time instead of staying consistent?

Because it usually passes through several systems and several people between the source of truth and the file that actually gets uploaded, and each hop is an opportunity for something to drift: an ERP export reformatted by hand in a spreadsheet, a price list merged from two regional sources with different conventions, a classification field populated once and never revisited as the taxonomy itself gets updated. No single mistake causes this; it's the accumulation of small, independent edits across a pipeline nobody owns end to end.

What's the difference between a duplicate SKU and a near-duplicate, and why does the distinction matter?

A duplicate SKU is the exact same identifier appearing twice, usually from a supplier or catalog change that accidentally reused an existing code. A near-duplicate is two different SKUs that describe what is functionally the same item: a case-pack and an each-pack variant with no explicit unit-of-measure distinction, or the same item re-submitted under a superseded and a current part number. Exact duplicates are usually caught by a uniqueness check; near-duplicates require actually comparing item attributes, which is why they survive validation more often.

Does a wrong classification code actually break anything, or is it just a data hygiene issue?

It depends on what the buyer's system does with the code, and that's usually more than categorization. Classification codes commonly drive approval routing and tax treatment on the buyer's side, so a wrong or missing code can route an order to the wrong approver or apply the wrong tax logic even though the catalog upload itself passed validation cleanly; the failure shows up downstream of ingestion, not at ingestion, which makes it harder to trace back to its source.

Can validation catch every one of these errors before a file is ingested?

Not all of them, and treating validation as a complete safety net is itself a mistake. Structural and referential checks (is this a valid currency code, does this classification code exist in the taxonomy version in use, is this SKU unique) catch a large share of errors reliably. Semantic errors, like a near-duplicate SKU describing a genuinely different pack size, or a price that's numerically valid but wrong, often require a human review step or a plausibility check against prior catalog versions rather than a pure schema check.

Should a whole catalog file be rejected if only a few rows have errors?

It depends on what kind of error and how the receiving system is built. A structural failure (malformed XML, a header row that doesn't match the expected schema) usually has to reject the whole file, because a parser can't reliably tell where the malformed content ends. Row-level content errors, like a handful of missing classification codes in an otherwise valid file, are better handled by accepting the clean rows and flagging the bad ones for correction, so one supplier's mistake on a handful of items doesn't block their entire catalog from updating.

Blog

Catalog Data Quality: The Errors That Break Supplier Uploads

The recurring data-quality errors that make a catalog upload fail or silently corrupt: bad units of measure, price precision, duplicate SKUs, wrong classification codes, broken image links.

September 16, 2026SupplierForge team

A catalog upload that fails outright is at least visible: someone gets an error message and knows to fix something. The more expensive failures are the ones that pass validation and still corrupt the buyer’s data: a price that’s off by a factor of ten, a classification code that routes an order to the wrong approver, an item that silently duplicates one already in the catalog under a slightly different SKU. BoreaTech’s primer on what supplier master data is covers why this data matters structurally to a buyer’s systems; this guide covers the specific, recurring errors that show up in the catalog data itself: where they come from, what they look like in practice, and which ones validation can actually catch before they reach a live catalog.

Why catalog data degrades

Catalog data rarely starts out wrong. It degrades because it passes through a chain of systems and people between wherever it’s authoritative (an ERP, a product information system, a supplier’s own pricing spreadsheet) and the file that eventually gets uploaded, and each step in that chain is an opportunity for something to drift without anyone deciding it should. A price list gets exported from an ERP, opened in a spreadsheet for a manual price adjustment, and re-saved with a formatting change nobody intended. A classification taxonomy gets a version update on the buyer’s side, and nobody goes back to re-check whether codes assigned two years ago are still valid under the new version. A regional sales team merges two supplier price lists that used slightly different currency or unit-of-measure conventions, and the merge preserves both conventions inconsistently rather than reconciling them.

None of this is any one person’s mistake in the way a typo is a mistake. It’s what happens by default when catalog data has multiple points of entry and no single system of record enforcing consistency across the whole pipeline, which is exactly why the errors below are so recurring rather than random: they’re the predictable failure modes of that kind of pipeline, not one-off accidents.

Unit-of-measure mismatches

A unit-of-measure field looks like the simplest kind of data a catalog carries, and it’s one of the most common sources of failure precisely because it looks that simple. The same concept gets written inconsistently (EA, EACH, PC, 1) by different suppliers, different systems, or even different rows from the same supplier’s export, and a buyer’s system that recognizes one convention and not another either rejects the row or, worse, accepts it and defaults to an assumption that doesn’t match what the supplier meant.

The costlier version of this error isn’t the unit code itself but the mismatch between the unit a price is quoted against and the unit a quantity is expressed in. A price of $48.00 per case doesn’t mean the same thing as $48.00 per each, and a catalog row that specifies quantity in eaches while carrying a case-level price (without a pack-size field connecting the two) produces an extended price that’s wrong by whatever the case size happens to be, silently, because nothing about the row looks structurally invalid. This is the same underlying category of error that shows up in OCI PunchOut sessions when a PRICEUNIT field is missing, covered in detail in the S/4HANA OCI PunchOut guide; the root cause there is the same one here: a price and the unit basis it’s quoted against separating without anything downstream noticing.

Currency and price-precision errors

Price fields fail in a few specific, recurring ways beyond the unit-of-measure problem above. A currency code left blank rather than explicitly stated is one of the most common: a receiving system that defaults a blank currency field to its own home currency rather than rejecting the row can silently treat a price quoted in one currency as though it were quoted in another, producing an error that’s numerically plausible and therefore hard to catch on inspection.

Precision is the second recurring issue. Some systems store or transmit price fields with a fixed number of decimal places, commonly two, which is fine for most retail-style pricing but loses information for a bulk or fractional-unit item genuinely priced to three or more decimal places: a per-unit price of $0.0075 for a component sold by the thousand becomes $0.01 after truncation, a rounding error that looks negligible per unit and compounds into a real discrepancy at volume. Decimal-separator confusion is the third: a price authored under a comma-decimal locale and read under a period-decimal assumption, or the reverse, doesn’t fail to import so much as import as a different number entirely, frequently larger or smaller by a factor of 100. That’s the same mechanism covered from the OCI PunchOut side in the S/4HANA integration guide, and it’s worth checking explicitly with real numbers during any new catalog relationship rather than assuming a plain numeric field carries no formatting risk.

Duplicate and near-duplicate SKUs

An exact duplicate SKU (the identical identifier appearing twice in a catalog) is usually the easier problem, because a uniqueness check catches it reliably: two rows with the same SKU is unambiguous, and the fix is either a deduplication rule or a rejection back to the supplier. Near-duplicates are harder, because they don’t fail a uniqueness check at all: they’re two different identifiers describing what is, functionally, the same item.

The most common source is a supplier part-number change that isn’t handled as a rename. A part gets superseded (a manufacturer revises a product and issues a new part number for it), and if a catalog refresh adds the new number without explicitly retiring the old one, both persist as separate active items indefinitely, splitting purchase history and search results between them. A related pattern shows up with pack-size variants: a case-pack SKU and an each-pack SKU for what a buyer’s system otherwise treats as the same underlying product, distinguishable only by a unit-of-measure or quantity field that a catalog viewer easily overlooks, producing two catalog entries a buyer’s user has no obvious way to tell apart without opening both.

sku,description,uom,unit_price
WDG-1002,"Widget, 3in, stainless",EA,4.75
WDG-1002-NEW,"Widget, 3in, stainless (rev. B)",EA,4.95

Nothing about that pair fails a structural check: both rows are individually well-formed. Catching it requires comparing descriptions and attributes across rows, not just validating each row in isolation.

Missing or wrong classification codes

Classification errors take a few distinct shapes, and they don’t all look the same to a validation pass. The most obvious is a missing code entirely: a row with no UNSPSC or eCl@ss value at all, which a required-field check catches easily. Less obvious is a code that’s syntactically valid but semantically wrong: a value from an older version of the taxonomy that’s since been deprecated or restructured, a code copied from a similar-but-different item during a rushed catalog build, or a generic catch-all code applied broadly because assigning a specific one for every SKU wasn’t done. A code truncated to fewer digits than the taxonomy requires, commonly because a spreadsheet reformatted a leading-zero code as a number and dropped the zero, passes a basic “is this field populated” check while still being the wrong value.

A quieter version of this error is a classification value landing in the wrong field entirely rather than simply being the wrong value in the right one. The S/4HANA OCI PunchOut guide walks through a verified case of exactly this: OCI’s MATGROUP field looks like a plausible home for an external commodity code and isn’t one; it’s the buyer’s own internal material grouping, while UNSPSC or eCl@ss has a separate field pair reserved for it entirely. A value sitting in the wrong field clears any check that only confirms a field is populated, which is precisely why this class of mistake survives review undetected. The same shape of error shows up in flat-file catalogs too, whenever a column mapping during ingestion silently misaligns a supplier’s classification column with the wrong target field.

Because classification frequently drives approval routing and tax treatment downstream, not just search and reporting, a wrong or missing code is one of the error types most likely to produce a failure that shows up well after ingestion, on a system the supplier never directly interacts with.

Broken image and attachment references

Image and document references degrade in a handful of predictable ways. A relative URL (one that assumes a specific hosting path) breaks the moment catalog data moves to a different host or gets re-served through a different domain, which happens more often than suppliers expect once a catalog is redistributed across multiple buyer-facing systems. A link to an image hosted in a private or access-restricted bucket works fine when tested from inside the supplier’s own network and fails silently for anyone outside it. Filenames tied to a part number break when the part number changes but the referenced filename doesn’t get renamed to match, and a supplier’s own e-commerce site reorganizing its URL structure, entirely outside the catalog relationship, can quietly invalidate every image link a catalog was pointing at it.

None of these produce an error at catalog ingestion time in most systems, because the reference itself is a syntactically valid URL; the failure only appears later, when something actually tries to load the resource and gets a broken link or an access-denied response instead.

Validation before ingestion

The errors above split roughly into two categories, and they call for different kinds of checks. Structural and referential errors (a missing required field, an invalid currency code, a classification code that doesn’t exist in the taxonomy version currently in use, a duplicate SKU) can be caught reliably with schema and lookup validation run before a file’s contents are treated as live catalog data. These are the checks worth enforcing strictly, because a false negative here becomes a downstream failure that’s much harder to trace back to its source.

Semantic errors are harder: a near-duplicate SKU, a price that’s numerically valid but implausible given the item’s history, a classification code that’s technically well-formed but wrong for the item. These typically need either a human review step for anything flagged as unusual, or a comparison against the item’s own prior catalog state: does this price differ from last refresh by more than a threshold that warrants a second look, does this SKU’s description differ enough from what’s on file to suggest it’s actually a different item wearing a reused code. A validation approach that only checks structure will pass a file full of confidently wrong data; one that also checks plausibility against what’s already known about an item catches a meaningfully different set of problems.

Whether a bad row should block an entire file matters here too. A structurally broken file (malformed XML, a header row that doesn’t match the expected schema) generally has to be rejected wholesale, because a parser has no reliable way to isolate the damage. A file that’s structurally fine but has a handful of rows with content errors is usually better served by accepting the valid rows and flagging the rest for correction, so one bad row doesn’t hold an entire catalog refresh hostage.

Where SupplierForge fits

Most of what’s described above is exactly what catalog health and data-quality monitoring exists to catch: unit-of-measure inconsistencies, price and currency anomalies, duplicate and near-duplicate SKUs, classification gaps, and broken references, flagged against a supplier’s own prior catalog state rather than checked only in isolation. SupplierForge’s supplier onboarding portal runs automated validation on ingestion across CSV, Excel, structured feeds, direct API, SFTP and EDI, and ongoing monitoring continues to surface drift after the initial upload rather than treating validation as a one-time gate. The full breakdown is in the feature set.

Frequently asked questions

Why does the same supplier's catalog data get worse over time instead of staying consistent?: Because it usually passes through several systems and several people between the source of truth and the file that actually gets uploaded, and each hop is an opportunity for something to drift: an ERP export reformatted by hand in a spreadsheet, a price list merged from two regional sources with different conventions, a classification field populated once and never revisited as the taxonomy itself gets updated. No single mistake causes this; it's the accumulation of small, independent edits across a pipeline nobody owns end to end.
What's the difference between a duplicate SKU and a near-duplicate, and why does the distinction matter?: A duplicate SKU is the exact same identifier appearing twice, usually from a supplier or catalog change that accidentally reused an existing code. A near-duplicate is two different SKUs that describe what is functionally the same item: a case-pack and an each-pack variant with no explicit unit-of-measure distinction, or the same item re-submitted under a superseded and a current part number. Exact duplicates are usually caught by a uniqueness check; near-duplicates require actually comparing item attributes, which is why they survive validation more often.
Does a wrong classification code actually break anything, or is it just a data hygiene issue?: It depends on what the buyer's system does with the code, and that's usually more than categorization. Classification codes commonly drive approval routing and tax treatment on the buyer's side, so a wrong or missing code can route an order to the wrong approver or apply the wrong tax logic even though the catalog upload itself passed validation cleanly; the failure shows up downstream of ingestion, not at ingestion, which makes it harder to trace back to its source.
Can validation catch every one of these errors before a file is ingested?: Not all of them, and treating validation as a complete safety net is itself a mistake. Structural and referential checks (is this a valid currency code, does this classification code exist in the taxonomy version in use, is this SKU unique) catch a large share of errors reliably. Semantic errors, like a near-duplicate SKU describing a genuinely different pack size, or a price that's numerically valid but wrong, often require a human review step or a plausibility check against prior catalog versions rather than a pure schema check.
Should a whole catalog file be rejected if only a few rows have errors?: It depends on what kind of error and how the receiving system is built. A structural failure (malformed XML, a header row that doesn't match the expected schema) usually has to reject the whole file, because a parser can't reliably tell where the malformed content ends. Row-level content errors, like a handful of missing classification codes in an otherwise valid file, are better handled by accepting the clean rows and flagging the bad ones for correction, so one supplier's mistake on a handful of items doesn't block their entire catalog from updating.