NDC-Konnektivität: Warum es bei der direkten Integration nicht nur um technische Aspekte geht
Ich habe mich kürzlich mit einem Kollegen unterhalten, der überlegt, direkt NDC-Integrationen für sein Reisebüro. Die Frage, die er stellte, war völlig logisch: Warum sollte man einen Aggregator oder einen anderen Vertriebskanal nutzen, wenn das Reisebüro direkt mit der Fluggesellschaft in Kontakt treten kann?
Auf dem Papier klingt ein solcher Ansatz verlockend. Die Agentur erhält mehr Kontrolle über die Inhalte, kann eigene Tarife und Zusatzleistungen direkt präsentieren und ist nicht vollständig von den Möglichkeiten der Vermittlungsplattform abhängig.
Das Gespräch wandte sich jedoch schnell einer wichtigeren Frage zu: Was passiert, nachdem das Ticket verkauft wurde?
Kann ein Reisevermittler das Datum einfach ändern? Kann er die Preisdifferenz automatisch berechnen, eine Teilrückerstattung vornehmen oder Gepäck hinzufügen? Wie wird eine Änderung des Flugplans abgewickelt? Was passiert mit den Buchhaltungsdaten und der Zahlung?
Gerade bei diesen Fragen wird deutlich, dass es bei der NDC-Integration nicht nur darum geht, eine Verbindung zu einer anderen API herzustellen.
NDC ist keine einheitliche, universelle API.
Die IATA definiert „New Distribution Capability“ als einen offenen Datenaustauschstandard, der auf der Verwaltung von Angeboten und Bestellungen basiert. Das Ziel ist Fluggesellschaften damit sie über verschiedene Vertriebskanäle umfangreichere Inhalte, zusätzliche Dienstleistungen und noch besser auf die Kundenbedürfnisse zugeschnittene Produkte anbieten können.
Der Begriff „NDC-Standard” kann jedoch den falschen Eindruck erwecken, dass alle Fluggesellschaften dieselbe technische Schnittstelle und dieselben Geschäftsprozesse nutzen.
In der Praxis existieren mehrere Generationen von NDC-Systemen gleichzeitig nebeneinander. Zudem entscheiden die Fluggesellschaften selbst, welche Funktionen sie implementieren. Zwei Fluggesellschaften können zwar dieselbe Version verwenden, haben jedoch völlig unterschiedliche Abläufe beim Kauf von Zusatzleistungen, bei der Änderung einer Buchung oder bei der Beantragung einer Rückerstattung.
Deshalb sagt die Bezeichnung „NDC-fähig” nicht viel über die tatsächliche Benutzererfahrung des Agenten aus. Die Anbindung unterstützt zwar die Suche und Buchung, erfordert aber gleichzeitig die manuelle Bearbeitung fast aller komplexeren Vorgänge nach dem Verkauf.
Vom Verkauf von Zusatzleistungen bis zur Auftragsabwicklung
Die im Jahr 2017 veröffentlichte Version 17.2 wurde zur ersten allgemein anerkannten operativen Grundlage von NDC. Sie trennte die Suche, die Validierung und die endgültige Erstellung der Buchung klarer voneinander. Sie verbesserte die Sitzplatzanzeige, den Verkauf von Zusatzleistungen sowie die Bearbeitung von Umbuchungen und Stornierungen.
Obwohl inzwischen weiterentwickelte Versionen veröffentlicht wurden, wird die Version 17.2 nach wie vor von einer Reihe von Fluggesellschaften und Technologieanbietern genutzt. Der Grund dafür liegt nicht unbedingt in technologischer Rückständigkeit. Für viele Fluggesellschaften deckt diese Version nach wie vor den Großteil ihrer geschäftlichen Anforderungen ab, während eine Umstellung Änderungen an einer größeren Anzahl miteinander verbundener Systeme erfordern würde.
In den Versionen 18.x, 19.x und 20.x wurde NDC schrittweise um strukturierte Regeln für Tarife, Zahlungen, Abrechnungen und die Finanzberichterstattung erweitert. Infolgedessen geht der Standard mittlerweile über den reinen Kauf eines Flugtickets hinaus.
Mit den 21.x-Versionen kam es zu einer grundlegenden strukturellen Veränderung. Gemeinsame Datenelemente reduzierten einige der Unstimmigkeiten zwischen Angeboten und Aufträgen, während die Funktion „OrderQuote“ es ermöglichte, die finanziellen Auswirkungen zu bewerten, bevor Änderungen an der Kalkulation bestätigt wurden. Die Version 21.3 wurde zu einem wichtigen neuen Ausgangspunkt für umfassendere Serviceprozesse und die zukünftige Weiterentwicklung des „Offers and Orders“-Modells.
In den Versionen 24.x wurden Bestellpositionen, Zahlungen, Strafgebühren und der Restwert nicht in Anspruch genommener Leistungen noch enger miteinander verknüpft. Dies ist für Reisebüros wichtig, da es ein genaueres Verständnis dafür ermöglicht, wie viel ein Passagier nach einer Umbuchung zahlen muss oder wie viel die Fluggesellschaft ihm schuldet.
Die neueste Version ist nicht immer die wichtigste.
Am 16. März 2026 veröffentlichte die IATA das Standardpaket 26.1. Zu den wichtigsten Neuerungen zählten die Möglichkeit, eine einzelne Bestellposition mit mehreren Zahlungsmethoden zu begleichen, die Gebührensimulation vor der Transaktionsbestätigung sowie ein detaillierterer Datenaustausch zu Mehrwertsteuer, GST und anderen Verbrauchssteuern.
Version 26.2 wurde am 4. Juni 2026 veröffentlicht, doch die wichtigsten Änderungen betrafen vor allem Meldungen im Zusammenhang mit Gepäck. Dies zeigt deutlich, warum eine höhere Versionsnummer nicht automatisch eine wesentliche Änderung für jedes Reisebüro bedeutet.
Für die Behörde ist es wichtiger, ob eine bestimmte Integration ihre Prozesse unterstützt, als ob dabei die technisch fortschrittlichste Lösung zum Einsatz kommt.
Eine direkte Integration bringt Kontrolle mit sich, aber auch Verantwortung.
Eine direkte Anbindung kann für ein Reisebüro sinnvoll sein, das große Volumina mit einer geringeren Anzahl strategisch wichtiger Fluggesellschaften abwickelt. Sie kann auch dann gerechtfertigt sein, wenn das Reisebüro eine eigene Plattform entwickelt, ein maßgeschneidertes Nutzererlebnis gestalten möchte oder Inhalte benötigt, die über andere Kanäle nicht in gleichem Maße zugänglich sind.
Jede direkte Verbindung erfordert jedoch Entwicklung, Tests, Überwachung und Wartung. Es müssen verschiedene Antwortformate, Fehler, Authentifizierungsmethoden, Abfragebeschränkungen und Versionsänderungen berücksichtigt werden. Hinzu kommen Zahlungen, Rückerstattungen, Verkehrsstörungen, der Abgleich von Finanzdaten und der Support durch Mitarbeiter.
Das Problem wird noch komplexer, wenn eine Fluggesellschaft zwar ein neueres Such- und Buchungssystem nutzt, für die Abwicklung der Buchungen jedoch einen älteren Prozess verwendet. Solche hybriden Lösungen sind keine Seltenheit, da sie es den Fluggesellschaften ermöglichen, neue Funktionen einzuführen, ohne ihre bestehende Infrastruktur vollständig zu ersetzen.
Ein Aggregator oder GDS beseitigt diese Komplexität nicht. Er übernimmt sie vielmehr selbst und versucht, die verschiedenen Integrationen zu einem einheitlicheren Prozess für das Reisebüro zusammenzufassen. Im Gegenzug hat das Reisebüro möglicherweise weniger Kontrolle über einzelne Funktionen oder ist davon abhängig, wie schnell der Vermittler die Inhalte einer bestimmten Fluggesellschaft einbindet.
Daher handelt es sich bei dieser Entscheidung nicht um eine einfache Wahl zwischen „direkt” und „über einen Vermittler”. Für viele Reisebüros wird das Hybridmodell die beste Lösung sein: direkte Anbindungen an die wenigen wichtigsten Fluggesellschaften, während die übrigen NDC- und traditionellen Inhalte über einen Aggregator oder ein GDS bezogen werden.
Letztendlich habe ich dem Kollegen zu Beginn der Geschichte nicht empfohlen, zunächst zu fragen, welche NDC-Version die Fluggesellschaft verwendet. Sinnvollere Fragen waren: Welche Prozesse können wir von Anfang bis Ende abwickeln, wie viel kostet es uns, diese aufrechtzuerhalten, und was passiert, wenn ein Passagier nach dem Kauf Hilfe benötigt?
Genau dann zeigt sich der wahre Wert der NDC-Integration. Nicht, wenn das Angebot auf dem Bildschirm angezeigt wird, sondern wenn die Buchung ohne manuellen Aufwand oder Anrufe beim Kundensupport geändert, bearbeitet und finanziell abgeschlossen werden muss.
