ERP & Automatisierung
PDF-Belege automatisch ins ERP übernehmen: Der Leitfaden für den Mittelstand
In fast jedem mittelständischen Unternehmen existiert derselbe Prozess, und fast nirgends taucht er in einer Digitalisierungsstrategie auf: Ein Beleg kommt als PDF per E-Mail an — eine Bestellung, eine Rechnung, ein Lieferschein — und ein Mensch überträgt die Daten von Hand ins ERP-System. Position für Position, Artikelnummer für Artikelnummer, Preis für Preis.
Dieser Prozess ist so alltäglich, dass er unsichtbar geworden ist. Dabei bindet er in einem typischen Industrieunternehmen mit 50 bis 500 Mitarbeitenden täglich mehrere Stunden qualifizierter Arbeitszeit, produziert vermeidbare Fehler mit teuren Folgekosten — und ist mit dem Stand der Technik von heute vollständig automatisierbar, ohne dass dafür ein einziges Dokument das eigene Netzwerk verlassen muss.
Dieser Leitfaden erklärt, welche Belege sich automatisieren lassen, welche Lösungswege es gibt, wie eine moderne Extraktions-Pipeline technisch funktioniert — und woran sich seriöse von unseriösen Genauigkeitsversprechen unterscheiden lassen.
Das stille Kostenleck: was manuelle Belegerfassung kostet
Die Zahlen sind seit Jahren gut dokumentiert. Branchenanalysen wie der Billentis-Report beziffern die vollständigen Prozesskosten einer manuell verarbeiteten Eingangsrechnung auf rund 15 bis 40 Euro — je nach Unternehmensgröße und Prozesstiefe, ein häufig zitierter Mittelwert liegt bei 17,60 Euro pro Beleg. Automatisierte Verarbeitung senkt diese Kosten auf etwa 4 Euro, eine Reduktion um bis zu 70 Prozent.
Diese Zahlen erfassen die direkte Bearbeitungszeit: öffnen, lesen, ins ERP übertragen, prüfen, ablegen. Die teureren Posten stehen jedoch selten in solchen Statistiken:
- Fehlerfolgekosten: Ein Zahlendreher in einer Bestellposition wird zur falschen Kommissionierung, zur Falschlieferung, zur Gutschrift, zur Retoure. Aus einem 30-Sekunden-Tippfehler werden schnell mehrere hundert Euro Prozesskosten — und ein verärgerter Kunde.
- Latenz: Belege, die einen halben Tag in einem Postfach liegen, verzögern Auftragsbestätigungen, Wareneingänge und Zahlungsläufe. Skontofristen verstreichen, Liefertermine geraten unter Druck.
- Saisonspitzen und Vertretungsfälle: Die Erfassung skaliert mit Personen. Bei Auftragsspitzen, Urlaub oder Krankheit entsteht sofort ein Rückstau — oder Überstunden.
- Opportunitätskosten: Die Mitarbeitenden, die Belege abtippen, sind dieselben, die Kunden beraten, Reklamationen lösen und Lieferanten verhandeln könnten. Gerade im Fachkräftemangel ist das die teuerste Verwendung knapper Innendienst-Kapazität.
Eine einfache Überschlagsrechnung für ein Unternehmen mit 40 Belegen pro Tag (Bestellungen, Rechnungen, Lieferscheine zusammengenommen), durchschnittlich 6 Minuten pro Beleg und 45 Euro Vollkosten pro Stunde: 40 × 6 Minuten = 4 Arbeitsstunden täglich, also rund 180 Euro pro Tag oder knapp 40.000 Euro pro Jahr — Fehlerfolgekosten noch nicht eingerechnet. Bei 100 Belegen pro Tag liegt der Wert entsprechend bei rund 100.000 Euro jährlich. (Die vollständige, nachrechenbare Modellrechnung inklusive Fehler-, Skonto- und Opportunitätseffekten: Was kostet manuelle Belegerfassung wirklich?)
Welche Belege betroffen sind — und warum „E-Rechnung” das Problem nicht löst
Wer „Belegerfassung automatisieren” hört, denkt zuerst an Eingangsrechnungen. Tatsächlich ist der Rechnungseingang nur ein Teil des Problems — und ausgerechnet der Teil, der sich regulatorisch gerade von selbst löst, zumindest in Deutschland.
| Belegart | Richtung | Strukturiert verfügbar? | Realität im Mittelstand |
|---|---|---|---|
| Eingangsrechnung (DE) | eingehend | zunehmend (E-Rechnungspflicht B2B seit 2025, Ausstellung gestaffelt) | Übergangsphase: weiterhin viele PDF-Rechnungen, Auslandslieferanten, Gutschriften |
| Eingangsrechnung (CH) | eingehend | nein — keine B2B-Pflicht; QR-Rechnung strukturiert nur Zahlungsdaten, keine Positionen | PDF bleibt Standard |
| Kundenbestellung / Auftrag | eingehend | nein — von keiner E-Rechnungs-Regulierung erfasst | PDF per E-Mail ist der Normalfall, EDI nur bei Großkunden |
| Auftragsbestätigung | eingehend | nein | |
| Lieferschein | eingehend | nein | PDF oder Papier |
| Bedarfsmeldungen, Preislisten, Spezifikationen | eingehend | nein | PDF, Excel, teils Scan |
Die Pointe: Die deutsche E-Rechnungspflicht macht mittelfristig genau eine Belegart strukturiert — die Rechnung. Bestellungen, Auftragsbestätigungen und Lieferscheine bleiben auf Jahre hinaus unstrukturierte PDFs. Und in der Schweiz existiert für B2B-Rechnungen gar keine entsprechende Pflicht; verpflichtend ist die E-Rechnung dort nur gegenüber der Bundesverwaltung. Wer den größten Hebel sucht, findet ihn deshalb meist nicht in der Buchhaltung, sondern in der Auftragserfassung: Dort hängen Liefertermine, Lagerbewegungen und Umsatz direkt an der Geschwindigkeit und Korrektheit der Erfassung. (Vertiefungen: Auftragserfassung automatisieren · Was die E-Rechnung löst — und was nicht · Lieferscheine und Auftragsbestätigungen: die vergessenen Belege)
Warum das Problem heute lösbar ist — und 2019 noch nicht war
Automatische Belegerkennung ist kein neues Versprechen. Klassische OCR-Lösungen mit Vorlagen („Templates”) gibt es seit über zwanzig Jahren — und sie sind regelmäßig an derselben Stelle gescheitert: Jedes Lieferanten-Layout brauchte eine eigene Vorlage. Bei zehn Geschäftspartnern funktioniert das. Bei dreihundert Partnern, die ihre Layouts gelegentlich ändern, wird die Vorlagenpflege zum eigenen Teilzeitjob, und das System erfasst trotzdem nur, was es kennt.
Der technologische Sprung der letzten Jahre verändert die Ausgangslage grundlegend. Moderne Sprachmodelle lesen Dokumente template-frei: Sie müssen ein Layout nicht kennen, um zu verstehen, dass „Pos. 3, Art.-Nr. 4711, 250 Stk. à 12,80” eine Bestellposition ist — auch wenn die Tabelle über einen Seitenumbruch läuft, die Artikelbezeichnung dreizeilig ist oder der Rabatt in einer Fußnote steht. Drei Entwicklungen kommen zusammen:
- Layout-Parser wie Docling (ein Open-Source-Projekt, ursprünglich von IBM Research) wandeln PDFs inklusive Tabellenstrukturen zuverlässig in maschinenlesbares Markdown um — auf normaler Server-CPU, ohne GPU.
- Kompakte Open-Weights-Modelle extrahieren daraus strukturierte Daten. Für diese Aufgabe braucht es kein Frontier-Modell aus der Cloud: Spezialisierte Extraktionsmodelle und kompakte Generalisten im Bereich von 4 bis 30 Milliarden Parametern (Stand Juni 2026 etwa die Gemma-Familie von Google oder auf Extraktion feinabgestimmte Modelle wie NuExtract) erledigen das lokal, auf eigener Hardware.
- Constrained Decoding zwingt das Modell, exakt das vorgegebene JSON-Schema zu liefern — die Ausgabe ist damit garantiert maschinenverarbeitbar und direkt gegen das ERP-Datenmodell validierbar.
Entscheidend ist die Einordnung: Diese Technik macht die Extraktion nicht fehlerfrei. Sie macht sie template-frei, lokal betreibbar und prüfbar — und das verschiebt die Architekturfrage von „Wie erkennen wir jedes Layout?” zu „Wie stellen wir sicher, dass kein Fehler unbemerkt durchrutscht?”. Dazu gleich mehr.
Die Lösungswege im Vergleich
Für die Automatisierung des Belegeingangs existieren im Wesentlichen vier Wege — mit sehr unterschiedlichen Profilen:
| EDI | ERP-Bordmittel (E-Rechnung) | Cloud-SaaS (IDP) | On-Premise-Pipeline | |
|---|---|---|---|---|
| Abdeckung | nur angebundene Partner | nur ZUGFeRD/XRechnung | breit | breit, alle Belegarten |
| Aufwand pro Geschäftspartner | hoch (Anbindungsprojekt) | keiner | keiner | keiner (template-frei) |
| Datenfluss | direkt | im ERP | über Anbieter-Cloud | bleibt im eigenen Netzwerk |
| Laufende Kosten | Verbindungsgebühren | inklusive | Abo + Volumen-/Dokumentpreise | Strom + Wartung, keine Stückkosten |
| ERP-Integration | nativ | nativ | Standard-Konnektor oder Export | maßgeschneidert, direkt |
| Eigentum an der Lösung | — | — | nein (Lock-in) | ja, inkl. Code |
EDI bleibt der Goldstandard für hochvolumige, dauerhafte Geschäftsbeziehungen — wo es existiert. In der Praxis haben aber selbst gut digitalisierte Mittelständler nur ihre größten Partner per EDI angebunden. Der lange Rest — oft 80 Prozent der Partner, die zusammen 20 bis 50 Prozent des Volumens schicken — sendet PDFs. Eine Extraktions-Pipeline ist insofern kein EDI-Ersatz, sondern dessen pragmatische Ergänzung: Sie behandelt das PDF wie eine eingehende EDI-Nachricht — strukturiert, validiert, automatisch verbucht. (Ausführlich: EDI für kleine Geschäftspartner — die realistische Alternative)
Cloud-SaaS-Anbieter (der Markt heißt „Intelligent Document Processing”) liefern schnelle Ergebnisse und sind für manche Unternehmen der richtige Weg. Drei strukturelle Eigenschaften sollte man dabei einpreisen: Erstens fließen sämtliche Geschäftsdokumente — Preise, Konditionen, Kundenbeziehungen — dauerhaft durch die Infrastruktur eines Dritten. Zweitens skalieren die Kosten mit dem Belegvolumen, typischerweise als Abo plus Staffelpreise; das Einsparpotenzial wird also anteilig an den Anbieter weitergereicht, dauerhaft. Drittens endet die Integration häufig an einem Standard-Konnektor oder CSV-Export — der letzte Meter ins eigene, gewachsene ERP bleibt offen, und genau dort steckt im Mittelstand die eigentliche Arbeit.
Die On-Premise-Pipeline dreht diese drei Punkte um: Dokumente bleiben im Haus, die Kosten sind nach dem Aufbau im Wesentlichen fix (Hardware, Strom, Wartung — keine Stückpreise), und die Integration wird exakt auf das vorhandene ERP-Datenmodell gebaut, bis hin zum direkten Schreiben in die Belegtabellen mit den hauseigenen Validierungsregeln. Der Preis dafür: Es ist ein Projekt, kein Abo-Abschluss. Es braucht einen Partner, der beides kann — moderne KI-Extraktion und solide ERP-Integration. (Vertiefung zur Datenschutz-Seite: KI-Dokumentenverarbeitung on-premise)
So funktioniert eine moderne Dokumenten-Pipeline
Der häufigste Konstruktionsfehler bei KI-Extraktion ist, das Sprachmodell als Gesamtlösung zu betrachten: PDF rein, fertige Buchung raus. Wer so baut, baut ein System, dessen Fehler niemand bemerkt. Eine produktionsreife Pipeline ist anders aufgebaut — als gestuftes System, in dem die KI genau eine Aufgabe hat und von deterministischen Prüfungen eingerahmt wird.
Stufe 0 — Eingang und Weiche
Jede eingehende Datei wird zuerst identifiziert (per kryptografischem Hash) und auf Dubletten geprüft — dieselbe Bestellung, zweimal gemailt, darf nie zweimal im ERP landen. Bereits strukturierte Eingänge (CSV-Exporte, echte E-Rechnungen) werden deterministisch geparst und brauchen gar keine KI. Nur unstrukturierte PDFs gehen in den Extraktionspfad.
Stufe 1 — Parsing: vom PDF zu lesbarem Text
Ein Layout-Parser wandelt das PDF in strukturiertes Markdown um — inklusive Tabellen, Lesereihenfolge und Positionsbezügen. Bei „born-digital” erzeugten PDFs (dem Normalfall im B2B-Verkehr) ist dafür nicht einmal OCR nötig; der Textlayer wird direkt ausgewertet. Der vollständige Rohtext wird gespeichert: Er ist später der Anker, gegen den jeder extrahierte Wert belegt werden muss.
Stufe 2 — Extraktion: das Modell schreibt ab, es rechnet nicht
Das Sprachmodell erhält den Rohtext und ein striktes Zielschema — die Felder des ERP-Belegmodells: Bestellnummer, Datum, Währung, Positionen mit Artikelnummer, Menge, Preis, Rabatt. Zwei Prinzipien sind hier entscheidend:
- Abschreiben statt Rechnen. Das Modell überträgt ausschließlich Werte, die wörtlich im Dokument stehen. Berechnete Felder (Nettopreise, Summen) ermittelt später deterministischer Code — denn Sprachmodelle sind gute Leser und unzuverlässige Taschenrechner.
- Constrained Decoding. Die Ausgabe wird auf das exakte JSON-Schema gezwungen. Das garantiert die Syntax — wohlgemerkt: nur die Syntax. Ob die Werte stimmen, prüft die nächste Stufe.
Stufe 3 — Validierung: Mathematik lügt nicht
Jetzt übernimmt deterministische Logik, und hier entsteht die eigentliche Verlässlichkeit des Systems:
- Arithmetik-Prüfung: Menge × Einzelpreis (abzüglich Rabatt) muss den Positionsbetrag ergeben; die Summe der Positionen muss zur Belegsumme passen — auf Rundungstoleranz genau. Ein Zahlendreher beim Abschreiben (12,80 → 12,08) fliegt hier mathematisch auf, ohne dass irgendjemand das Originaldokument ansehen muss.
- Grounding-Prüfung: Jeder extrahierte Wert muss sich im gespeicherten Rohtext wiederfinden lassen. Was das Modell nicht belegen kann, gilt als nicht extrahiert — das fängt Halluzinationen auch bei Feldern ab, die sich nicht nachrechnen lassen.
- Stammdaten-Abgleich: Artikelnummern werden gegen den Artikelstamm geprüft, Geschäftspartner gegen die Stammdaten, Währungen und Datumsformate normalisiert.
Stufe 4 — Eskalation und Mensch in der Schleife
Besteht ein Beleg alle Prüfungen, wird er automatisch ins ERP übernommen. Schlägt eine Prüfung an, eskaliert die Pipeline gestuft: erst stärkere Maschinerie (etwa ein Vision-Modell für PDFs mit beschädigtem Textlayer), dann — für die verbleibenden Restfälle — eine Review-Oberfläche, in der ein Mensch den Beleg neben den extrahierten Daten sieht und mit wenigen Klicks korrigiert. Jede Korrektur fließt als Beispiel zurück in die Pipeline und verbessert sie.
Das richtige Qualitätsziel: 0 % unentdeckte Fehler
Anbieter werben gern mit „bis zu 99 % Genauigkeit”. Diese Zahl ist aus zwei Gründen irreführend. Erstens bezieht sie sich meist auf einzelne Felder — ein Beleg mit 30 Feldern und 99 % Feldgenauigkeit ist nur mit etwa 74 % Wahrscheinlichkeit komplett korrekt. Zweitens verschweigt sie die entscheidende Frage: Woher weiß das System, welche Belege die fehlerhaften sind?
Das seriöse Qualitätsziel lautet deshalb nicht „100 % Rohgenauigkeit” (die ist bei frei gestalteten Layouts strukturell unerreichbar), sondern: null unentdeckte Fehler unter den automatisch übernommenen Belegen. Erreichbar ist das genau durch die beschriebene Architektur — harte mathematische Invarianten, Belegbarkeit jedes Werts gegen die Quelle, und eine Review-Queue für alles, was die Prüfungen nicht besteht. In der Praxis heißt das anfangs typischerweise: 70 bis 90 Prozent der Belege laufen vollautomatisch durch, der Rest landet zur schnellen Prüfung in der Queue — Tendenz mit jeder Korrektur steigend. Das ist ein ehrliches Betriebsmodell, das Verantwortliche gegenüber Geschäftsführung und Wirtschaftsprüfung vertreten können. (Warum die üblichen Genauigkeitsversprechen täuschen: Warum „99 %” die falsche Frage ist · die technische Tiefenbohrung: Anatomie einer Dokumenten-Pipeline)
Datenschutz und Souveränität: warum on-premise
Geschäftsbelege sind konzentrierte Geschäftsgeheimnisse: Einkaufskonditionen, Kundenpreise, Liefermengen, Margenstruktur. Bei Cloud-Verarbeitung entsteht daraus ein Geflecht aus Auftragsverarbeitungsverträgen, Drittstaaten-Fragen (Stichwort CLOUD Act bei US-Anbietern) und einem Restrisiko, das sich nicht wegverhandeln lässt: Die Daten sind physisch woanders.
Eine On-Premise-Pipeline löst diese Fragenklasse vollständig: Die Modelle laufen auf eigener Hardware im eigenen Netzwerk, kein Dokument und kein Tokenstrom verlässt das Haus. Open-Weights-Modelle (frei verfügbare Modellgewichte unter Lizenzen wie Apache 2.0) machen das ohne Lizenzkosten und ohne Anbieterabhängigkeit möglich — das Modell ist eine austauschbare Komponente, keine externe Abhängigkeit.
Die Hardware-Hürde ist dabei deutlich niedriger, als viele erwarten: Für mittelständische Belegvolumina genügt eine einzelne GPU-Workstation; kompakte KI-Appliances der DGX-Spark-Klasse (128 GB Unified Memory, Größenordnung 4.000 Euro) halten Extraktions- und Vision-Modell gleichzeitig im Speicher und verarbeiten damit das Tagesvolumen eines typischen Industrieunternehmens in Minuten. Zum Vergleich: Das entspricht wenigen Monatsraten eines IDP-SaaS-Abos mittlerer Größe. (Ausführlich: KI-Dokumentenverarbeitung on-premise: souverän ohne Cloud)
Einführung in der Praxis: vom Piloten zum Produktivbetrieb
Der belastbare Weg in den Produktivbetrieb führt über drei Stufen — und über eine Disziplin, die häufig übersprungen wird: ein Gold-Set. Das sind reale Belege aus dem eigenen Eingang, für die das korrekte Ergebnis einmal manuell festgelegt wird. Gegen dieses Set wird die Pipeline gemessen — nicht gegen Bauchgefühl oder Hersteller-Demos.
- Pilot (etwa 10 reale Belege, 2–3 Wochen): Die Pipeline läuft End-to-End gegen das Gold-Set. Hier zeigt sich, ob Schema, Prüfregeln und Stammdaten-Abgleich zur eigenen Belegwelt passen. Ein bewusst eingebauter Fehler muss zuverlässig gefangen werden — sonst ist die Validierung Dekoration.
- Validierung (etwa 100 Belege, inkl. bewusst zurückgehaltener Absender): Jetzt entstehen die Kennzahlen, die zählen: Wie hoch ist die Durchlaufquote ohne Korrektur? Wie genau sind die Positionsdaten? Wie verhält sich das System bei Absendern, die es noch nie gesehen hat? Aus diesen Werten wird die Schwelle kalibriert, ab der ein Beleg automatisch übernommen wird.
- Produktivbetrieb mit Review-Queue: Go-live mit aktivierter menschlicher Prüfung für alle unsicheren Fälle. Die Review-Quote sinkt über die ersten Monate, weil Korrekturen in die Pipeline zurückfließen. Gemessen wird weiter — pro Absender, pro Belegart.
Realistischer Zeithorizont vom Kick-off bis zum Produktivbetrieb: wenige Wochen bis wenige Monate, abhängig von Belegvielfalt und Integrationsweg ins ERP — nicht die ERP-Projekt-Zeiträume, die viele Unternehmen aus leidvoller Erfahrung kennen.
Häufige Fragen
Was kostet die manuelle Erfassung eines Belegs? Branchenanalysen (u. a. Billentis) setzen für eine manuell verarbeitete Eingangsrechnung 15 bis 40 Euro Prozesskosten an; automatisiert sinken die Kosten auf rund 4 Euro. Bei Bestellungen mit vielen Positionen liegen die manuellen Kosten eher höher, weil Erfassungszeit und Fehlerrisiko mit der Positionszahl wachsen.
Erreicht KI-Extraktion 100 % Genauigkeit? Nein — und Anbieter, die das suggerieren, sollte man genau dazu befragen. Erreichbar ist ein System, das fehlerhafte Extraktionen zuverlässig erkennt und zur Prüfung ausleitet: null unentdeckte Fehler unter den automatisch übernommenen Belegen. Möglich machen das deterministische Arithmetik-Prüfungen, der Belegbarkeits-Check gegen den Originaltext und eine Review-Queue.
Brauchen wir dafür Templates pro Lieferant oder Kunde? Nein. Moderne Sprachmodell-Extraktion ist template-frei: Neue Absender und geänderte Layouts werden ohne Einrichtung verarbeitet. Die Qualitätssicherung läuft über inhaltliche Prüfungen, nicht über Layout-Vorlagen.
Welche Belegarten lassen sich automatisieren? Alle strukturierten Geschäftsbelege: Bestellungen, Eingangsrechnungen, Auftragsbestätigungen, Lieferscheine, Gutschriften — auch Excel-Anhänge und Scans. Den größten Hebel hat im Mittelstand meist die Auftragserfassung, weil sie von keiner E-Rechnungs-Regulierung profitiert und direkt an Liefertermin und Umsatz hängt.
Müssen unsere Dokumente dafür in eine Cloud? Nein. Mit Open-Weights-Modellen läuft die komplette Verarbeitung auf eigener Hardware im eigenen Netzwerk — relevant für DSGVO bzw. das Schweizer Datenschutzgesetz und überall dort, wo Belege Geschäftsgeheimnisse enthalten. Cloud-Varianten sind möglich, aber keine technische Notwendigkeit mehr.
Was passiert mit Belegen, die das System nicht sicher lesen kann? Sie landen mit allen bereits extrahierten Daten in einer Review-Oberfläche und werden dort in Sekunden geprüft oder korrigiert — statt minutenlang abgetippt. Jede Korrektur verbessert die Pipeline.
Fazit
Manuelle Belegerfassung ist eines der letzten großen, flächendeckend ungelösten Effizienzprobleme im Mittelstand — und zugleich eines der am klarsten lösbaren. Template-freie KI-Extraktion mit deterministischer Validierung übernimmt Bestellungen, Rechnungen und Lieferscheine automatisch ins ERP; Open-Weights-Modelle auf eigener Hardware halten dabei jedes Dokument im Haus und die Kosten fix. Entscheidend ist die Architektur: Ein Sprachmodell allein ist keine Lösung — eine gestufte Pipeline mit Arithmetik-Prüfung, Quellen-Grounding und Mensch-in-der-Schleife ist es.
kitun baut solche Dokumenten-Pipelines als maßgeschneiderte ERP-Module — on-premise, mit Open-Weights-Modellen, direkt integriert in das vorhandene ERP, inklusive Code-Übergabe. Wer den eigenen Belegeingang auf Automatisierbarkeit prüfen will, findet im 20-minütigen Erstgespräch eine schnelle erste Einschätzung.