Odoo im Mittelstand: Editionen, Preise, API und KI

Odoo lässt sich gut an ein externes System anbinden, zum Beispiel an ein Kundenportal oder ein Planungstool. Entscheidend ist aber nicht nur die Technik, sondern welche Edition und welches Betriebsmodell beim Kunden im Einsatz ist. Davon hängt ab, welche Integrationswege offenstehen. Dieser Beitrag fasst die Inhalte eines Integrations-Workshops zusammen: Editionen und Preise, Datenmodell, API, Datenbank und KI, gezeigt an einem Demo-System mit Odoo 19.

Das Wichtigste in Kürze

Drei Betriebsmodelle: Odoo Online (SaaS von Odoo), Odoo.sh (Odoo-Plattform mit eigenem Code) und On-Premise (eigener Server). Online ist am einfachsten, aber am stärksten eingeschränkt.
Zwei Editionen: Community (Open Source, kostenlos) und Enterprise (Lizenz pro Nutzer, mit Accounting, Studio und nativer KI).
API-Zugriff: Die externe API gibt es bei Odoo Online nur im Custom-Plan. Auf Odoo.sh und On-Premise ist sie immer verfügbar.
Eigene Module (etwa ein eigener API-Endpunkt oder eine KI-Funktion) sind auf Odoo.sh und On-Premise möglich, auf Odoo Online nicht.
Neue Integrationen sollten die JSON-2-API (ab Odoo 19) nutzen. XML-RPC und JSON-RPC sind abgekündigt.
Schreiben immer über die API, nie direkt in die Datenbank. Nur so laufen Nummernkreise, Steuern, Buchungen und Prüfungen.
KI: Enterprise bringt KI eingebaut mit. In Community lässt sie sich über eigene Module ergänzen.

Integrationsprinzip: externes System schreibt per POST und liest per GET aus Odoo — Das Grundprinzip der Integration: Das externe System schreibt per POST und liest per GET. Der API-Key ist der Hausausweis eines Odoo-Benutzers.

Editionen und Betriebsmodelle

Odoo gibt es in zwei Editionen, die auf drei Arten betrieben werden. Für eine Integration ist die Kombination beim jeweiligen Kunden entscheidend.

	Odoo Online	Odoo.sh	On-Premise Community	On-Premise Enterprise
Edition	Enterprise	Enterprise	Community	Enterprise
Betrieb	Odoo S.A.	Odoo S.A. (Plattform), Partner (Code)	Kunde / Partner	Kunde / Partner
Eigene Module	Nein	Ja (über GitHub)	Ja	Ja
Externe API	Nur Custom-Plan	Ja	Ja	Ja
Updates	Automatisch durch Odoo	Odoo + Tests durch Partner	Selbst	Selbst
Native KI	Ja	Ja	Nein (eigene Module)	Ja
Typisch für	Kleine Firmen, Standardprozesse	Mittelstand mit Anpassungen	Kostenbewusste Firmen mit IT/Partner	Mittelstand mit eigener IT, Datenhoheit

Für eine Integration heißt das: Bei Odoo Online ist nur die Standard-API nutzbar, und nur mit Custom-Plan. Das externe System muss mit Odoos Datenmodell arbeiten. Auf Odoo.sh und On-Premise kann zusätzlich ein eigenes Modul installiert werden, etwa mit einem stabilen API-Endpunkt oder Webhooks. Und weil einige Felder und Apps (zum Beispiel das volle Accounting) nur in Enterprise existieren, muss jede Integration prüfen, was beim Kunden installiert ist.

Odoo Online Enterprise-Testversion mit App-Übersicht — Odoo Online (Enterprise-Testversion) mit KI, Accounting, Documents, Sign und weiteren Apps.

Preise in Deutschland

Odoo rechnet pro Nutzer und Monat ab, nicht pro App. Deutschland nutzt die Preisliste „Europe (Central)“ in EUR. Stand der Recherche: Oktober 2026, Preise netto bei jährlicher Abrechnung.

Plan	Listenpreis	Aktionspreis	Enthalten
One App Free	0 €	0 €	Eine einzige App, beliebig viele Nutzer
Standard	24,90 €	19,90 €	Alle Apps, nur Odoo Online, keine externe API
Custom	37,40 €	29,90 €	Alle Apps, Online / Odoo.sh / On-Premise, Studio, Multi-Company, externe API
Community	0 €	0 €	Open Source, nur On-Premise, ohne Enterprise-Apps

Beispiel für 10 Nutzer: Standard kostet 249 € im Monat (2.988 € im Jahr), Custom 374 € (4.488 € im Jahr), mit Aktionspreis 299 € (3.588 € im Jahr). Bei Odoo.sh kommen Hosting-Gebühren hinzu, bei On-Premise ein eigener Server (kleiner VPS ab ca. 20 bis 100 € im Monat) samt Backups, Monitoring und Updates. Verbindlich ist immer das aktuelle Angebot auf odoo.com/pricing.

