Wechselkurse in Automatisierungen: warum derselbe Auftrag in drei Systemen drei Beträge hat

Der gleiche Auftrag, drei Beträge, vier Tage Suche

Ein Großhändler für Laborbedarf verkauft nach Österreich und in die Schweiz und kauft einen Teil seines Sortiments in den USA ein. Hauswährung ist Euro, die Schweizer Kunden bestellen in Franken, die amerikanischen Lieferanten fakturieren in Dollar. Wechselkurse stecken damit in fast jedem Beleg, den dieser Betrieb erzeugt. Über zwei Jahre sind drei Automatisierungen gewachsen: eine schreibt Aufträge aus dem Kundenportal ins CRM, eine legt Lieferantenrechnungen in der Buchhaltung an, eine baut jede Nacht die Umsatztabelle für die Geschäftsführung.

Im Frühjahr passte der Monatsabschluss nicht mehr. Das CRM meldete für den März 1,84 Millionen Euro Auftragseingang, die Buchhaltung 1,83 Millionen, die Umsatztabelle 1,86 Millionen. Bei rund dreihundertvierzig Aufträgen im Monat waren das Abweichungen, die niemand mehr auf einen einzelnen Buchungsfehler zurückführen konnte. Der Controller hat vier Tage gesucht.

Dahinter steckten drei getrennte Umrechnungen, die nie jemand aufeinander abgestimmt hatte. Die Portal-Automatisierung holte sich den Kurs bei einem kostenlosen Kursdienst, in dem Moment, in dem der Auftrag ankam. Die Buchhaltung rechnete mit dem Monatsdurchschnittskurs, den das Steuerbüro vorgegeben hatte. Und die Umsatztabelle rechnete gar nicht mit einem gespeicherten Kurs, sondern zog beim nächtlichen Lauf den jeweils aktuellen Tageskurs für alle Aufträge des Monats, auch für die vom Ersten. Ein Auftrag über 18.400 Franken vom 4. März stand deshalb im CRM mit 18.740 Euro, in der Buchhaltung mit 18.612 Euro und in der Tabelle mit 18.398 Euro.

Jede der drei Zahlen war für sich vertretbar. Zusammen waren sie unbrauchbar.

Wir sehen diesen Fall regelmäßig, und fast immer erst dann, wenn ein Abschluss ansteht oder eine Prüfung. Fremdwährung ist in Automatisierungen deshalb so tückisch, weil nichts abstürzt. Es gibt keine rote Fehlermeldung und keinen fehlgeschlagenen Lauf, sondern nur Zahlen, die plausibel aussehen und um zwei Prozent danebenliegen. Zwei Prozent auf zwanzig Millionen Jahresumsatz sind vierhunderttausend Euro, die irgendwo zwischen den Systemen wohnen.

Ein Betrag ohne Währungscode ist nur eine Zahl

Der häufigste Konstruktionsfehler steht ganz am Anfang der Kette. Ein Webhook liefert ein Feld `amount` mit dem Wert `18400`. Der Workflow schreibt diesen Wert in ein Feld, das im Zielsystem "Auftragswert" heißt und in Euro geführt wird. Fertig. Niemand hat gelogen, niemand hat sich verrechnet, und trotzdem sind gerade 18.400 Franken zu 18.400 Euro geworden.

Solange ein Unternehmen nur in einer Währung fakturiert, fällt das nie auf. Der Fehler entsteht in dem Moment, in dem der erste Auslandskunde dazukommt, und er entsteht rückwirkend im gesamten Datenbestand, weil die alten Datensätze keinen Währungscode haben und man ihn nachträglich nicht mehr sicher ermitteln kann.

Die Regel dagegen ist unspektakulär: Ein Geldbetrag besteht aus zwei Feldern, dem Wert und dem Währungscode nach ISO 4217. Die beiden reisen zusammen durch jedes System, jeden Webhook, jede Tabelle. Wer einen Betrag ohne Währungscode annimmt, trifft eine Annahme, und Annahmen dieser Art hält niemand nach zwei Jahren noch im Kopf.

