Rechnungsverarbeitung automatisieren: Software-Auswahl

Rechnungsverarbeitung automatisieren: Welche Software passt für den Mittelstand?

Kurzüberblick

Manuelle Rechnungsverarbeitung ist ein bisschen wie ein Paketzentrum, das keine Barcodes nutzt.

Die Pakete kommen an. Auf jedem Paket klebt ein Adresslabel. Für Menschen ist die Adresse lesbar. Aber das Sortiersystem kann damit wenig anfangen, wenn es nur ein Foto des Labels sieht. Irgendjemand muss hinsehen, abschreiben, prüfen und entscheiden, wohin das Paket gehört.

So ähnlich funktioniert in vielen Unternehmen noch immer der Rechnungseingang.

Lieferanten schicken PDF-Rechnungen per E-Mail. Manche Rechnungen kommen über Portale. Einige liegen als Scan vor. Andere kommen bereits als XRechnung oder ZUGFeRD. In der Kreditorenbuchhaltung werden Beträge, Lieferantendaten, Bestellnummern, Steuern, Fälligkeiten und Positionen geprüft, ins ERP übertragen, zur Freigabe weitergeleitet oder mit Bestellungen abgeglichen.

Das Ziel ist klar: weniger manuelle Erfassung, weniger Rückfragen, weniger Fehler, kürzere Durchlaufzeiten.

Die schwierigere Frage lautet: Welche Software braucht man dafür wirklich?

Denn „Rechnungsverarbeitung automatisieren“ kann sehr Unterschiedliches bedeuten: OCR, IDP, AP-Workflow, ERP-Modul, E-Rechnungsvalidator, EDI, Archiv, DMS, API-Integration oder PDF-to-Structured-Data-Automation. Für mittelständische Unternehmen im DACH-Raum ist die beste Antwort meist nicht ein einzelnes Tool, sondern ein sauberer Prozess, der verschiedene Rechnungstypen zuverlässig verarbeitet.

Warum die Software-Auswahl jetzt schwieriger wird

Früher war die Eingangsrechnung in vielen Unternehmen vor allem ein PDF-Problem.

Eine Rechnung kam per E-Mail. Ein Mensch öffnete sie, las sie, prüfte sie und übertrug die relevanten Daten ins ERP- oder Buchhaltungssystem. Automatisierung bedeutete dann häufig: OCR einführen, Belege erkennen lassen, einen Freigabeworkflow starten.

Heute reicht diese Sicht nicht mehr aus.

Der Rechnungseingang wird gemischter. Neben klassischen PDFs kommen strukturierte E-Rechnungen hinzu. In Deutschland liegt seit dem 1. Januar 2025 eine E-Rechnung im relevanten B2B-Kontext nur dann vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht. Einfache PDF-Dateien fallen nach der BMF-Darstellung nicht mehr unter diese Definition, sondern gelten als „sonstige Rechnung“.

Das bedeutet: Unternehmen müssen nicht nur PDFs besser lesen. Sie müssen unterschiedliche Formate, Kanäle und Prozessschritte zusammenführen.

Ein modernes Setup für die Eingangsrechnungsverarbeitung muss daher drei Fragen beantworten:

1. Können wir die Rechnung empfangen?
2. Können wir sie fachlich und technisch prüfen?
3. Können wir die Daten zuverlässig in ERP, AP-Workflow, Archiv und Freigabeprozess weitergeben?

Der Engpass verschiebt sich. Es geht nicht mehr nur um „Kann jemand das Dokument öffnen?“, sondern um „Kann unser Prozess die Daten ohne unnötige manuelle Arbeit nutzen?“

E-Rechnung empfangen heißt nicht automatisch E-Rechnung verarbeiten

Ein häufiger Denkfehler lautet: „Wenn wir XRechnung oder ZUGFeRD empfangen können, ist die Rechnungsverarbeitung automatisiert.“

Das ist zu kurz gedacht.

