How to Fix bol.com Listing Errors in Bulk

You uploaded an offer file or product content template to bol.com, and instead of hundreds of live listings you got hundreds of errors. The instinct is to fix them row by row, which turns a ten-minute upload into a two-day slog. The better move: recognize that bulk listing errors come in classes, and each class has one root cause that you can fix across the entire file in a single operation. Fix the EAN column once and three hundred EAN errors disappear together.

This guide walks through the failure classes that account for nearly every rejected bol.com bulk upload: EAN problems (mostly Excel's fault), missing required attributes, price and stock formatting, encoding of Dutch characters, and header mismatches against the template. For each, you get the diagnosis and the bulk fix, in your spreadsheet or with a cleaning pipeline, plus a pre-upload checklist that catches the whole list before bol.com does.

How bulk listing on bol.com works (and why files get rejected)

Selling in volume on bol.com runs on file uploads through your seller account: product content goes up via category-specific templates that define which attributes a product needs, and offers (your price, stock, and delivery promise for a product) go up via offer files. Everything hangs off the EAN: bol.com's catalog matches your rows to products by their EAN barcode, so a row whose EAN is malformed cannot be matched to anything, no matter how perfect the rest of the row is.

When bol.com processes your upload, it validates each row against the template's expectations: is the EAN a valid barcode, are the required attributes for this category filled, are prices and stock in the expected format, do the columns match the template? Rows that fail come back as errors. The crucial insight for bulk fixing: the validation is per-row, but the causes are per-column. Three hundred rows failing on EAN is not three hundred problems; it is one column-level problem that Excel probably created.

Failure class 1: EAN problems (usually Excel's doing)

EANs are 13-digit (sometimes 8-digit) barcodes, and the single most destructive thing you can do to a column of them is open the file in Excel. Excel sees digits and helpfully treats them as numbers, which mangles them in two ways.

Leading zeros stripped

An EAN starting with 0 becomes a 12-digit number the moment Excel parses it: 0012345678905 turns into 12345678905, and bol.com rejects it as invalid or matches nothing. Once stripped, the zeros are gone from the saved file; no display format brings them back after a save-as-CSV.

Scientific notation

Thirteen digits exceeds Excel's default display width for numbers, so EANs render, and then save to CSV, as scientific notation: 8712345678906 becomes 8.71235E+12. The saved text '8.71235E+12' is not a barcode, and every such row fails.

What Excel does to an EAN column:

  Original EAN      After Excel round-trip
  0012345678905  -> 12345678905        (leading zero gone)
  8712345678906  -> 8.71235E+12        (scientific notation)
  8712345678913  -> 8712345678913     (looks fine... this time)

Both corrupted forms are rejected. The fix must happen BEFORE
Excel parses the column as numbers, not after saving.

The bulk fix is to force the EAN column to be text before Excel ever interprets it. Do not double-click the CSV to open it; instead use Data > From Text/CSV (or the legacy Text Import Wizard) and set the EAN column's type to Text during import. In Google Sheets, File > Import with 'Convert text to numbers, dates and formulas' turned off achieves the same. If the damage is already saved, you need to re-export the EANs from your source system; scientific notation in a saved CSV has permanently discarded digits (the notation rounds), so reconstructing them by formatting alone is not reliable.

Two more EAN checks worth running in bulk: length (every EAN should be exactly 13 digits, or 8 for EAN-8; anything else fails) and stray characters (spaces, hyphens, or an apostrophe prefix picked up along the way). A regex find and replace that strips every non-digit from the column, followed by a length check, catches both.

Failure class 2: missing required attributes

bol.com's product templates are category-specific: the template for toys demands different attributes than the one for electronics, and some fields that are optional in one category are mandatory in another. A batch of rows failing with missing-attribute errors usually means one of two things: you used a template from the wrong category (or an outdated version of the right one), or your source data genuinely has gaps in a required column.

For the first cause, re-download the current template for the correct category from your seller account and rebuild against it; templates change, and last year's file can silently miss a newly required column. For genuine gaps, filter the required column for blanks to see the damage in one view. Watch for pseudo-blanks: cells containing 'N/A', 'NULL', '-', or a lone space are not empty to your eye but do not contain valid attribute values either, and they hide from a blank filter. Standardize those variants to genuinely empty cells first, so filtering shows the true gap list, then fill the gaps from your source data.

Failure class 3: price and stock format problems

Price columns fail on format, not value. The classic trap for Dutch and Belgian sellers is decimal notation: locally you write 19,95, but a file's expected format may want a dot decimal, 19.95, and whichever convention your file uses, it must match what the template expects, consistently, in every row. A file where half the prices came from one system with commas and half from another with dots will fail on exactly one of the halves. Currency symbols and thousands separators are the other repeat offenders: a price cell should contain only the number ('19.95'), not '€ 19,95' or '1.204,50'.

Stock columns are simpler but fail the same way: whole numbers only, no thousands separators, no text like '10+' or 'op voorraad' pasted in from somewhere. The bulk fix for both is a pass of find and replace on the column: strip the euro sign and spaces, remove thousands separators, then convert the decimal separator to whichever one the template expects, in that order, so the thousands separator does not get confused with the decimal.

Failure class 4: encoding of Dutch characters

Dutch product content is full of characters that break on the wrong encoding: 'ë' in 'geïsoleerd' or 'België', 'é' in 'café', euro signs in descriptions. If your file is saved in a legacy encoding like Windows-1252 and read as UTF-8 (or vice versa), those characters turn into mojibake: 'België' becomes 'België'. Sometimes that garbage makes rows fail; worse, sometimes it uploads fine and your live listings display the garbage to customers.

Save as UTF-8 explicitly: in Excel, 'CSV UTF-8 (Comma delimited)' rather than the plain CSV option; from Google Sheets, downloads are always UTF-8. Then verify by opening the saved file in a text editor and finding a row you know contains an accented character; if you see the character itself and not a two-character garble, the encoding is right.

Failure class 5: header and column mismatches

Template-based validators match your columns to expected fields by header, and they are literal about it. A trailing space in a header, a renamed column ('Prijs' where the template says something else), a missing column, or columns in an order the parser does not expect can fail every row at once, which is actually good news: an upload where everything failed identically is nearly always a header or template-version problem, not a data problem. The fix: re-download the current template, and make your file's headers match it character for character, in the same order, with no extra columns appended on the right.

Fixing it all in bulk: spreadsheet + pipeline

In your spreadsheet, the sequence is: re-import the raw file with the EAN column forced to Text, fix headers against a fresh template, then run column-wide find and replace passes for prices, stock, and stray characters. That works, but it is manual, and next week's upload needs it all again.

A note on the preview step: before downloading, scan the EAN column specifically. Every value should be 13 digits (or 8), no 'E+' anywhere, leading zeros present where your source has them. Thirty seconds of eyeballing that one column prevents the most common re-upload cycle.

The pre-upload checklist

Bulk listing errors on bol.com look overwhelming because the error count scales with your row count, but the cause count does not. Almost every rejected batch traces back to the same short list: an EAN column that met Excel, a price column with the wrong decimal convention, a template that drifted, gaps in required attributes, or an encoding slip. Fix at the column level, keep a pipeline that applies the fixes automatically, send a small test batch first, and bulk uploads go back to being the time-saver they were supposed to be.