Dazu kommt, dass die Quellsysteme sich nicht einig sind, was sie in diesem Feld überhaupt liefern. Stripe gibt Beträge in der kleinsten Währungseinheit aus, `1840` bedeutet dort 18,40 Euro. PayPal liefert eine Zeichenkette mit Punkt als Dezimaltrennzeichen. Ein deutsches ERP exportiert oft `18.400,00` mit Punkt als Tausendertrennzeichen. Drei Formate, drei Bedeutungen für optisch ähnliche Zahlen. Wenn ein Workflow die Werte aus zwei dieser Quellen im selben Feld ablegt, ohne sie zu normalisieren, entsteht ein Datenbestand, in dem der Faktor 100 zufällig verteilt ist.

Praktisch bewährt hat sich, den Betrag an genau einer Stelle in ein internes Format zu bringen, direkt nach dem Empfang, und danach nie wieder umzuformen. Wir schreiben in dieser Normalisierung drei Werte weg: den Betrag in der kleinsten Einheit als ganze Zahl, den Währungscode und die Quelle. Alles Weitere im Workflow arbeitet nur noch mit diesen Feldern.

Nicht jede Währung hat zwei Nachkommastellen

Die Umrechnung "mal hundert" für die kleinste Einheit ist der Standardgriff, und für Euro, Dollar und Franken stimmt sie auch. Der japanische Yen hat keine Nachkommastellen, 1000 JPY sind tausend Yen und nicht zehn. Der kuwaitische Dinar, der bahrainische Dinar und der tunesische Dinar haben drei, dort entspricht die kleinste Einheit einem Tausendstel.

Das klingt exotisch, bis der erste Kunde aus Tokio bestellt oder ein Dienstleister in Tunis abrechnet. Wer fest mit hundert multipliziert, verzehnfacht Yen-Beträge oder zehntelt Dinar-Beträge, und weil beides in der Größenordnung noch plausibel wirkt, fällt es in der Freigabe nicht auf.

Die Anzahl der Nachkommastellen steht in ISO 4217 und ändert sich praktisch nie. Sie gehört in eine kleine Tabelle im eigenen System, zusammen mit den Währungen, die man tatsächlich verarbeitet, und nicht in eine Formel, die dreimal im Workflow wiederholt wird. Ein zweiter Grund für diese Tabelle: Sie ist gleichzeitig die Positivliste. Kommt eine Währung herein, die nicht darin steht, bricht der Lauf ab und landet in der Ausnahmebehandlung, statt eine Umrechnung zu erfinden.

Kommazahlen sind der falsche Datentyp für Geld

Make, n8n und Zapier rechnen intern mit Gleitkommazahlen, so wie JavaScript das tut. In dieser Arithmetik ergibt 0,1 plus 0,2 nicht 0,3, sondern 0,30000000000000004. Bei einem einzelnen Betrag ist das folgenlos. In einer Schleife über zweihundert Rechnungspositionen, gefolgt von einer Rundung am Ende, wandert dieser Rest nach oben und erzeugt Summen, die um einen Cent von der Rechnung im Quellsystem abweichen.

Ein Cent ist harmlos, solange ihn niemand prüft. Sobald ein Zahlungsdienstleister die Beträge abgleicht oder eine Schnittstelle zur Buchhaltung Rechnungsbetrag und Summe der Positionen vergleicht, wird aus dem Cent eine abgelehnte Buchung. Wir haben Schnittstellen gesehen, die deshalb jeden Tag zwischen zwei und fünf Belege in eine Fehlerwarteschlange geschoben haben, die dann jemand manuell nachgebucht hat, jahrelang, ohne dass die Ursache je gesucht wurde.

Der saubere Weg ist, Beträge im Workflow als ganze Zahlen in der kleinsten Einheit zu führen und die Division erst bei der Ausgabe vorzunehmen. Wo das nicht geht, weil das Zielsystem Dezimalwerte erwartet, hilft eine feste Rundungsstelle unmittelbar nach jeder Multiplikation, nicht erst am Ende der Kette. Und in jedem Fall gilt: Der Betrag, der auf dem Beleg steht, ist die Referenz. Wenn die Automatisierung eine Summe selbst nachrechnet und ein anderes Ergebnis bekommt, ist das ein Grund anzuhalten, kein Grund, den eigenen Wert zu schreiben.

Den einen richtigen Wechselkurs gibt es nicht

Für dieselbe Umrechnung existieren an einem Tag mehrere legitime Kurse, und sie unterscheiden sich um Beträge, die in der Buchhaltung sichtbar werden.

