Odoo -> XRechnung

Odoo zu XRechnung — Open-Source-ERP für deutsche Behördenrechnungen

Odoo unterstützt seit Version 14 PEPPOL BIS 3.0 nativ über das Modul `account_edi` und seit Version 16 erweiterte EN-16931-Funktionalität für europäische E-Invoicing-Standards. Die deutschen Anpassungen — CIUS-DE-Pflichtfelder, Leitweg-ID-Routing, XRechnung-spezifische Validierungs-Regeln — sind jedoch nicht out-of-the-box verfügbar. Das Community-Modul `l10n_de_xrechnung` (verfügbar im Odoo Apps Store) bietet einen ersten Lösungsansatz, deckt jedoch primär XRechnung 1.x und 2.x ab und wird nicht durchgängig auf den aktuellen 3.0-Standard aktualisiert.

XRechnung-Bereit erweitert Ihre Odoo-Installation um vollumfängliche XRechnung-3.0-Konformität — kompatibel mit Odoo Online (SaaS), Odoo.sh (Hosted) und Self-Hosted-Installationen, von Odoo Community bis Enterprise. Sie nutzen den nativen PEPPOL-Export aus dem `account_edi`-Modul, und unser Tool transformiert das BIS-3.0-XML in CIUS-DE-konforme XRechnung-XML mit allen Pflichtfeldern.

Für Open-Source-Affine ist relevant: XRechnung-Bereit ergänzt Odoo, ersetzt es nicht. Ihr Workflow, Ihre Datenhoheit und Ihre Modul-Konfiguration bleiben unverändert. Die XRechnung-Konvertierung ist ein Post-Processing-Schritt, der via Webhook (Odoo Studio Automation Rule) oder manuell per Web-Upload erfolgt — kein Vendor-Lock-in, keine Modul-Abhängigkeit.

Der praktische XRechnung-Pfad

1

Quelle sichern

Nutzen Sie Odoo als Ausgangspunkt und ziehen Sie fehlende Pflichtfelder frueh nach.

2

XML sauber strukturieren

Leitweg-ID, Steuerlogik, Referenzen und Summen muessen semantisch im richtigen Feld landen.

3

Validator vor Versand

Vor dem Versand an Behoerden sollte die Datei immer gegen aktuelle KoSIT-Regeln geprueft werden.

Worauf Sie achten sollten

Bei Odoo entscheiden vor allem Exportformat, Leitweg-ID, Steuerkategorien, Summenlogik und KoSIT-Validierung dar?ber, ob die Datei vom Beh?rdenportal akzeptiert wird. Der systemspezifische Abschnitt unten zeigt, welche Felder und Workflows Sie vor der ersten produktiven XRechnung pr?fen sollten.

Was ist bei der Odoo zu XRechnung Konvertierung besonders?

Odoo's E-Invoicing-Architektur basiert auf zwei Schlüsselmodulen: `account_edi` (seit Odoo 14) ist die generische EDI-Schicht für strukturierte Rechnungsdaten und definiert Format-Provider-Interfaces; `l10n_de` liefert die deutsche Lokalisierung mit DATEV-konformen Buchungslogiken, Steuerschlüsseln und Kontenrahmen (SKR03, SKR04). Für XRechnung-Output gibt es im Standard-Odoo keinen nativen Provider — das Community-Modul `l10n_de_xrechnung` schließt diese Lücke teilweise, ist aber typischerweise auf XRechnung 2.x limitiert.

Der empfohlene Workflow mit XRechnung-Bereit umgeht diese Limitierung. Sie aktivieren in Odoo den nativen PEPPOL-Export — entweder über das `account_edi_ubl`-Modul (Odoo Community) oder das `account_edi_facturx`-Modul (für Factur-X / ZUGFeRD-Style-Rechnungen). Die exportierte BIS-3.0-XML enthält bereits alle EN-16931-Pflichtfelder; XRechnung-Bereit ergänzt die deutsch-spezifischen CIUS-DE-Felder (Leitweg-ID-Routing über BT-10, deutsche Steuerschlüssel-Mapping, XRechnung-3.0-Codelisten-Updates) und produziert die konforme XML.

Kritische Konfigurationspunkte in Odoo, die für die Konvertierung relevant sind: Erstens, die Leitweg-ID: legen Sie ein Custom Field auf dem `res.partner`-Modell an (z.B. `x_leitweg_id`, Typ Char 50). Über Odoo Studio (Enterprise) oder via XML-Modul (Community) ist die Anlage in 5-10 Minuten erledigt. Beim PEPPOL-Export wird das Feld als BT-10 (`BuyerReference`) in die ausgehende XML übernommen — sofern Sie das Mapping in der Format-Provider-Konfiguration ergänzen, was in unseren Setup-Anleitungen dokumentiert ist. Zweitens, die Steuersatz-Codes: Odoo's `account.tax`-Modell hat einen Code-Feld (`code`), das in den deutschen Lokalisierungen (`l10n_de`) bereits mit den korrekten EN-16931-Werten belegt ist (`S` für 19%, `S` für 7%, `Z` für 0%, `AE` für Reverse-Charge §13b UStG). Prüfen Sie nach Modul-Updates, ob diese Codes erhalten bleiben. Drittens, das Multi-Mandanten-Setup: Odoo unterstützt Multi-Company nativ; jede Company hat eigene Steuer-IDs, Bankverbindungen und Adressen. Bei Konvertierung über die XRechnung-Bereit-API kann pro Mandant eine eigene Konfiguration hinterlegt werden.

