CSV data quality
Why CSV Decimal Numbers Change—and How to Fix Separators Safely
Decimal values usually change after CSV import because the source and receiving tools interpret . and , differently. A value such as 1,234.56 may mean one thousand two hundred thirty-four point five six, while 1.234,56 represents the same amount under another convention. CSV stores characters and separators, not a universal numeric locale. Keep the original file, identify the source convention and field delimiter, inspect raw values, import with an explicit locale when the tool supports it, and compare row counts, sample values, sums, minimums, and maximums before using the data. Do not fix the file with a global character replacement until quoting, grouping separators, decimal precision, and mixed-format rows have been checked.
Short answer
Decimal values usually change after CSV import because the source and receiving tools interpret . and , differently. A value such as 1,234.56 may mean one thousand two hundred thirty-four point five six, while 1.234,56 represents the same amount under another convention. CSV stores characters and separators, not a universal numeric locale. Keep the original file, identify the source convention and field delimiter, inspect raw values, import with an explicit locale when the tool supports it, and compare row counts, sample values, sums, minimums, and maximums before using the data. Do not fix the file with a global character replacement until quoting, grouping separators, decimal precision, and mixed-format rows have been checked.
Upload
Bring the CSV you already use.
Understand
Start with the brief and evidence.
Act
Ask, edit, filter, and export.
A practical starting point
Decimal values usually change after CSV import because the source and receiving tools interpret . and , differently. A value such as 1,234.56 may mean one thousand two hundred thirty-four point five six, while 1.234,56 represents the same amount under another convention. CSV stores characters and separators, not a universal numeric locale. Keep the original file, identify the source convention and field delimiter, inspect raw values, import with an explicit locale when the tool supports it, and compare row counts, sample values, sums, minimums, and maximums before using the data. Do not fix the file with a global character replacement until quoting, grouping separators, decimal precision, and mixed-format rows have been checked.
Concrete examples
Example 1: European-style sales values import as text
A sales column contains 1.234,56, 245,00, and 19,95. A tool expecting decimal points does not recognize the values consistently, so the chart omits them. The reviewer confirms the source convention, imports with the matching locale, and validates the corrected sum against the source report.
Example 2: A decimal comma collides with a comma delimiter
The intended row is SKU-7,12,50,3, where 12,50 was meant to be one price. Without quotes, the row has four fields rather than three. The source export must emit a valid boundary such as SKU-7,"12,50",3 or use a documented alternative delimiter. Joining the two middle cells by guesswork could hide a broader export fault.
Example 3: A grouping mark is mistaken for a decimal mark
An inventory value 1,250 means 1,250 units in the source system, but an import rule treats it as 1.25. The total looks numerically valid but is one thousand times too small. A known stock record and a range check expose the error before the dashboard is shared.
Example 4: Mixed supplier conventions require row-level review
A procurement file combines 2,450.75 from one supplier and 2.450,75 from another. Applying one replacement rule damages one group. The team keeps the original strings, tags each source, parses by confirmed supplier convention, and flags rows with unknown provenance.
Example 5: A numeric-looking identifier must not be normalized
A column named InvoiceID contains 1.234.567. It may be a formatted number or an identifier containing punctuation. The reviewer checks the source schema before stripping separators; arithmetic is not meaningful for an identifier, and changing it could break lookups.
Examples are illustrative and are not customer results.
Common questions
What is the safest way to work with this CSV problem?
Decimal values usually change after CSV import because the source and receiving tools interpret . and , differently. A value such as 1,234.56 may mean one thousand two hundred thirty-four point five six, while 1.234,56 represents the same amount under another convention. CSV stores characters and separators, not a universal numeric locale. Keep the original file, identify the source convention and field delimiter, inspect raw values, import with an explicit locale when the tool supports it, and compare row counts, sample values, sums, minimums, and maximums before using the data. Do not fix the file with a global character replacement until quoting, grouping separators, decimal precision, and mixed-format rows have been checked.
Keep exploring
See what your own CSV is saying.
Try the browser workspace with a real file and keep the public guide open when you need help.
Start free