Die Europäische Zentralbank veröffentlicht an Bankarbeitstagen am Nachmittag Referenzkurse. Sie sind kostenlos, nachvollziehbar und für interne Bewertungen gut geeignet. Sie sind keine Handelskurse, zu diesem Kurs kauft niemand Devisen.

Die Hausbank rechnet mit ihrem eigenen Kurs plus Marge. Der Betrag, der tatsächlich auf dem Konto ankommt, richtet sich nach diesem Kurs, nicht nach dem der EZB.

Zahlungsanbieter wie Stripe, PayPal oder Adyen rechnen ebenfalls mit eigenen Kursen und weisen sie in ihren Berichten aus. Wer diese Berichte automatisiert einliest, bekommt den Kurs frei Haus mitgeliefert und sollte ihn übernehmen, statt ihn nachzurechnen.

Für die Umsatzsteuer gibt das Bundesfinanzministerium monatlich Durchschnittskurse bekannt, die nach § 16 Abs. 6 UStG für die Umrechnung von Werten in fremder Währung verwendet werden. Das ist ein anderer Kurs als der, mit dem die operative Automatisierung am Auftragstag gerechnet hat, und das ist auch in Ordnung, solange beide Werte am Beleg stehen und ineinander überführbar sind.

Für den Jahresabschluss kommt nach § 256a HGB der Devisenkassamittelkurs am Abschlussstichtag ins Spiel, für Posten, die am Stichtag noch offen sind.

Vier bis fünf Kurse für denselben Geschäftsvorfall, jeder mit einem eigenen Zweck. Das Problem entsteht nicht dadurch, dass es sie gibt, sondern dadurch, dass die Wahl in vielen Automatisierungen implizit getroffen wird. Jemand hat vor achtzehn Monaten in einem Make-Szenario einen kostenlosen Kursdienst eingebaut, weil er ohne Anmeldung funktionierte. Seitdem ist dieser Dienst die maßgebliche Kursquelle des Unternehmens, und niemand hat das je entschieden.

Unsere Empfehlung: Legen Sie pro Zweck eine Quelle fest und schreiben Sie sie auf. Operative Umrechnung für Reporting und CRM aus einer Quelle, steuerliche Umrechnung aus den BMF-Kursen, Zahlungsverkehr aus dem Bericht des Zahlungsanbieters. Drei Quellen, drei Zwecke, keine Diskussion mehr im Abschluss.

Der Zeitpunkt entscheidet mehr als die Quelle

Zwischen Angebot und Zahlungseingang liegen bei einem Handelsgeschäft leicht acht Wochen. In dieser Zeit bewegt sich das Währungspaar Euro zu Dollar erfahrungsgemäß um zwei bis vier Prozent, in unruhigen Phasen auch deutlich mehr. Damit gibt es für einen einzigen Vorgang mindestens fünf Zeitpunkte, an denen man umrechnen könnte: Angebotsdatum, Auftragsbestätigung, Lieferung, Rechnungsdatum, Zahlungseingang.

Die Automatisierung trifft diese Wahl an dem Punkt, an dem der Workflow läuft, und das ist selten der fachlich richtige Zeitpunkt. Ein nächtlicher Lauf, der Aufträge des Vortags verarbeitet, rechnet mit dem Kurs von heute Morgen. Ein Wiederholungslauf nach einer Störung rechnet drei Tage später erneut, und plötzlich hat derselbe Auftrag einen anderen Euro-Wert als beim ersten Versuch.

Zwei Regeln haben sich bei uns durchgesetzt.

Erstens: Der Kurs wird zum fachlich definierten Zeitpunkt bestimmt, nicht zum Ausführungszeitpunkt. Wenn die Regel "Rechnungsdatum" lautet, holt der Workflow den Kurs für das Rechnungsdatum, auch wenn er drei Tage später läuft. Kursdienste liefern historische Kurse, das kostet nichts außer einem zusätzlichen Parameter im Aufruf.

Zweitens: Der Kurs wird eingefroren und am Beleg gespeichert. Nicht nur der umgerechnete Betrag, sondern der Kurs selbst, das Datum, für das er gilt, und die Quelle. Drei zusätzliche Felder pro Datensatz. Ohne sie ist ein umgerechneter Betrag nicht prüfbar, weil man den Rechenweg nicht mehr rekonstruieren kann. Mit ihnen beantwortet man die Frage "Wie kommen Sie auf diesen Betrag?" in dreißig Sekunden statt in vier Tagen.

