PIM, ecommerce and ERP: how to keep catalogue, pricing and stock consistent across every channel

The more sales channels you add, your own store, marketplaces, physical store, wholesalers, the more a problem shows up that starts small and ends up expensive: product information is not the same everywhere. A different description, an old image, a price that was not updated in one channel. The catalogue, which should be an asset, turns into a source of errors. Integrating a PIM (Product Information Management) with the ecommerce and the ERP solves that problem at the root, but only if it is clear what each system manages. This guide explains how to split those responsibilities and which flows to configure so catalogue, pricing and stock stay consistent without depending on someone updating each channel by hand.

Quick summary

• The PIM is the source of truth for how the product is described; the ERP, for what it costs and how many there are. Confusing those roles is the origin of most catalogue conflicts.
• A shared, stable SKU across all systems is the non-negotiable requirement of this architecture.
• Every marketplace demands its own format: format translation must live in the integration layer, not in the PIM or in each channel.
• Without a PIM, the cost of adding a channel grows in proportion to the size of the catalogue.

What a PIM solves that the ERP and the ecommerce cannot solve alone

The ERP is strong on transactional data: stock, costs, purchase prices, commercial terms. The ecommerce is strong at presenting the product to the customer and converting. Neither is designed to manage dozens of product attributes, variants, technical specifications, images, copy per language or per channel, rich content, in a centralised way and with quality control. The PIM takes that place: it is the single source of truth for everything that describes the product, while the ERP remains the source of truth for stock, costs and transactional prices. There is a less discussed and very valuable function: the PIM makes it possible to measure catalogue completeness. Knowing that 400 products are published without a secondary image, or that 120 have no technical specifications loaded, is actionable information that no ERP delivers and that directly affects conversion and the organic ranking of product pages.

How to split responsibilities across the three systems

Data	Source of truth	Who consumes it
Name, description, attributes, variants	PIM	Ecommerce, marketplaces, print catalogues
Images and media per channel	PIM or DAM	Ecommerce, marketplaces
Category and commercial taxonomy	PIM	Ecommerce, marketplaces
SKU, EAN/UPC	ERP	Everyone
Cost and base price	ERP	Ecommerce, POS
Price lists and terms	ERP	Ecommerce, POS, B2B portal
Available stock per warehouse	ERP or WMS	Ecommerce, marketplaces, POS
SEO content per channel	PIM	Ecommerce

The rule that prevents most conflicts: no data point has two owners. If the price can be edited both in the ERP and in the ecommerce, sooner or later both will be edited, and the last sync will overwrite someone’s work.

What data should be synced and how often

• Product attributes: name, description, category, specifications, variants (size, colour, format). Batch sync; descriptive changes do not need real time.
• Images and media: including channel- or marketplace-specific versions, which usually have different size and background requirements.
• Base prices and commercial price lists: originated in the ERP and distributed to the channels, with latency of minutes.
• Available stock per channel: in near real time, to avoid publishing products with no availability.
• Unique identifiers: SKU and EAN/UPC consistent across all systems, with no formatting or capitalisation variations.
• Publication status: which product is published in which channel, a decision better centralised in the PIM instead of repeated by hand in each platform.

Typical problems of a catalogue without centralised integration

The half-updated product. The description is corrected in the ERP, but the ecommerce and two marketplaces keep the previous version. The customer compares and finds contradictory information from the same brand. One catalogue per channel. Each platform ends up with its own version, maintained by hand. Maintenance cost grows with the number of channels multiplied by the number of SKUs, which is exactly the worst possible curve. Identifier mapping errors. The internal SKU does not match the code each marketplace requires. Every mismatch generates a duplicate product, a rejected listing or a stock movement that lands in the wrong place. Delayed launches. Loading a new product into five channels, with five different formats, turns a launch into a project. In seasonal categories, that delay is lost sales outright. Badly modelled variants. When the ERP treats each size and colour combination as an independent product and the ecommerce groups them, the integration needs explicit grouping rules. Without them, phantom products and unsellable stock appear.

How to structure the integration without duplicating effort

The recommended order is clear:

1. The ERP manages costs, stock and base prices. It is the system with accounting control and it should not compete with anyone on that ground.
2. The PIM enriches and standardises descriptive information. That is where mandatory attributes are validated, completeness is controlled and content variants per channel are generated.
3. The integration layer translates. A layer such as Weavee’s Universal Connection takes the information from the PIM and the ERP and delivers it to each channel in the exact format it demands: marketplace-specific category names, units, image requirements, mandatory fields.
4. The channels only consume. Product data is not edited directly in the ecommerce or the marketplace, except for documented exceptions.

This avoids the most common and most expensive pattern: loading the same product information several times, in different formats, in every system where you sell. And it connects directly with the broader discipline of master data management, where the catalogue is just one of the entities to govern. In practice, the channel may be a store on VTEX or WooCommerce: the split of responsibilities between PIM, ERP and channel is the same.

When a PIM is not yet justified

It is worth saying, because not every operation needs one. A PIM contributes little when the catalogue is small and stable, there is a single sales channel, and there are few attributes per product. In that scenario, the ecommerce reasonably fulfils the role of descriptive repository. The conditions that do justify the investment, especially in combination: more than two sales channels with different formats, catalogues above a few thousand SKUs, high turnover of new products, selling in more than one language or country, or a team spending weekly hours loading the same product page into several platforms.

Frequently asked questions

What is the difference between a PIM and an ERP? The ERP manages the transactional operation of the product: cost, stock, purchasing, invoicing. The PIM manages the information that describes the product in order to sell it: attributes, copy, images, taxonomy and content per channel. They complement each other; they do not compete. Does a PIM replace the ecommerce catalogue? It does not replace it: it feeds it. The ecommerce still has its catalogue, but it stops being the place where information is edited, and becomes a reflection of what the PIM defines. Can you have a consistent catalogue without a PIM? Yes, if the catalogue is small and there are few channels. With a well-maintained ERP and an integration layer that distributes to each channel, it can hold up for quite a while. The PIM becomes necessary when content richness per product and the number of channels grow. What happens with product variants when integrating? It is the point that causes the most problems. You have to define explicitly how variants are modelled in each system and how they map to each other before syncing. Doing it afterwards means cleaning up duplicate products by hand. How long does it take to publish a new product with this architecture? It depends on content validation, not on the integration. Once the product meets the mandatory attributes in the PIM, its publication across all channels becomes automatic, and the time is measured in minutes instead of days.

Checklist to integrate your catalogue

• Is there a single source of truth for the product’s descriptive information?
• Are product identifiers (SKU, EAN) consistent across ERP, PIM and all channels?
• Is it defined which attributes are mandatory before publishing a product?
• Does a price or stock change in the ERP get reflected automatically in every channel?
• Are variants modelled and mapped explicitly between systems?
• Does adding a new channel or marketplace require loading the catalogue by hand again?
• Is there traceability of when and where each product data point was updated?

You may also be interested in reading: • “How to integrate POS, ecommerce and ERP without breaking inventory, pricing or invoicing” • “Master data in ecommerce: what it is and how to integrate it for AI, reporting and automation” • “How to integrate Odoo with WooCommerce without duplicating products, orders or customers” With Weavee you connect your PIM, your ERP and every sales channel in a single flow, with format translation resolved in the integration layer, so the catalogue is updated once and reflected the same way everywhere.