Die größten Kostentreiber sind selten die Lizenzen. Einführung, Datenmigration und Versions-Upgrades kosten in der Praxis mehr, besonders mit vielen eigenen Modulen, die bei jedem Major-Release angepasst werden müssen. Laut Partnerberichten erhebt Odoo seit April 2026 zudem einen Aufschlag von 25 % auf Enterprise-Abos für Versionen, die älter als drei Releases sind.

Belegfluss und Datenmodell

Odoo ist modular aufgebaut. Jede App ist ein Modul, und die Module greifen über gemeinsame Datensätze ineinander. Der zentrale Belegfluss im Verkauf:

Belegfluss im Verkauf: Angebot, Auftrag, Lieferung, Rechnung, Zahlung — Belegfluss im Verkauf mit den zugehörigen Odoo-Modellen. Der Einkauf läuft analog.

Modell	Tabelle	Inhalt
`res.partner`	`res_partner`	Kunden, Lieferanten, Kontakte
`product.template` / `product.product`	`product_template` / `product_product`	Produkt und Varianten
`sale.order` / `sale.order.line`	`sale_order` / `sale_order_line`	Angebot oder Auftrag mit Positionen
`stock.picking`	`stock_picking`	Lieferung oder Wareneingang
`account.move`	`account_move`	Rechnung, Gutschrift oder Buchung
`res.users`	`res_users`	Benutzer, inklusive Portal-Nutzer

Typisch im Mittelstand sind Multi-Company-Setups (mehrere Gesellschaften in einer Datenbank), die deutsche Lokalisierung mit SKR03 oder SKR04, DATEV-Export und E-Rechnung (XRechnung, ZUGFeRD), gewachsene Anpassungen und Systeme, die ein bis drei Versionen hinter dem aktuellen Release laufen.

Die Demo-Umgebung

Für den Workshop lief Odoo 19 Community lokal in Docker, mit den Demo-Daten von Odoo und ohne echte Kundendaten. Zwei Container (Odoo und PostgreSQL) und drei Module: ein eigener REST-Endpunkt, eine eigene KI-Erweiterung mit Gemini und das OCA-Modul web_responsive.

Aufbau der Demo-Umgebung mit Odoo- und PostgreSQL-Container — Aufbau der Demo: Browser, externes System und Datenbank-Werkzeug sprechen mit zwei Containern.

docker compose up -d                 # starten
docker compose logs -f odoo          # Log live ansehen
docker compose exec db psql -U odoo -d demo   # in die Datenbank

Neue Module hinzufügen

Standard-Apps werden unter Apps aktiviert. „Aktivieren“ heißt: kostenlos in Community. „Upgrade“ heißt: nur in Enterprise verfügbar.

App-Liste in Odoo Community mit Enterprise-Apps — App-Liste in Community. „Upgrade“ markiert Enterprise-Apps wie Accounting oder Studio.

Ein eigenes Modul ist ein Ordner mit einer Beschreibungsdatei und Python-Code:

{
    "name": "SaaS Demo API",
    "version": "19.0.1.0.0",
    "depends": ["sale_management", "stock", "account"],
    "license": "LGPL-3",
    "installable": True,
}

Installiert wird es in der Oberfläche (Entwicklermodus, App-Liste aktualisieren) oder per Kommandozeile mit -i, nach Code-Änderungen mit -u:

docker compose exec odoo odoo -c /etc/odoo/odoo.conf -d demo -i saas_demo_api --stop-after-init --no-http
docker compose restart odoo

Community-Module der Odoo Community Association (OCA) ergänzen vieles, was sonst nur Enterprise bietet. Bei Fremdmodulen zählen passende Version (Branch 19.0), Lizenz (LGPL oder AGPL), Wartungsstatus und Abhängigkeiten. Jedes zusätzliche Modul muss bei jedem Upgrade mitgezogen werden.

Shop und Kundenportal

Ein Produkt wird im Shop veröffentlicht, ein Kunde kauft es und sieht danach unter /my Aufträge, Rechnungen, Zahlungen und die Sendungsverfolgung. Das ist Odoo-Standard ohne eigenen Code. Wichtig für Integrationen: Eine Shop-Bestellung ist ein ganz normaler Auftrag (sale.order) mit gesetztem website_id. Shop, Backend und API arbeiten auf denselben Datensätzen.

Die API: lesen (GET) und schreiben (POST)

Odoo ist wie ein Lager mit einem Schalter. Das externe System kommt nie ins Lager selbst, also nie direkt in die Datenbank, sondern immer an den Schalter: Fragen stellen (GET) und Aufträge abgeben (POST).

	Standard-API (JSON-2)	Eigener Endpunkt (Modul)