Der Gegenentwurf, den wir häufig vorfinden, ist die Live-Umrechnung in der Anzeige. Ein Dashboard, das Fremdwährungsbeträge beim Öffnen mit dem Tageskurs umrechnet, sieht modern aus und ist als Steuerungsinstrument wertlos. Der Umsatz des letzten Quartals ändert sich dann täglich, ohne dass ein einziger Auftrag hinzugekommen ist. Für Vergleiche über die Zeit braucht man festgeschriebene Werte.

Wo die Cents verschwinden

Rundung wirkt wie ein Randthema, bis eine Rechnung abgelehnt wird, weil die Summe der Positionen nicht dem Rechnungsbetrag entspricht.

Ein Beispiel mit drei Positionen zu je 33,33 Dollar und einem Kurs von 0,9134. Rechnet man jede Position einzeln um, ergibt das dreimal 30,4436, gerundet dreimal 30,44, in Summe 91,32 Euro. Rechnet man zuerst die Summe von 99,99 Dollar um, ergibt das 91,3306, gerundet 91,33 Euro. Ein Cent Unterschied, und beide Ergebnisse sind mathematisch korrekt.

In einem einzelnen Beleg ist das eine Fußnote. In einer Schnittstelle, die Positionen und Kopfbetrag getrennt überträgt und im Zielsystem gegeneinander prüft, ist es ein täglicher Fehlerfall. Deshalb gehört die Rundungsregel in die Spezifikation, bevor gebaut wird: entweder positionsweise und der Kopfbetrag ist die Summe der gerundeten Positionen, oder auf Kopfebene und die Positionen tragen die Differenz. Beides funktioniert, solange alle beteiligten Systeme dieselbe Regel verwenden.

Zur Rundungsebene kommt die Rundungsart. Kaufmännisch wird die Fünf aufgerundet, in der kaufmännischen Praxis ist das der Normalfall. Manche Systeme, vor allem im angelsächsischen Raum und in einigen Statistikbibliotheken, runden die Fünf zur nächsten geraden Ziffer, um systematische Verzerrungen über große Datenmengen zu vermeiden. Zwischen zwei Systemen mit unterschiedlicher Rundungsart entstehen Abweichungen, die genau bei den Beträgen auftreten, deren dritte Nachkommastelle eine Fünf ist, also bei ungefähr jedem zehnten umgerechneten Wert. Wer eine Schnittstelle baut und die Beträge nicht zusammenbekommt, sollte diese Stelle früh prüfen, weil sie nach Zufall aussieht und keiner ist.

Dazu kommt die Umsatzsteuer. Bei Rechnungen in fremder Währung muss der Steuerbetrag nach § 14 UStG in Euro angegeben werden, auch wenn Netto- und Bruttobetrag in Fremdwährung stehen bleiben. Eine Automatisierung, die die komplette Rechnung in Dollar erzeugt und den Steuerbetrag mit umrechnet, produziert formal unvollständige Rechnungen. Das fällt oft erst bei einer Prüfung auf, und dann für einen längeren Zeitraum.

Ein letzter Punkt zur Rundung, der überraschend häufig auftaucht: die Aufteilung eines Betrags auf mehrere Empfänger oder Kostenstellen. Hundert Euro auf drei Teile sind dreimal 33,33 und ein Restcent. Wer diesen Cent nicht bewusst zuweist, verliert ihn, und die Summe der Teile ist nicht mehr das Ganze. In automatisierten Provisions- und Verteilungsläufen sammelt sich das über Monate zu Beträgen, die jemand erklären muss.

Zahlungseingang, Gutschrift, Teilzahlung

Bis hierher ging es um eine Umrechnung. Die interessanten Fälle entstehen, wenn ein Vorgang zweimal umgerechnet wird, zu unterschiedlichen Zeitpunkten.

Ein Kunde in der Schweiz bekommt eine Rechnung über 12.500 Franken. Gebucht wird sie mit dem Kurs vom Rechnungsdatum, das ergibt 12.980 Euro als offenen Posten. Sechs Wochen später zahlt der Kunde pünktlich und vollständig 12.500 Franken. Die Bank schreibt zum Kurs des Zahlungstages 12.905 Euro gut. Der offene Posten wird um 12.905 Euro reduziert, es bleiben 75 Euro stehen.

