PDF to EDIFACT oder XRechnung: Warum OCR allein nicht reicht

Eine PDF-Rechnung sieht oft so aus, als wäre sie schon digital. Sie kommt per E-Mail, liegt im Download-Portal, hat sauber gesetzte Spalten und lässt sich problemlos öffnen. Für Menschen ist das praktisch. Für Systeme ist es oft nur die halbe Wahrheit.

Man kann sich das vorstellen wie einen Screenshot aus Excel. Auf dem Bild sieht man Zahlen, Summen, Positionen und Spaltenüberschriften. Aber niemand kann darin filtern, Formeln prüfen, Zellbezüge auslesen oder Pflichtfelder automatisch validieren. Der Screenshot zeigt Informationen. Er liefert aber keine belastbare Datenstruktur.

Genau an dieser Stelle stößt OCR an seine Grenze. OCR kann sichtbare Zeichen erfassen. Für PDF to EDIFACT, PDF to XRechnung oder PDF to EDI reicht das allein aber nicht aus. Denn in diesen Workflows geht es nicht nur um Text. Es geht um Geschäftskontext, Feldlogik, Tabellenstruktur, Validierung und die Übergabe an nachgelagerte Systeme.

Oder kurz gesagt: OCR liest Zeichen. PEDIF erkennt wiederkehrende Geschäftsdokumente.

Das Problem ist nicht das PDF

PDFs sind in der Geschäftskommunikation beliebt, weil sie einfach sind. Lieferanten, Kunden und Partner können sie erzeugen, versenden, öffnen und archivieren. Viele Prozesse im Einkauf, in Finance, im Vertrieb und in der Supply Chain laufen deshalb weiterhin PDF-basiert.

Das Problem beginnt erst, wenn ein ERP-, EDI- oder Finance-System mit diesen Informationen weiterarbeiten soll. Ein Mensch erkennt vielleicht sofort, wo Rechnungsnummer, Lieferant, Nettobetrag, Steuerbetrag, Bruttosumme, Bestellreferenz und Positionstabelle stehen. Ein System braucht diese Inhalte aber nicht als sichtbaren Text, sondern als eindeutig strukturierte Daten.

Für Finance bedeutet das: Solange Rechnungen nur als PDF vorliegen, bleiben manuelle Prüfung, Nacharbeit und Medienbrüche wahrscheinlicher.

Für IT und EDI bedeutet das: Ein PDF ist keine EDIFACT-Nachricht, keine XRechnung und keine saubere ERP-Nutzlast. Es ist ein Eingangsdokument, aus dem erst ein strukturierter Datenfluss entstehen muss.

Was OCR kann – und warum das nicht genügt

OCR steht für Optical Character Recognition. Die Technologie erkennt Zeichen in Bildern, Scans oder PDF-Dokumenten. Das ist nützlich, besonders wenn Dokumente keine sauber auslesbare Textschicht enthalten.

OCR kann zum Beispiel erkennen:

· eine Rechnungsnummer,

· ein Datum,

· einen Lieferantennamen,

· einen Betrag,

· eine IBAN,

· Positionstexte,

· Mengen und Preise.

Aber OCR beantwortet nicht automatisch die entscheidende fachliche Frage: Was bedeutet dieser Wert im Prozess?

Ein Betrag wie „1.250,00“ kann Nettowert, Bruttowert, Steuerbetrag, Einzelpreis oder Positionssumme sein. Ein Datum kann Rechnungsdatum, Lieferdatum, Leistungsdatum oder Fälligkeitsdatum sein. Eine Nummer kann Rechnungsnummer, Bestellnummer, Kundennummer, Artikelnummer oder Lieferscheinnummer sein.

Bei Tabellen wird es noch anspruchsvoller. Eine Rechnung kann Positionen über mehrere Zeilen, Seitenumbrüche, Rabatte, Zwischensummen, abweichende Mengeneinheiten oder separate Steuerlogiken enthalten. OCR kann Text erkennen. Aber für einen strukturierten Zielprozess muss das System verstehen, welche Spalte welche Bedeutung hat und welcher Wert zu welcher Position gehört.

Das ist der Unterschied zwischen „Text gelesen“ und „Geschäftsdaten verstanden“.

Warum PDF to EDIFACT mehr braucht als Texterkennung

EDIFACT ist kein schön formatiertes Dokument, sondern ein strukturierter elektronischer Nachrichtenaustausch. Wer aus einem PDF eine EDIFACT-nahe Zielstruktur erzeugen möchte, muss die Daten aus dem Dokument in eine definierte Nachrichtenlogik überführen.

