Intercompany-Reconciliation: Abstimmung über Gesellschaften und Währungen hinweg

Intercompany-Reconciliation klärt die Salden, die zwei Gesellschaften gegeneinander buchen, bevor diese Salden in einen konsolidierten Abschluss einfließen. Differenzen entstehen, weil sich die beiden Ledger selten über Referenz, Währung oder Buchungsdatum einig sind. Die Lösung ist Entity Resolution über beide Ledger hinweg, ergänzt um einen Matcher, der die legitimen Abweichungen toleriert und die echten einseitigen Buchungen darunter isoliert.

Nehmen wir einen typischen Fall. Gesellschaft A bucht eine Belastung zum Handelstag in EUR; Gesellschaft B bucht dieselbe Belastung zum Settlement-Datum in USD, unter einem anderen Buchungstext und mit einer anderen Rechnungsnummer. Ein exaktes Match scheitert, und es erscheint eine Differenz, die in Wirklichkeit eine Transaktion ist, nur zweimal gesehen. Die naive Lösung ist eine Tabelle mit einem SUMIF, das voraussetzt, dass beide Seiten dieselbe Referenz und dieselbe Währung am selben Tag verwendet haben. Haben sie nicht. Echte Reconciliation ist Entity Resolution über zwei Ledger hinweg, die von verschiedenen Teams, in verschiedenen Systemen, unter verschiedenen lokalen GAAP-Konventionen aufgesetzt wurden – gefolgt von einem Matching-Schritt, der die legitimen Abweichungen toleriert und die anderen markiert.

Woher die Differenzen tatsächlich kommen

Vor jedem Modell sollte man die Kategorien benennen, denn sie brauchen unterschiedliche Behandlung – und eine einzelne „Match-Rate” verdeckt sie alle.

• Timing-Differenzen. Eine Gesellschaft bucht zum Handelstag, die Gegenseite zum Settlement oder bei Rechnungseingang. Die Beträge stimmen überein, die Perioden nicht. Zum Quartalsende dominieren diese, und die meisten davon klären sich in der Folgeperiode von selbst.
• FX-Differenzen. Jede Seite bucht in ihrer funktionalen Währung. Eine GBP-Forderung gegen eine USD-Verbindlichkeit wird sich nie auf den Cent genau ausgleichen, solange man nicht einen Kurs und einen Zeitpunkt für den Vergleich fixiert.
• Referenz-Mismatch. Bestellnummer auf der einen Seite, interner Kostenstellenschlüssel auf der anderen, ein Freitext-Memo auf einer dritten. Es gibt keinen gemeinsamen Schlüssel, also muss sich das Matching auf Betrag, Datumsnähe, Gesellschaftspaar und Textähnlichkeit zusammen stützen.
• Echte einseitige Buchungen. Eine Belastung, die eine Gesellschaft gebucht und die andere überhaupt nicht abgegrenzt hat. Das sind die Differenzen, auf die es ankommt, und der ganze Sinn der Pipeline ist es, zu verhindern, dass die ersten drei sie verschütten.

Wer eine Differenz nicht in eine dieser Kategorien einordnen kann, kann auch nicht entscheiden, wer darauf reagiert. Also ist der Classifier, der die Kategorie zuweist, genauso wichtig wie der Matcher, der die Datensätze paart.

Die Matching-Pipeline

Wir behandeln das als Blocking, dann Scoring, dann Resolution.

Blocking verkleinert den Kandidatenraum. Man vergleicht nicht jede Buchung in Gesellschaft A gegen jede Buchung in Gesellschaft B; man gruppiert nach Gesellschaftspaar und einem Zeitfenster, das breit genug ist, um die größte legitime Timing-Lücke aufzunehmen, die man gemessen hat – meist wenige Geschäftstage um die Periodengrenzen herum. Das hält den Scoring-Schritt handhabbar und, noch wichtiger, hält die False Positives niedrig, weil man nie Paare bewertet, die plausibel gar nicht zusammengehören können.