Für die Automatisierung sieht das aus wie eine Teilzahlung. Der Mahnlauf, der jeden Montag alle offenen Posten über null Euro anschreibt, mahnt einen Kunden an, der bezahlt hat. Wir haben genau diesen Fall bei einem Logistikdienstleister erlebt, dessen Schweizer Kunden über Monate freundliche, aber irritierte Rückfragen geschickt haben. Die Ursache war kein Fehler im Mahnwesen, sondern eine fehlende Regel für Kursdifferenzen beim Ausgleich offener Posten.

Die fachliche Antwort darauf ist alt und in jedem Buchhaltungssystem vorgesehen: Eine Differenz aus unterschiedlichen Umrechnungszeitpunkten ist keine Restforderung, sondern ein Kursverlust oder Kursgewinn und wird als solcher gebucht. Die technische Antwort ist eine Toleranzgrenze im Ausgleich plus eine Regel, welches Konto die Differenz aufnimmt. Beides muss jemand festlegen, und in No-Code-Automatisierungen legt es niemand fest, weil die Automatisierung nur Beträge vergleicht und keine Buchhaltungslogik kennt.

Der zweite Fall ist die Rückerstattung. Eine Rechnung über 10.000 Dollar wurde im März mit 0,9200 gebucht, also 9.200 Euro. Die Gutschrift im Mai läuft über den Kurs von 0,8850, also 8.850 Euro. Der Vorgang ist wirtschaftlich neutral, in der Buchhaltung bleiben 350 Euro Differenz. Eine Automatisierung, die Gutschriften spiegelbildlich zum aktuellen Kurs erzeugt, produziert diese Differenz systematisch. Eine Automatisierung, die den ursprünglichen Kurs vom Beleg übernimmt, produziert sie nicht, kann dafür aber vom tatsächlichen Zahlungsausgang abweichen. Welche Variante richtig ist, entscheidet die Buchhaltung und nicht der Workflow-Bauer. Die Frage muss nur gestellt werden, bevor der Workflow live geht.

Bei Teilzahlungen kommt beides zusammen. Drei Raten zu drei Kursen auf eine Forderung zu einem Kurs ergeben fast immer einen Restbetrag im niedrigen einstelligen Bereich. Ohne Toleranzregel bleibt jede dieser Forderungen ewig offen.

Was in No-Code-Werkzeugen konkret schiefgeht

Bis hierher war das fachlich. Die folgenden Fehler sind handwerklich, und wir finden sie in fast jedem Bestandsszenario, das Fremdwährung verarbeitet.

Der Kursabruf hängt an einem kostenlosen Dienst ohne Zusage zur Verfügbarkeit. Diese Dienste sind gut genug für einen Prototyp und ungeeignet für einen Prozess, der monatlich Beträge in sechsstelliger Höhe umrechnet. Fällt der Dienst aus, ist das Feld leer.

Und ein leeres Feld ist der eigentliche Sprengsatz. In Make ergibt eine Multiplikation mit einem leeren Wert je nach Formel eine Null oder einen Fehler. In n8n wird aus einer Multiplikation mit `undefined` ein NaN, das anschließend als Text im Zielfeld landet. Beide Ergebnisse werden vom Zielsystem oft klaglos angenommen. Ein Auftrag mit dem Wert null erscheint in keiner Auswertung, und ein Auftrag mit dem Text NaN im Betragsfeld fällt erst auf, wenn jemand sortiert. Wir bauen deshalb in jeden Währungs-Workflow eine harte Prüfung ein: Ist der Kurs leer, null, negativ oder unplausibel weit vom Vortageswert entfernt, bricht der Lauf ab und der Datensatz geht in die Ausnahmewarteschlange. Einen angehaltenen Lauf repariert jemand am selben Nachmittag. Einen stillen Nullbetrag findet man im Mai.

Der Kurs wird pro Datensatz abgerufen. Bei dreihundert Aufträgen sind das dreihundert Aufrufe an denselben Dienst mit demselben Ergebnis, was Kontingente verbrennt und Läufe verlangsamt. Ein Kurs pro Währung und Tag reicht. Wir legen ihn in einer kleinen Tabelle ab, einmal täglich befüllt, und alle Workflows lesen daraus. Das hat einen Nebeneffekt, der wichtiger ist als die Einsparung: Der Kurs ist damit dokumentiert und nachträglich prüfbar.

