Veröffentlicht am 28. Oktober 2026
Die Kreditorenbuchhaltung in Fertigung und Vertrieb hat eine ganz eigene Version des Rechnungsproblems, mit dem AP-Teams in einfacheren Unternehmen nicht konfrontiert sind: hohe Positionenzahlen, Bestellungen mit Teillieferungen und gestaffelten Lieferungen sowie Lieferantenrechnungen, die selten zweimal im selben Layout eintreffen. Ein 2-way oder 3-way match, der auf dem Papier trivial ist — Rechnungsbetrag entspricht PO-Betrag entspricht Wareneingang — scheitert in der Praxis ständig an Teillieferungen, Rückständen, uneinheitlich berechneten Frachtkosten und Abweichungen bei der Maßeinheit zwischen der Rechnung eines Lieferanten und der PO-Position im Einkaufssystem.
Klassische OCR-plus-Template-Tools zur Rechnungserfassung decken den einfachen Teil dieses Problems ab — sie lesen Lieferantenname, Rechnungsnummer und Gesamtsumme aus einem bekannten Layout aus — und geben der AP-Fachkraft dann alles weiter, was nicht sauber passt. In einer Fertigungsumgebung ist das oft ein großer Anteil des gesamten Rechnungsvolumens. Document Intelligence, die OCR mit einem Sprachmodell kombiniert, das Positionen im Kontext wirklich liest, schließt einen wesentlichen Teil dieser Lücke, auch wenn sie den Bedarf an einem Menschen bei tatsächlich unklaren Ausnahmen nicht vollständig ersetzt.
Warum Rechnungen in Fertigung und Vertrieb komplexer sind als im Durchschnitt
Einige konkrete Muster machen das schwieriger als typische AP-Automatisierung:
- Teil- und Split-Lieferungen. Eine einzelne PO-Position über 10,000 Einheiten kann sich über vier Lieferungen und vier Rechnungen verteilen, die jeweils gegen die verbleibende offene Menge dieser PO-Position abgeglichen werden müssen — nicht gegen die ursprüngliche Gesamtmenge.
- Abweichungen bei der Maßeinheit. Eine PO in Kartons und eine Rechnung in Stück oder eine Rohstoff-PO in Kilogramm gegen eine Rechnung in Pfund erfordern einen Umrechnungsschritt, bevor ein 1:1-Abgleich überhaupt möglich ist.
- Fracht, Zuschläge und Treibstoffanpassungen. Diese erscheinen oft als separate Positionen, die nie ausdrücklich auf der PO standen, und eine starre Abgleichregel würde die gesamte Rechnung ablehnen, statt nur die eine Position zu isolieren, die geprüft werden muss.
- Vielfalt bei Lieferantenformaten. Ein Distributor mit Hunderten von Lieferanten erhält Rechnungen in ebenso vielen Layouts, darunter gescannte Papierbelege, PDFs aus älteren ERP-Systemen und EDI-Feeds, die nur einen Teil der Lieferanten abdecken.
- Volumen konzentriert sich zum Monats- und Quartalsende. Abschlusszyklen erzeugen Spitzen, die die manuelle Bearbeitung von Ausnahmen genau dann zum Engpass machen, wenn Finance saubere Zahlen am dringendsten braucht.
Was eine Document-Intelligence-Schicht hier tatsächlich leistet
Extraktion, die Struktur versteht und nicht nur Text
Anstatt sich auf ein festes Template pro Lieferant zu verlassen, liest eine modellbasierte Extraktionsschicht die Rechnung als Dokument — sie erkennt Kopfbereiche, Positionstabellen und Summen anhand ihrer Rolle im Dokument und nicht anhand ihrer Pixelposition. Genau das macht sie tolerant gegenüber neuen Lieferanten und Layoutänderungen, ohne dass jedes Mal jemand ein neues Template bauen muss, wenn ein Lieferant sein Rechnungsdesign ändert. Das ist ein zentraler Teil unserer intelligent document processing work, und es ist der Baustein, den die meisten templatebasierten OCR-Tools tatsächlich nicht leisten können.
Abgleichlogik auf Positionsebene
Statt nur die Rechnungssumme mit der PO-Summe abzugleichen, gleicht das System auf Positionsebene ab: Menge, Einzelpreis und Maßeinheit, mit Umrechnungslogik dort, wo Lieferanten in anderen Einheiten abrechnen als in der PO verwendet wurden. Teillieferungen werden gegen die verbleibende offene Menge der PO-Position abgeglichen, wobei laufende Salden bei jeder verarbeiteten Rechnung aktualisiert werden, statt zu verlangen, dass die gesamte PO erst erfüllt sein muss, bevor eine Rechnung freigegeben werden kann.
Ausnahmeklassifizierung, nicht nur Ausnahmekennzeichnung
Die nützliche Version dieses Systems sagt nicht einfach nur „Diese Rechnung passt nicht, an einen Menschen weiterleiten.“ Sie klassifiziert den Grund: eine Mengenabweichung innerhalb einer definierten Toleranz, eine Preisabweichung außerhalb der Toleranz, eine unerwartete Frachtposition, eine Umrechnung der Maßeinheit, die bestätigt werden muss, oder eine Abweichung zwischen Lieferant und PO, die darauf hindeutet, dass die Rechnung eigentlich zu einer anderen Bestellung gehört. Genau diese Klassifizierung ermöglicht es einer AP-Fachkraft, eine Warteschlange effizient zu bearbeiten, statt jede Ausnahme jedes Mal von Grund auf neu zu analysieren.
Prüfpfad standardmäßig enthalten
Jeder extrahierte Wert, jede Abgleichentscheidung und jede Routing-Entscheidung für Ausnahmen muss mit einem Verweis auf das Quelldokument protokolliert werden. In der AP ist das nicht optional: Nur so ist der Prozess in einem Audit belastbar, und nur so kann ein Controller einem automatisierten Abgleich vertrauen, statt ihn manuell nachzuprüfen.
Warum Toleranzschwellen wichtiger sein können als die AI
Ein Punkt, der in Vendor-Pitches oft zu wenig Gewicht bekommt: Der größte Teil des Nutzens bei der automatisierten Rechnungsabgleichung entsteht durch klug gewählte Toleranzregeln, nicht durch die Raffinesse des Extraktionsmodells. Eine Preisabweichungstoleranz von 2% und ein definierter Frachtkosten-Spielraum sorgen dafür, dass ein großer Teil der Rechnungen automatisch freigegeben wird, ganz egal, wie sie extrahiert wurden. Wenn diese Schwellenwerte in die eine oder andere Richtung falsch gesetzt sind — zu eng, und das System eskaliert fast alles und verfehlt damit seinen Zweck; zu großzügig, und es gibt Rechnungen frei, die eigentlich hätten geprüft werden müssen —, wirkt sich das stärker auf die reale Leistung des Systems aus als marginale Verbesserungen bei der OCR-Genauigkeit. Das ist ebenso sehr eine Frage von Finanz- und Beschaffungsrichtlinien wie eine technische Entscheidung, und es sollte von den Verantwortlichen für die AP-Richtlinien festgelegt und regelmäßig überprüft werden, nicht als Standardvorgabe bleiben.
Integration mit dem ERP
Damit sich der Aufbau lohnt, muss das System PO- und Wareneingangsdaten direkt aus dem ERP lesen können (SAP, NetSuite, Dynamics oder ein branchenspezifisches Fertigungs-ERP) und abgeglichene Rechnungen in einem Format zurück in den AP-Workflow schreiben, das das ERP ohne manuelle Neueingabe verbuchen kann. Die Integrationsschicht — nicht das Extraktionsmodell — ist in der Regel der Punkt, an dem der eigentliche Engineering-Aufwand und das eigentliche Risiko liegen, weil sie mit den Eigenheiten des ERP umgehen muss: wie es Teillieferungen abbildet, wie es mehrwährungsfähige POs verarbeitet und wie Abweichungen codiert werden sollen, wenn sie verbucht werden.
Ein Rollout-Ansatz, der die Kontrolle beim AP-Team lässt
- Beginnen Sie mit Ihren volumenstärksten, standardisiertesten Lieferanten. So lässt sich die Extraktions- und Matching-Logik anhand der Rechnungen prüfen, bei denen sich Korrektheit am einfachsten verifizieren lässt.
- Schalten Sie die automatische Buchung anfangs aus. Lassen Sie das System im Modus laufen, in dem es einen Match vorschlägt und ein AP-Sachbearbeiter ihn freigibt, damit Sie die Genauigkeit an echten Ergebnissen messen können, bevor Sie es automatisch buchen lassen.
- Aktivieren Sie die automatische Buchung nur für Rechnungen, die innerhalb enger Toleranzen sauber zusammenpassen. Alles andere — und das sollte bei komplexen Lieferanten bewusst ein relevanter Anteil des Volumens bleiben — läuft weiterhin an eine Person, absichtlich und nicht als Ausweichlösung.
Das ehrliche Ziel eines solchen Systems ist nicht „Zero-Touch AP“. Es geht darum, die Zeit der Mitarbeitenden von der erneuten Eingabe und Prüfung von Rechnungen abzuziehen, die ohnehin sauber gematcht hätten, und sie auf den kleineren Bestand an Ausnahmen zu lenken, bei denen wirklich menschliches Urteilsvermögen gefragt ist — und genau dort liegt in einer Fertigungs- oder Vertriebsumgebung meist ohnehin das eigentliche finanzielle Risiko.
Was vor und nachher gemessen werden sollte
Es ist leicht anzunehmen, ein solches Projekt funktioniere, weil Rechnungen schneller freigegeben werden, und dabei zu übersehen, ob sie auch korrekt freigegeben werden. Einige Kennzahlen sollten von Beginn an bewusst verfolgt werden, bevor das System live geht, und dann noch einmal nach einigen Monaten: der Anteil der Rechnungen, die ohne Ausnahme automatisch gematcht werden, der Anteil, der an eine Person weitergeleitet wird, und warum, die durchschnittliche Zeit vom Rechnungseingang bis zur Buchung und — das wird von Teams am häufigsten ausgelassen — ein regelmäßiger manueller Audit einer Stichprobe automatisch gematchter Rechnungen, um zu bestätigen, dass die Matches tatsächlich korrekt waren und nicht nur von den Toleranzregeln akzeptiert wurden. Ein System, das Rechnungen schneller freigibt, aber mit geringerer Genauigkeit, hat nichts verbessert; es hat den Punkt, an dem Fehler entdeckt werden, nur weiter nach hinten verschoben, meist in einen Lieferantenstreit oder einen Periodenabschlussabgleich, wo die Behebung deutlich teurer wird.
Es lohnt sich auch, diese Zahlen getrennt nach Lieferant oder Lieferantenkategorie zu verfolgen und nicht nur als eine zusammengefasste Kennzahl. Ein System, das insgesamt gut funktioniert, kann für einen bestimmten Lieferanten, dessen Rechnungsformat sich geändert hat, trotzdem stillschweigend versagen, und eine aggregierte Zahl würde das verbergen, bis die Ausnahme-Warteschlange für diesen Lieferanten sich über Wochen gestaut hat.
Wenn das Volumen an Rechnungsabweichungen einen überproportionalen Teil der Zeit Ihres AP-Teams auffrisst, helfen wir Ihnen gern dabei herauszufinden, wo Document Intelligence tatsächlich den entscheidenden Unterschied machen würde, bevor Sie sich für eine Umsetzung entscheiden. Kontaktieren Sie uns, und wir gehen Ihren aktuellen Matching-Workflow gemeinsam durch.
Verwandt