Product Details: Keeping Them Accurate From Supplier Sheet To Sales Channel

Product details are the facts a buyer needs before paying and a regulator expects to see on the listing. For a cordless drill, that means the SKU and GTIN, battery voltage and chemistry, chuck size, torque, weight with and without battery, warning texts, the manufacturer's postal address, a manual as a PDF, photos, and the spare battery that fits.

Most companies have all of this. They just have it in five places, in five versions. The ERP holds the net weight. The shop shows the shipping weight. The marketplace listing still mentions last year's battery because someone uploaded a spreadsheet in spring and nobody has opened it since.

This article covers where product details live, why they drift apart, what EU regulation and AI shopping assistants now demand from them, and how PIM software keeps them consistent in practice.

Key Takeaways

• Decide which system owns each product attribute before building any integration. Most data quality problems between the ERP and sales channels start with two systems writing the same field.
• EU authorities now check product details listing by listing. In the 2026 product safety sweep, 42% of checked listings lacked part of the manufacturer and identification data the GPSR requires.
• The EU Digital Product Passport registry has been live since July 2026, and the first mandatory passports apply to certain large batteries from February 2027.
• AI shopping assistants send fast-growing, high-converting traffic, and they skip product details trapped in images and loose prose.
• A PIM helps through specific mechanisms: typed attributes, classifications, completeness rules per channel, approval workflows, and channel mappings. It does not repair bad source data by itself.

What Counts As Product Details

The groups change at different speeds and belong to different people. Price changes weekly and belongs to sales. A torque value changes when engineering redesigns the motor. A warning text changes when a standard or the legal team says so. A photo changes when marketing reshoots the range.

Trouble starts when one system is asked to hold every group, or when every system holds a copy of every group.

Where Product Details Live And How They Drift Apart

The ERP is the transactional backbone. It knows the item number, price, stock, tax class, and the gross weight a carrier will bill. ERP item masters are built around fixed fields that apply to every item. Adding "IP rating" for lamps means a custom field that also appears on screws and cables. Most teams avoid that, so technical attributes land in a free-text field or in no system at all.

Engineering keeps specifications in PLM systems and CAD drawings. Those values are precise and written for engineers. "Rated torque 60 Nm" needs a measuring standard and a plain-language explanation before it helps someone compare two drills.

Retailers and distributors receive product details from suppliers as spreadsheets or BMEcat files, often classified according to ETIM in electrical and HVAC wholesale. Every supplier uses its own column names and units. One writes "stainless steel", another writes "INOX", and both mean the same material.

The online shop renders product pages from its own database. Shop managers fix typos directly in the shop admin because it is faster. The next sync overwrites the fix. Or it doesn't, and the shop quietly becomes a second master.

Marketplaces add their own category trees, required attributes, value lists, and character limits. A listing without a required attribute gets rejected or suppressed. Sellers often answer with one spreadsheet per marketplace, which adds another copy to keep in sync.

Drift follows a few repeating patterns: manual edits in a downstream channel, unit conversions done by hand, translations made per channel instead of per attribute, supplier updates that reach one channel and miss the others, and discontinued items that stay live because the deletion never propagated.

In projects we implemented for manufacturers of technical products, the first data workshop usually surfaces the same finding. Several departments maintain the same weight or dimension value, and each believes its version is correct. Nobody is wrong on purpose. The company never decided whose number counts.

Regulation Turned Product Details Into Evidence

Since December 2024, the EU General Product Safety Regulation (GPSR) has required every online offer of a consumer product to show the manufacturer's name with a postal and an electronic address. If the manufacturer is based outside the EU, the listing must also name the EU responsible person with contact details. The listing needs information that identifies the product, including a picture and its type, plus any warnings or safety information in a language consumers easily understand.

Authorities enforce this per listing. In the 2026 product safety sweep, national authorities screened nearly 1,700 listings for childcare and gym products on 35 online marketplaces. They found that only 58% of the reviewed listings showed manufacturer details, the EU responsible person, and product identification at the same time, and they sent 560 orders to marketplaces over non-compliant listings.

42% of the listings EU authorities checked in 2026 still missed part of the basic product details the GPSR requires.

The missing data usually exists somewhere in the company. The importer's address sits in the purchasing system. The warning text sits in a PDF manual. Neither reached the fields a marketplace reads.