Scoring vergleicht Kandidaten anhand mehrerer Signale gleichzeitig: Betragsübereinstimmung nach FX-Umrechnung in eine gemeinsame Währung zu einem Point-in-Time-Kurs, Datumsnähe, Gültigkeit des Gesellschaftspaars und Referenz- oder Buchungstext-Ähnlichkeit. Der FX-Schritt muss Point-in-Time-korrekt sein. Rechne jede Seite zu dem Kurs um, der an ihrem eigenen Buchungsdatum galt, in eine gemeinsame Reporting-Währung, und vergleiche dann; vergleiche nicht einen veralteten Saldo in Reporting-Währung gegen einen frisch neubewerteten, sonst erfindest du eine Differenz, die ausschließlich ein Artefakt davon ist, wann die beiden Snapshots genommen wurden.

Resolution entscheidet. Ein hoher kombinierter Score mit einem kleinen, erklärbaren Residualbetrag innerhalb deiner Wertbandbreite wird als Timing- oder FX-Differenz geklärt, und die Pipeline schlägt die eliminierende Buchung vor. Alles andere ist eine Kandidaten-Differenz mit angehängten Belegen: die beiden Buchungen, die Signale, die übereinstimmten und die nicht, sowie der verwendete Kurs. Ein Prüfer sieht einen Fall, keinen rohen Ledger-Dump.

Das False-Positive-Budget ist die Design-Restriktion, die man gern überspringt. Ein Matcher, der aggressiv auf Paarung getrimmt ist, klärt echte einseitige Buchungen versehentlich – und das ist der eine Fehler, den man sich beim Abschluss nicht leisten kann, weil er eine echte Differenz aus dem Blickfeld nimmt. Wir tunen zugunsten von Recall auf der Differenz-Seite: im Zweifel sichtbar machen. Das bedeutet eine größere manuelle Warteschlange, und es bedeutet, dass die manuelle Warteschlange schnell abzuarbeiten sein muss – weshalb das Beleg-Bündel wichtiger ist als der reine Match-Prozentsatz.

So hält es beim Abschluss stand

Eine Zahl in einer Eliminierungsbuchung muss Wochen später noch verteidigbar sein, wenn ein Prüfer fragt, wie aus diesen beiden Buchungen eine wurde. Das ist ein Audit-Trail- und Lineage-Problem – und genau daran scheitern die meisten schnellen Automatisierungen.

• Lineage bei jeder Klärung. Jedes automatisch geklärte Paar hält die Quellzeilen, den Kurs und seine Quelle, die Regel- oder Modellversion, die sie gematcht hat, sowie den Score fest. Die Reproduktion der Entscheidung darf nicht davon abhängen, ein Modell erneut laufen zu lassen, das seither gedriftet ist.
• Ein eingefrorenes Eval-Set bekannter Differenzen. Nimm eine Periode, die du vollständig von Hand abgestimmt hast, und halte sie zurück. Jede Änderung an Blocking-Fenstern, Scoring-Gewichten oder Schwellenwerten läuft dagegen, bevor sie Live-Abschlussdaten berührt. Ohne das tunest du nach Bauchgefühl und entdeckst Regressionen erst zum Quartalsende.
• Rate-Governance. Entscheide einmal, welche Kursquelle und welche Zeitkonvention du für die Point-in-Time-Umrechnung verwendest, und speichere sie mit dem Match. Wenn zwei Leute über einen Residualbetrag streiten, liegt es fast immer daran, dass sie zu unterschiedlichen Kursen umgerechnet haben.
• Drift-Überwachung des Mixes. Verfolge die Kategorienverteilung über die Zeit. Ein plötzlicher Anstieg von Referenz-Mismatch-Differenzen bedeutet in der Regel, dass ein Upstream-System geändert hat, wie es Referenzen setzt – nicht, dass die Reconciliation schlechter geworden ist. Die Pipeline sollte dir sagen, welches.

Einem Modell hinterherzujagen, das alles klärt, ist das falsche Ziel. Eine gute Pipeline schiebt das Timing- und FX-Rauschen automatisch durch, übergibt einem Prüfer eine kurze Warteschlange echter Differenzen mit bereits zusammengestellten Belegen und hinterlässt einen Nachweis, der das Audit übersteht. Bringe die Entity Resolution und das Point-in-Time-FX in Ordnung, und das Matching hört auf, der schwierige Teil zu sein. Der schwierige Teil werden dann die beiden Upstream-Ledger, die nie dafür entworfen wurden, übereinzustimmen – und genau dorthin sollte die Arbeit gehen.