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 Odoo von sich aus nicht liefert - 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 741 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: Der Buchhaltungsexport ist Eigenarbeit oder fremdes Produkt. Die Unveränderbarkeit 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: Der Export ist Ihre Aufgabe, und das Format ist die kleinere Hälfte
Weil die Box nichts mitbringt, lautet die Frage nur, wer den Export schreibt: ein gekauftes Modul, ein Partner oder ich. Wer auch immer - 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, was die deutschen Regeln verlangen, und es ist ab Werk aus. Journale tragen restrict_mode_hash_table; ist der Modus an, bekommt jede gebuchte Zeile einen inalterable_hash und eine secure_sequence_number, eine nachträgliche Änderung ist also erkennbar. Die Firma hat zusätzlich restrictive_audit_trail für das Protokoll, das nicht aufgeräumt werden darf.
Zwei Fallen. Erstens trägt das Journal auch has_unhashed_entries - das ehrliche Eingeständnis, dass alles, was vor dem Einschalten gebucht wurde, außerhalb der Kette liegt, und keine spätere Einstellung repariert das. 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.