In diesem Beitrag
Odoo-Rechnungs-OCR: Wann brauchst du einen Ausnahmeprozess?
Auf der Rechnung stehen zehn Stück. Die Bestellung enthält zehn Stück. Im Lager sind acht angekommen. Selbst eine fehlerfreie Texterkennung lässt damit eine Entscheidung für die zuständigen Menschen offen.
Nutze native Odoo-Rechnungs-OCR und den Bestellabgleich, soweit die installierte Konfiguration deinen Prozess erfüllt. Ergänze einen eigenen Ausnahmeprozess für eine nachgewiesene Lücke bei Prüfung, Nachweisen oder Freigaberechten. Erhalte Quellwerte neben erwarteten Geschäftswerten, weise jede Abweichung einem Verantwortlichen zu und prüfe die Wirkung vor automatischer Buchung.
Recherchestand: 5. November 2026. Produktangaben stammen aus der offiziellen Odoo-Dokumentation für 20.0. Rechnung, Werte und Abnahmefälle sind fiktiv. Wir haben keinen OCR-Dienst, kein Modell, keinen Connector und keinen Buchhaltungsablauf ausgeführt. Der beispielhafte Steuerbetrag ist eine Rechengröße, keine steuerliche Empfehlung.
Was leistet die native Rechnungsverarbeitung in Odoo bereits?
Lass Digitalisierung, Bestellabgleich und Buchungseinstellungen vorführen, bevor du einen eigenen Rechnungsprozess spezifizierst. Halte Odoo-Version, installierte Apps und relevante Einstellungen fest. Prüfe, ob diese Konfiguration deine Kontrollen ausführt und ihre Nachweise erhält, auch bei Ausnahmen. Ein Funktionsname beantwortet noch keine Frage zur verbindlichen Freigaberegel.
Die Digitalisierungsdokumentation für Odoo 20 beschreibt das Auslesen einer Rechnung und die Suche nach einer Bestellung, gefolgt vom manuellen Abgleich mit offenen Bestellpositionen.
OCR grundsätzlich jede Beteiligung am Bestellabgleich abzusprechen wäre zu pauschal. Ebenso wenig belegt die Funktion, dass jede Rechnung ohne Eingriff korrekt zugeordnet wird. Lass den konkreten Weg mit den Dokumenten und Bestellstrukturen demonstrieren, die du unterstützen willst.
Die Dokumentation zu Lieferantenrechnungen nennt auch lieferantenspezifische Optionen für automatische Buchung. Jede Rechnung manuell zu prüfen ist damit eine Regel- und Konfigurationsentscheidung, keine bedingungslose Beschreibung des nativen Verhaltens.
Für die hier vorgeschlagene Abnahme bleibt die Freigabe unter der vereinbarten Prüfregel. Notiere vor der Bewertung, welche Automatismen aktiv sind. Eine Demonstration mit einer Konfiguration belegt nicht dieselbe Wirkung, wenn im Verlauf unbemerkt andere Einstellungen aktiviert werden.
Erzwingt eine Abgleichabweichung deine Freigaberegel?
Eine angezeigte Ausnahme und eine durchgesetzte Freigaberegel brauchen eigene Nachweise. Ein Status kann eine Abweichung melden und trotzdem weitere Aktionen erlauben. Verlangt dein Prozess einen Stopp, demonstriere, dass die relevante Identität ihn über die vorgesehenen Anwendungs- und Integrationswege nicht umgehen kann. Prüfe den Geschäftszustand nach der Aktion.
Odoos Dokumentation zur Rechnungskontrolle unterscheidet bestellte und erhaltene Mengen. Geänderte Entwürfe können den Status Should Be Paid: Exception erhalten, ohne dass diese Änderungen blockiert werden.
Formuliere daraus eine Abnahmeanforderung. Nach unserer Beispielregel darf eine Rechnung mit ungeklärter Wareneingangsdifferenz den geschützten Freigabeschritt nicht durchlaufen. Wer die Differenz klärt, muss Grund und Nachweis hinterlassen. Ob Konfiguration, Modul oder eigene Kontrolle diese Regel durchsetzt, bleibt eine Umsetzungsfrage.
Trenne Vorbereitung, Buchung und Zahlung im Umfang. Eine bestandene Rechenprüfung erlaubt nicht automatisch alle drei. Kläre, welche Identität jede Aktion ausführen darf, welche Freigabe sie dafür braucht und was bei geänderten Beträgen oder Belegen nach der Prüfung geschieht.
Leite aus einem Feldnamen keine allgemeingültige Buchungs- oder Zahlungssperre ab. Unterstelle einer konkreten Installation aber auch nicht, dass sie keine besitzt. Zusätzliche Konfiguration und Module können das Verhalten verändern. Prüfe den tatsächlich betriebenen Weg.
Wann ist ein eigener Ausnahmeprozess gerechtfertigt?
Ein eigener Ausnahmeprozess ist sinnvoll, wenn nach der Demonstration des nativen Weges eine vereinbarte Anforderung offen bleibt. Benenne die fehlende Regel, Nachweisquelle oder Zuständigkeit und begrenze die Ergänzung. Ein falsch erfasster Wareneingang oder eine ungeklärte Geschäftsregel lässt sich nicht durch ein weiteres Extraktionsmodell entscheiden.
| Beobachteter Bedarf | Zuerst zu prüfender Ansatz | Nachweis vor eigener Entwicklung |
|---|---|---|
| Unterstützte Rechnungen und Abgleichnachweise liegen bereits in Odoo. | Native Digitalisierung, Abgleich und Prüfkonfiguration. | Repräsentative Rechnungen und Ausnahmen erreichen die vereinbarten Zustände mit erhaltenen Nachweisen. |
| Zuständigkeit, Freigabeschritt oder Betragsregel fehlt. | Demonstrieren, ob vorhandene Konfiguration oder ein gepflegtes Modul die Regel durchsetzt. | Die genau fehlende Bedingung und ein Fall, der sie derzeit umgeht. |
| Abnahmenachweise liegen in einem anderen operativen System. | Begrenzte Integration, die die nötigen Nachweise abruft und erhält. | Quellidentität, Aktualität, Zugriffsbefugnis und Verhalten bei Ausfall der Quelle. |
| Native Extraktion scheitert an einer dokumentierten Eingabeklasse. | Anderen Extraktionsweg anhand dieser Dokumente bewerten. | Beobachtete Erkennungsfehler und anschließender Prüfaufwand. |
Erhalte das ursprüngliche Lieferantendokument, auch wenn ein Prüfer erwartete Werte aus einer Bestellung auswählt. Die Ausnahme muss die Differenz sichtbar lassen. Ersetzt du einen vorgeschlagenen Betrag durch den Sollwert, ohne die Quelle zu erhalten, wird der Streitpunkt später schwerer nachvollziehbar.
Der bestehende Leitfaden zu Rechnungsextraktion und menschlicher Prüfung behandelt die Parserbewertung. Nutze ihn bei einer nachgewiesenen Erkennungslücke. Hier geht es um Entscheidungen, nachdem Werte zur Prüfung vorliegen.
Warum kann eine korrekt gelesene Rechnung trotzdem offen bleiben?
Eine korrekt gelesene Rechnung kann an einer Geschäftsprüfung scheitern. Erkennung und Akzeptanz beantworten verschiedene Fragen. Prüfe zuerst die Rechnung rechnerisch, dann Menge und Preis gegen freigegebene Bestellung und Wareneingangsregel. Halte Abweichungen getrennt, damit der Prüfer erkennt, welche Entscheidung noch fehlt und welche Prüfung bereits bestanden ist.
Das fiktive Beispiel verwendet Lieferant V01, Rechnung INV-082 und Unternehmen A. Die Rechnung enthält zehn Stück zu je 25 €, einen beispielhaften Steuerbetrag von 50 € und keine weiteren Kosten. Bestellt wurden zehn Stück, im Wareneingang stehen acht.
| Prüfung | Quell- oder Sollwert | Rechnung | Entscheidung nach der Beispielregel |
|---|---|---|---|
| Nettobetrag der Position | 10 Stück zu je 25 €. | 10 × 25 € = 250 €. | Rechnerisch stimmig. |
| Bruttobetrag | 250 € netto plus 50 € Steuerbetrag. | 250 € + 50 € = 300 €. | Rechnerisch stimmig; steuerliche Behandlung folgt weiterhin der freigegebenen Regel. |
| Bestellmenge | 10 bestellt und 10 berechnet. | 10 − 10 = 0 Stück. | Keine Mengendifferenz zur Bestellung. |
| Erhaltene Menge | 8 erhalten und 10 berechnet. | 10 − 8 = 2 Stück. | Nach der vereinbarten Wareneingangsregel zur Prüfung anhalten. |
Die OCR-Ausgabe könnte das Dokument hier vollständig korrekt wiedergeben. Die Differenz von zwei Stück braucht trotzdem eine Erklärung. Ein falsch erfasster Eingang, eine Teillieferung und eine vereinbarte kaufmännische Ausnahme würden unterschiedliche Nachweise erfordern. Das System soll die Differenz zeigen, ohne ihre Ursache zu erfinden.
Ändere jetzt nur den extrahierten Bruttobetrag auf 310 €, während Netto- und Steuerwerte bei 250 € und 50 € bleiben. Die ungeklärte Differenz beträgt 310 € − (250 € + 50 €) = 10 €. Ein Prüfer muss klären, ob etwas falsch gelesen, eine Gebühr ausgelassen oder das Dokument fehlerhaft verstanden wurde. Den Gesamtbetrag still auf 300 € zu setzen würde diese Untersuchung verdecken.
„Bereit für die Finanzprüfung“ bedeutet in der Vorlage nur, dass die aufgeführten Prüfungen nach den Beispielregeln keine offene Abweichung zeigen. Es bedeutet weder gebucht noch zur Zahlung freigegeben oder bezahlt. Die befugte Finanzverantwortung bestimmt Behandlung und Freigabebedingungen.
Was gehört in den Datensatz einer Ausnahme?
Erhalte die strittigen Werte, ihre Quellen, einen konkreten Grund und die zuständige Person. Nenne Unternehmen und Währung, damit ein plausibler Betrag nicht im falschen Kontext zugeordnet wird. Verbinde die Freigabe mit genau den Nachweisen und der Datensatzversion, die der Verantwortliche tatsächlich geprüft und akzeptiert hat.
| Element | Erforderlicher Inhalt | Zweck |
|---|---|---|
| Identität | Unternehmen, Lieferant, Dokumentreferenz und Kennungen möglicher Datensätze. | Die richtige Rechnung im richtigen Geschäftskontext prüfen. |
| Beobachtete Werte | Fundstelle im Original und extrahierte Mengen oder Beträge. | Erhalten, was auf dem Lieferantendokument steht. |
| Erwartete Werte | Bestellung, Eingang oder anderer freigegebener Nachweis samt Version. | Zeigen, weshalb das Unternehmen einen anderen Wert erwartet. |
| Grund und Zuständigkeit | Benannte Abweichung bei Eingang, Preis, Identität oder Rechnung. | Die Frage an den entscheidungsbefugten Menschen senden. |
| Freigabenachweis | Entscheidung, verantwortliche Person, aktuelle Version und Belegreferenz. | Vor dem geschützten Schritt festhalten, was freigegeben wurde. |
Eine wiederholte Referenz sollte eine Dublettenprüfung auslösen, keine automatische Löschung. Odoo weist darauf hin, dass Teilrechnungen dieselbe Bill Reference verwenden können. Vergleiche Dokumente und Identitäten, bevor du sie als dieselbe Verpflichtung behandelst.
Ordne jedem Grund einen nächsten Schritt zu. Der Einkauf kann einen Bestellpreis klären. Der Wareneingang kann einen Mengenbeleg korrigieren oder erläutern. Finance verantwortet Betragsregeln und Buchungsfreigabe. Lieferantenstammdaten brauchen ihr gesondert genehmigtes Prüfverfahren; Rechnungstext darf Bankdaten nicht still überschreiben.
Bewerte die Freigabe neu, wenn sich ein wesentlicher Wert oder Nachweis ändert. Erhalte die frühere Entscheidung und den Grund, weshalb sie nicht mehr gilt. Sonst kann auch eine gut gestaltete Ausnahme-Queue eine geänderte Rechnung mit veralteten Nachweisen freigeben.
Wie nimmst du den Prozess vor der Automatisierung ab?
Prüfe bei erlaubten Fällen und verbotenen Übergängen den endgültigen Rechnungszustand samt Nachweisen. Verwende die tatsächliche Konfiguration in einer geschützten Umgebung. Bestätige, dass Ausnahmen einen Verantwortlichen erreichen und dort blockiert bleiben, wo die Regel es verlangt. Eine Warnanzeige oder ein abgeschlossener Job ist nur ein Teil dieses Nachweises.
Lade die Abnahmematrix mit zwölf Rechnungsausnahmen herunter. Sie umfasst Mengen- und Preisdifferenzen, Rechenprüfungen, Unternehmens- und Lieferantenidentität, Währung, mögliche Dubletten, Stammdatenänderungen, fehlende Toleranzen und veraltete Freigaben. Jeder Ausführungsstand ist NOT_RUN.
- Regeln zuerst freigeben. Finanz- und Prozessverantwortliche bestimmen, was eine Rechnung anhält und wer sie freigeben darf.
- Ausgangskonfiguration festhalten. Dokumentiere Version, Module, Kontrollregeln, automatische Buchung und technische Rechte.
- Passenden Fall und direkte Ausnahme prüfen. Behalte etwa die Rechnungswerte bei und ändere die erhaltene Menge von zehn auf acht.
- Alle relevanten Wege prüfen. Demonstriere erlaubten Übergang und Umgehungsversuch mit der tatsächlichen Identität. Erhalte den resultierenden Zustand.
- Geänderte Nachweise ausprobieren. Ändere eine wesentliche Eingabe nach der Prüfung. Die alte Freigabe darf keinen anderen Rechnungszustand autorisieren.
- Wiederaufnahme und Zuständigkeit prüfen. Offene Arbeit muss sichtbar bleiben, wenn eine externe Quelle oder ein Prüfer ausfällt.
Der Leitfaden zur Abnahme von Odoo-Agenten anhand des Geschäftszustands beschreibt das übergreifende Vorgehen. Bei Rechnungen muss der richtige Datensatz aus dem richtigen Grund weiterlaufen. Ein angehaltener Fall darf die vereinbarte Bedingung nicht umgehen.
Erklärt eine KI die Abweichung oder schlägt eine Zuordnung vor, erhalte diesen Vorschlag getrennt von der Entscheidung. Bewerte das Modell erst nach einem echten Lauf mit repräsentativen erlaubten Eingaben. Diese vorgeschlagene Matrix belegt weder native OCR-Genauigkeit noch Modellleistung.
Was würden wir zuerst umsetzen?
Wir würden den nativen Weg mit einem kleinen vereinbarten Rechnungssatz demonstrieren und danach eine fehlende Ausnahmeregel mit klarer Zuständigkeit und klaren Nachweisen ergänzen. Automatische Freigabe bleibt im abgenommenen Umfang. Erweitere erst nach Beobachtung offener Abweichungen und des tatsächlichen Prüfaufwands.
Die Kosten pro akzeptiertem Odoo-Ablauf berücksichtigen Prüfung und fehlgeschlagene Arbeit. Der Vergleich von Individual- und Standardsoftware hilft bei Konfiguration, Modulen und gepflegten Integrationen. Für Wavects API-Integration bringst du eine bereits beherrschte Rechnung und eine noch nicht zuverlässig durchgesetzte Ausnahme mit.