Am Wochenende gibt es keinen neuen Referenzkurs. Läuft der Kursabruf sonntagnachts, liefert der Dienst je nach Anbieter den Freitagswert, den letzten verfügbaren oder gar nichts. Alle drei Verhalten sind vertretbar, aber sie sind unterschiedlich, und der Workflow muss wissen, welches er bekommt. Dasselbe gilt für Feiertage, die je nach Land unterschiedlich liegen.

Und schließlich das Umrechnen in beide Richtungen. Ein Kurs von 0,9134 für Dollar in Euro wird gern über die Division wieder zurückgerechnet, wenn ein Betrag in Dollar angezeigt werden soll. Das Ergebnis weicht durch die Rundung vom Ausgangswert ab. Wer beide Richtungen braucht, speichert beide Beträge, statt einen aus dem anderen zu rekonstruieren.

Reporting: Kurseffekt und Mengeneffekt trennen

Wenn die Umrechnung sauber ist, kommt die betriebswirtschaftliche Frage. Der Auslandsumsatz ist um sechs Prozent gestiegen, und niemand weiß, ob mehr verkauft wurde oder ob nur der Dollar gestiegen ist.

Die übliche Lösung ist eine zweite Kennzahl, die alle Perioden mit einem festen Kurs rechnet, meist dem Durchschnittskurs des Vorjahres. Die Differenz zwischen beiden Zahlen ist der Währungseffekt. Für einen Betrieb mit fünf Prozent Auslandsanteil ist das Aufwand ohne Ertrag. Ab etwa einem Fünftel Auslandsanteil ist es der Unterschied zwischen einer Steuerung und einem Ratespiel.

Technisch ist es billig, wenn die Grundlagen stimmen. Wenn jeder Beleg den Originalbetrag, die Währung, den Kurs und den umgerechneten Wert trägt, ist die währungsbereinigte Auswertung eine zusätzliche Spalte. Wenn nur der umgerechnete Euro-Wert gespeichert wurde, ist sie nachträglich nicht mehr herstellbar. Das ist der praktische Grund, warum wir den Originalbetrag auch dann mitschreiben, wenn ihn im ersten Jahr niemand sehen will.

Dasselbe gilt für die Vertriebs-Pipeline. Ein Forecast, der Fremdwährungsdeals täglich neu umrechnet, bewegt sich, ohne dass ein Vertriebler etwas getan hat. Ein Forecast mit eingefrorenem Kurs beim Anlegen der Chance bewegt sich nur, wenn sich das Geschäft bewegt. Die zweite Variante ist die, mit der man arbeiten kann.

Die Einkaufsseite verzeiht noch weniger

Auf der Verkaufsseite fallen Umrechnungsfehler irgendwann im Abschluss auf. Auf der Einkaufsseite fallen sie in der Marge auf, und dort sucht sie niemand.

Ein typischer Aufbau bei Händlern: Der Artikelstamm führt einen Einkaufspreis in Euro. Der Lieferant fakturiert in Dollar. Irgendwann hat jemand eine Automatisierung gebaut, die neue Preislisten des Lieferanten einliest, die Dollarpreise mit dem Tageskurs umrechnet und den Euro-Einkaufspreis im Artikelstamm überschreibt. Das ist bequem und funktioniert, solange der Kurs stabil ist.

Was dabei passiert, merkt man erst über Monate. Der Einkaufspreis im Stammsatz gilt ab dem Moment des Imports für den kompletten Lagerbestand, auch für die Ware, die vor sechs Monaten zu einem anderen Kurs bezahlt wurde. Die Deckungsbeitragsrechnung vergleicht dann einen Verkaufspreis von heute mit einem umgerechneten Einkaufspreis von heute, während die Ware im Regal zu einem ganz anderen Preis eingekauft wurde. Bei einer Kursbewegung von acht Prozent über ein Halbjahr und einer Rohmarge von zwanzig Prozent verschiebt das den ausgewiesenen Deckungsbeitrag um mehr als ein Drittel, ohne dass sich am Geschäft etwas geändert hat.