The fix is structural. Store the manufacturer and the responsible person as records of their own, with postal address and email, and link products to them. When an importer changes, one record changes and every linked listing updates on the next export. Warnings belong in a localized attribute with an owner and an approval step. A product should not be publishable to a channel in a given country until the warning text exists in that country's language.

The Digital Product Passport adds a second layer. On 20 July 2026, the European Commission launched the Digital Product Passport registry together with a testing environment. The registry stores unique product identifiers and metadata. The passport data itself stays decentralized, hosted by the economic operator or a service provider. Operators register each passport through a web interface or an API and can request an electronic proof of registration to show B2B partners. The first mandatory deadline is 18 February 2027 for certain large batteries. The registry is built to support textiles, steel and aluminium, tyres, furniture, ICT and energy-related products under the Ecodesign Regulation, plus batteries, construction products, toys, and detergents under other EU laws. Six harmonized standards are already available, covering unique identifiers, interoperability, data carriers, APIs, data exchange protocols, and data storage.

What a passport must contain is set by each product group's own legal act. For most groups, those texts are not final yet. So hard-coding a passport format today is a gamble. The prerequisites are safer bets: persistent identifiers at model, batch, or item level, material composition as structured attributes instead of text inside a PDF, versioned values with change history, and an API that can export a product's data in a schema you can still adjust.

AI Shopping Assistants Read Product Details Differently

Adobe, which measures more than 1 trillion visits to U.S. retail sites, reported that traffic from AI sources to U.S. retail sites grew 393% year over year in the first quarter of 2026. In March 2026, those visits converted 42% better than non-AI traffic. A year earlier, they had converted 38% worse.

The same report used Adobe's AI visibility checker to score how much page content large language models can read. Homepages averaged 75%. Individual product pages averaged 66%, the lowest of the page types Adobe listed.

About a third of what retailers publish on product pages is invisible to the AI systems that now recommend products.

The causes are mundane. Spec tables uploaded as images. Key facts buried in long marketing paragraphs. Variant data that loads only after a click. Units that differ between page and feed. Missing GTINs, which make it harder for any system to confirm that two listings describe the same product.

Machines work best with explicit attribute values, units, and identifiers that match everywhere the product appears. That means structured data markup on the product page (schema.org Product with GTIN, brand, price, and availability), feeds generated from the same values as the page, and spec tables in HTML instead of images. None of this is new. It matters more now that a growing share of shoppers arrives through a model that reads the page on their behalf.

Generative AI also writes product details now. Teams use it to draft descriptions, translate them, extract attributes from supplier PDFs, and fill empty fields. It drafts well. It also fills gaps with confident guesses. Ask a model for the battery capacity of a drill without a data sheet, and it returns a plausible number.

A plausible wrong value is worse than an empty field. Empty fields at least get noticed.

So mark AI-generated values with their source, keep them in a draft status, and require human approval for technical and compliance attribute groups. Style and length checks can run automatically. Fact checks need a person or a trusted source document.

How PIM Software Keeps Product Details Consistent

A PIM (product information management) system holds descriptive product data between the sources and the outputs. ERP, PLM, and supplier files feed it. Shops, marketplaces, print catalogs, and passport exports draw from it. The value sits in a set of concrete mechanisms.

Field Ownership Comes Before Integration

Each attribute gets one owner system. Price, stock, and logistics data stay in the ERP and flow outward. Descriptive attributes, translations, assets, and compliance texts are created in the PIM and never edited downstream. Integrations follow that map: one write direction per field, with no exception for quick fixes in the shop.

Our customers often turn to us after the shop has become a second master. Product managers correct texts in the shop admin, the next import overwrites them, and nobody can say which version is current. In projects we implemented, the turning point was a field ownership matrix agreed by product management, sales, e-commerce, and IT before any integration work started. After go-live, shop users lost write access to PIM-owned fields. The overwrite loop ended because only one system could write each value.

Typed Attributes And Classifications

In a spreadsheet, "230V", "230 V", "230 Volt", and "0.23 kV" are four different values. In a PIM, voltage is a numeric attribute with a unit. All four become one value, and filters and unit conversion for channels start working.

Attributes have types: numbers with units, lists from a controlled vocabulary, booleans, dates, multilingual text, rich text, and references to assets or other records. Classifications, also called families or product types, define which attributes each kind of product needs. A cable gets conductor cross-section and sheath material. A drill gets torque and chuck size. Neither carries the other's empty fields. Classifications can follow industry standards such as ETIM or ECLASS, which matters when wholesalers expect data in exactly that structure.