Dabei reicht es nicht, den Text aus dem PDF auszulesen. Entscheidend sind Fragen wie:

· Welche Werte gehören in welche EDIFACT-Segmente?

· Welche Pflichtfelder erwartet der Empfänger?

· Welche Referenzen sind Käufer-, Lieferanten-, Kunden- oder Artikelreferenzen?

· Welche Werte müssen normalisiert werden?

· Welche Positionsdaten gehören zusammen?

· Welche Ausnahmen dürfen nicht automatisch durchlaufen?

Das BMF weist im Kontext der E-Rechnung darauf hin, dass auch vereinbarte Formate wie EDIFACT genutzt werden können, sofern das verwendete Format die richtige und vollständige Extraktion der nach dem UStG erforderlichen Angaben ermöglicht. Daraus folgt für PDF-to-EDIFACT vorsichtig formuliert: Nicht der Name des Zielformats allein ist entscheidend, sondern ob die erforderlichen Inhalte korrekt, vollständig und maschinenverarbeitbar abgebildet werden können.

Für Unternehmen bedeutet das: PDF to EDIFACT ist ein Mapping- und Validierungsprozess, kein OCR-Export.

Warum PDF to XRechnung ebenfalls Struktur braucht

Bei XRechnung ist die Abgrenzung besonders sichtbar. Seit dem 1. Januar 2025 liegt im deutschen B2B-Kontext nach BMF eine E-Rechnung grundsätzlich nur noch dann vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und elektronische Verarbeitung ermöglicht. Ein einfaches PDF fällt nicht mehr unter diese Definition und gilt als „sonstige Rechnung“. Übergangsregelungen und konkrete Anwendungsfälle müssen gesondert geprüft werden.

XRechnung ist kein PDF mit anderem Namen. XRechnung steht im Kontext der europäischen Norm EN 16931, semantischer Geschäftsregeln und technischer Syntaxen. Die offizielle XRechnung-Seite beschreibt unter anderem das semantische Datenmodell, Geschäftsregeln sowie die Syntaxen UBL 2.1 und UN/CEFACT CII. Eine Rechnung ist zur CIUS XRechnung nur dann konform, wenn sie als wohlgeformtes XML-Dokument ausgestellt, übermittelt und empfangen wird und die Informationselemente entsprechend der Spezifikation verwendet; Teile davon können maschinell geprüft werden, während semantische Aspekte Kontextinformationen benötigen.

Damit wird klar: Eine PDF-to-XRechnung-Strecke braucht nicht nur Zeichenerkennung. Sie braucht Feldzuordnung, Pflichtfeldlogik, technische Syntax, Geschäftsregeln und Validierung. OCR kann ein Baustein sein. Der eigentliche Wert entsteht aber erst, wenn aus sichtbaren Rechnungsinformationen strukturierte, prüfbare Daten werden.

Der Excel-Screenshot-Effekt

Die Excel-Screenshot-Analogie zeigt das Problem sehr konkret.

Wenn jemand eine Tabelle als Screenshot schickt, sehen Sie vielleicht alles:

· Artikelnummern,

· Mengen,

· Preise,

· Steuerwerte,

· Summen,

· Fußnoten,

· Zahlungsbedingungen.

Aber das empfangende System bekommt keine echte Tabelle. Es bekommt kein Zellformat, keine Spaltenlogik, keine Formeln und keine sichere Beziehung zwischen Kopf, Positionen und Summe. Wenn jemand den Screenshot abtippt oder mit OCR ausliest, entsteht vielleicht Text. Aber noch keine verlässliche Datenstruktur.

Für PDF-Rechnungen gilt dasselbe. Das Dokument ist sichtbar. Aber ERP, EDI und XRechnung brauchen verwertbare Struktur.

PEDIF setzt genau an diesem Übergang an: PDF bleibt der Eingang. Strukturierte Daten sind das Ergebnis.

Wo PEDIF ansetzt

PEDIF ist nicht einfach OCR und nicht nur generische KI-Dokumentenverarbeitung. PEDIF ist als No-Touch PDF Interchange / PDF-to-EDI / Dokumentendigitalisierung in der Supply Chain positioniert. Die Lösung schließt die Lücke zwischen klassischen EDI-Systemen und Geschäftspartnern, die weiterhin PDFs oder andere Nicht-EDI-Dokumente senden.

Der Ansatz ist:

1. PDF bleibt als Eingang möglich.
   Partner müssen ihren Prozess nicht sofort auf EDI, Portal oder API umstellen.

2. Wiederkehrende Layouts werden erkannt.
   PEDIF nutzt Fingerprint-/Augmented-Intelligence-Logik für wiederkehrende Dokumentenlayouts. Der Fokus liegt nicht auf einzelnen Zeichen, sondern auf wiedererkennbaren Geschäftsdokumentstrukturen.

3. Felder werden fachlich zugeordnet.
   Aus Rechnungsnummer, Beträgen, Positionen, Referenzen und Steuern werden nicht nur Textfragmente, sondern strukturierte Felder.

4. Validierung und Ausnahmebehandlung bleiben Teil des Prozesses.
   No-Touch bedeutet nicht No-Control. In geeigneten, geprüften Scopes können Standardfälle automatisiert laufen; Ausnahmen müssen sichtbar bleiben.

5. Das Zielsystem erhält strukturierte Daten.
   Je nach bestätigtem Projekt-Scope kann der Handoff in Richtung EDIFACT/EDI, XRechnung, ERP, XML, CSV oder API vorbereitet werden. Der konkrete Zielstandard, die Feldlogik und die Empfängeranforderungen müssen projektbezogen validiert werden.

So bleibt die PEDIF-Positionierung sauber: PEDIF ersetzt EDI nicht – PEDIF schließt die Lücke dort, wo EDI nicht ankommt.

Praktischer Ablauf: Von PDF zu strukturierter Zielausgabe

Ein typischer Workflow kann so aussehen:

1. PDF-Eingang

Ein Lieferant oder Kunde sendet weiterhin ein PDF. Für den Partner bleibt der bestehende Versandweg zunächst unverändert.

2. Dokument- und Layouterkennung

PEDIF prüft, ob das Dokumentlayout bekannt, wiederkehrend oder aktivierbar ist. Bei bekannten Layouts kann die Verarbeitung stärker standardisiert werden. Neue oder abweichende Layouts müssen geprüft und gegebenenfalls aktiviert werden.

3. Extraktion relevanter Geschäftsdaten

Aus dem PDF werden fachlich relevante Daten extrahiert: zum Beispiel Rechnungsnummer, Rechnungsdatum, Lieferant, Beträge, Steuerinformationen, Positionsdaten oder Bestellreferenzen. Welche Felder verarbeitet werden, hängt vom Dokumenttyp, Zielstandard und Projekt-Scope ab.

4. Plausibilisierung und Validierung

Die extrahierten Daten werden nicht nur gelesen, sondern gegen definierte Erwartungen geprüft. Fehlen Pflichtangaben, passen Summen nicht zusammen oder ist die Zielstruktur unvollständig, sollte eine Ausnahme entstehen statt blinder Automatisierung.

5. Mapping auf Zielstruktur

Die Daten werden in eine Zielstruktur überführt. Das kann je nach Scope EDIFACT/EDI, XRechnung, ERP-Import, XML, CSV oder API-Handoff sein. Diese Zielausgabe darf nicht pauschal behauptet werden, sondern muss im Projekt bestätigt werden.

6. Handoff an nachgelagerte Systeme

Das empfangende System bekommt nicht nur ein sichtbares Dokument, sondern strukturierte Daten. Das ist der eigentliche Unterschied zwischen PDF-Ablage und Prozessautomatisierung.

OCR vs. PEDIF vs. klassisches EDI

Wann reicht OCR, wann braucht es PEDIF?

OCR kann ausreichend sein, wenn Sie nur sichtbaren Text aus einzelnen Dokumenten extrahieren möchten. Zum Beispiel für Suche, Ablage oder einfache Vorverarbeitung.

PEDIF wird relevant, wenn mindestens eine dieser Fragen mit Ja beantwortet wird:

· Kommen regelmäßig ähnliche PDF-Rechnungen oder Geschäftsdokumente an?

· Müssen die Daten in ERP, EDI, XML, CSV oder API weiterlaufen?

· Soll ein PDF-to-EDIFACT- oder PDF-to-XRechnung-Workflow aufgebaut werden?

· Müssen Pflichtfelder, Positionen, Beträge oder Referenzen geprüft werden?

· Gibt es viele Partner, die nicht auf klassisches EDI wechseln?

·  Müssen Ausnahmen sichtbar und steuerbar bleiben?

·  Soll Finance weniger manuell erfassen und IT/EDI einen saubereren Datenstrom erhalten?

