Aus 1.234,50 wird 1,23: das Zahlenformat, das Ihre Preise kippt
Ein deutscher Preis wandert per Automatisierung in ein System, das den Punkt als Dezimaltrennzeichen liest, und plötzlich kostet der Artikel einen Bruchteil. Warum Komma und Punkt zwischen zwei Systemen zum Problem werden und wie Sie es an der Grenze abfangen.
Ein Artikel für 1.234,50 Euro stand plötzlich für 1,23 Euro im Shop
An einem Montagmorgen rief uns der Betreiber eines Großhandels an, hörbar nervös. Über Nacht waren rund sechshundert Bestellungen eingegangen, alle auf denselben Artikel, alle zu einem Preis, der nicht sein durfte. Ein Produkt, das 1.234,50 Euro kostet, war im Shop für 1,23 Euro gelistet. Kunden hatten palettenweise zugeschlagen, und die Ware war zum Teil schon kommissioniert.
Die Automatisierung, die die Preise aus dem ERP in den Shop schrieb, war nicht abgestürzt. Kein rotes Modul, kein Fehler im Protokoll, keine Benachrichtigung. Sie war jede Nacht sauber durchgelaufen und hatte genau das getan, wofür sie gebaut war. Nur eben mit einer Zahl, die unterwegs ihre Bedeutung verloren hatte.
Warum aus 1.234,50 eine 1,23 wird
In Deutschland trennt der Punkt die Tausender und das Komma die Nachkommastellen. 1.234,50 ist also eintausendzweihundertvierunddreißig Euro und fünfzig Cent. Viele Systeme im englischsprachigen Raum machen es genau umgekehrt: Dort trennt das Komma die Tausender und der Punkt die Nachkommastellen. Dieselbe Zahl heißt dort 1,234.50.
Das Problem entsteht in dem Moment, in dem die Automatisierung den Preis als Text von einem System ins nächste reicht. Das ERP gibt "1.234,50" aus, formatiert für die deutsche Anzeige. Der Shop erwartet eine Zahl mit Punkt als Dezimaltrennzeichen. Sein Parser liest von links, nimmt den Punkt als Komma und stoppt beim tatsächlichen Komma. Übrig bleibt 1.234, also ein Euro dreiundzwanzig. Kein System hat sich beschwert, weil aus technischer Sicht nichts falsch war. Eine gültige Zahl ging rein, eine gültige Zahl kam raus.
Der Fehler funktioniert auch andersherum. Kommt ein englisch formatierter Betrag wie 1,234.50 in ein System, das nach deutschem Muster liest, wird daraus schnell 1234,50 oder, je nach Parser, eine ganz andere Größenordnung.
Es geht nicht nur um Preise
Im Großhandel und in der Logistik steckt in fast jedem Feld eine Zahl mit Trennzeichen. Gewichte, Mengen, Volumina, Rabattsätze, Rechnungssummen. Eine Palette mit 1.500 Kilogramm wird zu 1,5 Kilogramm, wenn der Tausenderpunkt falsch gelesen wird. Eine Bestellmenge von 2.000 Stück kippt auf 2. Diese Fehler sind besonders tückisch, weil das Ergebnis fast immer plausibel aussieht. 1,23 Euro ist ein Preis, den man theoretisch verlangen könnte. Niemand stutzt beim Blick auf die Zahl allein.
Wo sich der Fehler einschleicht
Fast immer sitzt das Problem an einer Übergabestelle, an der ein Textfeld auf ein Zahlenfeld trifft. In Make oder n8n zieht ein Modul einen Wert aus dem einen System und legt ihn im nächsten ab, und im Mapping steht dann eben "1.234,50" als Zeichenkette, die das Zielsystem nach seinen eigenen Regeln deutet. Besonders gern passiert das bei CSV-Exporten aus dem ERP, bei Werten, die vorher durch Excel gelaufen sind, und bei APIs, die Beträge als String statt als Zahl zurückgeben. Excel ist dabei ein eigener Verstärker, weil es Zahlen je nach Ländereinstellung des Rechners unterschiedlich formatiert. Derselbe Export sieht auf dem Rechner der Buchhaltung anders aus als auf dem des Praktikanten, der die Automatisierung eingerichtet hat.
Der Fehler taucht nie im Log auf
Das ist der eigentliche Grund, warum diese Sorte Bug so lange überlebt. Es gibt keinen Absturz, den man debuggen könnte. Die Automatisierung meldet Erfolg, jeder Lauf ist grün, jedes Modul zufrieden. Sichtbar wird der Schaden erst, wenn ein Mensch eine seltsame Zahl bemerkt oder ein Kunde eine Bestellung aufgibt, die zu gut ist, um wahr zu sein. Bis dahin sind je nach Volumen schon Stunden oder Tage vergangen.
Genau deshalb fällt so ein Fehler auch in Tests durch die Maschen. Wer mit einer glatten 5 oder einer 99 testet, sieht nie ein Problem, weil diese Zahlen kein Trennzeichen enthalten. Die Werte, die es auffliegen lassen, sind die krummen mit Tausenderpunkt und Nachkommastelle.
Wie wir das abfangen
Vier Dinge helfen, und keines davon ist aufwendig.
Reichen Sie Zahlen niemals als anzeigeformatierten Text zwischen zwei Systemen weiter. Ein Betrag ist eine Zahl, keine Zeichenkette mit Punkten und Kommas. Die Formatierung für die Anzeige gehört an das Ende der Kette, nicht in die Mitte.
Parsen Sie explizit, statt sich auf die Automatik des Zielsystems zu verlassen. Wenn Sie einen deutschen Textwert übernehmen müssen, entfernen Sie zuerst den Tausenderpunkt, ersetzen dann das Komma durch einen Punkt und wandeln erst danach in eine Zahl. Drei kleine Schritte, die aus 1.234,50 zuverlässig 1234.5 machen.
Transportieren Sie Zahlen wo möglich als echte Zahlen, nicht als String. Viele APIs akzeptieren beides, und der numerische Weg lässt gar keinen Interpretationsspielraum zu.
Bauen Sie eine einfache Plausibilitätsgrenze ein. Ein Preis, der plötzlich unter einen Schwellenwert fällt, oder eine Menge, die weit über dem Üblichen liegt, hält den Datensatz an und meldet ihn zur Prüfung. Das kostet ein paar Minuten Aufbau und verhindert genau die Nacht, die den Großhändler sechshundert Fehlbestellungen gekostet hat.
Was ich daraus mitgenommen habe
Eine Zahl, die für die Maschine richtig aussieht, und eine Zahl, die für einen Menschen richtig aussieht, sind zwei verschiedene Dinge. Der Abstand zwischen beiden ist genau die Stelle, an der im Stillen Geld verloren geht.
Wenn Sie eine Automatisierung haben, die Preise, Mengen oder Beträge zwischen zwei Systemen bewegt, testen Sie sie einmal mit einem echten krummen Wert. Nehmen Sie 1.234,50, nicht die glatte 100. Kommt am anderen Ende exakt derselbe Betrag an, ist alles gut. Kommt etwas anderes an, wissen Sie jetzt, wo Ihr nächstes teures Missverständnis wartet.