Der Umgang damit ist keine Frage der Automatisierung, sondern der Bewertungsmethode. Wareneingänge werden mit dem Kurs des Wareneingangs bewertet, und der Lagerbestand trägt einen gewichteten Durchschnitt. Wichtig für den Workflow-Bauer ist nur die Konsequenz: Eine Automatisierung darf einen bewerteten Einkaufspreis nicht überschreiben, weil eine neue Preisliste eingetroffen ist. Sie darf einen neuen Listenpreis anlegen, datiert, neben dem alten. Welcher davon in die Marge einfließt, entscheidet die Warenwirtschaft.

Dazu kommen bei Importen aus Drittländern die Zollwerte. Für die Einfuhrabgaben gelten eigene, von der Zollverwaltung veröffentlichte Umrechnungskurse, die monatlich festgelegt werden und bewusst nicht dem Tageskurs folgen. Eine Automatisierung, die Zolldokumente aus den Lieferantenrechnungen befüllt und dabei den EZB-Kurs des Tages verwendet, erzeugt Werte, die von denen der Zollanmeldung abweichen. Das ist selten dramatisch, kostet aber Rückfragen, und Rückfragen kosten bei jeder Sendung dieselben zwanzig Minuten.

Wer das Währungsrisiko trägt, ist eine Preisentscheidung

Eine Frage kommt in Projekten regelmäßig zu spät, nämlich erst dann, wenn der Kurs sich schon bewegt hat: Wer trägt das Risiko zwischen Angebot und Zahlung?

Es gibt drei übliche Antworten, und alle drei haben eine technische Entsprechung im System. Verkauft ein Unternehmen in Euro, trägt der Kunde das Risiko, und die Automatisierung braucht überhaupt keine Umrechnung im Verkaufsprozess. Verkauft es in Fremdwährung mit einer festen Preisliste, trägt es das Risiko selbst, und die Preisliste braucht ein Gültigkeitsdatum und einen hinterlegten Planungskurs. Verkauft es in Fremdwährung mit tagesaktueller Umrechnung aus einer Euro-Liste, wandert das Risiko in die Preisstellung, und dann muss jemand definieren, wie oft der Kurs nachgezogen wird.

Die dritte Variante sehen wir am häufigsten und sie ist die, die am seltensten durchdacht ist. Ein Shop rechnet die Euro-Preise beim Seitenaufruf in Franken um. Der Kunde legt Ware in den Warenkorb, kommt zwei Tage später zurück und bezahlt einen anderen Preis als den, den er gesehen hat. Beschwerden darüber landen im Kundenservice, nicht bei dem, der die Umrechnung gebaut hat.

Praktisch hilft ein Planungskurs mit Puffer, der quartalsweise überprüft wird, statt einer täglichen Neuberechnung. Preise, die sich täglich ändern, sind für Kunden im Geschäftskundenbereich ein Ärgernis, und der Aufwand für die Pflege ist geringer, als die meisten annehmen. Vier Termine im Jahr, in denen jemand den hinterlegten Kurs prüft und bei Bedarf anpasst, reichen für die allermeisten Betriebe aus.

Symptome, bevor der Abschluss es zeigt

Die Abweichung im Monatsabschluss ist das späte Symptom. Vorher gibt es mehrere frühere, die man in bestehenden Systemen suchen kann, ohne ein Projekt aufzusetzen.

Auffällig sind Datensätze mit Betrag null, die trotzdem eine Position und einen Kunden haben. In einem sauberen Datenbestand gibt es sie fast nur bei Mustersendungen. Häufen sie sich, ist meistens ein Kursabruf leer zurückgekommen.

Ebenso auffällig sind Beträge, die exakt gleich sind wie der Originalbetrag in Fremdwährung. Wenn ein Auftrag über 18.400 Franken mit 18.400 Euro im CRM steht, hat die Umrechnung nicht stattgefunden. Eine Abfrage über alle Fremdwährungsaufträge, die Original- und Euro-Betrag vergleicht, findet das in einer Minute.

Dann die offenen Posten mit Kleinbeträgen. Eine Liste aller offenen Forderungen unter fünfzig Euro, die älter als sechzig Tage sind, besteht in Betrieben mit Auslandsgeschäft fast vollständig aus Kursdifferenzen. Wenn diese Liste lang ist, arbeitet das Mahnwesen gegen die eigenen Kunden.

