The file said 1.234,56. The import stored 1.23456 and called it a success.

A Dutch or German Excel writes one thousand two hundred thirty-four euros and fifty-six cents as 1.234,56. Until August 2026, our file import took the comma out of that value, sent 1.23456 to the database and called the import a success. The price was a thousand times too small. No cell turned red, and the log stayed empty.

We fixed it by refusing the value. Primentra now reads a number from a file in one format only, a dot for the decimal and no thousands separator, and it names the row when a value does not fit. A comma still works in two places. The reason it is safe there is the reason it is unsafe in a file.

One string, two numbers

In Amsterdam and Berlin, 1.234 is one thousand two hundred thirty-four. In London and New York it is one point two three four. A CSV file carries no flag that says which convention wrote it. RFC 4180, the closest thing CSV has to a standard, covers the commas between fields, the quotes and the line breaks. It says nothing about numbers.

So the program that reads the file picks a meaning, and each program picks its own:

// JavaScript
parseFloat('1,5')        // 1
parseFloat('1.234,56')   // 1.234

-- SQL Server
SELECT TRY_CAST('1234.56'  AS DECIMAL(22,10));  -- 1234.5600000000
SELECT TRY_CAST('1.234,56' AS DECIMAL(22,10));  -- NULL
SELECT TRY_CAST('1,234.56' AS DECIMAL(22,10));  -- NULL

parseFloat reads up to the first character it does not understand and returns what it has so far. It raises no error. A load script that leans on it turns 1,5 kg into 1 kg. SQL Server is stricter and refuses both grouped forms: TRY_CAST returns NULL, and a plain CAST stops with a conversion error.

Why Primentra does not guess

An import could study the whole column first. A value with both a dot and a comma gives the game away, because the last of the two marks the decimal. That rule works on a price list.

Now try a column of weights in kilograms, three places each: 1.250, 0.875, 2.500. Each value is valid in both conventions, and the two readings sit a factor of a thousand apart. The column holds no clue.

A guess that is right on nine files out of ten does its damage on the tenth. That file loads cleanly, and the wrong prices travel on to the ERP, the web shop and the invoices before anyone looks. A refused row costs you a minute. So Primentra reads what it can be sure of and refuses the rest.

A comma is fine when you see the result

A Dutch data steward does not have to retype every number. We drew the line at one question: do you see the value before Primentra saves it?

Type 3,14 in a cell and the screen shows 3.14. The comma is safe there because no route in Primentra accepts a thousands separator. 1.234,56, 1,234.56 and 1 234,56 are refused everywhere, the grid included. With grouping gone, a lone comma can only mean a decimal point.

A file gets no such help. An upload that holds 1234,56 stops at Preview, which names the row and says why. You choose whether the good rows go in without it, and that choice has its own post. The REST API gives the same refusal in one sentence:

"1234,56" is not a number. Use a dot for the decimal and no thousands separator.

The same text in two column types

The column type has a say as well. In a Decimal column, 1.234 is one and a bit, and Primentra stores 1.234. In a whole-number column the same five characters are refused, because there they could only mean one thousand two hundred thirty-four with a separator in it.

A whole-number column does take 1.0 and stores 1. Some systems export whole numbers that way, and 1.0 is a whole number. The Number formats page has the full table for each route and each type.

How the grid shows a number is a separate setting

Reading a number and showing it are two jobs. Under General Settings › Formats, Number Display sets how the grid draws Whole number and Decimal columns: Plain (1234567.89), English (1,234,567.89), European (1.234.567,89) or Space (1 234 567,89). Plain is the default.

The setting changes the screen and nothing else. An export under European display still writes 1234567.89, because somebody will import that file again, maybe in London. A column filter does follow the screen: under European display, type 1.234.567,89 in the filter and it finds the row.

A clean file from a Dutch or German Excel

1. Select the number columns. Open Format Cells, pick Number and clear Use 1000 Separator.
2. Or change Excel itself: File › Options › Advanced, clear Use system separators and set the decimal separator to a dot.
3. Save as CSV. Open the file in a text editor and look at one price. 1234.56 is ready. 1234,56 is not.

Then upload it and read the preview before you import. Import from Excel and CSV lists what a file must hold for each data type.

Test your own feeds with one bad row

Each feed that loads numbers into your master data has made this choice already, whether or not anybody decided it. Find out which choice yours made. Make a file with one row and put 1.234,56 in a price column. Send it through each route you have: the SSIS package, the staging table, the API client, the spreadsheet upload.

Two results are fine. The feed refuses the row with a reason, or the value arrives as 1234.56. Anything else is this bug: 1.23456, 1.234, 1 and an empty cell all mean the feed changed a number and told nobody.

Decimal places can fail in the same quiet way. We wrote up the time we offered ten places and stored six, with two queries to check your own columns.

Common questions