PIM Errors in Your ERP: Which Master Data Mistakes Block Which Processes
The tricky thing about master data errors is that the mistake itself happens right at product creation. Anyone looking for the cause afterward usually looks in the wrong place. This article shows the five most common error patterns, with the specific data field, the affected process, and the consequence.
Key takeaways
Master data errors often block ERP processes only weeks after the product was created, that time gap is what makes them hard to find.
A missing purchase price, a wrongly modeled packaging unit, the wrong tax rate, unlinked variants, and missing customs data each hit a different ERP process, from replenishment to international shipping.
Mandatory fields at product creation, CSV import validation, and fallback values in the shipping method catch data gaps before they surface in the process.
Why do errors in product data cause ERP problems so much later?
An order gets stuck. The shipping label won't generate. The reorder suggestion doesn't fire, even though stock has long since hit zero. The team looks at the process, checks the interface, asks the carrier, and finds nothing. Because the cause isn't in the process itself. It's in the product data, created three months earlier, when nobody was thinking about this product ever being shipped internationally or listed on Amazon.
That's the problem with PIM errors in your ERP: they happen early, the effects show up late, and the link between cause and effect is rarely obvious.
Your ERP doesn't warn you; it waits
The real problem isn't that the ERP accepts faulty product data. It's that the data only becomes visible in the process, long after the product was created, and then shows up somewhere completely different in the business than where it originated.
No purchase price is stored on the product. That's only noticed three weeks later, when stock falls below the minimum level and the product still doesn't show up in the reorder suggestion.
The wrong unit of measure goes unflagged at import, but picking pulls the wrong quantity, while returns pile up without anyone connecting the dots.
A product with a missing tax attribute is created in the ERP, but invoice dispatch only fails on the next order, and until then nobody suspects the product.
This time gap between cause and symptom is why operations teams spend so much time debugging processes that aren't actually the problem. The picking process isn't broken. The carrier interface works fine. The problem sits in the product master, and it was created by someone no longer involved in this transaction at all.
For a deeper analysis, see our guide on the cost of poor master data quality.
Five typical errors in product master data and their consequences
Error 1: No purchase price on the product, the reorder suggestion skips it
Error in the field: No purchase price with a supplier is stored on the product, or the product isn't marked as a stock item.
Affected process: Reorder suggestion and replenishment.
What happens: The reorder suggestion works off the purchase prices stored on the product. That's how Xentral derives the supplier and groups line items. Without a purchase price, there's no supplier to assign the line item to, and the product drops out of the suggestion. Having the min. stock level maintained doesn't help at that point. Purchasing only notices once stock hits zero and orders can no longer be fulfilled. That often happens right in the middle of peak season, when reorders take longest.
The fix: Three things need to be in place for a product to show up in the reorder suggestion. The supplier address needs a supplier number, the product needs a purchase price stored for that supplier, and the product needs to be marked as a stock item. Xentral warns you along the way: if a product shares its main supplier with others but has no purchase price, the reorder suggestion shows a note. Paying attention to that costs seconds, searching for it later in the process costs hours.
And the EAN? In Xentral, that's the key identifier your products are recognized by, but in the warehouse, not in purchasing. It's tied to the scan processes: goods receipt, picking, the packing station, returns, POS. If it's missing or assigned twice, you scan into thin air. It has no bearing on replenishment.
Consequence: Delivery delays, frustrated customers, emergency orders on worse terms.
„We used to work with pseudo stock levels [...]. With Xentral, it's now possible in two clicks to reflect actual stock on hand and reorder in time.“
Alexander Kessler, E-Commerce-Manager at VanDeBord
Error 2: Wrong units in the ERP, picking pulls the wrong quantity
Error in the field: The product is traded in boxes of 12, but no repack unit is set up in the product master.
Affected process: Picking and shipping.
What happens: The Unit field on the product is just a label. It appears on documents and in parts lists, but it doesn't convert anything. Someone orders "5" meaning boxes, and gets five individual pieces picked if stock is tracked in individual units. The shipment is wrong, the return comes back. Because the error becomes visible in picking, the team looks for the cause there and doesn't find it.
The fix: On the product, under Repack Unit, set up the repack unit's barcode and the quantity it contains. Xentral then automatically recognizes the correct product quantity on every scan and posts it. Important: repack unit numbers need their own numbering range, separate from product numbers.
Our overview page explains exactly how warehouse management in Xentral works.
Error 3: Wrong tax rate, the invoice goes out and it's wrong
Error in the field: The wrong tax rate is selected on the product, for example standard instead of reduced for food.
Affected process: Invoicing and accounting export.
What happens: The tax rate on the product is a choice between the two rates stored system-wide, in Germany 19% and 7%. If nothing is set, the standard rate applies. So the invoice goes out, looks correct, and carries the wrong rate. It only becomes noticeable at correction time: cancellation invoice, reissue, new payment run. On top of that comes the accounting export. Xentral pulls revenue accounts in this order: account on the product, then account on the product category, then system settings. If no account is maintained for a product with a deviating tax rate, revenue lands on the default account. So the error moves from the invoice into accounting. Especially tricky for products that switch between 7% and 19%, like food with and without processing: the tax rate rarely gets attention at creation time.
Consequence: Delayed payment receipt, correcting the booking costs hours, in the worst case GoBD-relevant errors.
Our product page has a detailed look at how accounting and invoicing in Xentral work.
Error 4: Missing variant structure, the marketplace listing fails
Error in the field: Color and size aren't set up as a variant matrix, but as separate individual products with no link between them.
Affected process: Transfer to shop and marketplace.
What happens: The interface expects a structured variant hierarchy, a parent-child relationship. Without it, the transfer fails, or the product gets listed as a single variant with no selection option. Customers can't choose size or color, and the product barely sells or doesn't sell at all. This often only gets noticed once sales numbers drop and someone checks why the product barely shows up anymore. In Xentral, you set this up as a matrix product: one parent product, with child products underneath for each combination of color and size. For Shopify and Shopware 6, sync via Connect is documented. On first transfer, it runs step by step: first the matrix product, then wait until it shows green in the journal, then the variants. Try to do it all in one go, and you get exactly the failed transfer this is about.
Consequence: Missing visibility on the marketplace, lost revenue, manual correction effort for every affected variant. For large ranges, this can quickly affect dozens of products.
Error 5: Wrong weight or missing customs number, the international order gets stuck
Error in the field: Product weight is missing or wrong, customs tariff number (HS code) isn't stored.
Affected process: Shipping label for international orders.
What happens: Generating the shipping label fails. Without weight in the product master data, no label. Without the customs tariff number, also none. Someone has to research the data from the manufacturer or in customs databases and restart shipping. For one product, that's annoying. For 200 products just being rolled out to a new market, it's a bottleneck.
The countermeasure: For exactly this case, Xentral has two emergency brakes built in. In the shipping method, under Fallback Line-Item Weight, you store a weight in kilograms that kicks in when none is maintained on the product. Under Auto-Fallback for HS Code, you store a customs tariff number that steps in when none is set on the product. The shipment keeps moving instead of getting stuck at the packing table. The fallbacks aren't a substitute for maintained master data: weight, customs tariff number and country of origin still have to be correct, or the customs paperwork won't match. They just buy you time to fix the error properly.
Where the fields are: weight on the product under Details > Warehouse/Dimensions, the customs tariff number under Details > Manufacturer.
Consequence: Delivery delays for international customers, manual effort per order, scaling abroad becomes a source of errors instead of a growth lever.
„Xentral is a genuine all-in-one solution for us. What helps most is the central upkeep of our product data, it saves time and reduces errors.“
Alexander Kessler, E-Commerce-Manager at VanDeBord
How does Xentral rule out PIM errors at the ERP integration?
The five error patterns above share a common cause: the ERP gave no feedback when the product was created that a relevant field was missing. And if you don't know at creation time which fields matter for which process, you leave them out. The system lets you.
The fix isn't training or a new checklist document, it's a safe structure built into the system itself.
In Xentral's item management, you can configure exactly that:
Mandatory fields per product type: In the Mandatory Fields module, you define system-wide which fields must be filled in when saving, with your own error message. For weight and customs tariff number, this is the most effective lever, since international shipping depends on it. Anyone creating a new product gets stopped at exactly the point where the gap would otherwise enter the ERP. The rule applies system-wide per module, not per product type, so you can't set different mandatory fields for physical products than for services. Alongside module and page, you enter the field ID, which you read out in the browser via "Inspect element."
Validation rules on import: The CSV importer checks your mapping before writing. If something doesn't match, you get a red message and correct the flagged records; if everything's green, the import starts in the background and you track status per record. The check catches records Xentral can't process: a product number that doesn't exist, a purchase price with no supplier, a gross price below the net price. What it doesn't catch are plausible but wrong values. For product import, only product number and name are mandatory. Every empty field gets set to the default. So a wrong unit still counts as valid data. The only thing that helps there is visually checking your import template before uploading 500 rows.
Fallback values for shipping: For the two fields where international shipping actually fails, you can store a fallback in the shipping method. If weight is missing on the product, the fallback line-item weight kicks in. If the customs tariff number is missing, the auto-fallback for the HS code kicks in. The order keeps moving, and you fix the master data afterward instead of in the middle of shipping. The Standard Product Unit in general settings works the same way: products with no unit automatically get the stored default unit on documents. Useful when your daily shop import doesn't supply units.
Conclusion: prevent PIM errors in your ERP systematically, structure once instead of checking by hand five times
To stop errors in master data from blocking ERP processes, you first have to make the connection between the data field that's missing at creation and the process that later fails because of it. The five error patterns here are a good starting point for checking your e-commerce product data deliberately.
The second step is structure: mandatory fields, validation rules, and channel-specific release logic prevent new errors from occurring. Not through manual checking, but because the system itself no longer lets gaps through.
„Xentral is our single source of truth for every order. I can let orders run through without a second thought and end up with accurate numbers. Because we can rely on everything being correct, it's much easier for us to plan around large volumes.“
Adrian Gellissen, Logistik & Operations Manager at vly
Eliminate typical error sources for good with Xentral
See for yourself in a personal demo how Xentral's item management specifically supports you. Or run a no-obligation needs assessment with us and find out where data gaps are forming in your system today.