Wenn ja, ist die Frage nicht „OCR oder keine OCR“. Die bessere Frage lautet: Wie entsteht aus einem sichtbaren PDF ein kontrollierter Datenfluss?

Typische Missverständnisse

„Wenn OCR die Rechnung lesen kann, ist der Prozess automatisiert.“

Nicht unbedingt. OCR kann Text liefern. Prozessautomatisierung braucht Struktur, Feldlogik, Validierung und Zielsystemübergabe.

„PDF to EDIFACT ist nur ein Formatwechsel.“

Nein. Es ist ein fachlicher Transformationsprozess: Dokumentstruktur erkennen, Werte zuordnen, Pflichtfelder prüfen und Zielsegmente korrekt befüllen.

„XRechnung ist einfach ein anderes PDF-Format.“

Nein. XRechnung ist im Kontext strukturierter XML-Daten, EN 16931, Geschäftsregeln und technischer Validierung zu betrachten. Ein einfaches PDF ist seit 2025 im BMF-Kontext keine E-Rechnung im neuen Sinne.

„PEDIF ersetzt EDI.“

Nein. PEDIF ergänzt EDI. Klassisches EDI bleibt sinnvoll, wenn Partner strukturierte Nachrichten senden können. PEDIF hilft dort, wo Partner weiterhin PDFs oder Nicht-EDI-Dokumente senden.

„No-Touch heißt, dass nie jemand prüfen muss.“

Nein. No-Touch bedeutet nicht No-Control. Standardfälle können im passenden Scope automatisiert laufen. Ausnahmen müssen sichtbar bleiben und gezielt bearbeitet werden.

Fazit

Ein PDF kann digital aussehen und trotzdem für Systeme schwer verwertbar sein. OCR kann Zeichen erkennen, aber daraus entsteht noch keine EDIFACT-Nachricht, keine XRechnung und kein sauberer ERP-Datenfluss.

Für PDF to EDIFACT, PDF to XRechnung oder PDF to EDI braucht es mehr: wiederkehrende Layouterkennung, fachliche Feldzuordnung, Validierung, Mapping und einen strukturierten Handoff.

PEDIF setzt genau dort an. Der Partner darf PDF bleiben. Ihr System bekommt strukturierte Daten.

FAQ

Kann OCR eine PDF-Rechnung direkt in EDIFACT umwandeln?

OCR kann Text aus einer PDF-Rechnung erkennen. Für EDIFACT braucht es zusätzlich Mapping, Feldlogik, Segmentzuordnung, Empfängeranforderungen und Validierung. OCR kann also ein Baustein sein, ist allein aber nicht der vollständige PDF-to-EDIFACT-Prozess.

Ist ein PDF seit 2025 noch eine E-Rechnung?

Nach BMF liegt seit dem 1. Januar 2025 eine E-Rechnung grundsätzlich nur vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und elektronische Verarbeitung ermöglicht. Ein einfaches PDF fällt nicht mehr darunter und gilt als sonstige Rechnung. Übergangsregelungen und konkrete Fälle sind zu prüfen.

Was braucht ein PDF-to-XRechnung-Workflow?

Ein PDF-to-XRechnung-Workflow braucht die vollständigen relevanten Rechnungsdaten, eine korrekte semantische Zuordnung, technische Syntax, Geschäftsregeln und Validierung. XRechnung-Konformität ist nicht nur eine Frage der Texterkennung, sondern der strukturierten XML-Abbildung.

Ersetzt PEDIF klassisches EDI?

Nein. PEDIF ergänzt EDI. Klassisches EDI bleibt sinnvoll, wenn Partner strukturierte Nachrichten senden können. PEDIF hilft bei Partnern und Dokumentenflüssen, die weiterhin PDF-basiert oder Nicht-EDI-basiert sind.

Ist No-Touch bei jedem PDF möglich?

Nein. No-Touch ist scopeabhängig. Es braucht bekannte oder aktivierbare Layouts, definierte Regeln, Zielstrukturen, Validierung und Ausnahmeprozesse. Neue oder abweichende Layouts müssen geprüft werden.

Warum ist der Excel-Screenshot ein gutes Bild für PDF-Prozesse?

Weil er zeigt, dass Sichtbarkeit nicht dasselbe ist wie Struktur. Ein Screenshot kann Zahlen zeigen, aber keine Zelllogik, Formeln oder maschinenlesbare Tabellenstruktur liefern. Genauso kann ein PDF lesbar sein und trotzdem für ERP, EDI oder XRechnung nicht direkt ausreichen.