Und schließlich die Textfelder mit Zahlenmüll. Ein Betragsfeld, in dem NaN, undefined oder eine Zahl mit vierzehn Nachkommastellen steht, ist der direkte Beweis, dass eine Umrechnung ohne Prüfung durchgelaufen ist. Diese vier Abfragen dauern zusammen einen Vormittag und ersparen im Zweifel die vier Tage, die der Controller aus dem ersten Abschnitt gebraucht hat.

Die Testfälle, die wir jedem Währungs-Workflow mitgeben

Vor dem Livegang schicken wir immer denselben Satz Testdaten durch die Kette. Er ist kurz und deckt die Fälle ab, die in echten Daten irgendwann auftreten.

Ein Betrag in einer Währung ohne Nachkommastellen, typischerweise 1000 JPY, um die Multiplikation mit hundert zu entlarven. Ein Betrag mit drei Nachkommastellen, etwa 1,500 KWD. Ein Betrag über einer Million, damit Tausendertrennzeichen und Feldlängen im Zielsystem geprüft werden. Ein Betrag von null, den es bei Freilieferungen und Mustersendungen wirklich gibt. Ein negativer Betrag für die Gutschrift. Ein Vorgang, dessen Datum auf einen Sonntag fällt. Ein Vorgang mit einer Währung, die nicht in der Positivliste steht, um zu prüfen, ob der Lauf sauber abbricht. Und ein simulierter Ausfall des Kursdienstes, indem man den Zugangsschlüssel für zehn Minuten ungültig macht.

Der letzte Test ist der wichtigste und der, den fast niemand macht. Er beantwortet die Frage, die nach dem Livegang zählt: Was passiert, wenn der Kurs fehlt? Solange die Antwort "null Euro im CRM" lautet, ist der Workflow nicht fertig.

Was festgelegt sein muss, bevor gebaut wird

Der organisatorische Teil ist kleiner, als man denkt. Es sind sieben Entscheidungen, und sie passen auf eine Seite.

Die Hauswährung des Unternehmens, in der ausgewertet und berichtet wird. Die Regel, dass jeder Betrag mit Währungscode reist. Die Kursquelle je Zweck, operativ, steuerlich und für den Zahlungsverkehr. Der fachliche Stichtag für die Umrechnung, also Auftrags-, Liefer- oder Rechnungsdatum. Die Rundungsregel und die Ebene, auf der gerundet wird. Die Behandlung von Kursdifferenzen beim Ausgleich, mit Toleranzgrenze und Konto. Und das Verhalten bei fehlendem Kurs, das immer Abbruch heißen sollte.

Diese Seite entsteht in einem Gespräch von neunzig Minuten zwischen Buchhaltung, Vertrieb und dem, der die Automatisierung baut. Ohne sie trifft der Workflow-Bauer alle sieben Entscheidungen allein, im Zweifel unterschiedlich in jedem Szenario, und niemand weiß hinterher, welche Entscheidung wo getroffen wurde.

Der Selbsttest für ein Quartal

Wenn Sie wissen wollen, wie es bei Ihnen aussieht, nehmen Sie eine einzige Fremdwährungsrechnung aus dem letzten Quartal, am besten eine, die inzwischen bezahlt ist. Verfolgen Sie den Betrag durch jedes System, das ihn anfasst: Portal, CRM, Rechnungsprogramm, Buchhaltung, Reporting. Notieren Sie in jedem System den Euro-Wert und daneben, mit welchem Kurs er zustande gekommen ist.

Wenn Sie den Kurs in mindestens einem System nicht mehr ermitteln können, haben Sie ein Nachvollziehbarkeitsproblem. Wenn zwei Systeme unterschiedliche Euro-Werte zeigen, haben Sie ein Abstimmungsproblem, und zwar für jeden Auftrag des Quartals, nicht nur für diesen einen. Beides ist reparierbar, solange die Originalbeträge und Währungscodes noch irgendwo liegen.

Ein Großteil der Arbeit, die wir in solchen Projekten machen, besteht nicht aus dem Bau neuer Automatisierungen, sondern aus dem Nachrüsten von drei Feldern in bestehenden. Betrag im Original, Währung, Kurs mit Datum und Quelle. Danach ist der Abschluss wieder eine Rechenaufgabe statt einer Suche.