Variants And Inheritance

A T-shirt in six sizes and four colors is 24 SKUs that share one description. The PIM stores shared values on the parent product and only the differences on each variant: size, color, GTIN, and images. Change the care instructions once, and all 24 variants inherit the change. Overrides on individual variants stay intact.

Completeness Rules And Publishing Gates

Completeness turns "our data is bad" into a list of specific products and fields, sorted by the channel they block. These rules do most of the work:

• Required attributes per channel and per language. A product can be complete for the German shop and incomplete for a French marketplace, and the PIM shows which fields block which channel.
• Format checks, such as a valid GTIN check digit or a customs tariff code of the right length.
• Plausibility rules, such as a net weight that must stay below the gross weight.
• Controlled value lists, so "anthracite" and "dark grey" do not coexist as two separate colors.
• Publishing gates. A product without warnings or without a linked manufacturer record cannot be exported to a channel that requires them.

Workflows, Roles, And Change History

Product details pass through several hands: a supplier import, a product manager, a translator, a compliance reviewer. Workflows give each step a status and an owner. Roles restrict who edits which attribute group, so marketing can rewrite a description and cannot touch a warning text. Change history answers the question a market surveillance authority or an unhappy customer will eventually ask: which value was live on which date, and who set it.

Relations And Documents

Manufacturer, responsible person, accessories, spare parts, successor products, certificates, manuals, and declarations of conformity are records linked to products. One certificate can cover forty products. When it expires, a filter finds all forty. Images and documents sit in a DAM module attached to the same records, so the manual linked to a listing is the current revision.

Channel Mapping And Export

Each channel gets a mapping from PIM attributes to channel attributes, with value translation, unit conversion, and length limits. A marketplace that only accepts "Grey" receives "Grey" when the PIM holds "anthracite", while the own shop keeps the precise color name. Channel-specific values, such as a shorter title for a marketplace with a character limit, live as channel-level variations of the same product. Exports run through APIs or scheduled feeds, and the same data model also feeds print catalogs and passport data.

Supplier Onboarding

Supplier files land in a staging area first. Column mapping, unit normalization, value mapping, and duplicate checks are configured once per supplier and reused for every delivery. A comparison against the previous delivery shows only what changed, so a product manager reviews the changed values instead of rereading the whole file.

In projects we implemented for manufacturers selling through wholesalers, the bottleneck before the PIM was the wholesalers' own templates. Each wholesaler portal wanted a different file, and each file was filled by hand from the same Excel master. After the switch, those templates became export profiles fed by the classification data. New products reached the wholesaler portals in the same release cycle as the manufacturer's own shop.

AtroPIM, our open-source PIM built on the AtroCore platform, follows this approach. Classifications determine which attributes each product has, while channels store attribute values specific to each sales channel. On top of that, the platform provides validation rules, context-dependent mandatory fields, role-based access control, and a full change history. You can run it self-hosted or in the cloud, and it integrates with ERP systems, online shops, and marketplaces via its REST API and dedicated integration modules.

Trade-Offs Before You Start A PIM Project

A PIM needs a data model before it holds useful data. Modeling classifications and attributes for a broad catalog takes weeks of decisions from people who know the products, and those people are busy. Teams that skip this step move their spreadsheet chaos into a more expensive place.

Integration is usually the larger share of the work. ERP connectors and marketplace mappings carry most of the risk and most of the budget.

Over-modeling is a common failure. An attribute without a responsible person stays empty, and empty attributes drag completeness scores down until people stop looking at them. Start with the attributes that channels and regulators require, then add.

A PIM does not repair the ERP. If item numbers or units are wrong at the source, the PIM distributes the error to more channels, faster.

And a single shop with a few hundred products and one person maintaining them can live with the shop's own product admin. The case for a PIM grows with each added channel, language, product type, and editor.

Where To Start

1. List every product attribute you publish, the system it lives in, who edits it, and how often it changes. A spreadsheet is enough for this step.
2. Pick one product category and one channel with a visible problem, such as marketplace rejections or GPSR gaps.
3. Define the classification and required attributes for that category, with manufacturer and responsible person as linked records.
4. Set completeness rules for that channel and fix the data until the products pass.
5. Connect the channel export, then expand category by category.
6. Introduce AI drafting once approval workflows exist.