ERP & Automatisierung
EDI für kleine Geschäftspartner: Warum PDF-Extraktion die realistische Alternative ist
Elektronischer Datenaustausch zwischen ERP-Systemen — EDI — ist seit Jahrzehnten der Goldstandard für automatisierte Geschäftsprozesse: Bestellung, Auftragsbestätigung, Lieferavis und Rechnung fließen ohne menschliches Zutun von System zu System. Wo EDI läuft, gibt es kein Abtippen, keine Übertragungsfehler, keine Latenz.
Die unbequeme Wahrheit steht im Wort „wo”: In den meisten mittelständischen Unternehmen läuft EDI mit einer Handvoll Partnern — und der gesamte Rest des Geschäftsverkehrs kommt als PDF per E-Mail. Dieser Artikel erklärt, warum das kein Versäumnis ist, sondern ökonomische Logik; warum WebEDI und Portale daran wenig ändern; und wie sich der lange Rest der Partnerliste heute trotzdem automatisieren lässt.
Warum EDI im Long Tail scheitert: eine Kostenrechnung
Eine EDI-Anbindung ist kein Schalter, sondern ein Projekt — pro Geschäftspartner. Formate abstimmen (EDIFACT, ANSI X12, branchenspezifische Subsets), Feld-Mappings definieren, Testzyklen mit beiden Seiten fahren, Sonderfälle klären, Betrieb und Monitoring aufsetzen. Je nach Komplexität und Dienstleister liegen die Kosten pro Anbindung im vierstelligen bis fünfstelligen Bereich, plus laufende Gebühren für Übertragung oder Clearing — und plus Wartung, wenn ein Partner sein System wechselt.
Diese Rechnung kippt schnell. Ein Beispiel mit realistischen Größenordnungen: Ein Kunde, der zwölfmal im Jahr bestellt, verursacht bei manueller Erfassung (8 Minuten, 45 €/h Vollkosten) etwa 72 Euro Erfassungskosten pro Jahr. Selbst eine günstige EDI-Anbindung für 3.000 Euro amortisiert sich gegen diese 72 Euro rechnerisch erst nach Jahrzehnten. Bei einem Großkunden mit zwanzig Bestellungen täglich dreht sich das Bild vollständig — dort amortisiert sich dieselbe Anbindung in Wochen.
Deshalb sieht die EDI-Landschaft im Mittelstand überall gleich aus, völlig zu Recht: Die Top-5-bis-20-Partner sind angebunden, die übrigen 80 bis 95 Prozent der Partnerliste nicht — und werden es nie. Das Problem: Dieser lange Schwanz schickt zusammen häufig 20 bis 50 Prozent des Belegvolumens. Genau diese Belege werden heute abgetippt.
WebEDI und Portale: das Problem wird verschoben, nicht gelöst
Die Branchenantwort auf den Long Tail heißt WebEDI: Der kleine Geschäftspartner bekommt ein Webportal, in das er seine Bestellungen, Auftragsbestätigungen oder Lieferdaten von Hand einträgt. Technisch entsteht dabei eine saubere EDI-Nachricht. Praktisch ist es Datenerfassung per Mensch — nur dass jetzt der Partner tippt statt des eigenen Innendiensts.
Entsprechend fallen die Ergebnisse aus. Für den Partner ist das Portal ein Fremdsystem ohne Integration in seine Abläufe: Er erfasst jede Bestellung doppelt — einmal im eigenen ERP, einmal im Portal des Kunden. Wer mehrere Großkunden mit jeweils eigenem Portal beliefert, jongliert ein Dutzend Logins und Oberflächen. Die Folge ist bekannt: zögerliche Nutzung, Eingabefehler, Belege, die doch wieder per Mail kommen. WebEDI funktioniert dort, wo ein mächtiger Marktteilnehmer Druck ausüben kann — im klassischen Mittelstandsgeschäft unter Augenhöhe-Partnern funktioniert es selten gut.
Der Kern des Problems: Beide Ansätze — klassisches EDI wie WebEDI — verlangen, dass der Geschäftspartner sein Verhalten ändert. Das ist die teuerste Währung im B2B-Geschäft.
Der dritte Weg: das PDF wie eine EDI-Nachricht behandeln
Dabei ist die Ausgangslage besser als ihr Ruf. Das PDF, das der Partner schickt, ist ja kein Chaos — es ist ein maschinell erzeugter, sauber strukturierter Beleg aus seinem ERP-System. Alle Daten einer EDI-Nachricht stehen darin; sie sind nur als Layout statt als Datensatz kodiert. Moderne, template-freie KI-Extraktion dekodiert genau das: Sie liest den Beleg unabhängig vom Absender-Layout, überträgt die Werte in ein striktes Zielschema und übergibt — nach denselben Prüfungen, die auch eine EDI-Nachricht durchlaufen würde — an das ERP.
Die Analogie zu EDI ist dabei präziser, als sie zunächst klingt, denn die belastbare Pipeline übernimmt alle Rollen einer EDI-Strecke:
- Das Mapping übernimmt das Extraktionsmodell — allerdings template-frei: Neue Absender brauchen keine Einrichtung, geänderte Layouts kein Re-Mapping. Der „Anbindungsaufwand pro Partner”, der EDI im Long Tail unwirtschaftlich macht, entfällt strukturell.
- Die Syntaxprüfung erledigt das erzwungene Zielschema (Constrained Decoding): Die Ausgabe ist garantiert wohlgeformt.
- Die Plausibilitätsprüfung leistet deterministische Validierung — Arithmetik der Positionen, Abgleich gegen Artikel- und Partnerstamm, Belegbarkeit jedes Werts im Quelldokument.
- Das Fehler-Handling übernimmt eine Review-Queue statt eines EDI-Clearing-Tickets: Unsichere Belege landen vorausgefüllt bei einem Menschen, der in Sekunden entscheidet.
Für den Geschäftspartner ändert sich: nichts. Er bestellt, bestätigt und liefert, wie er es immer getan hat. Genau deshalb funktioniert dieser Weg auch dort, wo Portale scheitern. (Den Auftragseingang als wichtigsten Anwendungsfall behandelt im Detail der Artikel zur automatisierten Auftragserfassung.)
Wann echtes EDI trotzdem die richtige Antwort ist
Ehrlichkeit gehört dazu: PDF-Extraktion ersetzt EDI nicht überall, und sie sollte es nicht.
- Hochvolumige Dauerbeziehungen — der Kunde mit zwanzig Bestellungen täglich, der Logistikpartner mit Lieferavisen im Minutentakt — gehören auf eine echte EDI-Strecke. Determinismus schlägt Extraktion, wo sich die Anbindung rechnet.
- Branchen mit EDI-Zwang (Automotive, große Handelsketten) lassen ohnehin keine Wahl: Wer liefern will, bedient die geforderten Standards.
- Echtzeit-Prozesse wie Just-in-Time-Abrufe brauchen garantierte Maschinenlatenz, keine E-Mail-Postfächer.
Die realistische Zielarchitektur ist deshalb eine Koexistenz: EDI für die Partner, bei denen es sich rechnet — Extraktion für alle anderen. Beide Pfade münden in dieselbe Validierung und dieselben ERP-Prozesse; für das ERP ist nicht erkennbar (und nicht relevant), ob ein Auftrag aus einer EDIFACT-Nachricht oder einem PDF entstand. Das Gesamtbild dieser Architektur zeichnet der Leitfaden zur Belegautomatisierung.
Häufige Fragen
Ist PDF-Extraktion so zuverlässig wie EDI? EDI ist deterministisch und bleibt das Maß für angebundene Partner. Eine validierte Extraktions-Pipeline erreicht für den Long Tail das betrieblich entscheidende Ziel: Belege laufen automatisch durch, und kein Fehler passiert unbemerkt — Arithmetik-Prüfung, Quellen-Grounding und Review-Queue sichern das ab. Der Unterschied zur manuellen Erfassung, die heute den Long Tail bedient, ist in beiden Dimensionen dramatisch.
Können wir damit Partner später auf EDI umziehen? Ja — und besser informiert: Die Pipeline liefert pro Absender Volumen- und Qualitätsdaten. Rechtfertigt ein Partner irgendwann eine echte Anbindung, ist das ein gezieltes Projekt statt einer Bauchentscheidung.
Was ist mit ausgehenden Belegen? Extraktion betrifft den Eingang. Ausgehend (Auftragsbestätigungen, Rechnungen) erzeugt das eigene ERP strukturierte Daten — dort sind E-Rechnung und klassisches EDI die richtigen Kanäle. Die Kombination beider Richtungen ergibt den vollständig automatisierten Belegfluss.
Lohnt sich das schon bei wenigen PDF-Belegen pro Tag? Die Wirtschaftlichkeit hängt am Volumen und an den Fehlerkosten. Ab etwa 10–20 Belegen täglich wird es regelmäßig deutlich; darunter entscheidet der Einzelfall — eine kurze Bestandsaufnahme des Belegeingangs beantwortet das meist in einer Stunde.
Fazit
Dass EDI nur die größten Partner erreicht, ist keine Nachlässigkeit, sondern Mathematik: Anbindungskosten pro Partner gegen Belegvolumen pro Partner. Der lange Rest der Partnerliste war bisher schlicht nicht automatisierbar — Portale verschieben die Arbeit nur zum Partner. Template-freie PDF-Extraktion mit deterministischer Validierung schließt genau diese Lücke: Sie behandelt das PDF als das, was es ist — eine EDI-Nachricht im falschen Gewand — und lässt Geschäftspartner dabei so arbeiten, wie sie es immer getan haben.
kitun baut diese Pipelines als maßgeschneiderte ERP-Module — on-premise, template-frei, koexistent mit bestehenden EDI-Strecken, ohne Stückkosten pro Beleg. Ob der eigene Belegeingang das hergibt, klärt ein 20-minütiges Erstgespräch.