Eine deutsche Anfrage nach Odoo-Schnittstellen nennt fast immer dieselben drei Gegenstellen: den Steuerberater mit DATEV, den Shop auf Shopware oder JTL und, seit letztem Jahr, die E-Rechnung. Das Anbinden selbst ist selten das Problem. Das Problem ist, dass alle drei die Daten in einer Form erwarten, die von Entscheidungen abhängt, die Odoo Ihnen nicht abnehmen kann - und dass das am Anfang niemand ausspricht.
Also der Reihe nach: was im Standardimage steckt, was nicht, und welche Nähte ich bisher von Hand nähen musste.
Was Odoo für Deutschland mitbringt - gezählt statt vermutet
Das laufende Image von Odoo 19 Community enthält 659 Module. Genau eines davon ist deutsch: l10n_de, der Kontenrahmen. Module mit DATEV im Namen: kein einziges. Das europäische One-Stop-Shop-Modul l10n_eu_oss ist dabei, ebenso die Formatliste für elektronische Rechnungen, die XRechnung bereits kennt.
Diese eine Zahl bestimmt den Zuschnitt jedes deutschen Projekts auf Community: Der Buchhaltungsexport ist Eigenarbeit oder fremdes Produkt, Enterprise bringt einen mit. Der Audit-Trail kommt mit dem deutschen Kontenrahmen, der Hash auf gebuchten Belegen ist eine Einstellung, die man erst finden muss. Die E-Rechnung ist näher, als die meisten denken. Und alles, was der Shop braucht, hängt vollständig am Connector.
DATEV: Enterprise bringt den Export mit, Community nicht, und das Format ist die kleinere Hälfte
Odoo Enterprise hat das Modul l10n_de_reports, das dem Hauptbuch zwei Exporte hinzufügt: DATEV DATA, CSV-Dateien mit Kunden, Lieferanten und Buchungszeilen, die Ihr Berater importiert, und DATEV ATCH, die Rechnungsdateien, die über DATEV Belegtransfer gehen. Community hat beides nicht, nur das Feld l10n_de_datev_code an den Steuern, in der SKR03-Vorlage bei 4 von 49 Steuern gefüllt. Dort lautet die Frage, wer den Export schreibt: ein gekauftes Modul, ein Partner oder ich. In beiden Editionen gilt: Schwierig ist nicht die CSV-Datei. DATEV will Buchungen, keine Dokumente: Konto und Gegenkonto, einen Steuerschlüssel, die Belegnummer, über die Ihr Berater abstimmt, und ein Datum, das in der richtigen Periode landet. Odoo liefert alle vier bereitwillig - sobald jemand entschieden hat, welches Odoo-Konto auf welche Nummer im Kontenrahmen des Beraters zeigt und was mit den Fällen passiert, für die es gar keine Nummer gibt.
Genau diese Fälle verderben den Monatsabschluss: eine Gutschrift über den Periodenwechsel, eine Zahlung vor der Rechnung, eine Marktplatz-Auszahlung, die eine Zeile für zweihundert Bestellungen ist. Ich bitte deshalb um die Buchungen des Vormonats vom Steuerberater, bevor ich eine einzige Zeile Exportcode schreibe: Diese Datei sagt mehr über das Mapping als jedes Meeting.
GoBD: Unveränderbarkeit ist ein Schalter - und er gehört früh umgelegt
Odoo hat dafür zwei Mechanismen, und sie starten unterschiedlich. Der Audit-Trail ist bereits an: Der deutsche Kontenrahmen setzt bei der Installation restrictive_audit_trail, und in Odoo 19 kann eine deutsche Firma ihn nicht abschalten, das Protokoll der Buchungszeilen lässt sich also nicht aufräumen. Der Hash ist ab Werk aus. Journale tragen restrict_mode_hash_table; ist der Modus an, bekommt jeder gebuchte Beleg einen inalterable_hash, der mit dem vorherigen verkettet ist, eine nachträgliche Änderung ist also erkennbar.
Zwei Fallen. Erstens bleiben alte Belege bei spätem Einschalten nicht für immer außerhalb der Kette: Die nächste Buchung hasht ihre Nummernfolge rückwirkend bis zum letzten gehashten Beleg, und der Assistent Secure Entries versiegelt Belege auf Anforderung. Aber ein Hash versiegelt einen Beleg nur so, wie er an diesem Tag aussieht, und sagt nichts darüber, was vorher mit ihm geschah; eine Lücke in der Nummernfolge stoppt die Buchung zudem mit einem Fehler. Ob noch etwas offen ist, zeigt has_unhashed_entries am Journal. Also zum Go-live einschalten, nicht wenn die Prüfung angekündigt ist. Zweitens die Schnittstelle selbst: Ein Connector, der eine gebuchte Rechnung „korrigiert“, weil der Shop die Bestellung geändert hat, zerstört genau die Eigenschaft, die der Hash beweisen soll. Korrekturen sind neue Dokumente - Gutschrift oder Storno - und der Connector muss vom ersten Tag an so geschrieben sein.
Shop: Shopware oder JTL - die Frage ist der Besitz
Beide sprechen gut genug: Shopware über seine Admin-API, JTL über die eigene Datenbank und den Connector. Daran scheitert kein Projekt. Es scheitert daran, dass Bestand und Preis auf beiden Seiten existieren und beide Seiten sich für zuständig halten.
Eine Tabelle klärt das vor jeder Zeile Code: links jedes Feld, das die Grenze überquert, rechts das eine System, das es ändern darf. Der Bestand gehört Odoo, der Shop wird informiert. Preise gehören meist dem Shop, weil dort die Aktionen laufen. Jedes Feld, bei dem die Antwort „beide“ lautet, wird innerhalb eines Quartals zum Support-Ticket.
Und dann das deutsche Detail, das die meiste Zeit kostet: Shops denken brutto, Odoo denkt netto. Rechnen Sie neunzehn Prozent aus 49,99 € heraus und wieder hinein, ein paar tausend Mal, und die Centdifferenzen stehen als endlose Liste kleiner Abweichungen in der Buchhaltung, die niemand erklären kann. Einmal festlegen, welche Seite für die Zahl maßgeblich ist, die der Kunde sieht - und die andere Seite rechnet daraus ab.
E-Rechnung: XRechnung ist schon an Bord
Seit Anfang 2025 müssen deutsche Unternehmen strukturierte Rechnungen empfangen können; die Pflicht zum Versand kommt gestaffelt. Die gute Nachricht: Odoo 19 bringt das Format bereits mit - in der Formatliste am Kunden steht „Germany (XRechnung)“ neben Factur-X und Peppol BIS 3.0. Der Peppol-Zugang selbst liegt in eigenen Modulen.
Für eine Schnittstelle heißt das vor allem eins: Die Rechnung, die Ihr System verlässt, ist ein Dokument mit Feldern und kein PDF mit einem Bild davon. Alles, was das XML braucht - Leitweg- beziehungsweise Käuferreferenz, Steueraufteilung, Mengeneinheit -, muss im Datensatz stehen, bevor der Export läuft. Das führt mich in der Praxis fast immer zurück zum Shop-Connector, um Felder einzusammeln, die niemand gemappt hat.
Wie ich so ein Projekt beginne
Ein Gespräch und drei Fragen, die den Aufwand entscheiden: Welchen Kontenrahmen nutzt Ihr Berater, und muss der Export einer bestehenden Buchungspraxis folgen? Ist der Hash-Modus an, und seit wann? Wem gehören Bestand, Preis und Kundendatensatz? Die Antworten passen auf eine Seite, und diese Seite ist die Spezifikation der Schnittstelle.
Läuft Ihr Connector bereits, ist die nützlichere Frage eine andere: Was tut er, wenn er zweimal läuft, und woran merken Sie, dass er heute Nacht gar nicht gelaufen ist? Genau deswegen werde ich meistens gerufen.