The same sofa is wrong in three channels in three different ways. On Google Shopping it is rejected because the colour “antraciet / anthracite / donkergrijs” is used interchangeably and the GTIN is missing. On Amazon a header row invalid because the file was saved as a comma CSV instead of a tab TSV. On Bol an offer that never goes live because the EAN is not registered with GS1.
Three channels, three formats, three error messages, and beneath all that noise exactly one cause: you are pushing messy source data straight into systems that each impose their own strict requirements. The reflex is to build an export per channel and patch the errors one by one. That works, until your supplier changes something. Whoever turns it around starts not with the feed but with the catalogue.
Why “just export a feed” almost always goes wrong
A feed is not a file you build once. It is a contract with three parties who each want something different and who regularly change that contract unilaterally. Bol wants a registered EAN, Amazon wants the latest category template, Google wants the final price including VAT. As long as you export from your raw source data, you are simply moving the mess outward and letting Bol, Amazon and Google check your data quality. That is an expensive place to discover your mistakes.
Three channels, three formats
Start with the most basic point: the same product has to fit into three completely different files. Google Shopping works with XML (or a Merchant Center feed). Amazon works with tab-separated flat files, TSV, saved as UTF-8. Accidentally save such an Amazon file as a comma CSV and the header corrupts, giving you the notorious error that the header row is missing or invalid (source: Amazon Seller University / FlatFilePro). Bol product feeds are delivered as a text file with the pipe character (|) as the separator, with a maximum of 10 MB per file (source: Bol.com affiliate product feed guide).
// Bol -- pipe-separated text (CSV)EAN|title|price|stock|image8712345678901|Lounge sofa Faro antraciet|649.00|12|https://cdn/faro-1.webp// Amazon -- tab-separated (TSV), UTF-8sku item_name standard_price quantity main_image_urlFARO-ANTR Lounge sofa Faro antraciet 649.00 12 https://cdn/faro-1.webp// Google Shopping -- XML<item><g:id>FARO-ANTR</g:id><g:title>Lounge sofa Faro antraciet</g:title><g:price>649.00 EUR</g:price><g:gtin>8712345678901</g:gtin><g:availability>in_stock</g:availability></item>
One product, three file formats. And this is before you even get to the required fields.
Different fields, different rules
The format is the easy part. The real pain sits in what each channel makes mandatory, and those lists overlap but never cover each other.
Google Shopping has eight universally required attributes for every product: id, title, description, link, image_link, price, availability and condition (plus brand for branded products). Source: Google Merchant Center Help, product data specification. The title may be at most 150 characters, the description at most 5,000, and the price must be the final consumer price including VAT, the price the buyer pays at checkout. Sell clothing, shoes or accessories and four more required fields appear: color, size, gender and age_group. Miss one and the product is rejected.
GTIN is mandatory at Google for every product for which the manufacturer has assigned one. Fail to supply it and you risk rejection. Only genuinely handmade, custom or vintage items without an identifier may use identifier_exists=false; for branded products without a GTIN, Google requires the combination brand + mpn. A rejected product does not appear in Shopping, and reprocessing after correction typically takes 24 to 72 hours (source: Google Merchant Center / FeedOn.ai).
Amazon works with category-specific flat file templates. The required fields differ by product type, by marketplace and sometimes between creating a new ASIN and updating an existing one. Core fields include sku, product-id, product-id-type, item_name, brand_name, manufacturer, standard_price, quantity and main_image_url, plus the category-specific fields (source: ClearAds / WISEPIM). The sting: at Amazon an empty required field leads to rejection of the entire file, not just that one row (source: LitCommerce / StoreAutomator).
Bol is stricter on identifiers than the rest. Every item needs a valid, registered EAN, GTIN or ISBN; for branded products an EAN registered with GS1 is mandatory. A range with a code that is not GS1-registered can be taken offline by Bol (source: Bol Partnerplatform). The basic information consists at minimum of EAN, title and at least one image.
The hidden cost: tinkering again for every channel
Most shops solve this with a separate export per channel and a stack of manual patches. Rename a column for Amazon, a little script that adds the VAT for Google, a filter that keeps products without an EAN out of the Bol feed. That is exactly the kind of work that looks like an afternoon and becomes a permanent chore. Because the moment your supplier changes a column name, introduces a new spelling for a colour or Amazon updates its template, the chain breaks and the patching starts all over again.
- A separate export per channel with its own columns and scripts
- Adding VAT by hand, cleaning up colours, filtering out empty fields
- A supplier changes one column name and three feeds break at once
- Errors only surface in the dashboard of Bol, Amazon or Google
- A clean catalogue as source, an automatic projection per channel
- Normalised values and golden records, so cleaning happens once
- Change the source and every channel follows without a rebuild
- Quality gates catch the error inside, before a channel rejects it
The reversal: start with a clean catalogue, not with the feed
The real solution is not “build a feed per channel” but a clean catalogue as source, from which the system automatically derives the right fields in the right format per channel. Channel-specific then becomes a projection of your data instead of loose manual work. You maintain one truth, and Bol, Amazon and Google each receive their own tidy slice of it.
You do not build three feeds. You build a clean catalogue and let three channels read their own slice out of it.
Golden record and normalised values
Feeds are rejected on exactly two things: missing identifiers and inconsistent values. You fix both at the source. Sources are merged and deduplicated on SKU, EAN and barcode, enriched with AI, into a golden record with provenance per field. And spellings are normalised: 47 colour variants back to your 12, purple, lilac and violet all to “Purple”, antraciet and anthracite to one value. That is exactly what prevents a Google rejection on color.
color Antraciet (1 of your 12 spellings)ean 8712345678901 (GS1-registered)price 649.00 (incl. 21% VAT)title Lounge sofa Faro antraciet (3-seat)// all three channels accept this
Click to toggle. The same sofa, cleaned up to one truth.
An automatic projection per channel
From that golden record the system sends exactly the right fields in the right format per channel: Bol.com as CSV, Amazon as TSV, Google Shopping as XML and Vergelijk.nl as XML. And, important for calm in your chain: only changes are sent. A price change on one product does not push your entire range out again. For WooCommerce and Magento there is also a direct integration that is live, so with realtime connections to webshop and marketplace you close the nightly export window entirely. See the integrations and feeds per channel for which channels go out.
Setting up those fields per channel is done with ready-made automations without code: building blocks that map a master field to the right channel column, add the VAT or derive a category, without you having to write a script for it.
Quality gates: stopping errors before they go out
The cheapest place to find a feed error is before it reaches Bol, Amazon or Google. Quality gates hold back anomalies: a duplicate SKU, an unusual price or stock jump, a mass deletion. You set the strictness yourself: pass through automatically, review as it goes, or have everything approved first. Every push takes a snapshot beforehand, so you can roll back in one click if something odd slips through after all.
Product feed management in practice: how to set this up
On a good network connection SyncRefine processes up to roughly 100,000 products in around 10 minutes (with that caveat), and AI can translate into 42 languages and derive attributes. Let us be honest, though: the AI learns your structure, not your tone of voice, and photos are converted to WebP at the right size, without background removal, watermarking or upscaling.
- Bol, Amazon and Google each ask for a different format: pipe CSV, tab TSV and XML, with their own required fields.
- Feeds are mostly rejected on missing identifiers (GTIN/EAN) and inconsistent values such as colour, and you fix both at the source.
- Do not build a feed per channel, but a clean catalogue as source from which each channel gets an automatic projection.
- Quality gates and a snapshot per push catch the error inside, before Bol, Amazon or Google finds it for you.