Für den Empfang einer E-Rechnung kann bereits ein E-Mail-Postfach ausreichen. Gleichzeitig folgt daraus nicht, dass die Rechnung automatisch validiert, interpretiert, kontiert, freigegeben, abgeglichen und gebucht wird.

Für die Praxis ist genau diese Lücke entscheidend.

Ein Unternehmen kann formal empfangsfähig sein und trotzdem operativ weiter manuell arbeiten. Zum Beispiel, wenn:

• XML-Rechnungen nicht verständlich visualisiert werden,
• Validierungen fehlen,
• Pflichtfelder nicht gegen interne Regeln geprüft werden,
• Bestellnummern nicht sauber erkannt oder zugeordnet werden,
• das ERP-System strukturierte Daten nicht ohne Mapping übernimmt,
• Freigabe- und Prüfprozesse weiterhin getrennt laufen,
• PDF-Rechnungen aus dem Long Tail der Lieferanten weiter manuell erfasst werden.

Mit anderen Worten: Empfang ist die Eingangstür. Automatisierung ist der Weg bis zur nutzbaren Buchungs- und Prozessinformation.

Was sich ab 2027/2028 im Rechnungseingang verändert

Für deutsche B2B-Umsätze gelten Übergangsregelungen. Rechnungsaussteller können im Zeitraum vom 1. Januar 2025 bis 31. Dezember 2026 weiterhin sonstige Rechnungen ausstellen. Bei einem Vorjahresumsatz bis 800.000 Euro verlängert sich diese Frist bis Ende 2027. Nach Ablauf der Übergangsfristen wird die Verwendung einer E-Rechnung bei Umsätzen zwischen inländischen Unternehmen tatsächlich verpflichtend.

Für mittelständische Rechnungsempfänger heißt das: Ab 2028 ist in vielen deutschen B2B-Rechnungsflüssen mit deutlich mehr strukturierten E-Rechnungen zu rechnen. XRechnung und ZUGFeRD werden dabei besonders relevant, weil diese Formate in Deutschland als übliche Formate gelten, sofern die jeweiligen Anforderungen erfüllt sind.

Aber daraus folgt nicht, dass PDFs sofort verschwinden.

In DACH-Realitäten bleiben oft Mischformen bestehen: internationale Lieferanten, Sonderfälle, Portale, Anhänge, ergänzende Dokumente, Bestandsprozesse, Kleinlieferanten, Branchenbesonderheiten und historische ERP-Setups. Gerade deshalb braucht der Mittelstand keine isolierte „E-Rechnungs-Checkliste“, sondern eine robuste Architektur für den gesamten Rechnungseingang.

Die wichtigsten Softwareklassen für die Eingangsrechnungsverarbeitung

Wer Rechnungsverarbeitung automatisieren will, sollte zuerst die Softwareklassen unterscheiden. Viele Anbieter überschneiden sich. Trotzdem hilft die Einteilung, um Anforderungen sauber zu formulieren.

1. ERP-native Rechnungsverarbeitung

Viele ERP-Systeme bieten Funktionen für Rechnungsprüfung, Buchungsvorschläge, Freigaben oder Bestellabgleich. Das ist sinnvoll, weil das ERP ohnehin Stammdaten, Bestellungen, Wareneingänge und Buchungslogik enthält.

ERP-native Funktionen sind besonders stark, wenn:

• Lieferantenstammdaten sauber gepflegt sind,
• Bestellungen und Wareneingänge strukturiert vorliegen,
• Rechnungen bereits als verwertbare Daten ankommen,
• die Organisation im ERP-Prozess arbeiten will.

Die Grenze liegt oft beim Eingang selbst. Ein ERP ist nicht automatisch gut darin, uneinheitliche PDFs, Portaldokumente, Scans oder lieferantenspezifische Layouts zu strukturieren.

2. AP-Workflow-Software

Accounts-Payable- oder Kreditorenworkflow-Systeme konzentrieren sich auf Prüfung, Freigabe, Eskalation, Kontierung und Prozesssteuerung.

