Die Unternehmen buchen in drei Währungen
So lassen sie sich in einem Bericht konsolidieren
Ein konsolidierter Konzernbericht kann falsch sein und trotzdem fertig aussehen. Die Rechnungen des deutschen Unternehmens stimmen, die des UK-Unternehmens stimmen und die des US-Unternehmens stimmen – und irgendwo in der Mitte hat eine Zwischensumme stillschweigend EUR, GBP und USD zu einer Zahl vermischt, die niemand auf eine einzige Währung zurückführen kann. Der Fehler liegt in den Nahtstellen zwischen den Büchern, nicht in einem einzelnen davon, und genau deshalb übersteht er jede Prüfung. Dieser Artikel behandelt, wie das passiert, wenn ein Unternehmen mehrere Niederlassungen in verschiedenen Ländern betreibt, und wie die Dokumentebene der Konsolidierung so aufgebaut wird, dass Währung und Unternehmen getrennt bleiben, bis der Controller über die Umrechnung entscheidet.
Wichtigste Erkenntnisse
- Jedes Unternehmen kann korrekt sein und die Konzernsumme trotzdem unsinnig, weil der Fehler in den Nahtstellen entsteht, wo EUR, GBP und USD addiert werden.
- Keine Rechnungsprüfung kann eine Buchung im falschen Unternehmen kennzeichnen, denn das Dokument selbst ist korrekt und nur die Konzernebene ist falsch.
- Eine Spalte für das Unternehmen und eine für die Währung machen aus einer gemischten Zwischensumme keinen Zufall mehr, sondern etwas, das man absichtlich herbeiführen müsste.
Das Problem: Eine Zwischensumme, die stillschweigend Währungen vermischt
Nennen Sie den Moment, in dem ein Multi-Entity-Abschluss schiefzulaufen beginnt, und Sie landen meist bei einer Zahl, die niemand überprüft hat: der Zwischensumme. Eine Gruppe mit einer deutschen GmbH, einer UK Ltd und einer US LLC erhält EUR 4.200 an deutschen Lieferantenrechnungen, GBP 1.300 an britischen Rechnungen und USD 5.900 an US-Rechnungen, und jemand addiert sie in eine Spalte, die 11.400 anzeigt. Diese Summe ist nicht falsch im Sinne eines Übertragungsfehlers: Sie ist ein Wert, den kein Teilnehmer der Gruppe interpretieren kann, weil drei Währungen summiert wurden, als wären sie eine. Keine einzelne Buchungszeile ist falsch. Der Fehler entstand im Akt des Summierens.
Der zweite Fehler ist ein Dokument, das unter der falschen Entity abgelegt wurde. In einem Intercompany-Thread auf r/Accounting nannte ein Praktiker, warum er seinen Monat damit verbringt, Buchungen neu zu erfassen, die auf den falschen Büchern gelandet sind: "Die Lohnabrechnung läuft in Firma A, aber die Leute unterstützen Firma B – das muss per JE verschoben werden. Bestellungen/Rechnungen aus der falschen Firma – das muss verschoben werden." (r/Accounting, 2024). Die Dokument-Ebene-Version ist dasselbe, eine Rechnung nach der anderen: Der britische Buchhalter bearbeitet die Rechnung eines deutschen Lieferanten, der Dateiname sagt nichts darüber aus, zu welcher Entity sie gehört, und der EUR-Betrag wird unter UK Ltd summiert.
Dies ist eine andere Aufgabe als die Multi-Currency-Extraktion, die für einzelne Konten behandelt wurde. Das Ziehen der Kontoauszüge eines einzelnen Revolut- oder HSBC-Kontos in eine Tabelle betrifft ein einzelnes Auszugsarchiv mit eigenem Saldo. Hier ist die Arbeitseinheit die Konsolidierung über Entities hinweg, bei der jede Entity ihre eigenen Zahlen zertifizieren kann und niemand die Nahtstellen zertifiziert. Der Rest dieses Artikels handelt davon, diese Nahtstellen sichtbar und prüfbar zu machen.
So sieht „korrekt" aus: Eine festgelegte FX-Basis und eine Zuordnung pro Unternehmen
Vor jeder Korrektur muss das Ziel definiert sein, und ein Konzernabschluss hat drei Rollen, die es unterschiedlich definieren. Sie zu einer einzigen „Finanzabteilung" zusammenzufassen, ist der Grund, warum die Nahtstellen unsichtbar bleiben.
| Rolle | Verantwortlich für | Übergibt der nächsten Rolle |
|---|---|---|
| Buchhalter des Unternehmens | Abschluss der lokalen Bücher in der lokalen Währung, mit Lieferantenrechnungen als Beleg | Rechnungen und Kontoauszüge in der eigenen Sprache und Währung des Unternehmens |
| Konzernbuchhalter | Sammlung der Dokumente aller Unternehmen und deren Vereinheitlichung in einer Tabelle | Eine Tabellenkalkulation, in der jede Zeile mit Unternehmens- und Währungs-Tags versehen ist |
| Controller | Festlegung der FX-Basis, Prüfung der getaggten Tabelle, Buchen von Umrechnungs- und Abschlussbuchungen | Die konsolidierten Zahlen, die nach außen gehen |
„Korrekt" für die Arbeitstabelle bedeutet zwei Dinge. Erstens eine festgelegte FX-Basis. Nach IAS 21 (IFRS) und ASC 830 (US GAAP) werden Bilanzposten zum Stichtagskurs am Bilanzstichtag umgerechnet, während Erlöse und Aufwendungen zu Kursen umgerechnet werden, die näher am Transaktionsdatum liegen, in der Regel ein Periodendurchschnitt. Eine Tabellenkalkulation, die alles mit einem einzigen Kurs multipliziert, ist nach beiden Standards strukturell falsch. Zweitens eine Zuordnung pro Unternehmen: Jede Rechnungszeile muss mit ihrem Unternehmen und ihrer ursprünglichen Währung gekennzeichnet sein, damit eine Konzern-Zwischensumme sie niemals versehentlich vermischen kann. Die Rohzahlen müssen noch nicht umgerechnet werden. Sie müssen sauber und sichtbar getrennt gehalten werden.
Die Realität der Software erklärt, warum die Rechnungsebene in der Regel der manuellste Teil davon ist. QuickBooks und Xero erfassen Fremdwährungstransaktionen problemlos, aber keines von beiden konsolidiert nativ über Unternehmen hinweg; Xeros eigene Anleitung zur Multi-Entity-Buchhaltung weist darauf hin, dass getrennte Firmendateien bedeuten, sich an mehreren Orten anzumelden und manuell zu konsolidieren, „was zu Fehlern führen und jeden Monat Zeit kosten kann" (Xero, Leitfaden zur Multi-Entity-Buchhaltung). Die Konsolidierungsmodule der ERP-Systeme, die Konzerne tatsächlich nutzen – NetSuite OneWorld, Oracle Fusion Financial Consolidation and Close Cloud und SAP S/4HANA Group Reporting – starten ihre Automatisierung stattdessen auf der Ebene der Summenbilanz. Niemand in diesem Stack verarbeitet rohe Lieferantenrechnungen auf Deutsch, Französisch und Englisch, außer einem Menschen mit einer Tabellenkalkulation.
Wo es scheitert: Jede Entität ist korrekt, also erzwingt nichts die entitätsübergreifende Prüfung
Der Grund, warum dies Monat für Monat fehlerhaft bleibt, ist, dass die Fehlerbilder Prozessprobleme und keine Datenprobleme sind, und jedes davon hat eine plausible Ausrede. Beginnen wir mit der oben beschriebenen Fehlzuordnung: Eine Rechnung ist in jedem Feld korrekt, sie liegt nur unter dem falschen Unternehmen. Keine Validierungsregel für das Dokument markiert sie, denn das Dokument selbst enthält keinen Fehler. Die Buchung ist auf Gruppenebene falsch und auf Dokumentebene nicht erkennbar.
Währungs-Querprüfungen haben dieselbe Struktur. Zwei Entitäten, die miteinander Geschäfte machen, buchen denselben Intercompany-Deal zu unterschiedlichen Kursen: Eine Seite verwendet den Kassakurs am Transaktionsdatum, die andere den Monatsdurchschnitt, den ihre lokalen Rechnungslegungsvorschriften vorschreiben. Beide Zahlen sind vertretbar. Die Abweichung, die am Monatsende auftritt, ist kein zu behebender Fehler, sondern eine erwartete Differenz, die jemand isolieren und erklären muss. In einer Antwort auf diesen r/Accounting-Thread formulierte ein leitender Intercompany-Buchhalter die Diagnose: "Ist FX oder eine Währungsdifferenz im Spiel? Das sind typische Probleme bei Intercompany, besonders über Grenzen hinweg." (r/Accounting, 2026). Selbst die erfahrensten Teams verbringen Stunden mit einzelnen Abweichungen; ein neuerer Mitarbeiter im selben Thread beschrieb, wie er vier Stunden für einen Posten aufwendete und "am Ende eine Differenz von $1.900 hatte, die ich nicht abschließen konnte."
Der tiefste Grund ist organisatorischer Natur: Niemand ist für die Nahtstellen verantwortlich. In derselben Intercompany-Diskussion fasste ein Kommentator zusammen, warum eine Abweichung wochenlang ungelöst bleiben kann: "Beide Seiten behaupten, dass ihre Zahlen stimmen." (r/Accounting, 2024). Jede Entität kann ihr eigenes Hauptbuch bestätigen, und nichts erzwingt die entitätsübergreifende Prüfung, also findet die Prüfung nur statt, wenn jemand entdeckt, dass EUR und USD zusammengezählt wurden, oder wenn die Gruppenzahl nicht aufgeht.
Die Kosten dieser Entdeckung sind messbar. Das Benchmarking von APQC mit mehr als 2.300 Organisationen, berichtet in der Metric-of-the-Month-Serie von CFO.com zum Finanzabschluss, beziffert den medianen monatlichen Abschluss auf 6,4 Kalendertage, mit dem obersten Quartil bei 4,8 Tagen und dem untersten Quartil bei 10 Tagen oder mehr (APQC via CFO.com). Multi-Entity-, Multi-Währungs- und Intercompany-Aktivitäten sind genau das, was Gruppen in Richtung des unteren Endes dieser Spanne drückt. Dasselbe manuelle Muster zeigt sich sogar an der Spitze des Marktes: Die PwC Global Treasury Survey 2025 ergab, dass 52 % der Unternehmen mit einem Umsatz von 1 bis 10 Milliarden USD Prognosedaten weiterhin manuell erfassen und konsolidieren, und 38 % der größeren Unternehmen tun dasselbe (PwC, Global Treasury Survey 2025).
Die Lösung: Währung und Unternehmen normalisieren, dann jedes Dokument zuordnen
Zwei Funktionen des Extraktionstools entsprechen den beiden Schritten, die von Hand immer wieder fehlschlagen: jede Zeile so zu normalisieren, dass sie Unternehmen und Währung trägt, und ein aufgeteiltes Dokument wieder einem einzelnen Datensatz zuzuordnen. Jede Funktion ist an eine bestimmte Einstellung geknüpft, nicht an das Tool allgemein.
Die erste Funktion ist die Benutzerdefinierte Spaltenextraktion. Statt Felder mit Rahmen zu markieren, werden die gewünschten Spaltennamen eingegeben und die KI findet jeden Wert anhand seiner Bedeutung, nicht anhand seiner Position auf der Seite. Die eingegebenen Spaltennamen werden zu den Kopfzeilen der endgültigen Tabelle, und dieselbe Definition funktioniert über Anbieter hinweg, deren Layouts und Sprachen sich unterscheiden. Für einen Konzernabschluss wird der Satz einmal definiert, zum Beispiel Entity (Optionen: US LLC, UK Ltd, DE GmbH), Currency (Optionen: USD, GBP, EUR), Supplier Name, Invoice Number, Invoice Date und Total Amount. Entity und Currency sind abgeleitete Spalten: Die Rechnung druckt nicht neben jedem Betrag „GBP" oder über jeder Zeile „DE GmbH", daher liest die KI den Dokumentkopf, den eingetragenen Firmennamen, die Adresse und das Währungssymbol und füllt das Tag für jede Zeile aus. Das ist die Konfiguration, die Währung und Unternehmen normalisiert. Eine deutsche Rechnung, die im Batch des britischen Buchhalters ankommt, wird weiterhin mit Currency: EUR und Entity: DE GmbH extrahiert, weil die Extraktion das Dokument liest, nicht die Upload-Reihenfolge. Mit einer Currency-Spalte in jeder Zeile ist eine Gruppenzwischensumme strukturell geschützt: Die Summierung nach Währung wird zu einem Filter, nicht zu einer Gedächtnisaufgabe.
Die zweite Funktion ist die Mehrseiten-Zusammenführung. In den Vorlageneinstellungen kann ein Batch extrahierter Ergebnisse gruppiert werden, sodass ein logisches Dokument, das über Seiten oder Dateien verteilt angekommen ist, wieder zu einer einzigen Zeile zusammengeführt wird: eine neue Gruppe starten, wenn sich der Wert einer verfolgten Spalte ändert, alle Seiten abgleichen, die eine Referenznummer gemeinsam haben, oder nach einer festen Anzahl von Uploads gruppieren. Wiederkehrende Informationen wie der Firmenname oder die Rechnungsnummer werden in jede Zeile der Gruppe übernommen, und bei Konflikten zwischen Seiten kann „erste behalten", „letzte behalten", „verketten" oder „aufteilen" gewählt werden. Das ist die Konfiguration, die ein Dokument seinem Unternehmen zuordnet. Eine über drei Seiten gescannte Rechnung eines deutschen Lieferanten – Kopf auf Seite eins, Positionen auf Seite zwei, Summen auf Seite drei – ist nach der Verarbeitung ein Datensatz statt drei Zeilen, die ein Mensch zusammenfügen muss, und die Entity- und Currency-Tags werden über die gemeinsame Referenz mitgeführt. Eine mehrseitige Monatsabrechnung eines britischen Lieferanten wird ebenso zu einer Zeile pro Periode mit demselben GBP-Tag statt zu einer Zeile pro Seite.
Der Workflow weist jeder Rolle den Schritt zu, den sie verantwortet:
Hier verarbeitet das Tool einen Batch von Rechnungen, wobei derselbe Spaltensatz bereit ist, über Lieferantenformate hinweg zu lesen:
Dateien werden sicher verarbeitet und nicht gespeichert.
Der Controller erhält eine Tabelle, in der die Konsolidierungsannahmen sichtbar statt implizit sind. Jede Zeile enthält eine Invoice Number, einen Supplier, ein Entity und eine Währung, sodass „Ausgaben des deutschen Unternehmens“ ein Filter und „EUR-Zwischensumme“ ein Filter ist – keine Erinnerung daran, welche Datei welche war. Da das Währungs-Tag immer vorhanden ist, kann eine gemischte Währungssumme nur existieren, wenn jemand absichtlich über Filter hinweg summiert. Das ist die Eigenschaft, die ein Prüfer nachvollziehen und ein Buchhalter vertrauen kann. Der direkte Weg für einen einzelnen Lieferanten ist eine Rechnung in eine Tabellenzeile zu verwandeln, und der Workflow für Handelsrechnungen zeigt dieselben Spalten, angewendet auf Exportdokumente.
Was dieses Setup weiterhin nicht automatisieren kann
Das Tool hält Währungen und Entitäten sauber; es wählt nicht den Umrechnungsansatz, und das sollte auch nicht erwartet werden. Nach IAS 21 und ASC 830 werden Bilanzposten zum Stichtagskurs umgerechnet, während Posten der Gewinn- und Verlustrechnung einen Periodendurchschnitt verwenden. „Alles zu einem Kurs umrechnen“ ist daher keine Vereinfachung, die ein Controller akzeptieren kann. Die Wahl der Kursbasis, ihre konsistente Anwendung und die Buchung der Umrechnungs- und kumulierten Umrechnungsdifferenz-Posten bleiben beim Controller und beim Konzernbuchhalter. Die ehrliche Arbeitsteilung: Das Tool macht aus dem Rohmaterial eine saubere Tabelle in Originalwährungen, und die Umrechnungspolitik ist das buchhalterische Urteil darüber.
Dies ist auch keine Intercompany-Eliminierungs-Engine und kein ERP. Die Tabelle speist die Hauptbücher, sie ersetzt nicht die Konsolidierungsmaschinerie in NetSuite OneWorld, Oracle FCCS oder SAP Group Reporting, die weiterhin Intercompany-Salden eliminieren und gesetzliche Berichte erstellen. Diese Module erwarten Probebilanzen; die Lücke, die hier geschlossen wird, ist die zwischen dem Posteingang des Unternehmens und der Probebilanz – genau die Ebene, die die großen Systeme manuell lassen.
Eine weitere Grenze ist erwähnenswert: Die Extraktion transkribiert, was das Dokument aussagt. Eine absichtlich aufgeblähte Rechnung wird als aufgeblähter Gesamtbetrag extrahiert, und das falsche Entity-Tag funktioniert nur, wenn das Dokument die Identität der Entität im Kopfbereich trägt. Die Prüfung, was tatsächlich bestellt und bezahlt wurde, bleibt eine Aufgabe der Buchhaltung – weshalb der Entity-Buchhalter weiterhin prüft, bevor die Tabelle hochgeladen wird. Was sich ändert, ist, dass die Prüfung nun etwas zu prüfen hat: eine einzige Tabelle, sortiert nach Entität und Währung, statt eines Stapels von Dateien in drei Sprachen. Das Batch-Muster für den Belegpfad ist dasselbe wie bei der Diagnose der Extraktionsgenauigkeit bei mehrsprachigen Dokumenten, und Teams, die bereits die Kontoauszüge eines Kontos konsolidieren, erkennen die Mechanik hier angewandt auf mehrere Entitäten (Einzelkonto-Mehrwährungs-Kontoauszugsextraktion ist die Ein-Konto-Version dieses Problems).
Mehrwährungs- und Multi-Entity-Konsolidierung: Häufig gestellte Fragen
Kann es EUR, GBP und USD automatisch in die Berichtswährung umrechnen?
Nein, und das ist beabsichtigt. Das Tool extrahiert und bewahrt die ursprüngliche Währung in einer Währungsspalte; es rechnet keine Zahlen um. Die Umrechnung bleibt beim Team, da die Umrechnung eine politische Entscheidung ist: IAS 21 und ASC 830 verlangen unterschiedliche Kurse für Bilanzposten im Vergleich zu Ertragsposten, daher gibt es keinen einzelnen Umrechnungsfaktor, der der „richtige“ ist. Was das Tool garantiert, ist, dass jede Zeile weiterhin ihre ursprüngliche Währung trägt – die Voraussetzung für jeden vertretbaren Umrechnungsschritt.
Funktioniert dasselbe Spalten-Setup, wenn Rechnungen in verschiedenen Sprachen eintreffen?
Ja. Da die Extraktion Werte anhand der Bedeutung und nicht anhand der Vorlagenposition lokalisiert, sind die Spaltennamen der Vertrag, und jede Sprache ist nur ein weiteres Layout, das diesen erfüllt. Eine deutsche und eine französische Rechnung erfüllen beide „Supplier Name“ und „Total Amount“, auch wenn die Beschriftungen auf den Dokumenten unterschiedlich sind. Das ist der Unterschied zwischen semantischer Extraktion und layoutbasierter OCR, und genau deshalb ersetzt ein Spaltenset die vorlagenspezifischen Vorlagen pro Anbieter.
Woher weiß das Tool, zu welchem Unternehmen eine Rechnung gehört, wenn sie im falschen Batch angekommen ist?
Die Entity-Spalte wird aus dem Dokument selbst abgeleitet. Die KI liest den registrierten Firmennamen, die Adresse oder die Währung im Kopfbereich und kennzeichnet jede Zeile mit dem passenden Unternehmen aus Ihrer Optionsliste – unabhängig davon, mit welchen Dateien sie hochgeladen wurde. Eine deutsche Rechnung, die vom britischen Buchhalter bearbeitet wird, wird trotzdem als Entity: DE GmbH extrahiert. Wenn ein Dokument keinerlei Unternehmensidentität aufweist, besteht die praktische Lösung darin, den Unternehmensnamen in der Dateinamen zu führen oder ihn beim Hochladen in einer Notiz zu ergänzen.
Was passiert, wenn eine Lieferantenrechnung über drei Seiten gescannt wurde?
Aktivieren Sie Mehrseiten-Zusammenführung und gruppieren Sie nach der gemeinsamen Referenznummer: Seiten mit derselben Rechnungsnummer werden zu einer einzigen Zeile zusammengeführt, wobei die Felder von der jeweiligen Seite übernommen werden, die sie enthält. Wiederkehrende Werte wie Entity und Rechnungsnummer werden automatisch übernommen, und die Konfliktbehandlung „erste gewinnt“ löst die Kopffelder auf, die auf späteren Seiten wiederholt werden. Das Ergebnis ist ein Rechnungsdatensatz statt drei Seitendatensätzen.
Ersetzt das unser ERP-Konsolidierungsmodul?
Nein. Konsolidierungsmodule wie NetSuite OneWorld, Oracle FCCS und SAP Group Reporting arbeiten mit Saldenbilanzen: Sie eliminieren konzerninterne Salden und erstellen gesetzliche Abschlüsse. Dieses Tool arbeitet eine Ebene darunter und wandelt die rohen Lieferantendokumente des Unternehmens in die saubere, mit Entity gekennzeichnete Tabelle um, die diese Systeme speist. Für einen Konzern ohne ERP-Konsolidierungsmodul ist die gekennzeichnete Tabelle ein funktionierender Ersatz für die Zusammenfassung, wobei der Controller weiterhin für die FX-Basis und die Abschlussbuchungen verantwortlich ist.
Wer sollte welche Dateien hochladen?
Der Buchhalter jedes Unternehmens lädt die eigenen Rechnungen hoch oder leitet sie in die gemeinsame Warteschlange weiter. Da der Spaltensatz gemeinsam genutzt wird und das Entity-Tag aus dem Dokument gelesen wird, spielt es keine Rolle, durch welche Hände eine Datei geht, bevor sie im Batch landet. Das Ergebnis ist eine Tabelle, in der jede Zeile dasselbe bedeutet – genau das, worauf ein Multi-Entity-Abschluss angewiesen ist.
Die Multi-Entity-Konsolidierung scheitert genau dort, wo niemand hinschaut: zwischen den Büchern, nicht in ihnen. Der Wandel besteht darin, diese Lücke in eine sichtbare, prüfbare Tabelle zu verwandeln, in der jede Rechnungszeile ihr Entity und ihre ursprüngliche Währung trägt, sodass eine Zwischensumme sie nicht mehr stillschweigend vermischen kann. Der Controller legt weiterhin die FX-Basis fest und bucht den Abschluss, und die konzerninterne Eliminierung hat weiterhin ihre eigene Mechanik – aber das Rohmaterial kommt endlich sauber an. Testen Sie den Ablauf mit den Rechnungen Ihrer eigenen Unternehmen und sehen Sie, ob der nächste Abschluss mit einer Tabelle beginnen kann statt mit einem Stapel Dateien in drei Sprachen.