How to Manage Supplier Product Feeds?
How to manage supplier product feeds so that the webshop, inventory, and sales work securely from the same verified data.
Short Answer
Effectively manage supplier product feeds to ensure your webshop, inventory, and sales are based on the same verified data.
In an online store, a product is available in the morning, the supplier discontinues it by noon, and an order arrives for it in the afternoon. Customer service is making excuses, procurement is looking for alternatives, finance is canceling, and the warehouse is trying to identify an item number that appears in different statuses across multiple systems. In such cases, it's not just a product data problem. The flow of information is not under control.
The question is not just how to technically handle supplier product feeds. First, it is necessary to clarify what business decisions are built on this data, who is responsible for it, and what happens when the supplier's data source is incomplete, delayed, or incorrect.
A product feed is not just an import file
A supplier feed can be a CSV, XML, Excel file, API connection, or even a regularly received email attachment. It may contain product name, item number, price, stock, description, image, category, and shipping information. However, the technical format is just the surface.
The real question is what changes in the company's operations after the data is entered. Does the price automatically update on the webshop? Can the new product appear immediately? Does the offer disappear if the stock is set to zero? Can the supplier's item number be reliably linked to the product used in the company's ERP, warehouse system, or invoicing?
For many growing retailers, managing feeds becomes difficult because they originally developed a working routine for a single supplier and a few hundred products. Later, data comes from five, ten, or twenty sources, with different structures and update frequencies. The old routine then often requires more and more manual checks, spreadsheets, and exception handling.
First, map the data's journey
Before considering new integration, PIM system, or automation, it is worth tracing the path of a specific product data. For example: the supplier changes the purchase price, the data is entered into a file, someone downloads it, copies it into a spreadsheet, checks the percentage difference, and then uploads it to the webshop admin interface. After that, someone else modifies the ERP price, or perhaps does not modify it at all.
In this process, it usually quickly becomes visible where risks arise. Does the data exist in multiple places? Does an employee have the rule in mind for which margin to use for certain brands? Is there a supplier whose stock data is not considered reliable, yet it is automatically published? Who notices if the feed does not arrive one day?
Not every manual step is bad. Approving a new, strategically important product can be a conscious commercial decision. Investigating an unusually large price movement may also be justified. The problem begins when human attention is consumed by repetitive tasks like comparing columns, renaming files, or searching for errors, leaving little time for exceptions and decisions.
Without an identifier, there is no reliable connection
One of the most common hidden errors in product feeds is identification. The supplier's item number, the manufacturer's item number, the EAN code, the webshop's internal identifier, and the ERP product code do not always match. A product may have multiple versions, packages, or colors, which appear as separate rows in one feed and as a main product and variant relationship in another system.
If there is no clear matching rule, the system may update the price or stock for the wrong product. Even worse, it may quietly create a new product because it cannot find the existing one. Within a few weeks, duplicate product cards, differing stock values, and uncertain reports may arise.
Therefore, it is worth defining the primary identifier for each source, as well as the supplementary fields that can be used to verify the match. The EAN is often a good starting point, but it is not a universal solution: it may be missing, incorrect, or not adequately distinguish between variants.
How to manage supplier product feeds with rules?
Good feed management does not start by immediately passing everything from the supplier to the webshop. Supplier data is external data. It is useful, but not automatically reliable and does not necessarily fit the company's own business logic.
Therefore, the company needs clear rules. Which fields can come directly from the supplier? Which data is managed by the internal team, such as product description, category, or marketing name? What price changes can be published automatically, and what deviations require approval? What should happen if the stock is unknown, not zero?
The rules do not have to be overly complicated, but they must be documented and consistent. A well-defined process can, for example, separate the creation of new products, the updating of existing products, and the handling of faulty records. This way, a missing price or image does not halt the entire process, but neither does it go unnoticed by customers.
Stock and price are not the same data
Stock data often has a different rhythm and business significance than product descriptions. A weekly update of a description usually does not cause problems. However, a daily or hourly delay in the stock of a fast-selling product can directly affect order fulfillment.
The same applies to prices. A supplier may change the purchase price, but the company's own selling price must consider the margin, promotions, shipping costs, contractual terms, and sometimes market position. Therefore, updating the supplier's price does not necessarily mean an immediate price change on the webshop.
It is also worth handling availability separately. "In stock" can mean that the product is truly immediately deliverable, but it can also mean that it is theoretically available in the supplier's external warehouse. If these statuses are simplified to a single yes-no field, the delivery time promised to the customer can easily become inaccurate.
Without validation and exception handling, errors scale
When a person uploads products, they instinctively notice many errors. They notice the zero price, the tenfold stock, or the missing category. In automated processing, this business control must be replaced with rules.
Validation can check, for example, whether an item number is mandatory, whether there is a valid price, whether the stock has changed unrealistically, or whether the new product meets the publication criteria. The goal is not to prevent every deviation. The goal is for the system to distinguish between normal changes and events that require investigation.
Exceptions should be displayed in a worklist that clearly shows what happened, why the record stopped, and who needs to make a decision about it. If error notifications only go to a general technical email address or remain in a single colleague's inbox, the process remains dependent on individuals.
Observability is also necessary for operation. It should be visible when the feed last arrived, how many records were processed, how many products were updated, how many were exceptions, and what discrepancies are recurring. These numbers are not IT decorations. For commercial and operational leaders, they indicate whether the product offering that sales rely on is reliable.
Do not treat it as a single large project
When multiple suppliers, webshops, ERP, and warehouse processes are interconnected, it can be tempting to redesign everything at once. This is often too risky. It is more advisable to start where the most manual work, order errors, or business uncertainty arises.
The first fix may be as simple as standardizing item number matches and creating daily reports on failed imports. In other cases, a stable integration between the supplier, product data management, and webshop may be justified. If product data goes to multiple channels with many exceptions and rich content, a separate central product data management layer may also be justified.
The right solution depends on how many data sources there are, how quickly the data changes, the size of the product range, and the business damage caused by an error. Not every company needs the same system. But every company needs to know where each data comes from, what rule it is modified by, and who is responsible for exceptions.
A well-managed supplier feed is ultimately valuable not because fewer files need to be opened. It is valuable because sales, the warehouse, and customer service can work from the same more reliable picture, while people's attention can focus on real business decisions instead of copying.
Planning a similar system or integration?
Show us the current process and systems. We will help identify the lowest-risk next step.
Key Takeaways
- Ensure all systems use the same verified data for consistency.
- Supplier data is external and should be verified before use.
- Align supplier data with your business logic for optimal results.
Frequently Asked Questions
How do we manage supplier product feeds with rules?
Effective feed management doesn't start by passing everything from the supplier to the webshop immediately. Supplier data is external, useful but not automatically reliable, and may not fit your business logic.
Related Engineering Insights
Who is Responsible for Data Quality in System Integration?
Who is responsible for data quality in system integration? The answer is not a single role: it requires clear responsibility, process, and control.
B2B Client Portal Design Guide in 8 Decisions
B2B client portal design guide for growing companies: processes, permissions, and integrations for reduced administration and improved corporate operations.
Industrial Data Collection System Guide for Factories
Industrial data collection system guide for managers: what to measure, how to start, and how data can lead to better decisions in the factory.