Sie helfen, wenn Rechnungen intern durch mehrere Hände gehen: Einkauf, Fachabteilung, Kostenstellenverantwortliche, Finance, Management. Der Vorteil liegt in Transparenz und Steuerung.

Aber auch hier gilt: Ein Workflow ist nur so gut wie die Daten, die hineinfließen. Wenn Rechnungskopf, Positionen, Steuerinformationen und Bestellbezug vorher manuell korrigiert werden müssen, bleibt ein wichtiger Teil des Problems bestehen.

3. E-Rechnungsvalidator und Viewer

Für XRechnung, ZUGFeRD und andere strukturierte E-Rechnungsformate braucht man häufig technische Validierung, Visualisierung und Formatverständnis.

Validatoren und Viewer beantworten aber meist nicht die ganze Prozessfrage.

Sie sagen zum Beispiel: „Ist die Datei formal plausibel?“
Sie sagen nicht automatisch: „Passt diese Rechnung zur Bestellung, zum Wareneingang, zum Lieferantenstamm, zur Kontierung und zum Freigabeprozess?“

4. OCR und IDP

OCR erkennt Zeichen. Intelligent Document Processing, kurz IDP, geht weiter und versucht, Felder, Tabellen, Positionen und Zusammenhänge zu extrahieren.

Das ist nützlich, vor allem bei unbekannten, variablen oder schlecht strukturierten Dokumenten. OCR/IDP kann helfen, manuelle Erfassung zu reduzieren und Belege für Review-Strecken vorzubereiten.

Die Grenze: Viele OCR-/IDP-Ansätze arbeiten probabilistisch. Sie liefern Wahrscheinlichkeiten, Confidence Scores und Prüfstrecken. Das ist nicht schlecht. Aber für wiederkehrende Lieferantenrechnungen mit stabilen Layouts kann ein reiner „Wir lesen jedes Dokument neu“-Ansatz unnötig viel Unsicherheit und Nacharbeit erzeugen.

OCR liest Zeichen. PEDIF erkennt wiederkehrende Geschäftsdokumente.

5. EDI

EDI bleibt stark, wenn große Lieferanten oder Partner mit stabilen, hohen Volumina strukturiert angebunden sind. Für planbare, wiederkehrende Beziehungen ist EDI oft der sauberste Weg.

Aber EDI erreicht nicht automatisch jeden Lieferanten. Gerade mittelständische Unternehmen haben häufig einen langen Lieferanten-Tail: viele kleinere oder mittlere Partner, die weiterhin PDFs, E-Mails oder Portalrechnungen senden.

PEDIF ersetzt EDI nicht. PEDIF schließt die Lücke dort, wo EDI nicht ankommt.

6. PDF-to-Structured-Data-Automation mit PEDIF

PEDIF setzt dort an, wo eingehende Rechnungen zwar als PDF oder layoutgetriebenes Dokument ankommen, das empfangende Unternehmen aber strukturierte, validierte Daten benötigt.

Der Partner muss seinen Prozess nicht sofort ändern. Er darf PDF bleiben. Ihr System bekommt strukturierte Daten.

Für wiederkehrende, freigegebene Rechnungslayouts kann PEDIF die relevanten Daten aus PDF-Geschäftsdokumenten extrahieren und in strukturierte Formate für ERP, EDI, XML, CSV oder APIs überführen. Der Artikel bleibt bewusst auf Eingangsrechnungen fokussiert. PEDIF ist jedoch nicht grundsätzlich auf Rechnungen beschränkt und kann auch bei anderen Supply-Chain-Dokumenten relevant sein.

Die bessere Zielarchitektur: kein Tool-Silo, sondern hybrider Prozess

Für viele mittelständische Unternehmen ist die beste Architektur hybrid:

• EDI für stabile High-Volume-Partner.
• XRechnung/ZUGFeRD-Verarbeitung für strukturierte E-Rechnungen.
• Einheitliche PDF-/Kontrollansichten für menschliche Prüfprozesse, wenn strukturierte Formate zwar maschinenlesbar sind, aber im Tagesgeschäft visuell geprüft werden müssen.
• PEDIF für wiederkehrende PDF- oder layoutgetriebene Eingangsrechnungen.
• OCR/IDP oder Human-in-the-Loop für unbekannte, variable oder Ausnahmefälle.
• ERP/AP-Workflow für Prüfung, Freigabe, Buchung und Prozesssteuerung.

So entsteht kein weiteres Tool-Silo. Stattdessen wird der Rechnungseingang als Datenfluss verstanden.

PDF bleibt der Eingang. Strukturierte Daten sind das Ergebnis.

Wo PEDIF in der Eingangsrechnungsverarbeitung ansetzt

PEDIF ist nicht das Archiv.
PEDIF ist nicht das ERP.
PEDIF ist nicht der Steuerberater.
PEDIF ist auch nicht einfach OCR mit hübscher Oberfläche.

PEDIF ist eine Dokumentenintelligenz- und Strukturierungsschicht für wiederkehrende Geschäftsdokumente. Bei Eingangsrechnungen bedeutet das: PEDIF erkennt freigegebene Layouts, extrahiert die relevanten Rechnungsdaten, prüft sie im definierten Scope und übergibt strukturierte Informationen an Zielsysteme wie ERP, AP-Workflow, EDI/XML, CSV oder API. Der genaue Umfang hängt vom aktivierten Layout, Dokumenttyp, Zielsystem und Prozessdesign ab.

No-Touch bedeutet dabei nicht No-Control.

No-Touch bedeutet: In einem definierten, freigegebenen Scope sollen nur Ausnahmen Aufmerksamkeit benötigen. Unbekannte Layouts, unklare Daten, fehlende Pflichtinformationen oder fachliche Sonderfälle gehören in eine Validierungs- oder Ausnahmebehandlung.

Genau das ist für Finance-Teams wichtig. Automatisierung darf nicht heißen, dass alles ungeprüft durchläuft. Sie soll dafür sorgen, dass Menschen ihre Zeit auf die Fälle verwenden, die wirklich Entscheidung brauchen.

Einheitliche Kontrollansicht: Warum ein generisches PEDIF-Layout helfen kann

Dieser Punkt gilt nicht nur für Eingangsrechnungen, sondern grundsätzlich für alle eingehenden Dokumententypen, die im Unternehmen noch visuell geprüft, freigegeben oder weiterbearbeitet werden: Bestellungen, Auftragsbestätigungen, Lieferscheine, Rechnungen oder andere Supply-Chain-Dokumente.

Ein PDF hat fast immer das individuelle Layout des Senders. Auch bei ZUGFeRD bleibt der PDF-Teil typischerweise in der Gestaltung des Rechnungsausstellers. Für Menschen ist das zwar lesbar, aber im Tagesgeschäft nicht immer angenehm: Rechnungsnummer, Bestellbezug, Beträge, Steuern, Positionen oder Lieferantendaten stehen je nach Sender an anderer Stelle.

PEDIF kann hier zusätzlich zur strukturierten Datenübergabe ein generisches, einheitliches Layout für menschliche Kontrollvorgänge bereitstellen. Die Logik ist einfach: gleiche Informationen stehen immer an der gleichen Stelle. Das hilft bei manuellen Prüfungen, Freigaben, Rückfragen und Ausnahmen, weil die Mitarbeitenden nicht jedes Lieferantenlayout neu „lesen lernen“ müssen.

Gerade in hybriden Rechnungseingängen ist das wertvoll:

• Bei klassischen PDF-Rechnungen wird aus dem individuellen Senderlayout eine strukturierte Datenbasis und optional eine einheitliche Kontrollansicht.
• Bei ZUGFeRD liegt neben dem PDF eine XML-Struktur vor. Seit Einführung der verpflichtenden E-Rechnung ist bei hybriden E-Rechnungen der strukturierte Teil führend, wenn strukturierter Teil und Bildteil voneinander abweichen. Eine PEDIF-Kontrollansicht sollte deshalb als Visualisierung des strukturierten Teils verstanden werden.[^bmf-faq]
• Bei XRechnungen gibt es keine mitgelieferte PDF-Ansicht. Für menschliche Prüfprozesse kann PEDIF aus dem XML ein zusätzliches PDF in einem einheitlichen, vertrauten Layout erzeugen.[^bmf-faq]

Wichtig ist die klare Einordnung: Das generierte PDF ist eine Arbeits-, Kontroll- oder Visualisierungsansicht. Es ersetzt nicht die originäre E-Rechnung und nicht die Aufbewahrung des strukturierten Originalteils. Für XRechnung plus Kontroll-PDF ist die vorsichtige Standardlogik: XML unverändert übergeben und aufbewahren, das PEDIF-PDF separat, aber eindeutig verknüpft bereitstellen. Eine nachträgliche Kopplung in einem PDF/A-3-Container oder einer ZUGFeRD-ähnlichen Datei sollte nur nach gesonderter technischer und rechtlicher Prüfung als Produktoption formuliert werden.

Für den Artikel wird dieser Punkt deshalb als Prozess- und Usability-Vorteil formuliert, nicht als Rechts- oder Compliance-Garantie.

Beispiel: Eingangsrechnung im Maschinenbau

Ein mittelständischer Maschinenbauer erhält jeden Monat viele Lieferantenrechnungen für Material, Komponenten, Ersatzteile und Dienstleistungen.

Ein Teil der großen Lieferanten ist per EDI angebunden. Einige Lieferanten senden ZUGFeRD oder XRechnung. Viele kleinere Lieferanten schicken weiterhin PDF-Rechnungen per E-Mail. Zusätzlich gibt es Rechnungen aus Portalen, die jemand regelmäßig herunterlädt.

Vor der Automatisierung sieht der Prozess so aus:

Eine Mitarbeiterin öffnet die Rechnung. Sie prüft Lieferant, Betrag, Steuer, Bestellnummer und Positionen. Dann sucht sie die Bestellung im ERP, prüft Wareneingang oder Leistungsnachweis, ergänzt Kontierung, startet Freigabe oder fragt beim Einkauf nach. Bei wiederkehrenden Lieferanten ist die Arbeit nicht schwierig, aber repetitiv. Genau das macht sie fehleranfällig.

Nach einer sinnvollen Automatisierung sieht der Prozess anders aus:

EDI-Daten laufen direkt in den strukturierten Prozess. XRechnung und ZUGFeRD werden technisch lesbar gemacht, validiert und in den AP-Prozess übergeben. Für menschliche Kontrollen kann zusätzlich eine einheitliche PEDIF-Ansicht genutzt werden, ohne dass der strukturierte Originalteil ersetzt wird. Wiederkehrende PDF-Rechnungen werden durch PEDIF in strukturierte Rechnungsdaten überführt. Unbekannte oder unklare Fälle gehen in eine Ausnahmeprüfung.

Das Ergebnis ist kein magisches „Alles bucht sich selbst“. Das Ergebnis ist besser: ein kontrollierter Rechnungseingang, bei dem manuelle Arbeit nicht mehr der Standardweg ist, sondern der Ausnahmeweg.

Software-Auswahl: Die wichtigsten Kriterien

Die richtige Rechnungsverarbeitungssoftware erkennt man nicht an der längsten Feature-Liste. Man erkennt sie daran, ob sie zur eigenen Realität passt.

1. Welche Eingangskanäle gibt es wirklich?

Zählen Sie nicht nur ideale Formate. Zählen Sie die Realität:

• PDF per E-Mail
• PDF aus Portalen
• Scans
• XRechnung
• ZUGFeRD
• EDI
• Anhänge
• Sonderformate
• internationale Lieferantenkommunikation

Viele Projekte scheitern daran, dass nur das Soll-Bild betrachtet wird. Der Rechnungseingang ist aber selten sauber sortiert.

