1,234.50 becomes 1.23: the number format that quietly breaks your prices
A European-formatted price flows through an automation into a system that reads the dot as a decimal point, and the item suddenly costs a fraction of what it should. Why commas and dots break numbers between systems, and how to stop it at the boundary.
The automation was green all night. It also sold a €1,234 item for €1.23.
A wholesaler called us one Monday, rattled. Six hundred orders had come in overnight, all for the same product, all at a price that made no sense. An item that should list at €1,234.50 had been sitting in the shop at €1.23. Customers had bought by the pallet. Some of it was already picked and packed.
Nothing had failed. The automation that pushed prices from the ERP into the webshop had run cleanly every night, no error, no red step, no alert. It did exactly what it was built to do, with a number that had quietly lost its meaning somewhere between two systems.
How a thousand turns into one
This is the boring, expensive detail that trips up cross-border and cross-tool automations: not every system agrees on what a dot means. In much of Europe, the dot groups thousands and the comma marks the decimal, so 1.234,50 is one thousand two hundred thirty-four and a half. In the English-speaking convention it is reversed, and the same amount reads 1,234.50.
The damage happens the moment your automation hands a number over as text. The source system emits "1.234,50", formatted for a German screen. The receiving system expects a decimal point. Its parser reads left to right, treats the dot as the decimal separator, and stops at the comma. What survives is 1.234, which rounds to 1.23. No system objected, because from a machine's point of view nothing was wrong. A valid number went in, a valid number came out.
It fails in the other direction too. Feed 1,234.50 into a parser that assumes European formatting and you can end up with 1234.50, or with an order of magnitude that has nothing to do with reality.
It is rarely just prices
In wholesale and logistics, almost every field is a number with a separator. Weights, quantities, volumes, discount rates, invoice totals. A pallet of 1,500 kilograms becomes 1.5 kilograms when the grouping separator is misread. An order of 2,000 units collapses to 2. These are the worst kind of error because the result almost always looks plausible. €1.23 is a price you could, in principle, charge. Nobody flinches at the number on its own.
Where it sneaks in
The problem almost always lives at a handoff, where a text field meets a number field. In Make or n8n, one module pulls a value out of the source and drops it into the target, and the mapping quietly carries "1.234,50" as a string that the receiving system then interprets by its own rules. It loves CSV exports out of an ERP, values that have passed through Excel, and APIs that return amounts as strings instead of numbers. Excel is an amplifier all its own, because it formats numbers according to the machine's regional settings. The same export looks one way on the finance team's laptop and another way on the laptop of whoever set up the automation.
The log never mentions it
That is the real reason this class of bug survives so long. There is no crash to debug. The automation reports success, every run is green, every step content. The problem only becomes visible when a human notices an odd figure, or a customer places an order that is too good to pass up. By then, depending on volume, hours or days have gone by.
It is also why these bugs sail through testing. Test with a clean 5 or a round 99 and you will never see it, because those numbers carry no separator at all. The values that expose the problem are the awkward ones, with a grouping mark and a decimal.
How we keep it out
Four habits, none of them heavy.
Never move a number between systems as display-formatted text. An amount is a number, not a string full of dots and commas. Formatting for humans belongs at the very end of the chain, not in the middle of it.
Parse deliberately instead of trusting the target's auto-detection. When you have to accept a locale-formatted value, strip the grouping separator first, then swap the decimal comma for a dot, then convert. Three small steps that turn 1.234,50 into 1234.5 every time.
Where you can, carry numbers as actual numbers, not strings. Plenty of APIs accept both, and the numeric path leaves no room for interpretation.
Add one cheap sanity check. A price that suddenly drops below a floor, or a quantity that jumps far above the norm, should hold the record and flag it for review. A few minutes of setup buys you protection against exactly the night that cost this wholesaler six hundred bad orders.
What I took from it
A number that looks right to a machine and a number that looks right to a person are two different things. The gap between them is precisely where money leaks out unnoticed.
If you run an automation that moves prices, quantities, or amounts between two systems, test it once with a genuinely awkward value. Use 1,234.50, not the tidy 100. If the same amount arrives at the other end, you are fine. If something else shows up, you now know where your next expensive misunderstanding is waiting.