openTRANS ist ein XML-basierter Transaktionsstandard, der häufig von ERP-Systemen, Online-Shops und Marktplätzen angefordert wird. Wir erklären euch die wesentlichen Grundlagen zu diesem Standard ganz einfach und verständlich.

openTRANS ist ein XML-basierter Datenstandard, der speziell für den automatisierten Austausch von Geschäftsdokumenten wie Rechnungen, Aufträgen oder Lieferavisen entwickelt wurde. Er fungiert als einheitliche Sprache zwischen verschiedenen Systemen wie ERP-Lösungen, Online-Shops und eProcurement-Plattformen. Das Zweck von openTRANS ist also, den Datenaustausch zwischen Lieferanten und Empfängern effizienter zu gestalten. Technisch ist der Datenstandard in strukturierte Bereiche – Header, Positionsliste und Zusammenfassung – unterteilt. Die Einhaltung präziser Vorgaben zu Feldern und Inhalten ist hier besonders wichtig. Dank seiner engen Verwandtschaft zum ebenfalls XML-basierten Standard BMEcat und seiner breiten Kompatibilität hilft openTRANS dabei, Bestellvorgänge zu standardisieren und langfristig Zeit sowie Kosten zu sparen. Da die Implementierung jedoch komplex sein kann, empfiehlt sich der Einsatz spezialisierter Datenmanagement-Software oder entsprechender Schnittstellen.
openTRANS ist ein XML-basierter Datenstandard, der zum automatisierten Austausch von Geschäftsdokumenten dient. Spezifisch fällt openTRANS also unter die Kategorie der Transaktionsstandards.
Wie schon der Datenstandard BMEcat im Jahr 1999, wurde der openTRANS-Standard im Jahr 2001 vom „eBusiness Standardization Committee“ in Zusammenarbeit mit dem Fraunhofer IAO entwickelt. Das Ziel dieser Institutionen war, Geschäftsprozessdokumente zu standardisieren und dadurch Zeit und Kosten im Rahmen der Bestellvorgänge zu reduzieren. Durch die Kooperation bei der Entwicklung sind der BMEcat und openTRANS ähnlich aufgebaut und verwenden häufig gleiche Datenstrukturen.
Obwohl der openTRANS-Standard hauptsächlich in Deutschland eingesetzt wird, steht er sowohl in deutscher als auch in englischer Sprache zur Verfügung. Ihr könnt damit also auch internationale Geschäftsdokumente austauschen.
Hinweis: Redaktionelles Update im April 2026 (Fachlicher Stand: Mai 2024)
Wie bei den meisten Datenstandards gibt es auch bei openTRANS verschiedene Versionen.
Bislang wurden drei Versionen entwickelt: openTRANS 1.0, 2.0 und die aktuelle Version 2.1. Es ist jedoch wichtig zu beachten, dass die Version 2.1 nicht rückwärtskompatibel zu 1.0 ist. Trotzdem weisen beide Versionen eine ähnliche Struktur auf. Daher sollte es vergleichsweise einfach sein, euer Softwaresystem auf die neueste Version anzupassen.
Der Standard wird überall dort eingesetzt, wo standardisierte Geschäftsdokumente wie Auftragsbestätigungen und Rechnungen ausgetauscht werden müssen. Demnach gibt es viele verschiedene Anwendungsfälle für den Datenaustausch zwischen unterschiedlichen Systemen wie ERP, Lieferantensystemen, Shops, eProcurement-Plattformen und Marktplätzen, wie Mercateo. Mercateo kommuniziert beispielsweise über openTRANS 1.0.
Der Standard schreibt euch im Übrigen nicht vor, wie ihr die Geschäftsprozesse gestalten sollt. Ihr bzw. eure Geschäftspartner oder Marktplätze entscheiden selbst, wie und welche Dokumente ausgetauscht werden. openTRANS gibt euch also lediglich vor, welche Felder gepflegt werden müssen und wie lang diese Felder sein dürfen.
BMEcat und openTRANS ähneln sich im Aufbau ziemlich, nicht zuletzt aufgrund ihrer XML-Struktur.
Für den Austausch der elektronischen Geschäftsdokumente stellt openTRANS zehn standardisierte Dokumenttypen zur Verfügung, die genutzt werden können:
Diese Dokumente weisen von der Struktur her einen ähnlichen Aufbau auf. Im unteren Bild seht ih die grobe Struktur anhand einer openTRANS-Rechnung.