2. Wie wiederkehrend sind Ihre Lieferantenlayouts?

Wenn viele Rechnungen von denselben Lieferanten in ähnlichen Layouts kommen, ist das ein starkes Signal für PEDIF.

Wiederkehrende Layouts müssen nicht jedes Mal „neu erraten“ werden. Sie können aktiviert, geprüft und kontrolliert verarbeitet werden. Genau hier unterscheidet sich ein layout- und fingerprintbasierter Ansatz von allgemeiner OCR.

3. Welche Rolle spielt Ihr ERP?

Das ERP bleibt meist das System der Wahrheit für Buchung, Stammdaten, Bestellungen, Wareneingänge und Finanzprozesse.

Die Frage lautet daher nicht: „Ersetzen wir das ERP?“
Die Frage lautet: „Wie bekommt das ERP bessere Eingangsdaten?“

Eine gute Lösung respektiert bestehende Systeme und ergänzt sie dort, wo Dokumente noch nicht strukturiert genug sind.

4. Müssen Positionen verarbeitet werden?

Viele einfache Lösungen können Kopfdaten auslesen: Lieferant, Rechnungsnummer, Datum, Betrag.

In der Praxis reichen Kopfdaten oft nicht. Bei bestellbezogenen Rechnungen sind Positionen, Mengen, Artikelnummern, Steuerlogik, Bezug zur Bestellung und Abweichungen entscheidend.

Wer Positionen braucht, sollte das früh klären.

5. Wo braucht der Prozess Validierung?

Validierung ist mehr als technische Formatprüfung.

Sie kann auf mehreren Ebenen stattfinden:

• Ist das Format technisch lesbar?
• Sind Pflichtfelder vorhanden?
• Stimmen Beträge und Steuern logisch zusammen?
• Gibt es einen Lieferanten im ERP?
• Gibt es eine passende Bestellung?
• Stimmen Mengen oder Preise?
• Ist eine Freigabe nötig?
• Gibt es Dublettenrisiken?

Nicht jede Software deckt jede Ebene ab. Deshalb sollte Validierung in der Anforderungsliste genau beschrieben werden.

6. Was passiert mit Ausnahmen?

Ausnahmen sind kein Scheitern der Automatisierung. Sie sind Teil eines seriösen Prozesses.

Wichtige Fragen:

• Wie werden unbekannte Layouts behandelt?
• Wer prüft unsichere Ergebnisse?
• Gibt es eine Human-in-the-Loop-Strecke?
• Wird aus Korrekturen gelernt?
• Sind Prüfprotokolle nachvollziehbar?
• Können Fachabteilungen eingebunden werden?

Eine gute Lösung macht Ausnahmen sichtbar, statt sie im Postfach verschwinden zu lassen.

Typische Missverständnisse bei der Rechnungsautomatisierung

„Wir brauchen nur OCR.“

OCR kann hilfreich sein, aber OCR ist nicht gleich Prozessautomatisierung. Zeichen zu erkennen ist nur der Anfang. Entscheidend ist, ob aus dem Dokument verlässliche, strukturierte und prozessfähige Daten entstehen.

„E-Rechnung löst alles.“

E-Rechnung ist ein wichtiger Schritt. Aber eine strukturierte Datei muss trotzdem geprüft, visualisiert, validiert, gemappt, archiviert und in den ERP-/AP-Prozess integriert werden. Empfangsfähigkeit ist nicht dasselbe wie End-to-End-Automatisierung.

„Unser ERP kann das schon.“

Vielleicht. Viele ERP-Systeme können viel. Aber prüfen Sie konkret, wie gut Ihr ERP mit PDF-Rechnungen, Portaldokumenten, XRechnung, ZUGFeRD, Anhängen, Positionen und Sonderfällen umgeht. Häufig braucht das ERP keine Ablösung, sondern bessere Eingangsdaten.

„Wir müssen alle Lieferanten auf EDI zwingen.“

