Most businesses know their product data is a mess. They just don’t know how bad the mess is, or how much it’s costing them.
A 2023 Gartner study found that poor data quality costs organizations an average of $12.9 million per year. For companies selling hundreds or thousands of products across multiple channels, that number climbs fast. The problem isn’t exotic data corruption or rogue systems. It’s structural mistakes that repeat across industries, often for years, before anyone calculates the damage.
Here’s what’s actually going wrong.
Treating the ERP as the product information system
The ERP was built to manage transactions, not to describe products. It stores SKUs, prices, and inventory counts. It was never designed to hold 47 images per product, localized descriptions for six markets, or structured attribute data that feeds a product configurator.
But most manufacturers still use it as their product data source of truth. The result is a fragmented setup where someone exports a spreadsheet from the ERP, adds columns for marketing copy, passes it to someone else who reformats it for the webshop… That export step is the tell. It exists because there’s no live PIM-ERP integration, no automatic handoff between the system that owns logistics data and the system that owns product content.
This is the single most common starting point for a lot of manufacturers. The ERP data is accurate for logistics. It’s unusable for commerce without significant manual work each time a product changes.
A dedicated product information management system solves this by separating concerns. The ERP manages what it’s good at: stock levels, pricing, and procurement. The PIM manages product content, attributes, and channel-specific outputs. Each system does one job, and does it well.
Spreadsheets as a collaboration tool
Spreadsheets work fine for one person managing a small catalog. They break when multiple people need to update data simultaneously, when version history matters, or when the catalog exceeds a few hundred products.
The specific failures are predictable:
- Two people edit the same file, and one overwrites the other’s changes.
- Column names drift across files (“Colour,” “Colour,” “color_code”), and merges become error-prone.
- There’s no audit trail. Nobody can see who changed what, or when.
- Formula errors propagate silently; a miscalculated weight or wrong unit of measure ships to every channel before anyone notices.
A catalog of 3,000 products with 80 attributes per product is 240,000 data points. Managing that in a spreadsheet isn’t slow — it’s structurally impossible to do accurately.
Some companies graduate to shared drives or cloud spreadsheets, which solves the simultaneous editing problem but not the structural ones. The underlying issue is that spreadsheets are flat files pretending to be databases. They have no concept of mandatory fields, no validation rules, and no workflow enforcement. They’re fine for analysis. They have poor infrastructure for a living catalog.
No clear data ownership
In most organizations, nobody owns product data quality, and the consequences of that gap are entirely predictable.
Marketing assumes the product manager entered the technical specs. The product manager assumes marketing wrote the descriptions. Operations updates the weight and dimensions but doesn’t tell anyone. The result is that incomplete records ship to every channel.
Consider what this looks like in practice: a product launches with placeholder copy and a missing safety certification field. Three months later, it’s still placeholder copy, because nobody’s job description includes checking. The product gets flagged by a major retailer’s feed validator six weeks before peak season. The fix is urgent, manual, and expensive.
This isn’t a technology problem. It’s a process problem that technology can reinforce or fix. A PIM with defined workflows, mandatory fields, and completeness scoring makes ownership visible. If a product record is at 60% completeness, someone has to account for that before it goes live. Without that structure, data quality depends entirely on individuals being diligent. That’s not a reliable system.
Duplicating work for every channel
A product sold on the company website, on Amazon, through a wholesale partner portal, and in a print catalog needs different data formats for each channel. Different image sizes, different attribute structures, different character limits on descriptions.
Most businesses handle this by creating separate exports or feeds for each channel and maintaining them independently. When a product spec changes, someone has to update it in four places. Usually, they update it in two and forget the rest. The Amazon listing shows the old weight. The print catalog still has last year’s dimensions. Customer returns follow.
The correct approach is to maintain a single master record and generate channel-specific outputs from it. Change it once, publish everywhere.
That’s the core principle behind a PIM with channel management. It’s not a complicated idea, but it requires infrastructure that most businesses haven’t invested in, and the cost of not investing compounds with every new channel added.
Inconsistent attribute structures
This one is slow to become a problem and expensive to fix. When different product categories or different team members define attributes independently, the catalog develops structural inconsistencies that make filtering, comparison, and search unreliable.
One category uses “Material: Stainless Steel.” Another uses “Material Type: Stainless” and “Finish: Steel.” A third records it as free text in a description field. Customers searching by material get inconsistent results. Downstream systems trying to filter by material get garbage. Faceted navigation on the webshop quietly stops working correctly.
In projects with established manufacturers, we’ve seen catalogs where the same physical attribute was stored in seven different ways across product lines. Cleaning that up requires mapping every variant back to a standard, then migrating the data. It’s months of work for something that could have been prevented with a taxonomy defined at the start.
Good attribute management means defining a shared data model before people start entering data. That requires upfront planning, and because the pain is invisible until the catalog is broken, most companies skip it.
Ignoring data completeness until something breaks
Product data gets entered when a product launches. After that, it rarely gets reviewed systematically. Specifications change, but the records don’t. Products originally sold in one country get rolled out to new markets without localized content. Images that were acceptable at launch are now below the resolution requirements of a key channel.
The problem stays invisible until something breaks: a retailer rejects a product feed; a customer calls about a specification that doesn’t match what they received; a compliance requirement flags missing safety data. At that point, the fix is reactive, and reactive fixes come with a cost premium.
A regular completeness audit, even a quarterly one, catches most of these issues before they cause downstream failures. For high-volume catalogs, automated completeness scoring is more practical, flag the gaps in the system, assign owners, and close them before they become incidents.
Treating translation as an afterthought
For businesses selling across multiple languages, translation is usually the last step before a product goes live in a new market. That means translators receive unstructured data, often in spreadsheets, with no context about which fields are mandatory, which are character-limited, or which attributes are structured data versus free text.
The structured attributes get translated literally, which breaks filtering in the local store. Free text descriptions get handled by the localization team with no consistency guidelines. Images with embedded text get missed entirely. The German store launches with half its attributes unfiltered and the rest inconsistently worded.
A functional multilingual setup treats translation as part of the data model, not a downstream task. Translatable fields are defined in the system. Translators work within the product record, not alongside it in a separate file. Character limits and field types are enforced regardless of language. The process is repeatable, not improvised.
Underestimating the cost of bad data
The cost of poor product data is distributed across the organization and rarely shows up as a single line item. Returns attributed to “product not as described.” Customer service calls answering questions that the product page should answer. Sales cycles stall because technical documentation is incomplete. Development time spent building workarounds for data that should have been clean at the source.
The distributed nature of this cost is what makes it persist. No single budget owner sees the full picture, so nobody champions the fix. It’s only when a company audits across returns, support volume, and channel rejection rates simultaneously that the true figure becomes visible, and it’s rarely comfortable.
The businesses that take product data seriously treat it as infrastructure, not admin. The ones that don’t spend more time managing consequences than improving the catalog.
What to look for in a product data solution
If the mistakes above sound familiar, a dedicated PIM is the right next step. But not all PIM solutions are built the same, and the wrong choice creates its own problems. The system that works for a 500-SKU catalog with simple attributes is different from one that needs to manage 50,000 products across twelve markets with complex hierarchies.
A few criteria matter more than most:
- Open architecture. Vendor lock-in is a structural risk. If exporting your data or connecting to other systems requires the vendor’s involvement, that dependency compounds over time. Prioritize platforms where the data model is transparent and integrations are owned by your team.
- Configurability. Generic solutions fit generic catalogs. If your products have industry-specific attribute structures, layered hierarchies, or channel requirements that do not map neatly to a standard template, the system needs to bend to your data, not the other way around.
- Real ERP and commerce integrations. Pre-built connectors to common ERP and e-commerce platforms save significant implementation time. The alternative, custom middleware built to bridge an incompatible system, tends to become technical debt quickly.
- Deployment flexibility. On-premise and SaaS should both be viable options. Infrastructure requirements change, and being locked into one model can become a real constraint at the wrong moment.
- Scalability without migration. The system that works for your catalog today should still work when it is ten times larger. A platform migration mid-growth is expensive and disruptive.
One platform that fits those criteria is AtroPIM. It is open source, which addresses lock-in directly, since the codebase is auditable and extensible by your own team. It supports both deployment models, handles complex catalog structures that simpler PIMs are not designed for, and has native integration paths for ERP and commerce platforms. It serves manufacturers and distributors across the full range, from growing mid-market companies to large enterprises with high-volume catalogs and demanding integration requirements.