Adresse	`/json/2/<modell>/<methode>`	frei wählbar, z. B. `/api/demo/orders`
Installation beim Kunden	Keine	Eigenes Modul nötig
Odoo Online	Ja (Custom-Plan)	Nein
Aufrufe für Auftrag, Rechnung, Lieferung	Mehrere	Einer
Datenformat	Odoos interne Feldnamen	Eigenes, stabiles Format
Pflege	Keine auf Odoo-Seite	Modul muss pro Version migriert werden

Anmeldung: Der API-Key gehört zu einem Odoo-Benutzer (Meine Einstellungen, Kontosicherheit, Neuer API-Schlüssel). Das externe System sieht genau das, was dieser Benutzer sehen darf. Jeder Aufruf schickt den Key im Header Authorization: Bearer <API-Key> mit. Odoo 19 bietet unter /doc einen interaktiven API-Explorer.

GET: Der eigene Endpunkt liefert Auftrag, Rechnungen, Zahlungsstatus und Lieferungen in einem Paket:

{
  "name": "S00007",
  "customer": {"id": 15, "name": "Gemini Furniture"},
  "state": "sale",
  "invoice_status": "invoiced",
  "amount_total": 1706.0,
  "delivery_status": "full",
  "invoices": [{"name": "INV/2026/00003", "payment_state": "paid"}],
  "deliveries": [{"name": "WH/OUT/00005", "state": "done"}]
}

Wird in Odoo die Rechnung erstellt und bezahlt, wechselt der Status beim nächsten Abruf auf „invoiced“ und „paid“. Genau so erkennt das externe System, dass bezahlt oder geliefert wurde.

POST: Das externe System schickt nur das Nötigste, also wer, was und wie viel. Auftragsnummer, Preis, Steuern, Summe und mit confirm: true auch die Lieferung erledigt Odoo selbst.

POST /api/demo/orders
Authorization: Bearer <API-Key>
Content-Type: application/json

{
  "partner_id": 15,
  "reference": "SAAS-DEMO-001",
  "lines": [{"product_id": 64, "quantity": 2}],
  "confirm": false
}

Per API angelegte Angebote in der Odoo-Angebotsliste — Per API angelegte Angebote erscheinen sofort in Verkauf, Angebote.

Die Antwort-Codes sind die üblichen: 200 (Daten geliefert), 201 (angelegt), 400 (ungültige Anfrage), 401 (Key fehlt oder falsch), 403 (keine Berechtigung), 404 (Modul nicht installiert oder Datensatz existiert nicht).

Filter mit Domains

Die Standard-API filtert mit Domains: Listen aus Bedingungen der Form [feld, operator, wert], die mit UND verknüpft werden.

Ziel	Domain
Bestätigte Aufträge	`[["state", "=", "sale"]]`
Aufträge über 1.000 €	`[["amount_total", ">", 1000]]`
Offene Kundenrechnungen	`[["move_type", "=", "out_invoice"], ["payment_state", "!=", "paid"]]`
Kunden mit „GmbH“ im Namen	`[["name", "ilike", "GmbH"]]`
Seit gestern geändert	`[["write_date", ">=", "2026-10-08 00:00:00"]]`

Delta-Sync statt Vollabgleich: write_date ist der wichtigste Filter für jede Integration. Statt bei jedem Abgleich alles zu laden, werden nur Datensätze abgefragt, die sich seit dem letzten Abgleich geändert haben.

Tipp: In jeder Odoo-Liste lässt sich ein benutzerdefinierter Filter zusammenklicken. Im Entwicklermodus zeigt Odoo die erzeugte Domain an, ein guter Weg, Domains für die API auszuprobieren.

PostgreSQL: lesen ja, schreiben nein

Odoo speichert alles in PostgreSQL. Ein Blick in die Tabellen zeigt, wie viel ein einziger API-Aufruf im Hintergrund erledigt:

-- Die neuesten Aufträge
SELECT so.name, rp.name AS kunde, so.state, so.invoice_status, so.amount_total
FROM sale_order so JOIN res_partner rp ON rp.id = so.partner_id
ORDER BY so.id DESC LIMIT 5;

-- Produktnamen sind übersetzbar und als JSONB gespeichert
SELECT name->>'de_DE' AS produkt, name->>'en_US' AS product FROM product_template LIMIT 5;

Der Unterschied zwischen Lesen und Schreiben wird mit einem Testauftrag sichtbar:

-- Gefährlich: Summe direkt ändern
UPDATE sale_order SET amount_total = 9999 WHERE name = 'S00042';
-- Die Liste zeigt 9.999, die Positionen ergeben weiter 2,48.
-- Steuern, Nettobetrag und Verlauf wurden nicht angepasst: inkonsistente Daten.