EDI ist stark, aber nicht immer realistisch für den gesamten Lieferantenstamm. Für große, stabile Partner kann EDI der beste Weg sein. Für den PDF-Long-Tail braucht es andere Ansätze.

„No-Touch heißt, dass niemand mehr kontrolliert.“

No-Touch bedeutet nicht No-Control. Es bedeutet: Nur Ausnahmen brauchen Aufmerksamkeit. Gerade in der Rechnungsverarbeitung ist kontrollierte Automatisierung besser als blinde Automatisierung.

Eingangsrechnung ist nicht Ausgangsrechnung

Dieser Artikel konzentriert sich bewusst auf eingehende Lieferantenrechnungen.

Für ausgehende, eigene Rechnungen ist die Fragestellung anders: Dort geht es stärker um das Erzeugen, Validieren und Versenden strukturierter E-Rechnungen, etwa als XRechnung oder ZUGFeRD. Dieses Thema gehört in den separaten Cluster-2-Artikel „E-Invoicing, XRechnung and ZUGFeRD from PDF“.

Der Unterschied ist wichtig:

Bei der Ausgangsrechnung kontrollieren Sie die Quelle.
Bei der Eingangsrechnung kontrollieren Sie die Vielfalt der Lieferanten nur begrenzt.

Deshalb braucht der Rechnungseingang besonders viel Format- und Prozessrobustheit.

Entscheidungscheckliste: Welche Lösung passt?

Fazit: Die beste Rechnungssoftware passt zum Eingang, nicht zur Demo

Automatisierte Rechnungsverarbeitung beginnt nicht mit einer Produktdemo. Sie beginnt mit einer ehrlichen Analyse des Rechnungseingangs.

Welche Formate kommen wirklich an?
Welche Lieferanten wiederholen sich?
Welche Daten braucht das ERP?
Welche Prüfungen sind Pflicht?
Welche Ausnahmen bleiben menschliche Aufgabe?

Für mittelständische DACH-Unternehmen wird diese Analyse wichtiger, weil der Rechnungseingang nicht einfach von PDF auf XRechnung umschaltet. Er wird hybrider. PDFs bleiben praktisch relevant. XRechnung und ZUGFeRD gewinnen an Bedeutung. ERP, AP-Workflow, Archiv und Validierung müssen zusammenspielen.

PEDIF passt dort, wo wiederkehrende PDF- oder layoutgetriebene Eingangsrechnungen in strukturierte, validierte Daten für nachgelagerte Systeme überführt werden sollen, ohne jeden Lieferanten sofort auf EDI oder ein neues Portal zu zwingen.

Der Partner darf PDF bleiben. Ihr System bekommt strukturierte Daten.

Wie automatisierbar ist Ihr Rechnungseingang wirklich?

Lassen Sie Ihre Eingangsrechnungen, Formate, Lieferantenlayouts und Zielsysteme prüfen. Im PEDIF Invoice Processing Assessment identifizieren wir, welche Rechnungsflüsse für ERP-native Verarbeitung, E-Rechnung, EDI, OCR/IDP oder PEDIF geeignet sind.Rechnungsfluss sprechen

FAQ

Welche Software eignet sich für die automatisierte Eingangsrechnungsverarbeitung?

Das hängt von Ihrem Rechnungseingang ab. ERP-Module helfen bei Buchung und Prozesslogik, AP-Workflow-Systeme bei Freigabe und Steuerung, Validatoren bei strukturierten E-Rechnungen, OCR/IDP bei variablen Dokumenten und PEDIF bei wiederkehrenden PDF-Rechnungslayouts, die in strukturierte ERP-/AP-Daten überführt werden sollen.

Reicht XRechnung oder ZUGFeRD aus, um Rechnungen automatisch zu verarbeiten?

Nicht automatisch. XRechnung und ZUGFeRD liefern strukturierte Daten, aber diese müssen validiert, visualisiert, gemappt, geprüft und in ERP- oder AP-Prozesse integriert werden. Die operative Verarbeitung bleibt eine Prozess- und Systemfrage.

