E-Rechnung mit Odoo - Pflicht, Formate und Einrichtung für deutsche KMU

Seit dem 1. Januar 2025 muss jedes deutsche Unternehmen im inländischen B2B-Geschäft E-Rechnungen empfangen können - ohne Übergangsfrist und unabhängig von der Unternehmensgröße. Für den Versand gelten gestaffelte Übergangsfristen: Papier und einfache PDFs sind grundsätzlich noch bis Ende 2026 zulässig, für Unternehmen mit einem Vorjahresumsatz bis 800.000 Euro bis Ende 2027. Ab dem 1. Januar 2028 ist die strukturierte E-Rechnung im inländischen B2B-Verkehr dann verpflichtend - für alle.

Dieser Beitrag zeigt, was das konkret für ein Odoo-System bedeutet: welche Formate unterstützt werden, wie Ein- und Ausgang praktisch laufen, was in der Buchhaltung wirklich konfiguriert werden muss - und wo in der Praxis die Fehler passieren.

Was rechtlich eine E-Rechnung ist

Eine PDF-Rechnung per E-Mail ist keine E-Rechnung. Der Gesetzgeber verlangt ein strukturiertes elektronisches Format nach der europäischen Norm EN 16931, das maschinell auslesbar und weiterverarbeitbar ist. In Deutschland sind damit praktisch zwei Formate relevant:

• XRechnung. Reines XML, im öffentlichen Auftragswesen (B2G) faktisch Standard und auch im B2B weit verbreitet.
• ZUGFeRD ab 2.x (Profil EN 16931 / „Comfort" aufwärts). Hybrid: ein PDF/A-3 mit eingebettetem XML - für Menschen lesbar, für Maschinen auswertbar.
• PEPPOL BIS Billing 3.0. Kein eigenes „drittes Format" im engeren Sinn, sondern der europäische Übertragungsweg samt Netzwerk - zunehmend der bequemste Kanal.

Wichtig: ZUGFeRD-Profile unterhalb von EN 16931 (z. B. „Basic WL" oder „Minimum") erfüllen die Anforderung nicht. Wer ZUGFeRD nutzt, sollte konsequent auf das EN-16931-Profil oder höher setzen.

Was Odoo mitbringt

Odoo unterstützt E-Rechnung im Standard - kein Drittanbieter-Modul nötig, wenn die Version aktuell genug ist. Ab Odoo 17 ist das Handling brauchbar, ab Odoo 18/19 deutlich ausgereifter (bessere Erkennung eingehender Formate, saubereres PEPPOL-Onboarding, robusterer Import).

• Ausgang. Rechnungen lassen sich pro Kunde als XRechnung (UBL) oder ZUGFeRD/Factur-X erzeugen und automatisch an die Rechnung anhängen.
• Eingang. Eingehende XML- und Hybrid-Rechnungen werden eingelesen und als Lieferantenrechnung mit Positionen, Steuern und Beträgen vorbefüllt - deutlich weniger Tipparbeit als OCR auf PDF.
• PEPPOL. Odoo kann als Access Point angebunden werden, sodass Versand und Empfang über das Netzwerk statt per E-Mail laufen.
• Rechnungs-E-Mail-Alias. Ein Posteingang wie rechnung@ihrefirma.de kann direkt in Odoo entwurfsweise Lieferantenrechnungen erzeugen.

In Odoo Community fehlen einige Komfort- und Lokalisierungsbausteine; hier landet man häufig bei OCA-Modulen und damit bei laufendem Pflegeaufwand. Details zum Unterschied stehen im Preisvergleich Community vs. Enterprise.

Einrichtung in sechs Schritten

1. Stammdaten härten. Vollständige Firmenanschrift, USt-IdNr., Steuernummer, IBAN und - für PEPPOL - eine gültige elektronische Adresse (z. B. Leitweg-ID oder USt-IdNr.-Schema).
2. Kundenstammdaten prüfen. Pro Kunde festlegen, welches Format erwartet wird. Behörden verlangen in der Regel XRechnung samt Leitweg-ID.
3. Format je Kunde hinterlegen. In Odoo wird das E-Invoicing-Format am Kontakt gesetzt - nicht global. Genau das wird gern vergessen.
4. Steuerkennzeichen sauber mappen. 19 %, 7 %, 0 %, innergemeinschaftliche Lieferung und Reverse-Charge müssen im XML korrekte Kategorie-Codes erzeugen, sonst weist der Empfänger die Rechnung ab.
5. Eingangskanal aufsetzen. E-Mail-Alias und/oder PEPPOL-Empfang aktivieren und den Freigabe-Workflow für Lieferantenrechnungen definieren.
6. Testlauf mit echten Belegen. Je zwei bis drei reale Kunden- und Lieferantenrechnungen End-to-End durchspielen und mit einem Validator gegen EN 16931 prüfen.

Typische Fehler aus der Praxis

• Leitweg-ID fehlt. Bei B2G-Rechnungen ohne Leitweg-ID ist die Ablehnung sicher - das Feld gehört pro Behördenkunde gepflegt.
• Falsches ZUGFeRD-Profil. Ein „Minimum"-Profil sieht aus wie eine E-Rechnung, ist aber keine.
• Freitext statt Struktur. Rabatte, Zuschläge oder Skonto nur im Bemerkungsfeld statt in den vorgesehenen XML-Feldern führen zu Validierungsfehlern.
• Nur PDF archiviert. Aufbewahrungspflichtig ist das strukturierte Original - nicht der optische Ausdruck.
• Alte Odoo-Version. Unter Odoo 17 wird E-Rechnung schnell zum Bastelprojekt - siehe Migrations-Leitfaden.

GoBD, Archivierung und DATEV

Die E-Rechnung ist im Original aufzubewahren: Das XML bzw. das PDF/A-3 mit eingebettetem XML ist der revisionsrelevante Beleg, acht Jahre lang, unveränderbar und maschinell auswertbar. Odoo legt die Datei am Buchungsbeleg ab - wichtig ist, dass Sperrdaten und Festschreibung greifen, damit der Beleg nachträglich nicht austauschbar ist. Details dazu im GoBD-Artikel.

Für die Übergabe an den Steuerberater ändert sich am Ablauf wenig: Der DATEV-Export bleibt der Weg, die Belegverknüpfung wird durch strukturierte Daten aber sauberer und die Erfassungsquote deutlich höher.

Was jetzt sinnvoll ist

Wer heute schon empfangsfähig ist und den Versand testweise auf einzelne Kunden umstellt, hat bis 2027/2028 alle Zeit der Welt. Wer wartet, macht Pflichtumstellung, Versionswechsel und Prozessumbau gleichzeitig - erfahrungsgemäß der teuerste Weg. Der pragmatische Einstieg: Odoo-Version prüfen, Stammdaten aufräumen, ein Format produktiv sauber zum Laufen bringen, danach ausrollen.