Regel für jede Integration: Lesen per SQL ist für Auswertungen in Ordnung. Schreiben immer über die API, denn nur dann laufen Nummernkreise, Steuern, Lagerbewegungen, Buchungen, Rechteprüfung und Protokoll.

KI in Odoo: Enterprise oder eigene Lösung

Ob KI „überall“ in Odoo steckt, hängt von der Edition ab, nicht vom Hosting. Enterprise läuft auch auf eigenen Servern und bringt die KI dann mit.

	Enterprise	Community mit eigenem Modul
Umfang	KI in allen Apps eingebaut	Genau dort, wo sie eingebaut wird
Beispiele	Ask AI, KI-Agenten, KI-Felder in Studio, Belegerkennung	Auftragszusammenfassung, Produkttexte, AI Builder
Anbieter	Eigener ChatGPT- oder Gemini-Key	Beliebig, austauschbar
Aufwand	Konfigurieren, kein Code	Entwicklung eines Moduls
Kontrolle über Daten	Nach Odoo-Vorgaben	Volle Kontrolle über Prompts und gesendete Daten

Die eigene KI-Erweiterung der Demo zeigt drei Funktionen in Community:

AI Summary im Auftrag: Gemini fasst Status, offene Punkte (Lieferung, Rechnung, Zahlung) und die nächste Aktion auf Deutsch zusammen und schreibt das Ergebnis in den Verlauf.
AI Description im Produkt: ein Shop-Text, der direkt auf der Website erscheint.
AI Builder: ein Feld in normaler Sprache beschreiben, etwa „Lieferpriorität niedrig/mittel/hoch und zugesagtes Lieferdatum“. Die KI schlägt die Felder vor, ein Mensch prüft, Odoo legt sie an. Ein kleiner Studio-Ersatz für Community.

KI-Zusammenfassung eines Auftrags im Odoo-Verlauf — AI Summary im Auftrag: Die Zusammenfassung steht rechts im Verlauf.

Datenschutz: Jeder KI-Aufruf sendet Geschäftsdaten wie Kundennamen und Beträge an den KI-Anbieter. Nötig sind ein Auftragsverarbeitungsvertrag (AVV), möglichst EU-Datenverarbeitung oder ein selbst gehostetes Modell. In der Demo spricht nur eine einzige Datei mit der KI, der Anbieter lässt sich dort austauschen.

Worauf es bei der Anbindung ankommt

Thema	Empfehlung
Installierte Module	Vor dem Abgleich prüfen, welche Module und Felder vorhanden sind (z. B. `margin` oder `website_id`).
Berechtigungen	Eigenen Integrations-Benutzer pro Kunde mit passenden Gruppen anlegen.
Multi-Company	Firma im Kontext immer explizit angeben.
Versionen	Pro Version testen, eigener Endpunkt als stabile Schicht.
Steuern, Rundung, Währung	Beträge nicht selbst berechnen, sondern von Odoo übernehmen.
Externe IDs	ID des Fremdsystems mitspeichern, damit wiederholte Importe keine Dubletten erzeugen.
Datenmenge	Mehrere Datensätze pro Aufruf anlegen, mit Seiten abfragen.
Externe Dienste	Wiederholungen mit Wartezeit und klare Fehlermeldungen.

Für die Migration aus Altsystemen eignet sich dieselbe API: zuerst Kunden und Produkte, dann Aufträge, dann Rechnungen. Bereits gebuchte historische Rechnungen werden in der Regel nicht neu erzeugt. Übernommen werden Eröffnungssalden und offene Posten, abgestimmt mit der Steuerberatung.

Empfehlungen und nächste Schritte

Zielgruppe klären: Welche Editionen und Betriebsmodelle nutzen die Pilotkunden? Davon hängt ab, ob ein Modul möglich ist oder nur die Standard-API.
Datenbedarf festlegen: Welche Odoo-Objekte werden gebraucht, nur lesend oder auch schreibend?
Zweigleisig bauen: Basis-Integration über JSON-2 für alle, optional ein Odoo-Modul mit stabilem Endpunkt für Odoo.sh und On-Premise.
Sync-Strategie: Delta-Abgleich über write_date, externe IDs, Wiederholungen bei Fehlern.
KI-Strategie: native KI (Enterprise) nutzen oder eigene mitbringen, Datenschutz früh mitdenken.
Proof of Concept: eine kleine Integration gegen das Setup eines Pilotkunden, etwa Aufträge lesen und Status zurückmelden.

Preise und Funktionsumfang können sich ändern. Vor Entscheidungen bitte die aktuellen Angaben auf odoo.com prüfen. Quellen: Odoo-Dokumentation (External RPC API, JSON-2), OEC.sh, erp-software.org, Attomy, UBM Soft, Cybrosys, OCA.

Ein ähnlicher Workshop für das eigene Team oder eine konkrete Odoo-Integration? Kontakt aufnehmen.