Why Does Every Retailer Want Product Data in a Different Format?
Why the same furniture range has to be reshaped for each retailer, and how manufacturers can stop rebuilding it from scratch.
The retailer is asking about the same sofa. It just does not look that way from the spreadsheet.
One template wants width, depth and height in separate columns. Another asks for a single dimensions field. One needs packaged measurements and carton count. Another needs room type, assembly information, care instructions and image links in a particular order.
The facts have not changed. The retailer's operating model has.
Retailers use product data for different jobs
A product submission may feed a website, warehouse, delivery planner, store system, search filter and customer service team. Each retailer gives more weight to the fields its business depends on.
A direct-to-consumer retailer shipping furniture from a supplier needs carton-level weights and dimensions. A showroom-led retailer may care more about collection, material and configurable options. A marketplace needs attributes that fit its category filters and validation rules.
Published retailer guidance shows how detailed this can become. Nebraska Furniture Mart asks direct-to-customer vendors for carton count, weight and dimensions for each carton, alongside specific image and content requirements.[1]
These requests are not arbitrary formatting preferences. They are inputs to different processes.
Standards help, but they do not create one universal template
There are established ways to exchange commercial product information. UN/EDIFACT includes the PRICAT product price catalog message, for example.[2] Retailers and suppliers also use portals, spreadsheets, APIs and sector-specific standards.
None of that means there is one furniture template accepted by every retailer.
Even when two businesses use the same transport method, they may define categories differently, require different fields or apply different validation rules. "Material" may be free text in one destination and a controlled list in another. A sectional may be one product with variants in one system and several separate products in another.
That is why the work cannot be solved by finding the perfect master spreadsheet.
The expensive part is rebuilding the facts
Every retailer needs some transformation. The waste appears when the team recreates the source information for every submission.
That usually looks like this:
- Copy the previous retailer file.
- Add the new products.
- Rewrite or split fields to fit the template.
- Search shared folders for image links.
- Correct errors after validation.
- Repeat the same changes in another file next month.
Over time, each submission becomes its own version of the catalog. A correction to dimensions or a discontinued finish has to be found and changed in several places. Nobody is quite sure which file contains the latest approved facts.
Keep one complete record, then map it
The practical answer is not to force every retailer to accept your format. It is to separate source information from destination formatting.
Your source record should hold the most complete approved version of the product and its variants. Keep individual facts in individual fields: assembled dimensions, packaged dimensions, materials, finishes, carton count, care information and so on.
For distributors, add Supplier and Supplier SKU as attributes on each product, kept separate from your own SKU. That preserves the relationship without pretending those fields appear automatically in every system.
Each retailer then gets a mapping from your fields to theirs. If one asks for Product Width and another asks for Width (cm), both can come from the same approved source field. If a destination needs a combined dimensions sentence, create it from the component measurements rather than storing a second hand-written version.
Treat each retailer format as a maintained view
A mapping needs an owner and a revision date. Retailer templates change. New mandatory fields appear. Category values are renamed. A file that worked last season may fail this season.
For each destination, record:
- The current template or specification
- Required and optional fields
- Accepted values and units
- Image and document requirements
- The last successful submission
- Any transformations or exceptions
Then test a small group of products before sending the whole range. The aim is not zero retailer-specific work. It is to solve each requirement once and reuse the decision.
The useful distinction
There are two separate questions:
- Do we have the complete, correct product facts?
- Can we deliver them in the shape this retailer accepts?
When those questions are mixed together, every failed submission looks like missing product data. When they are separated, the team can see whether it needs to improve the source record or repair the destination mapping.
That is how a retailer-specific request becomes a repeatable process instead of another spreadsheet rebuild.
For the mechanics of moving and updating the content, read How Furniture Product Content Reaches Retailers. Distributors carrying several suppliers into the same templates should also read why distributors struggle with product content.
Frequently asked questions
Why does every retailer want product data in a different format?
Because a product submission feeds a website, warehouse, delivery planner, store system, search filter and customer service team, and each retailer weights the fields its own business depends on. A direct-to-consumer retailer needs carton-level weights and dimensions; a showroom-led retailer cares more about collection, material and configurable options; a marketplace needs attributes that fit its category filters and validation rules.
Is there a standard furniture product data template?
No. There are established ways to exchange commercial product information — UN/EDIFACT includes the PRICAT product price catalog message, and retailers also use portals, spreadsheets and APIs — but none of that produces one furniture template accepted by every retailer. Even on the same transport, two businesses may define categories differently, require different fields or apply different validation rules.
How do you stop rebuilding product data for each retailer?
Separate source information from destination formatting. Keep one complete approved record with individual facts in individual fields — assembled dimensions, packaged dimensions, materials, finishes, carton count, care information — then give each retailer a mapping from your fields to theirs. Derive combined fields, such as a dimensions sentence, from the component measurements rather than storing a second hand-written version.
What should you record for each retailer format?
The current template or specification, required and optional fields, accepted values and units, image and document requirements, the last successful submission, and any transformations or exceptions. Give the mapping an owner and a revision date, then test a small group of products before sending the whole range.