Für Self-Hosted Odoo-Installationen (auf eigenem Server, AWS/Azure/Hetzner) ist zusätzlich relevant: die Odoo-zu-XRechnung-Bereit-Kommunikation erfolgt über HTTPS-Outbound-Verbindung, also kein Inbound-Port-Opening notwendig. DSGVO-Konformität ist gewahrt — XRechnung-Bereit verarbeitet die Rechnungsdaten auf EU-Servern in Frankfurt am Main mit automatischer Löschung nach sieben Tagen, und ein Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO ist Bestandteil der Bedingungen. Für besonders datensensible Konstellationen (Anwaltskanzleien, Gesundheitsbranche) steht zusätzlich die XRechnung-Bereit Desktop-App zur Verfügung, die Daten lokal verarbeitet.

Für automatisierte Workflows nutzen Sie Odoo Studio Automation Rules (Enterprise) oder Server Actions (Community): bei Status-Änderung der Rechnung auf `posted` feuert ein HTTP-Outgoing-Webhook gegen die XRechnung-Bereit-API; die Antwort-XML wird als Attachment am Invoice-Record gespeichert. Implementierungsaufwand: 2-4 Stunden für eine Standard-Integration, abhängig von Ihrer Odoo-Customization-Tiefe.

Pflichtfelder vor Versand pruefen

Leitweg-ID, Rechnungsnummer, Bestellreferenz, Leistungszeitraum, Steuercodes, Zahlungsziel und Summenlogik muessen vor dem Versand strukturiert vorhanden sein.

KoSIT-Validierung einplanen

Eine optisch korrekte Rechnung kann technisch trotzdem scheitern. Der Validatorlauf reduziert Ruecklaeufer bei Behoerdenportalen und macht Fehler frueh sichtbar.

Gast-Test ohne Projektstart

Fuer einzelne Behoerdenrechnungen reicht der manuelle Upload. Fuer wiederkehrende Mandanten oder ERP-Prozesse laesst sich der Ablauf spaeter standardisieren.

Haeufige Fragen

Reicht das Odoo l10n_de_xrechnung Community-Modul oder brauche ich eine externe Lösung?
Das Community-Modul `l10n_de_xrechnung` ist ein guter Ausgangspunkt für gelegentliche XRechnung-2.x-Anforderungen, hat jedoch praktische Grenzen: Erstens, es deckt typischerweise XRechnung 2.0-2.3 ab, jedoch nicht den aktuellen 3.0-Standard, der in den meisten Bundesland-Portalen ab 2026 Pflicht wird. Zweitens, die KoSIT-Validierung wird nicht in Echtzeit gegen den Live-Validator durchgeführt — Konfigurationsfehler werden erst beim Versand sichtbar. Drittens, der Modul-Maintainer-Support ist Community-getrieben, was bei Bug-Reports oder Standard-Updates zu Verzögerungen führen kann. Für regelmäßige B2G-Lieferanten oder Steuerberater mit B2G-Mandanten empfehlen wir die externe Lösung XRechnung-Bereit ergänzend zum Community-Modul: das Modul übernimmt den Export-Trigger, XRechnung-Bereit den eigentlichen Konvertierungsschritt mit Live-Validierung. Dieser Hybrid-Workflow kombiniert Odoo-native Trigger mit externer Validierungs-Tiefe.
Wie integriere ich XRechnung-Bereit in einen Odoo-Workflow?
Drei Pfade, abhängig von Ihrer Odoo-Edition. In Odoo Enterprise nutzen Sie Studio Automation Rules: bei Status-Änderung der Rechnung auf `posted` feuern Sie eine Server Action mit HTTP-Outgoing-Webhook gegen `https://xrechnung-bereit.de/api/convert`. Der Webhook-Body enthält die Rechnungsdaten als JSON (entweder das von `account_edi` exportierte UBL-XML oder ein flaches JSON-Mapping). Die Antwort-XML speichern Sie als `ir.attachment` am Rechnungs-Record. In Odoo Community nutzen Sie Server Actions mit Python-Code für denselben Effekt — etwas mehr Code, gleicher Workflow. In Odoo Online (SaaS) sind Server Actions limitiert; nutzen Sie stattdessen Zapier oder Make.com als Middleware: Zapier-Trigger `New Invoice in Odoo` → Action `POST to XRechnung-Bereit API`. Implementierungsaufwand: 1-3 Stunden für eine Basis-Integration, 4-8 Stunden für eine voll automatisierte Lösung mit Multi-Mandanten-Routing.
Funktioniert das mit Odoo Online (SaaS) und Odoo.sh?
Ja, vollumfänglich. Odoo Online (SaaS auf odoo.com) und Odoo.sh (Odoo's eigene PaaS) unterstützen beide HTTPS-Outgoing-Calls aus Server Actions oder Zapier-/Make-Middleware. Self-Hosted-Odoo (auf eigenem Server) funktioniert ebenso, mit dem Vorteil, dass Sie Custom-Module (z.B. ein dediziertes `xrechnung_bereit_connector`-Modul) installieren können, das die Integration tiefer einbindet. Für Odoo Online gibt es eine Einschränkung: Sie können keine Custom-Module installieren, daher ist die Zapier-/Make-Integration der praktischste Weg. Für Odoo.sh und Self-Hosted ist die direkte Server-Action-Integration eleganter und vermeidet die Abhängigkeit von einem dritten Middleware-Service. In allen drei Fällen verlassen Ihre Rechnungsdaten Odoo nur dann, wenn die Rechnung explizit zur Konvertierung freigegeben wird — keine Hintergrund-Synchronisation, kein Datenfluss ohne Trigger.