Ist eine PDF-Rechnung seit 2025 noch eine E-Rechnung?

Nach der BMF-Darstellung gilt seit dem 1. Januar 2025 eine E-Rechnung nur als solche, wenn sie in einem strukturierten elektronischen Format vorliegt und elektronische Verarbeitung ermöglicht. Ein einfaches PDF ist in diesem Kontext keine E-Rechnung, sondern eine sonstige Rechnung.

Bedeutet die deutsche E-Rechnungspflicht, dass ab 2028 alle Eingangsrechnungen automatisch verarbeitet werden?

Nein. Nach Ablauf der Übergangsfristen wird die Verwendung einer E-Rechnung in vielen inländischen B2B-Fällen verpflichtend. Das bedeutet aber nicht, dass jedes ERP- oder AP-System diese Rechnungen automatisch validiert, interpretiert und bucht. Empfangsfähigkeit und Prozessautomatisierung sind unterschiedliche Aufgaben.

Warum kann ein einheitliches PDF-Layout trotz E-Rechnung hilfreich sein?

Weil Menschen weiterhin prüfen, freigeben, klären und Ausnahmen bearbeiten. Individuelle Lieferantenlayouts erschweren diese Arbeit, weil gleiche Informationen je nach Sender an unterschiedlichen Stellen stehen. Ein generisches PEDIF-Kontrolllayout kann dafür sorgen, dass wichtige Informationen immer gleich angeordnet sind. Das gilt nicht nur für Rechnungen, sondern grundsätzlich für alle eingehenden Dokumententypen, bei denen menschliche Kontrollschritte relevant bleiben.

Kann PEDIF zu XRechnung oder ZUGFeRD ein PDF für Kontrollzwecke erzeugen?

Ja, als Kontroll- oder Visualisierungsansicht. Bei XRechnung kann PEDIF aus dem XML ein zusätzliches PDF erzeugen, weil XRechnung selbst keine PDF-Ansicht enthält. Bei ZUGFeRD kann ein einheitliches PEDIF-Kontroll-PDF den individuellen PDF-Teil des Senders für interne Prüfprozesse ergänzen. Wichtig ist: Das generierte PDF ersetzt nicht die originäre E-Rechnung. Der strukturierte Originalteil bleibt maßgeblich und muss unverändert erhalten bleiben.

Was ist der Unterschied zwischen OCR und PEDIF?

OCR erkennt Zeichen auf einem Dokument. PEDIF geht bei wiederkehrenden, freigegebenen Geschäftsdokumenten weiter: Es erkennt Layouts, ordnet Informationen fachlich zu und überführt sie in strukturierte Daten für Zielsysteme wie ERP, EDI, XML, CSV oder API. Der genaue Automatisierungsgrad hängt vom freigegebenen Scope ab.

Ersetzt PEDIF mein ERP oder DMS?

Nein. PEDIF ersetzt ERP, DMS, Archiv, Steuerprüfung oder Freigabeprozesse nicht. PEDIF liefert strukturierte Daten in diese Systeme und Prozesse. Dadurch können bestehende Systeme besser mit PDF- oder layoutgetriebenen Eingangsrechnungen arbeiten.

Kann PEDIF jede Eingangsrechnung automatisch verarbeiten?

Nein, nicht pauschal. PEDIF eignet sich besonders für wiederkehrende, aktivierte und freigegebene Layouts in einem definierten Scope. Unbekannte, stark variable oder unklare Dokumente benötigen Aktivierung, Validierung oder Ausnahmebehandlung. Dafür kann ein Human-in-the-Loop-Prozess eingesetzt werden, in dem Fachanwender unklare Fälle prüfen, korrigieren oder freigeben. Je nach Prozessdesign können dabei auch Abgleiche mit Stammdaten, Lieferanteninformationen oder anderen Referenzdaten einbezogen werden. 100-Prozent-Aussagen dürfen nicht allgemein verwendet werden.