Es gibt eine Version, den Header bzw. Kopfbereich, den Positionsbereich, also die ITEM List, und die Zusammenfassung, bzw. Summary. Jedes openTRANS-Dokument muss diese Bereiche abbilden. Denn wie beim BMEcat gibt es auch dort Pflicht (rot) – und optionale Felder (grün). Ein Dokument ist dabei openTRANS-konform, wenn es alle Pflichtfelder enthält und keine zusätzlichen Felder aufweist, die nicht in der Spezifikation definiert sind. Die Felder müssen außerdem in der richtigen Reihenfolge und mit der vorgegebenen Häufigkeit vorhanden sein.
Die Versionsangabe ist weitgehend selbsterklärend. Sie bezieht sich einfach auf die Ausgabe des openTRANS-Formats, also openTRANS 1.0 oder 2.0 beziehungsweise 2.1.
Im Kopfbereich oder Header wird es bereits komplexer. Hier werden Informationen beschrieben, die das gesamte Geschäftsdokument betreffen. Je nach Dokumenttyp enthält der Header unterschiedliche Abschnitte. Bei einer openTRANS-Rechnung umfasst der Header drei Abschnitte: CONTROL_INFO, INVOICE_INFO und ORDER_HISTORY.

CONTROL_INFO enthält Informationen zur automatischen Verarbeitung des Dokuments. Hier ist eine mögliche Struktur der CONTROL_INFO:

GENERATION_DATE ist dabei der Erstellzeitpunkt der Rechnung. Natürlich könnt ihr auch noch weitere Elemente in CONTROL_INFO pflegen. Bei der CONTROL_INFO handelt es sich im Gegensatz zur INVOICE_INFO um ein optionales Feld.
INVOICE_INFO beschreibt die Rechnungsinformationen. Im Folgenden sind alle Pflichtfelder in Rot und alle optionale Felder in Grün, die bei der INVOICE_INFO gepflegt werden können:

