EDI-Anbindung an Odoo: Bestellungen automatisch austauschen
Kurz gesagt
EDI ist der Austausch von Bestellungen, Lieferavis und Rechnungen in einem festgelegten Format. Odoo 19.0 und 20.0 sendet und empfängt Rechnungen über Peppol (laut Dokumentation BIS Billing 3.0, XRechnung CIUS und NLCIUS, Registrierung kostenlos) und liest im Verkauf UBL-Bestelldateien; ein EDIFACT- oder EANCOM-Format nennt die Odoo-Dokumentation nicht. In Deutschland müssen inländische Unternehmer bei Umsätzen zwischen im Inland ansässigen Unternehmern seit 1. Januar 2025 E-Rechnungen empfangen können; die Übergangsregel nach § 27 Abs. 38 UStG gilt nur für Formate, die § 14 Abs. 1 Satz 6 UStG nicht entsprechen: Papier oder ein anderes elektronisches Format, Letzteres nur mit Zustimmung des Empfängers, bis 31. Dezember 2026 für vor 2027 ausgeführte Umsätze und bis 31. Dezember 2027 für 2027 ausgeführte Umsätze bei einem Vorjahres-Gesamtumsatz bis 800.000 Euro; per EDI mit Zustimmung des Empfängers ohne Umsatzgrenze bis 31. Dezember 2027.
Das Wichtigste
- Odoo 19.0 und 20.0: Peppol-Registrierung laut Dokumentation kostenlos, auch in Odoo Community.
- Verkauf liest UBL-Bestelldateien (Odoo-Dokumentation 19.0 und 20.0); die Peppol-Kennung urn:fdc:peppol.eu:poacc:trns:order:3 belegt der öffentliche Community-Quellcode.
- Die Odoo-Dokumentation nennt als Formate BIS Billing 3.0, XRechnung CIUS und NLCIUS und für Bestellungen den UBL-Austausch; ein EDIFACT- oder EANCOM-Format führt sie nicht.
- Deutschland: E-Rechnungen müssen bei Umsätzen zwischen im Inland ansässigen Unternehmern ab 1. Januar 2025 empfangen werden können; § 27 Abs. 38 UStG erlaubt für Formate, die § 14 Abs. 1 Satz 6 UStG nicht entsprechen, Papier oder ein anderes elektronisches Format, Letzteres nur mit Zustimmung des Empfängers, bis 31. Dezember 2026 für vor 2027 ausgeführte Umsätze und bis 31. Dezember 2027 für 2027 ausgeführte Umsätze bei einem Vorjahres-Gesamtumsatz bis 800.000 Euro; per EDI mit Zustimmung des Empfängers ohne Umsatzgrenze bis 31. Dezember 2027.
- Österreich: Elektronische Rechnung nur mit Zustimmung des Empfängers und gesicherter Echtheit, Unversehrtheit und Lesbarkeit (§ 11 Abs. 2 UStG 1994).
- Schweiz: Rechnungen an den Bund sind elektronisch einzureichen, als PDF per E-Mail oder als strukturierter Datensatz über einen Service-Provider; Kleinbeschaffungen sind ausgenommen (EFV).
Wer mit einem Handelspartner regelmäßig Bestellungen, Lieferavis und Rechnungen austauscht, stößt auf zwei Fragen: Welches Format verlangt der Partner, und welcher Weg führt die Daten in Odoo hinein oder aus Odoo heraus. Die Antworten hängen zusammen, sind aber nicht dieselbe. Odoo deckt Rechnungen über das Peppol-Netzwerk ab und liest Bestelldateien im UBL-Schema; EDIFACT- und EANCOM-Dateien nennt die Odoo-Dokumentation dagegen nicht. Für solche Partner ist die Umwandlung außerhalb von Odoo ein möglicher Anbindungsweg.
Worauf es bei EDI ankommt
EDI (Electronic Data Interchange) ist der Austausch von Geschäftsdokumenten zwischen zwei Unternehmen in einem festgelegten, maschinenlesbaren Format, sodass das empfangende System die Daten ohne Neuerfassung zuordnen kann. Um vier Dokumentarten geht es dabei: Bestellung, Bestellantwort, Lieferavis und Rechnung. Die Peppol-Spezifikation führt sie als eigene Transaktionen (Order, Order Response, Despatch Advice, Invoice Response, Billing).
Für Odoo zählt die Richtung. Bestellungen kommen entweder von Ihrem Kunden herein und werden zum Verkaufsauftrag, oder Sie senden sie an Ihren Lieferanten. Rechnungen gehen in beide Richtungen und sind der Teil, für den in Deutschland und Österreich eigene Formvorgaben gelten (siehe unten).
Welche Formate kommen für den Austausch infrage?
Die Tabelle ordnet die gebräuchlichen Formate nach Herausgeber, typischen Nachrichten und dem, was Odoo 19.0 und 20.0 damit tut.
| Format | Herausgeber und Stand | Typische Nachrichten | Odoo 19.0 und 20.0 |
|---|---|---|---|
| UN/EDIFACT, in der Handelspraxis als GS1 EANCOM | UN/EDIFACT ist der Standard der Vereinten Nationen; EANCOM ist die GS1-Teilmenge, aktuelle Ausgabe EANCOM 2022 | ORDERS, ORDRSP, DESADV, INVOIC, PRICAT | Die Odoo-Dokumentation nennt kein EDIFACT- oder EANCOM-Format; ein Weg ist die Umwandlung außerhalb von Odoo |
| GS1 XML | GS1, aktuelle Version 3.7.1 (Stand 8. September 2025) | Order, Order Response, Despatch Advice, Invoice | ebenso nennt die Dokumentation kein GS1-XML-Format; ein Weg ist die Übergabe als UBL, CSV oder über die API |
| Peppol BIS Billing 3.0 | OpenPeppol AISBL, Fassung Mai 2026; UBL-Syntax | Rechnung, Gutschrift | Senden und Empfangen über Peppol; die Dokumentation nennt als Sendeformate BIS Billing 3.0, XRechnung CIUS und NLCIUS |
| Peppol Order (Transaktion 3) im Profil Peppol BIS Ordering | OpenPeppol AISBL; das Profil BIS Ordering 3.3 umfasst Order und Order Response, Lieferavis ist ein eigenes Peppol-BIS (Despatch Advice) | Bestellung, Bestellantwort | Verkauf liest Bestelldateien und Einkauf erzeugt sie (UBL-Schema laut Dokumentation); die Kennungen urn:fdc:peppol.eu:poacc:trns:order:3 (Verkauf) und urn:fdc:peppol.eu:poacc:bis:ordering:3 (Einkauf) belegt der öffentliche Community-Quellcode |
| XRechnung und ZUGFeRD (ZUGFeRD ab Version 2.0.1, ohne die Profile MINIMUM und BASIC-WL), beide nach EN 16931 | KoSIT (XRechnung; gültige Spezifikation Version 3.0.2, in Kraft mindestens bis 31. Juli 2027; Version 4.0 im September 2026 nur als Vorversion, final voraussichtlich Frühjahr 2027); FeRD (ZUGFeRD, PDF/A-3 mit eingebettetem XML) | Rechnung | für den Ländercode DE führt der öffentliche Community-Quellcode die Formate Germany (XRechnung) und Germany (ZUGFeRD); die offizielle EDI-Dokumentation nennt als Sendeformate BIS Billing 3.0, XRechnung CIUS und NLCIUS und kein ZUGFeRD |
| Order-X | FeRD; Bestellformat auf Basis der Cross-Industry-Order von UN/CEFACT, ebenfalls PDF mit XML | Bestellung, Bestellantwort | kein Import in der Dokumentation beschrieben; Bestelldateien erkennt der öffentliche Community-Quellcode an der Peppol-UBL-Kennung |
| XBestellung | KoSIT, Version 2.0; setzt auf Peppol BIS Order only 3.3 auf | Bestellnachricht in der öffentlichen Beschaffung | kein Import in der Dokumentation beschrieben; Übergabe als Datei oder über einen Dienstleister |
Welche Wege führen zu Odoo?
Für den Austausch mit Odoo kommen vier Wege in Frage. Keiner davon ist an einen bestimmten Anbieter gebunden; die Übertragungsstrecke können Sie je Partner wechseln.
| Weg | Was Odoo 19.0/20.0 beisteuert | Voraussetzung | Geeignet für |
|---|---|---|---|
| Peppol über Odoo | Odoo tritt laut Dokumentation als Access Point und SMP auf: Rechnungen und Gutschriften senden, Eingangsrechnungen abholen; Registrierung kostenlos, laut Dokumentation auch in Odoo Community | Land des Unternehmens steht in der Peppol-Liste der Dokumentation; Kennung (Schema und Wert) eintragen; Abholung im gewählten Einkaufsjournal oder im Dokumentenordner (Letzteres nur Enterprise) | Rechnungen, Gutschriften, Eingangsrechnungen |
| Dateiaustausch in der Oberfläche | Verkaufsaufträge aus UBL-Bestelldateien per Ziehen und Ablegen oder Einfügen in der Auftragsliste; Einkauf erzeugt Bestellungen als UBL; CSV und XLSX für Stammdaten und Belege | passendes Format; Bestellimport/-export laut Odoo-Dokumentation, Peppol-Kennungen laut öffentlichem Community-Quellcode | einzelne Bestellungen, Einstieg und Test |
| Eigene Anbindung über die externe API | JSON-2 mit POST auf /json/2/Modell/Methode und API-Schlüssel (neu in Odoo 19.0); Webhooks nehmen Ereignisse aus Fremdsystemen entgegen (Studio, Enterprise) | externe API laut Dokumentation nur in den Custom-Tarifen von Odoo Online; XML-RPC und JSON-RPC sind abgekündigt; Odoo Online lässt keine eigenen Module zu | laufender, getakteter Austausch |
| Umwandlung bei einem EDI-Dienstleister | Odoo liest die Zielformate (UBL, CSV) oder schreibt über die API; die Umwandlung von EDIFACT, EANCOM oder GS1 XML übernimmt der Dienstleister | Vertrag und Übergabeformat festlegen; Artikelnummern und Einheiten beider Seiten zuordnen | EDIFACT- und EANCOM-Partner, hohe Volumina |
Ein Rechenbeispiel
Beispielrechnung mit erfundenen Zahlen und der Annahme von 45 Euro Lohnkosten je Stunde: Ein Handelsbetrieb erhält 60 Bestellungen im Monat mit durchschnittlich 12 Positionen, zusammen 720 Positionen. Die manuelle Erfassung dauert 2 Minuten je Position, also 24 Stunden. Nach der Umstellung prüft der Betrieb jede eingelesene Bestellung 3 Minuten lang und braucht dafür 3 Stunden.
| Größe | manuell | mit Bestellimport |
|---|---|---|
| Bestellungen im Monat | 60 | 60 |
| Positionen im Monat | 720 | 720 |
| Minuten je Position | 2 | entfällt |
| Minuten je Bestellung (Prüfung) | entfällt | 3 |
| Zeitaufwand im Monat | 24 Stunden | 3 Stunden |
| Lohnkosten bei 45 Euro je Stunde | 1.080 Euro | 135 Euro |
Die Einsparung von 945 Euro hängt an einer Annahme: dass die Prüfung kurz bleibt. Genau dort entsteht der Aufwand. Bestellungen sind nur dann ohne Rückfragen zu verarbeiten, wenn Artikelnummern, Mengeneinheiten, Preise und Steuern beider Seiten einander zugeordnet sind.
Typische Fehler
- Artikelnummern fehlen. Der Partner sendet seine eigene Artikelnummer. Im öffentlichen Community-Quellcode sucht der Bestellimport das Produkt einer Zeile zuerst über die Kennungen aus der Datei (Barcode, Artikelnummer, Variantenkennung) und über den Namen und in 20.0 danach über die beim Kunden hinterlegte Produktreferenz; die Namenssuche vergleicht zuletzt über eine Ähnlichkeitsschwelle, die Odoo aus dem Systemparameter account.product_name_similarity_threshold liest; ohne gesetzten Wert beträgt sie 0,9 (90 Prozent) und lässt sich über diesen Parameter ändern. Erst wenn diese Suchen leer ausgehen, bleibt die Position ohne Produkt, und die Community-Fassung legt am Verkaufsauftrag eine Aktivität an, die die betroffenen Zeilen auflistet. Pflegen Sie die Nummern vorher, etwa über Lieferantenpreislisten.
- Rabatte und Staffeln fehlen. EDI-Bestellungen können Nettopreise und eigene Rabattzeilen enthalten. Fehlen diese Zeilen, stimmt die Auftragssumme nicht, obwohl der Einzelpreis richtig ist.
- Mengeneinheiten weichen ab. Bestellmenge in Stück oder Karton: ohne Umrechnung liefert Odoo die falsche Menge.
- PDF statt XML. Eine Bestellung als reines PDF ist keine Nachricht im XML-basierten Austausch; die Dokumentation beschreibt für diesen Fall den Upload der PDF-Anfrage im Verkaufs-Dashboard.
- Dieselbe Datei zweimal geladen. Der Upload einer Bestelldatei im Verkaufsbereich erzeugt laut Dokumentation automatisch einen Verkaufsauftrag. Prüfen Sie vor dem Bestätigen, ob die Bestellnummer des Partners bereits als Auftrag vorliegt, und laden Sie dieselbe Datei nicht ein zweites Mal.
- Die Partnerkennung fehlt oder ist falsch. Über Peppol erreicht der Status einer Rechnung erst dann Done, wenn das Dokument beim Access Point des Empfängers angekommen ist; die Dokumentation verlangt, den Kontakt vorher als Peppol-Teilnehmer zu prüfen.
Was in Deutschland, Österreich und der Schweiz gilt
In Deutschland müssen inländische Unternehmer E-Rechnungen bei Umsätzen zwischen im Inland ansässigen Unternehmern seit 1. Januar 2025 empfangen können; die Regelung gilt für nach dem 31. Dezember 2024 ausgeführte Umsätze, und für den Empfang gibt es keine Übergangsregelung (§ 14 Abs. 1 Satz 5, Abs. 2 Satz 2 Nr. 1 UStG). Für die Ausstellung verlangt § 14 Abs. 1 Satz 6 UStG ein strukturiertes elektronisches Format, das der europäischen Norm EN 16931 (Richtlinie 2014/55/EU) entspricht oder nach Nr. 2 zwischen Aussteller und Empfänger vereinbart ist; ein vereinbartes Format muss die richtige und vollständige Extraktion der Pflichtangaben in ein EN-16931-konformes oder damit interoperables Format ermöglichen. § 27 Abs. 38 UStG erlaubt Übergänge nur für Formate, die § 14 Abs. 1 Satz 6 UStG nicht entsprechen: Papier bis 31. Dezember 2026 für vor dem 1. Januar 2027 ausgeführte Umsätze (Nr. 1) und bis 31. Dezember 2027 für 2027 ausgeführte Umsätze bei einem Vorjahres-Gesamtumsatz bis 800.000 Euro (Nr. 2); ein anderes elektronisches Format ist nach Nr. 1 und 2 nur mit Zustimmung des Empfängers zulässig, per EDI nach Nr. 3 ebenfalls mit Zustimmung des Empfängers ohne Umsatzgrenze bis 31. Dezember 2027. Ein EDI-Verfahren, dessen Format die Anforderungen des § 14 Abs. 1 Satz 6 UStG erfüllt, bleibt auch nach dem 31. Dezember 2027 eine zulässige E-Rechnung. Das BMF-Schreiben vom 15. Oktober 2024 nennt EDI-Verfahren wie EDIFACT als ein solches zwischen den Parteien vereinbartes Format (Rn. 24, 33).
In Österreich gilt eine elektronische Rechnung nur als Rechnung, wenn der Empfänger dieser Form zustimmt und Echtheit der Herkunft, Unversehrtheit des Inhalts und Lesbarkeit gewährleistet sind (§ 11 Abs. 2 UStG 1994).
In der Schweiz regelt die Eidgenössische Finanzverwaltung die Rechnung an den Bund: Lieferanten reichen Rechnungen elektronisch ein, entweder als PDF per E-Mail oder als strukturierter Datensatz über einen Dienstleister; Kleinbeschaffungen sind ausgenommen.
So gehen Sie vor
- Klären Sie je Partner, welche Dokumente in welche Richtung laufen und welches Format er verlangt. Schreiben Sie Format und Ansprechpartner in die Stammdaten.
- Ordnen Sie Artikelnummern, Mengeneinheiten, Steuern und Preise zu, zuerst bei den Partnern mit der höchsten Bestellfrequenz.
- Testen Sie mit einer echten Datei in einer Kopie der Datenbank. Bei Odoo Online ist in der Kopie standardmäßig die Option für Testzwecke aktiv, die alle externen Aktionen abschaltet; die Kopie läuft nach 15 Tagen ab.
- Für Rechnungen: Format und Peppol-Kennung je Kunde festlegen; die Peppol-Registrierung sitzt in den Buchhaltungs-Einstellungen im Abschnitt PEPPOL Electronic Invoicing (so die Bezeichnung in der Dokumentation). Das Vorgehen beschreiben die Artikel Peppol mit Odoo, E-Rechnung senden und E-Rechnung empfangen.
- Für Bestellungen: Erst den Dateiimport erproben, dann die Übertragung automatisieren, über die externe API oder über einen Dienstleister. Die API-Grundlagen stehen im Artikel Odoo-API im Überblick.
- Prüfen Sie jede eingelesene Bestellung vor der Bestätigung auf Menge, Preis und Liefertermin und halten Sie Abweichungen fest. Wer die Prüfung überspringt, verlagert den Fehler nur an eine spätere Stelle.