Warum das Geld eines OTA nie zum Buchungsbetrag passt

Drei Zahlen, routinemäßig als eine behandelt

Eine Kanalbuchung trägt mindestens drei finanzielle Größen, und sie sind nicht austauschbar:

• Der Bruttobetrag. Was der Gast gezahlt hat — und die einzige Zahl, die die meisten Systeme speichern.
• Die Provision. Der Abzug des Kanals, und immer seltener eine einzige Zahl, da manche Kanäle für verschiedene Aufenthaltsarten unterschiedliche Sätze berechnen.
• Die Zahlungsgebühren. Kartenkosten, getrennt von der Provision, mal vom Kanal berechnet, mal von dem, der eingezogen hat.

Auf dem Konto landet die vierte Zahl: die Nettoauszahlung, also Brutto minus der Summe der anderen beiden. Wer nur das Brutto speichert, hat ein Buchungsjournal, das sich nicht mit einem Kontoauszug abgleichen lässt — der tatsächliche Umsatz lebt dann in einer Tabelle, die jemand von Hand pflegt.

NULL ist ein echter Wert, Null ist eine Behauptung

Das ist der Teil, der die Auswertung still verdirbt. Wenn ein Kanal seine Provision nicht meldet — und viele Integrationen tun das nicht, für bestimmte Aufenthaltsarten oder Tarifversionen — gibt es zwei Wege, sie zu speichern.

Als Null, was eine Behauptung ist: diese Buchung hat uns keine Provision gekostet. Als NULL, was eine andere Behauptung ist: wir wissen nicht, was sie gekostet hat.

Eine Direktbuchung hat wirklich null Abzug. Eine Kanalbuchung mit fehlender Provision nicht — und sind beide gleich gespeichert, kann kein Bericht sie je wieder trennen. In Boris sind alle vier Kanalspalten absichtlich nullable; das ist keine Schlamperei bei Standardwerten, sondern die einzige Möglichkeit, dass eine Margenzahl später sagen kann, wie viel von ihr unbekannt ist.

Eine Seite ableiten, nie beide

Die Anbieter sind sich nicht einig, welche Zahlen sie senden. Dieselbe Reservierung kommt mit Provision und ohne Netto, mit Netto und ohne Provision, mit beidem oder mit keinem — und das Feld heißt hostPayout, netAmount, payoutAmount, ownerRevenue oder importoNetto, je nach Anbieter, manchmal verschachtelt in einem money- oder financials-Block.

Das zu normalisieren ist undankbare Arbeit, und es gibt genau eine Regel, die es lohnt auszusprechen: die weggelassene Seite darf man berechnen, beide nicht.

• Provision bekannt → Netto ist Brutto minus Provision minus Gebühren.
• Netto bekannt → die Provision ist der Rest, und rundet dieser Rest auf Null, bleibt sie unbekannt statt zu einer selbstsicheren 0,00 € zu werden.
• Keines bekannt → beide bleiben NULL. Die Buchung ist weiterhin korrekt; sie behauptet nur nicht, ihre eigene Marge zu kennen.

Der Abgleich muss zwei Beträge pro Buchung akzeptieren

Fast jede Abgleichlogik vergleicht eine Gutschrift mit dem offenen Betrag der Buchung. Das funktioniert bei Direktbuchungen und scheitert bei jeder Kanalbuchung, denn die Gutschrift ist das Netto.

Die Korrektur ist klein: beim Zuordnen einer Transaktion gilt die gespeicherte Nettoauszahlung als zweiter akzeptabler Betrag derselben Buchung, mit ein paar Cent Toleranz, und es wird vermerkt, welcher der beiden gepasst hat. In Boris steht dieser Vermerk an der Zuordnung selbst — eine über das Netto zugeordnete Gutschrift ist ein anderer Beleg als eine über das Brutto, und wenn man einem Steuerberater einen Monat erklärt, ist dieser Unterschied die ganze Antwort.

Zwei Feinheiten zahlen sich aus: den Abgleich zeitlich begrenzen, damit eine Gutschrift von 412,37 € sich nicht an einen acht Monate alten Aufenthalt hängt, der zufällig dasselbe kostete. Und Buchungen überspringen, die bereits eine nicht stornierte Rechnung haben, denn dieses Geld hat ein anderes Zuhause.

Sammelauszahlungen sind die nächste Wand

Das Netto pro Buchung löst den Fall der einzelnen Gutschrift. Kanäle, die alle zwei Wochen eine Überweisung für vierzehn Aufenthalte schicken, sind schwieriger — und man sollte ehrlich über die Reihenfolge sein: man kann keinen Sammelbetrag aufteilen, den man nicht bewerten kann. Das erwartete Netto pro Buchung zu speichern macht den Sammelbetrag überhaupt auflösbar, denn dann ist er eine Summe, nach der man suchen kann, und keine Zahl, die niemand erklären kann.

Was man einen Bericht fragt, bevor man ihm glaubt

Zeigt ein Dashboard eine Take Rate pro Kanal, stelle ihm zwei Fragen:

1. Wie viele Buchungen in dieser Zahl haben gar keine Provision gemeldet?
2. Nutzt die Netto-Spalte das gemeldete Netto oder das Brutto, wo das Netto fehlt?

Die Kanalmarge in Boris zählt Zeilen ohne gemeldete Provision separat und zeigt diese Zahl neben dem Satz — deshalb ist der Satz dort manchmal als Untergrenze bezeichnet. Ein Bericht, der nicht sagen kann, wie viel von ihm geschätzt ist, ist nicht genauer als einer, der es kann; er ist nur selbstsicherer.