Es gibt 27 Elemente – und das nur in der ersten Ebene der Hierarchie. Denn hinter den Pfeilen verbergen sich weitere Felder, die ebenfalls gepflegt werden müssen.
Neben der Invoice_Info und der Control_Info enthält der Header noch die ORDER_History. Diese umfasst die Beschaffungsaktivitäten vor der Rechnungstellung, wie z. B. das Bestelldatum oder die Lieferscheinnummer. Es handelt sich dabei ebenfalls um ein optionales Feld.
Neben dem Headerbereich gibt es auch den Positionsbereich, also die ITEM_LIST. In diesem Abschnitt erfasst ihr eine Liste von Positionen im Geschäftsdokument. Diese Positionen können beispielsweise Produkte in einem Angebot oder einer Rechnung oder Lieferpositionen in einem Lieferavis sein. Dieses Element ist neben dem Header ein weiteres Pflichtfeld.
Den Abschluss des openTRANS-Dokuments bildet die Zusammenfassung oder SUMMARY. Hier werden Informationen dargestellt, die aus den Werten der Positionen berechnet werden können. Dieser Bereich dient hauptsächlich der Kontrolle. In einigen Geschäftsdokumenten, wie beispielsweise der Rechnung, ist dieser Abschnitt gesetzlich vorgeschrieben. Wie beim Header und ITEM_List handelt es sich bei der Summary auch um ein Pflichtfeld.
Ihr seht: Ein openTRANS-Dokument ist ziemlich verschachtelt. Der Header allein gliedert sich in viele Unterebenen, und je nach Art des Geschäftsdokuments variieren die Elemente zusätzlich. Es gibt also einige Hürden zu bewältigen.
Wie ihr jetzt wisst, ist openTRANS ein recht komplexer Standard, bei dem sich eine manuelle Datenpflege nicht wirklich lohnt – zumal die Fehleranfälligkeit dabei nicht unerheblich ist. Eine weitere Hürde liegt auch in der Akzeptanz: Es kann schwierig sein, verschiedene Lieferanten oder Kunden dazu zu bewegen, sich auf einen gemeinsamen Standard zu einigen.
Die Implementierung erfordert eine Schnittstellenanbindung an eure eigenen Systemen (z. B. PIM- oder ERP). Außerdem müsst ihr bestehende Prozesse womöglich überdenken und Mitarbeiter schulen. Die Einrichtung und Übermittlung von openTRANS-Dokumenten kann daher durchaus kostenintensiv sein.
Trotz dieser Herausforderungen bietet euch der openTRANS-Standard auch viele Chancen: Er unterstützt eine breite Palette von Systemen, einschließlich Online-Shops, Marktplätze und ERP-Systeme. Darüber hinaus weisen openTRANS 2.1 Geschäftsdokumente eine hohe Kompatibilität zu BMEcat 2005 Katalogdokumenten auf. Beide Standards verwenden nämlich identische Felder und Strukturen mit identischen Bedeutungen und Regeln. Wenn ihr also bereits mit der BMEcat-Struktur vertraut seid, wird es für euch einfacher sein, eure Daten im openTRANS-Format bereitzustellen.
Mithilfe unsere Softwarelösungen könnt ihr den openTRANS-Standard je nach Use-Case sowohl importieren, verarbeiten und optimal generieren. Dasselbe gilt natürlich auch für viele weitere Datenstandards: Ihr erhaltet beispielsweise BMEcat-Dateien von euren Lieferanten und wollt die darin enthaltenen Daten z. B. passgenau in euer PIM importieren? Oder möchtet ihr BMEcat-Dateien aus diversen Datenquellen generieren und automatisiert an diverse Zielkanäle bereitstellen – etwa für 1WorldSync, 2BA/InstallData, Amazon, ARGE Neue Medien, ausschreiben.de, BEGROS, building-masterdata.com, Conrad, eBay, ELGATE, Galaxus, GS1, Heinze-Lieferantenportal, Mercateo / Unite, Open Datacheck, OTTO, das SAXO-Portal, SAP Ariba, Shopware und simple system?
Dann schaut euch unsere vielseitigen SaaS-Softwarelösungen gerne einmal genauer an:
Wie ein fleißiges Eichhörnchen sammelt, prüft und sortiert das Supplier-Portal eure Lieferantendaten – strukturiert, automatisiert und nachvollziehbar.
Fehlerhafte Angaben werden früh erkannt, fehlende Informationen nachgefordert und alles sauber vereinheitlicht. So landen geprüfte, vollständige Daten direkt in euren Systemen – etwa PIM oder ERP. Für weniger manuelle Nacharbeiten, klar definierte Prozesse und Lieferanten, die wissen, was gefordert wird.
Wie ein wandelbares Chamäleon passt sich CatalogExpress jeder Datenanforderung an – egal ob von Kunden, Marktplätzen oder Datenpools.
Ihr kombiniert damit Produktdaten aus verschiedenen Quellen, prüft die Inhalte, bringt alles in die passende Struktur und verteilt die aufbereiteten Daten automatisiert. Ob individuelle Kundenanforderungen oder Standards wie BMEcat, ETIM & Co. – CatalogExpress generiert euch passende Produktdaten-Feeds schnell, fehlerfrei und jederzeit wiederverwendbar.
Julia ist seit März 2022 in unserem Marketingteam. Als Bachelor of Arts im Dienstleistungsmarketing versorgt Julia euch u. a. mit Inhalten zu Marketingthemen, Success-Storys und zur NEXIpedia.
