Der Purchase-to-Pay-Prozess, häufig als P2P bezeichnet und vielfach synonym mit Procure-to-Pay verwendet, gehört zu den zentralen End-to-End-Prozessen im Einkauf und Finanzwesen. Er verbindet die Bedarfsmeldung eines Fachbereichs mit Beschaffung, Bestellung, Wareneingang oder Leistungserfassung, Rechnungsprüfung und der abschließenden Zahlung an den Lieferanten.
Was zunächst wie eine einfache Prozesskette klingt, umfasst in der Praxis zahlreiche Beteiligte, Systeme, Freigaben und Ausnahmen. Bedarfsmeldungen entstehen im Fachbereich, Einkaufsorganisationen prüfen Konditionen, Lager oder Fachabteilungen bestätigen Waren und Leistungen, die Kreditorenbuchhaltung verarbeitet Rechnungen und Finance führt schließlich die Zahlung aus. Genau an diesen Übergängen entstehen häufig Medienbrüche, lange Durchlaufzeiten, fehlende Transparenz und unnötige manuelle Nacharbeit.
Ein durchgängiger Purchase to Pay Prozess verfolgt deshalb ein klares Ziel: Beschaffungs- und Zahlungsprozesse sollen nicht als voneinander getrennte Einzelschritte betrachtet werden, sondern als ein integrierter Daten- und Prozessfluss. SAP beschreibt Procure-to-Pay entsprechend als Verbindung von Einkaufs- und Kreditorenbuchhaltungssystemen und gliedert den Prozess in Auswahl von Waren und Dienstleistungen, regelkonforme Bestellung, Wareneingang und Abstimmung sowie Rechnungsstellung und Zahlung.
Für SAP-Unternehmen wird diese End-to-End-Sicht besonders wichtig. SAP S/4HANA bildet zentrale operative Schritte wie Bestellanforderung, Bestellung, Wareneingang, Lieferantenrechnung und Zahlung ab. Ergänzend können SAP Ariba, SAP Business Network, SAP Document and Reporting Compliance, SAP Signavio, OpenText Vendor Invoice Management und weitere Lösungen bestimmte Teilprozesse digitalisieren, zentralisieren oder stärker automatisieren.
In diesem Artikel erfahren Sie, welche Purchase-to-Pay-Prozess Schritte dazugehören, wie ein Purchase-to-Pay-Prozess SAP-seitig funktioniert, was ein Drei-Wege-Abgleich bedeutet, welche Rolle die E-Rechnung spielt und wie Unternehmen ihren Purchase to Pay Prozess automatisieren, digitalisieren und nachhaltig optimieren können.
Das Wichtigste zum Purchase-to-Pay-Prozess in Kürze
Der Purchase-to-Pay-Prozess beschreibt den Weg von einem identifizierten Beschaffungsbedarf bis zur Zahlung der Lieferantenrechnung. SAP, Descartes, Mindlogistik und weitere Anbieter verwenden Purchase-to-Pay beziehungsweise Procure-to-Pay weitgehend für denselben End-to-End-Zusammenhang.
Besonders wichtig sind dabei folgende Punkte:
- Ein durchgängiger P2P-Prozess verbindet Fachbereiche, Einkauf, Logistik beziehungsweise Leistungsempfänger und Kreditorenbuchhaltung.
- Eine Bestellung allein ist noch kein vollständiger Purchase-to-Pay-Prozess. Entscheidend ist die Verbindung bis zur Rechnungsprüfung und Zahlung.
- SAP S/4HANA unterstützt Bestellanforderungen, Bestellungen, Wareneingänge, Lieferantenrechnungen und Finanzprozesse innerhalb einer integrierten Belegkette.
- Beim klassischen Drei-Wege-Abgleich werden Bestellung, Wareneingang und Rechnung miteinander verglichen.
- Strukturierte E-Rechnungen können den Rechnungseingang zusätzlich automatisieren, da relevante Daten bereits maschinenlesbar vorliegen.
- Purchase to Pay Prozess Software kann Beschaffung, Freigaben, Rechnungsprüfung, Lieferantenkollaboration und Prozessanalyse unterstützen.
- SAP Signavio Process Intelligence kann unter anderem Durchlaufzeiten, manuelle Eingriffe und Automatisierungspotenziale im Procure-to-Pay-Prozess sichtbar machen.
- Ein automatisierter Purchase-to-Pay-Prozess setzt saubere Stammdaten, klar definierte Verantwortlichkeiten und standardisierte Ausnahmeprozesse voraus.
Inhaltsverzeichnis
- Purchase-to-Pay-Prozess Definition: Was bedeutet P2P?
- Purchase-to-Pay und Procure-to-Pay: Gibt es einen Unterschied?
- Purchase-to-Pay, Source-to-Pay und Order-to-Cash im Vergleich
- Warum ist der Purchase-to-Pay-Prozess so wichtig?
- Purchase-to-Pay-Prozess Schritte: Welche Phasen umfasst P2P?
- Purchase-to-Pay-Prozess SAP: Wie funktioniert P2P in SAP S/4HANA?
- Purchase-to-Pay-Prozess Beispiel: Vom Laptop-Bedarf bis zur Zahlung
- Wie funktioniert der Drei-Wege-Abgleich im P2P-Prozess?
- Welche Rolle spielt die E-Rechnung im Purchase-to-Pay-Prozess?
- Wie lässt sich der gesamte Purchase-to-Pay-Prozess digitalisieren?
- Purchase to Pay Prozess automatisieren: Wo liegen die größten Potenziale?
- Purchase to Pay Prozess Software: Welche Lösungen werden benötigt?
- Software Engpässe im Purchase-to-Pay-Prozess finden: Wie funktioniert das?
- Wie können KI und Automatisierung den Purchase-to-Pay-Prozess verbessern?
- Welche Vorteile bietet ein automatisierter Purchase-to-Pay-Prozess?
- Welche Herausforderungen und Fehlerquellen gibt es im Purchase-to-Pay-Prozess?
- Welche KPIs eignen sich für den Purchase-to-Pay-Prozess?
- Purchase-to-Pay-Prozess optimieren: Wo sollten Unternehmen beginnen?
- Best Practices für den Purchase-to-Pay-Prozess
- Do's & Don'ts beim Purchase-to-Pay-Prozess
- Schritt für Schritt den Purchase-to-Pay-Prozess digitalisieren und automatisieren
- Fazit – Warum der Purchase-to-Pay-Prozess End-to-End gedacht werden muss
- Häufig gestellte Fragen zum Purchase-to-Pay-Prozess
Purchase-to-Pay-Prozess Definition: Was bedeutet P2P?
Die Purchase-to-Pay-Prozess Definition lässt sich folgendermaßen zusammenfassen:
Purchase-to-Pay bezeichnet den End-to-End-Geschäftsprozess vom entstehenden Beschaffungsbedarf über Bestellung, Lieferung beziehungsweise Leistungserbringung und Rechnungsprüfung bis zur Zahlung des Lieferanten.
SAP beschreibt Procure-to-Pay als Integration von Purchasing und Accounts Payable. Descartes spricht ebenfalls von einem durchgängigen Prozess von der Bedarfsermittlung bis zur endgültigen Zahlung. Mindlogistik beschreibt Purchase-to-Pay als Prozess, der beim Einkauf beginnt und mit dem Ausgleich der Lieferantenrechnung endet.
Damit ist P2P wesentlich mehr als ein Rechnungsworkflow.
Die Eingangsrechnung befindet sich relativ weit hinten im Gesamtprozess. Viele Informationen, die für ihre erfolgreiche Verarbeitung benötigt werden, entstehen bereits vorher: Lieferant, Bestellnummer, Preis, Menge, Kontierung, Zahlungsbedingungen, Wareneingang oder Leistungsbestätigung.
Je sauberer diese Informationen bereits in den vorgelagerten Beschaffungsschritten strukturiert vorliegen, desto größer ist später das Automatisierungspotenzial.
Genau deshalb sollte ein Unternehmen die Rechnungsverarbeitung nicht isoliert betrachten. Ein hoher manueller Aufwand in der Kreditorenbuchhaltung kann seine Ursache beispielsweise bereits in unvollständigen Bestellungen, fehlenden Wareneingängen oder nicht eingehaltenen Beschaffungsrichtlinien haben.
Purchase-to-Pay und Procure-to-Pay: Gibt es einen Unterschied?
In der Praxis werden Purchase-to-Pay und Procure-to-Pay sehr häufig synonym verwendet.
SAP selbst verwendet überwiegend den Begriff Procure-to-Pay, während andere Anbieter von Purchase-to-Pay sprechen. Auch Mindlogistik bezeichnet Purchase-to-Pay als P2P und weist darauf hin, dass teilweise die Bezeichnung Procure-to-Pay verwendet wird. Easy Software beschreibt beide Begriffe ebenfalls als häufig synonym verwendete Bezeichnungen.
Eine allgemeingültige fachliche Trennung gibt es deshalb nicht.
In einzelnen Unternehmensmodellen wird „Procure“ weiter gefasst als „Purchase“. Dann können beispielsweise Lieferantenauswahl oder weitere vorgelagerte Beschaffungsaktivitäten stärker einbezogen werden.
Deutlich klarer ist dagegen die Abgrenzung zu Source-to-Pay.
Source-to-Pay beginnt typischerweise früher und umfasst zusätzlich strategische Beschaffungsaktivitäten wie:
Lieferantensuche, Ausschreibungen, Verhandlungen, Sourcing, Vertragsmanagement und strategisches Lieferantenmanagement.
Der Purchase-to-Pay-Prozess konzentriert sich dagegen stärker auf den operativen Weg vom konkreten Bedarf beziehungsweise der Bestellanforderung bis zur Zahlung.
Purchase-to-Pay, Source-to-Pay und Order-to-Cash im Vergleich
| Prozess | Typischer Startpunkt | Typisches Ende | Perspektive |
|---|---|---|---|
| Source-to-Pay | Strategische Bedarfs- und Lieferantenauswahl | Zahlung | strategische + operative Beschaffung |
| Purchase-to-Pay / Procure-to-Pay | Bedarf / Bestellanforderung | Lieferantenzahlung | Einkauf + Kreditorenbuchhaltung |
| Order-to-Cash | Kundenauftrag | Kundenzahlung | Vertrieb + Debitorenbuchhaltung |
Während der Purchase-to-Pay-Prozess Geld aus dem Unternehmen in Richtung Lieferant bewegt, bildet Order-to-Cash die entgegengesetzte Wertschöpfungsrichtung ab: Das Unternehmen liefert an einen Kunden, stellt eine Rechnung und erhält anschließend die Zahlung.
Warum ist der Purchase-to-Pay-Prozess so wichtig?
P2P verbindet zwei Bereiche, die organisatorisch häufig getrennt sind: Einkauf und Finance.
Der Einkauf möchte Bedarfe wirtschaftlich decken, Lieferanten steuern und Beschaffungsrichtlinien einhalten. Die Kreditorenbuchhaltung möchte korrekte Rechnungen schnell verbuchen, Skonti nutzen, Fälligkeiten steuern und Doppelzahlungen oder Compliance-Risiken vermeiden.
Werden beide Bereiche technisch und prozessual nicht miteinander verbunden, entstehen typische Probleme:
Bedarfsmeldungen erfolgen per E-Mail, Bestellungen werden nachträglich erstellt, Wareneingänge fehlen, Rechnungen treffen ohne Bestellreferenz ein oder Freigaben bleiben liegen. Easy Software nennt lange Durchlaufzeiten, Medienbrüche, fehlende Transparenz und ineffiziente manuelle Tätigkeiten als typische Herausforderungen nicht integrierter P2P-Prozesse.
Ein integrierter Purchase-to-Pay-Prozess schafft deshalb nicht nur operative Effizienz. Er verbessert auch Ausgabentransparenz, Compliance, Working Capital und die Zusammenarbeit mit Lieferanten.
Purchase-to-Pay-Prozess Schritte: Welche Phasen umfasst P2P?
Je nach Geschäftsmodell kann ein P2P-Prozess unterschiedlich detailliert dargestellt werden. Die folgende Struktur verbindet die typischen Abläufe der Wettbewerberseiten mit einem SAP-orientierten End-to-End-Modell.
Schritt 1 – Bedarf identifizieren
Der Purchase-to-Pay-Prozess beginnt mit einem Bedarf.
Ein Fachbereich benötigt beispielsweise Rohmaterial, Büroausstattung, externe Dienstleistungen, Software oder Beratungsleistungen.
Der Bedarf sollte möglichst strukturiert beschrieben werden. Entscheidend sind unter anderem Material beziehungsweise Leistung, Menge, Termin, Kostenstelle, Projekt, Budget und gegebenenfalls bevorzugter Lieferant.
Schritt 2 – Bestellanforderung erstellen und freigeben
Aus dem Bedarf entsteht eine Bestellanforderung beziehungsweise Purchase Requisition.
SAP beschreibt eine Purchase Requisition als internen Antrag an die Einkaufsorganisation, bestimmte Materialien oder Dienstleistungen zu beschaffen. In SAP S/4HANA können entsprechende Apps Bestellanforderungen erstellen, bearbeiten und ihren Prozessstatus verfolgen.
Je nach Unternehmen folgen Budgetprüfungen, Genehmigungen und fachliche Freigaben.
Schritt 3 – Lieferant und Bezugsquelle bestimmen
Wenn nicht bereits ein Lieferant über Katalog, Rahmenvertrag oder Source List vorgegeben ist, muss eine geeignete Bezugsquelle bestimmt werden.
In umfassenderen Source-to-Pay-Szenarien können an dieser Stelle Ausschreibungen, Angebote und Lieferantenbewertungen eine größere Rolle spielen.
Schritt 4 – Bestellung erzeugen und versenden
Nach Freigabe wird aus der Anforderung eine Bestellung.
SAP S/4HANA stellt dafür beispielsweise die App Manage Purchase Orders bereit. Sie unterstützt die Erstellung und Verwaltung von Bestellungen für Materialien und Services.
Ein digitaler Prozess sollte die Bestellung möglichst automatisch an den Lieferanten übertragen – beispielsweise über ein Business Network, EDI, API oder einen anderen integrierten Kanal.
Schritt 5 – Auftragsbestätigung verarbeiten
Der Lieferant bestätigt Preise, Mengen und Liefertermine.
Automatisierung ist an dieser Stelle besonders wertvoll, weil Abweichungen früh sichtbar werden können.
Wird beispielsweise ein anderer Liefertermin bestätigt, kann der Einkauf reagieren, bevor das Problem erst beim Wareneingang auffällt.
Schritt 6 – Waren oder Dienstleistungen empfangen
Bei Materialien wird der Wareneingang gebucht.
SAP S/4HANA unterstützt den Wareneingang mit Bezug auf die Bestellung. Dadurch werden Bestellung und tatsächliche Lieferung miteinander verknüpft.
Bei Dienstleistungen kann anstelle des klassischen Wareneingangs eine Leistungsbestätigung beziehungsweise Service Entry Sheet relevant sein.
Schritt 7 – Lieferantenrechnung empfangen
Anschließend trifft die Rechnung ein.
Sie kann beispielsweise als strukturierte E-Rechnung, über ein Netzwerk, per EDI, Portal oder – soweit zulässig und relevant – als PDF eingehen.
SAP S/4HANA ermöglicht Lieferantenrechnungen sowohl mit als auch ohne Bestellbezug. Bei Bestellbezug können unter anderem Purchase Order, Delivery Note oder Service Entry Sheet als Referenz verwendet werden.
Schritt 8 – Rechnung prüfen und abgleichen
Jetzt erfolgt einer der wichtigsten Kontrollschritte des Purchase to Pay Prozesses.
Das System prüft beispielsweise:
Stimmt der Lieferant? Stimmen Preise und Mengen? Gibt es eine Bestellung? Wurde die Ware tatsächlich empfangen? Wurde die Leistung bestätigt? Liegt eine Doppelrechnung vor? Sind Steuerinformationen plausibel?
Bei PO-Rechnungen kann ein automatischer Abgleich einen großen Teil dieser Prüfung übernehmen.
Schritt 9 – Rechnung freigeben und buchen
Passt die Rechnung zu Bestellung und Wareneingang, kann sie je nach Prozess weitgehend automatisch weiterverarbeitet werden.
Bei Abweichungen wird ein Exception Workflow gestartet.
Die richtige Person erhält dann beispielsweise eine Aufgabe zur Prüfung einer Preisabweichung, Mengenabweichung oder fehlenden Leistungsbestätigung.
Schritt 10 – Zahlung durchführen und Prozess auswerten
Nach Buchung und Zahlungsfreigabe wird die Rechnung entsprechend den Zahlungsbedingungen bezahlt.
SAP S/4HANA unterstützt automatisierte Zahlungsläufe innerhalb der Kreditorenbuchhaltung.
Damit endet der einzelne operative Vorgang. Für die Prozesssteuerung sollte anschließend jedoch analysiert werden, wie lange der Vorgang gedauert hat und wo Ausnahmen entstanden sind.
Purchase-to-Pay-Prozess SAP: Wie funktioniert P2P in SAP S/4HANA?
Ein Purchase-to-Pay-Prozess SAP-seitig ist kein einzelnes Modul. Er entsteht durch das Zusammenspiel mehrerer Funktionen innerhalb von Sourcing and Procurement, Inventory Management und Finance.
Eine typische Belegkette lautet:
Bestellanforderung → Bestellung → Wareneingang / Leistungserfassung → Lieferantenrechnung → Kreditorenbuchhaltung → Zahlung
Aktuelle SAP-S/4HANA-Cloud-Dokumentation stellt diese Objekte ebenfalls als miteinander verbundene Beschaffungsdokumente dar. SAP bietet beispielsweise Übersichten, in denen Purchase Requisitions, Purchase Orders, Goods Receipts und Supplier Invoices gemeinsam verfolgt werden können.
Bestellanforderung
Sie bildet den internen Bedarf ab.
Bestellung
Sie formalisiert die externe Beschaffung beim Lieferanten.
Wareneingang oder Leistungserfassung
Dieser Schritt bestätigt, dass die bestellten Waren oder Dienstleistungen tatsächlich geliefert beziehungsweise erbracht wurden.
Lieferantenrechnung
Die Rechnung wird gegen vorhandene Einkaufs- und Wareneingangsdaten geprüft.
Accounts Payable
Nach erfolgreicher Verbuchung wird aus dem Beschaffungsvorgang eine offene Lieferantenverbindlichkeit.
Zahlung
Die Verbindlichkeit wird entsprechend Fälligkeit, Zahlungsbedingungen und gegebenenfalls Skonto ausgeglichen.
Damit verbindet der Purchase-to-Pay-Prozess SAP-seitig Einkauf und Finance innerhalb eines konsistenten Datenmodells.
Purchase-to-Pay-Prozess Beispiel: Vom Laptop-Bedarf bis zur Zahlung
Ein praktisches Purchase-to-Pay-Prozess Beispiel verdeutlicht die Zusammenhänge.
Ein neuer Mitarbeiter benötigt einen Laptop.
Der Fachbereich erstellt eine digitale Bedarfsanforderung. Das System ordnet automatisch Kostenstelle und Genehmiger zu. Nach der Freigabe wird aus einem Rahmenvertrag beziehungsweise Katalog ein freigegebenes Gerät ausgewählt und die Bestellung erzeugt.
Der Lieferant erhält die Bestellung elektronisch und bestätigt Liefertermin und Preis.
Nach Anlieferung bestätigt der Wareneingang, dass ein Laptop in der richtigen Ausführung geliefert wurde.
Anschließend trifft die strukturierte E-Rechnung ein.
Das System erkennt die Bestellnummer und gleicht automatisch Bestellung, Wareneingang und Rechnung miteinander ab.
Stimmen Menge und Preis überein, ist keine manuelle Freigabe erforderlich. Die Rechnung wird gebucht und entsprechend den Zahlungsbedingungen in den nächsten Zahlungslauf aufgenommen.
Erst wenn beispielsweise zwei Geräte berechnet wurden, obwohl nur eines eingegangen ist, wird ein Mitarbeiter eingeschaltet.
Genau dies ist das Ziel eines automatisierten Purchase-to-Pay-Prozesses: Standardfälle laufen möglichst ohne manuelle Berührung, Menschen konzentrieren sich auf echte Ausnahmen.
Wie funktioniert der Drei-Wege-Abgleich im P2P-Prozess?
Der Drei-Wege-Abgleich – häufig auch Three-Way Match genannt – ist einer der wichtigsten Kontrollmechanismen in der Beschaffung.
Verglichen werden:
Bestellung – Wareneingang – Rechnung
Die Bestellung beantwortet die Frage:
Was wurde zu welchen Konditionen bestellt?
Der Wareneingang beantwortet:
Was wurde tatsächlich geliefert?
Die Rechnung beantwortet:
Was möchte der Lieferant bezahlt haben?
SAP dokumentiert beispielsweise für Business-Network-Szenarien einen Three-Way Match auf Basis von Standardfunktionen für Invoice Verification und Goods Receipt. Abhängig vom Prüfergebnis kann die Rechnung weiterverarbeitet oder abgelehnt werden.
Wichtig ist jedoch: Nicht jede Rechnung folgt einem klassischen Drei-Wege-Abgleich.
Bei Dienstleistungen kann anstelle eines Wareneingangs eine Service Entry Sheet maßgeblich sein. Bei bestimmten PO-Konstellationen kann eine Rechnung auch ohne Wareneingang verarbeitet werden. SAP S/4HANA unterstützt deshalb unterschiedliche Referenz- und Prüfmodelle.
Ein gut konzipierter Purchase-to-Pay-Prozess unterscheidet diese Szenarien gezielt, anstatt alle Rechnungen durch denselben Workflow zu schicken.
Welche Rolle spielt die E-Rechnung im Purchase-to-Pay-Prozess?
Im P2P-Kontext betrifft die E-Rechnung die Eingangsrechnungsseite.
Für deutsche Unternehmen ist das besonders relevant: Seit dem 1. Januar 2025 müssen inländische Unternehmen grundsätzlich technisch in der Lage sein, E-Rechnungen zu empfangen. Das BMF stellt zudem klar, dass eine E-Rechnung seit 2025 grundsätzlich in einem strukturierten elektronischen Format vorliegen muss; ein einfaches PDF ist keine E-Rechnung im neuen umsatzsteuerlichen Sinne.
Für Unternehmen entsteht daraus nicht nur eine Compliance-Anforderung, sondern auch ein Automatisierungspotenzial.
Strukturierte Rechnungsdaten müssen nicht wie ein unstrukturiertes PDF zunächst per OCR ausgelesen werden. Felder wie Rechnungsnummer, Beträge oder Positionen können direkt aus der strukturierten Datei übernommen und anschließend validiert und mit Bestelldaten abgeglichen werden.
Der aktuelle Fink-Leitfaden zum SAP-E-Rechnungseingang beschreibt genau diese End-to-End-Sicht: Empfang, Validierung, Übergabe an SAP, Workflow, Buchung und Archivierung sollten als zusammenhängender Prozess geplant werden.
Weiterführend:
SAP Document and Reporting Compliance
SAP DRC kann dabei den regulatorischen E-Invoicing- und Dokumentenaustausch unterstützen, während eine operative Rechnungsworkflow-Lösung anschließend Prüfung, Freigabe und Ausnahmebearbeitung übernimmt.
Wie lässt sich der gesamte Purchase-to-Pay-Prozess digitalisieren?
Die Frage „wie lässt sich der gesamte Purchase-to-Pay-Prozess digitalisieren?“ lässt sich nicht mit „Papier einscannen“ beantworten.
Digitalisierung bedeutet, dass Informationen entlang der gesamten Prozesskette strukturiert weitergegeben werden.
Ein digitaler P2P-Prozess kann beispielsweise so aussehen:
Bedarf digital erfassen → regelbasiert freigeben → Bestellung automatisch erzeugen → Lieferant elektronisch anbinden → Wareneingang mobil buchen → E-Rechnung strukturiert empfangen → automatisch matchen → Ausnahmen per Workflow bearbeiten → Rechnung buchen → Zahlung ausführen → Prozess analysieren
Der entscheidende Unterschied zu einer Sammlung einzelner digitaler Tools liegt in der Integration.
Wenn eine Bestellanforderung zwar digital erstellt wird, die Freigabe aber per E-Mail erfolgt und der Rechnungseingang anschließend wieder manuell bearbeitet wird, existiert noch kein echter End-to-End-Prozess.
Auch der Fink-Beitrag zu SAP Ariba Procure-to-Pay betont, dass der Mehrwert nicht aus der Digitalisierung einzelner Schritte entsteht, sondern daraus, Bedarf, Bestellung, Wareneingang, Rechnung und Zahlung in einem konsistenten Prozessmodell zusammenzuführen.
Weiterführend:
SAP Ariba Procure-to-Pay 2026: P2P optimieren
Purchase to Pay Prozess automatisieren: Wo liegen die größten Potenziale?
Wer den Purchase to Pay Prozess automatisieren möchte, sollte zwischen Standardfällen und Ausnahmen unterscheiden.
Das Ziel sollte nicht sein, jede Tätigkeit ohne menschliche Beteiligung abzuwickeln.
Das sinnvollere Ziel lautet:
Standardfälle automatisieren – Ausnahmen intelligent an die richtigen Personen leiten.
Besonders geeignet sind folgende Bereiche.
Bestellanforderungen und Freigaben
Genehmiger lassen sich anhand von Betrag, Warengruppe, Gesellschaft oder Kostenstelle automatisch bestimmen.
Bestellerzeugung
Aus freigegebenen Bedarfen können automatisiert Bestellungen erzeugt werden.
Lieferantenkommunikation
Bestellungen, Bestätigungen und Rechnungen können elektronisch über Netzwerke, EDI oder APIs ausgetauscht werden.
Rechnungsdatenerfassung
Bei strukturierten E-Rechnungen liegen relevante Daten bereits maschinenlesbar vor. Bei PDF- und Scan-Rechnungen können OCR- beziehungsweise KI-basierte Erfassungsverfahren ergänzen.
PO-Matching
Bestellung, Wareneingang und Rechnung können automatisch miteinander verglichen werden.
Touchless Posting
Wenn alle Prüfungen erfolgreich sind, können geeignete Standardrechnungen ohne manuelle Bearbeitung weiterverarbeitet werden.
Zahlung
Freigegebene und fällige Rechnungen können über automatisierte Zahlungsläufe verarbeitet werden.
Ein automatisierter Purchase-to-Pay-Prozess bedeutet damit nicht „keine Menschen mehr“, sondern eine konsequente Verlagerung menschlicher Arbeit von Routinefällen zu Ausnahmefällen.
Purchase to Pay Prozess Software: Welche Lösungen werden benötigt?
Die richtige Purchase to Pay Prozess Software hängt stark von der vorhandenen ERP-Landschaft und der gewünschten Prozessabdeckung ab.
Eine typische SAP-Architektur kann aus mehreren Ebenen bestehen.
| Ebene | Typische Aufgabe |
|---|---|
| SAP S/4HANA | Operativer ERP-Kern für Bestellungen, Wareneingang, Rechnung und Finance |
| SAP Ariba Buying and Invoicing | Guided Buying, Kataloge, P2P-Workflows, Supplier Collaboration |
| SAP Business Network | Elektronischer Dokumentaustausch mit Lieferanten |
| SAP DRC | E-Invoicing und regulatorische Compliance |
| OpenText VIM | Operative Eingangsrechnungsverarbeitung und Exception Handling |
| SAP Signavio | Process Mining und Identifikation von Engpässen |
| SAP Integration Suite | Integration von SAP- und Non-SAP-Systemen |
SAP Ariba Buying and Invoicing bietet aktuell unter anderem Guided Buying, Kataloge, Invoice Management und netzwerkbasierte Zusammenarbeit und ist als End-to-End-Procure-to-Pay-Lösung positioniert.
OpenText VIM wiederum fokussiert stärker auf die operative Eingangsrechnungsverarbeitung. Fink beschreibt Funktionen wie automatisierte Prüfungen, Workflows, Abweichungsbearbeitung und den Drei-Wege-Abgleich zwischen Bestellung, Lieferung und Rechnung.
Weiterführend:
SAP Invoice Management by OpenText
Wichtig ist deshalb: Die Auswahl einer Purchase to Pay Prozess Software sollte nicht mit einer Produktdemo beginnen. Zunächst müssen Prozessumfang und Zielarchitektur definiert werden.
Software Engpässe im Purchase-to-Pay-Prozess finden: Wie funktioniert das?
Die Suchfrage „Software Engpässe Purchase-to-Pay-Prozess finden“ zielt im Kern auf Process Mining und Prozessanalyse.
Klassisches Reporting zeigt beispielsweise:
„300 Rechnungen sind aktuell offen.“
Process Mining geht einen Schritt weiter und fragt:
Warum sind diese Rechnungen offen und an welcher Stelle entsteht die Verzögerung?
SAP Signavio Process Intelligence bietet aktuelle Procure-to-Pay-Accelerators für SAP S/4HANA, SAP ECC, SAP Ariba und systemübergreifende Szenarien. Die Dashboards analysieren unter anderem Durchlaufzeiten, Automatisierungsraten, verspätete Zahlungen und offene überfällige Rechnungen. SAP nennt ausdrücklich die Möglichkeit, Bottlenecks und Automatisierungspotenziale zu identifizieren.
Software kann beispielsweise folgende Engpässe erkennen:
- ungewöhnlich lange PR-Freigaben,
- manuelle Bestellerstellung,
- fehlende Wareneingänge,
- Bestellungen, die erst nach Rechnungseingang angelegt werden,
- hohe Quote gesperrter Rechnungen,
- wiederkehrende Preis- oder Mengenabweichungen,
- lange Bearbeitungszeit von Exceptions,
- verspätete Zahlungen,
- geringe Automatisierungsrate.
SAP Signavio stellt für P2P entsprechende Kennzahlen bereit, darunter den Anteil manueller Bestellanforderungen, manuell erstellter Bestellpositionen und automatisierter Wareneingänge.
Wer Software Engpässe im Purchase-to-Pay-Prozess finden lassen möchte, benötigt deshalb zwei Dinge: ausreichend hochwertige Prozessdaten und eine klare Interpretation der Ursachen.
Ein langer Rechnungsworkflow ist beispielsweise nicht automatisch das Problem. Er kann lediglich sichtbar machen, dass Bestellungen unvollständig angelegt oder Leistungen nicht rechtzeitig bestätigt werden.
Wie können KI und Automatisierung den Purchase-to-Pay-Prozess verbessern?
2026 erweitert sich die Rolle von KI im Einkauf deutlich.
SAP positioniert die aktuellen Ariba-Lösungen stärker in Richtung AI-assisted und zunehmend agentenbasierter Beschaffung. SAP Ariba Buying and Invoicing bietet bereits KI-gestützte Guided-Buying-Funktionen. Die aktuelle Procure-to-Pay-Produktseite nennt zudem autonome beziehungsweise KI-gestützte Assistenten für Buying, Receiving und Invoicing.
Mögliche Einsatzfelder sind:
Demand Intake: Nutzer formulieren ihren Bedarf in natürlicher Sprache und werden automatisch durch den richtigen Beschaffungsprozess geführt. SAP Ariba Intake Management beschreibt hierfür einen KI-gestützten zentralen Einstiegspunkt mit Joule.
Guided Buying: KI kann Nutzern geeignete Produkte, Lieferanten oder Beschaffungskanäle empfehlen.
Rechnungsverarbeitung: KI-basierte Datenerkennung kann unstrukturierte Dokumente erfassen, während intelligente Regeln bei Zuordnung und Ausnahmebearbeitung unterstützen.
Spend Analytics: Muster und Auffälligkeiten in Beschaffungsdaten können schneller erkannt werden.
Supplier Selection: KI kann Empfehlungen und Analysen bei Lieferantenentscheidungen unterstützen.
Process Mining: KI und Analytics können Engpässe und Automatisierungspotenziale priorisieren.
SAP beschreibt Next-gen SAP Ariba aktuell als KI-native Source-to-Pay-Suite auf Basis der SAP Business AI Platform. Neue Funktionen werden laut SAP schrittweise über 2026 und 2027 bereitgestellt; Unternehmen sollten deshalb bei Roadmaps zwischen aktuell verfügbaren Funktionen und angekündigten Innovationen unterscheiden.
Der Purchase-to-Pay-Prozess wird dadurch nicht automatisch vollständig autonom.
Ein sinnvoller Entwicklungspfad lautet vielmehr:
Standardisierung → regelbasierte Automatisierung → KI-gestützte Empfehlungen → kontrollierte Agentenaktionen.
Welche Vorteile bietet ein automatisierter Purchase-to-Pay-Prozess?
Kürzere Durchlaufzeiten
Digitale Workflows reduzieren Liegezeiten bei Freigaben und Rechnungsklärungen.
Weniger manuelle Eingaben
Daten müssen nicht mehrfach zwischen Fachbereich, Einkauf und Finance übertragen werden.
Höhere Transparenz
Der Status einer Bestellung oder Rechnung lässt sich systematisch nachverfolgen.
Bessere Compliance
Einkaufsrichtlinien, Genehmigungsgrenzen und bevorzugte Lieferanten können systemgestützt durchgesetzt werden.
SAP nennt Ausgabenkontrolle und Compliance als zentrale Vorteile digitalisierter Procure-to-Pay-Lösungen.
Höhere Skontonutzung
Je schneller korrekte Rechnungen freigegeben werden, desto leichter können Zahlungsziele und Skontofristen eingehalten werden.
Geringeres Fehlerrisiko
Automatisierte Prüfungen reduzieren manuelle Eingabefehler und unterstützen die Erkennung von Abweichungen oder Doppelrechnungen.
Bessere Lieferantenbeziehungen
Schnellere Freigaben, transparentere Statusinformationen und pünktliche Zahlungen reduzieren Rückfragen und Konflikte.
Welche Herausforderungen und Fehlerquellen gibt es im Purchase-to-Pay-Prozess?
Technologie allein löst keinen schlecht definierten P2P-Prozess.
Gerade bei SAP-VIM-Projekten zeigen vorhandene Fink-Unterlagen, dass Schwierigkeiten häufig an den Übergängen zwischen Einkauf und Finanzbuchhaltung, Rechnung und Bestellung, Wareneingang und Rechnungsprüfung sowie Standardprozess und historisch gewachsenen Ausnahmen entstehen.
Typische Ursachen sind:
fehlende Bestellpflicht, unvollständige Stammdaten, freie Beschaffung außerhalb definierter Kanäle, verspätete Wareneingangsbuchungen, zahlreiche Non-PO-Rechnungen, komplexe Freigabematrizen, uneinheitliche Kontierungen und fehlende Transparenz über Verantwortlichkeiten.
Hinzu kommen technische Herausforderungen wie heterogene ERP-Landschaften, unterschiedliche Rechnungseingangskanäle und internationale E-Invoicing-Anforderungen.
Der größte Fehler besteht deshalb darin, bestehende Probleme lediglich zu digitalisieren.
Ein schlechter manueller Prozess wird durch Automatisierung nicht automatisch zu einem guten Prozess.
Welche KPIs eignen sich für den Purchase-to-Pay-Prozess?
Wer den Purchase-to-Pay-Prozess optimieren möchte, benötigt messbare Ziele.
Geeignete Kennzahlen sind beispielsweise:
| KPI | Aussage |
|---|---|
| Requisition-to-Order Cycle Time | Zeit von Bedarfsmeldung bis Bestellung |
| Purchase Order Approval Time | Dauer der Bestellfreigabe |
| PR Automation Rate | Anteil automatisiert erzeugter Bestellanforderungen |
| PO Automation Rate | Anteil automatisiert erzeugter Bestellungen |
| PO Compliance Rate | Anteil regelkonformer Bestellungen |
| First-Pass Match Rate | Anteil sofort erfolgreich abgeglichener Rechnungen |
| Touchless Invoice Rate | Anteil ohne manuellen Eingriff verarbeiteter Rechnungen |
| Invoice Exception Rate | Anteil der Rechnungen mit Abweichungen |
| Invoice Processing Time | Bearbeitungszeit vom Eingang bis Buchung |
| Duplicate Invoice Rate | Anteil potenzieller Doppelrechnungen |
| On-Time Payment Rate | Anteil termingerecht gezahlter Rechnungen |
| Discount Capture Rate | tatsächlich genutzte Skontomöglichkeiten |
| Late Payment Rate | Anteil verspäteter Lieferantenzahlungen |
SAP Signavio stellt für Procure-to-Pay bereits standardisierte Analysemetriken zu manuellen und automatisierten PR-, PO- und Wareneingangsaktivitäten sowie zu Durchlaufzeiten bereit.
Purchase-to-Pay-Prozess optimieren: Wo sollten Unternehmen beginnen?
Wer den Purchase-to-Pay-Prozess optimieren möchte, sollte nicht mit einer Softwareauswahl beginnen.
Die erste Frage lautet:
Wie läuft der Prozess heute tatsächlich ab?
Nicht:
Wie sollte er laut Prozesshandbuch ablaufen?
Istprozess transparent machen
Erfassen Sie reale Prozessvarianten, Systeme, Beteiligte und Ausnahmen.
Engpässe datenbasiert identifizieren
Analysieren Sie Durchlaufzeiten, manuelle Aktivitäten und wiederkehrende Abweichungen.
Bestellpflicht überprüfen
Je höher der Anteil sauberer PO-basierter Beschaffung, desto größer kann das Matching- und Automatisierungspotenzial sein.
Stammdaten verbessern
Lieferant, Kontierung, Bestellinformationen und Zahlungsbedingungen sind Voraussetzung für stabile Automatisierung.
Ausnahmeprozesse standardisieren
Nicht jede Ausnahme lässt sich vermeiden. Entscheidend ist, dass sie definiert und routbar ist.
E-Rechnung integrieren
E-Invoicing sollte nicht als zusätzlicher Eingangskanal isoliert neben bestehende Prozesse gesetzt werden.
Weiterführend:
E-Rechnung empfangen in SAP: Technische Umsetzung
Rechnungseingang automatisieren
Strukturierte Daten, PO-Matching, Workflows und automatische Buchung sollten als zusammenhängende Prozessarchitektur betrachtet werden.
Weiterführend:
Automatisierte Rechnungsverarbeitung mit KI & SAP
Best Practices für den Purchase-to-Pay-Prozess
Erst Prozess, dann Technologie
Definieren Sie das Zielbild, bevor Systeme konfiguriert werden.
Standardfälle von Ausnahmen trennen
Der ideale Automatisierungsfall ist nicht zwangsläufig der komplexeste Rechnungsfall.
Beginnen Sie mit häufigen, stabilen und regelbasierten Vorgängen.
Daten nur einmal erfassen
Informationen aus Bedarf und Bestellung sollten später in Wareneingang und Rechnungsprüfung wiederverwendet werden.
PO-basierte Beschaffung fördern
Wo fachlich sinnvoll, schafft eine Bestellung eine belastbare Referenz für nachgelagerte Prüfungen.
Wareneingänge zeitnah erfassen
Ein nicht gebuchter Wareneingang kann selbst eine korrekte Rechnung in einen manuellen Ausnahmeprozess zwingen.
Process Mining nach dem Go-live weiter nutzen
Digitalisierung endet nicht mit der Einführung einer Software.
Prozesse sollten kontinuierlich überwacht und optimiert werden.
Do’s & Don’ts beim Purchase-to-Pay-Prozess
Do
Betrachten Sie Einkauf und Accounts Payable als gemeinsamen End-to-End-Prozess. Etablieren Sie klare Bestell- und Freigaberegeln, pflegen Sie Stammdaten konsequent und messen Sie Durchlaufzeiten, Matching- und Automatisierungsraten. Planen Sie E-Invoicing als Teil der P2P-Architektur und definieren Sie kontrollierte Ausnahmeprozesse.
Don’t
Digitalisieren Sie nicht lediglich bestehende Medienbrüche. Erzwingen Sie keinen Drei-Wege-Abgleich für Prozesse, bei denen fachlich kein Wareneingang erwartet wird. Leiten Sie jede Rechnung unabhängig vom Risiko durch denselben manuellen Workflow. Wählen Sie keine Purchase to Pay Prozess Software, bevor klar ist, welches Problem sie lösen soll.
Schritt für Schritt den Purchase-to-Pay-Prozess digitalisieren und automatisieren
Schritt 1 – Scope festlegen
Definieren Sie Gesellschaften, Beschaffungskategorien, Lieferantengruppen und relevante ERP-Systeme.
Schritt 2 – Prozess aufnehmen
Dokumentieren Sie den tatsächlichen Weg von Bedarf bis Zahlung.
Schritt 3 – Prozessvarianten identifizieren
Unterscheiden Sie beispielsweise:
PO-Rechnung, Non-PO-Rechnung, Materialbeschaffung, Dienstleistung, Katalogbeschaffung und Sonderprozesse.
Schritt 4 – KPIs ermitteln
Messen Sie Durchlaufzeit, PO-Quote, Matching Rate, Exception Rate und Touchless Processing.
Schritt 5 – Ursachen analysieren
Ermitteln Sie, ob Probleme aus Prozess, Stammdaten, Organisation oder Technologie entstehen.
Schritt 6 – Zielprozess definieren
Legen Sie fest, welche Vorgänge standardisiert und welche automatisiert werden.
Schritt 7 – Zielarchitektur auswählen
Bewerten Sie SAP S/4HANA, SAP Ariba, SAP DRC, VIM, Business Network, Integration und Process Mining.
Schritt 8 – E-Rechnung integrieren
Definieren Sie Formate, Kanäle, Validierung und Übergabe in den Rechnungsworkflow.
Schritt 9 – Pilotieren
Starten Sie mit einem klar abgegrenzten und ausreichend volumenstarken Prozess.
Schritt 10 – Messen und kontinuierlich verbessern
Vergleichen Sie KPIs vor und nach der Einführung und erweitern Sie die Automatisierung auf weitere Prozessvarianten.
Fazit – Warum der Purchase-to-Pay-Prozess End-to-End gedacht werden muss
Der Purchase-to-Pay-Prozess verbindet Beschaffung, Logistik beziehungsweise Leistungserfassung und Finance zu einem durchgängigen Geschäftsprozess.
Sein Erfolg hängt nicht nur davon ab, wie schnell eine Rechnung gebucht wird.
Entscheidend ist vielmehr, ob die Informationen bereits am Anfang des Prozesses strukturiert und korrekt entstehen.
Eine sauber angelegte Bestellanforderung verbessert die Bestellung. Eine korrekte Bestellung erleichtert Wareneingang und Rechnungsprüfung. Ein zeitnah gebuchter Wareneingang ermöglicht automatisches Matching. Eine strukturierte E-Rechnung reduziert Datenerfassungsaufwand. Ein stabiler Workflow sorgt dafür, dass nur echte Ausnahmen manuell bearbeitet werden.
Genau deshalb sollte ein Purchase-to-Pay-Prozess SAP nicht als Kombination einzelner Transaktionen verstanden werden.
SAP S/4HANA bildet den operativen Kern. SAP Ariba kann geführte Beschaffung und Lieferantenkollaboration erweitern. SAP DRC unterstützt E-Invoicing- und Compliance-Prozesse. OpenText VIM kann die operative Eingangsrechnungsverarbeitung und komplexe Ausnahmeprozesse automatisieren. SAP Signavio macht Prozessvarianten und Engpässe sichtbar.
Die zunehmende Integration von KI erweitert diese Architektur zusätzlich.
Ein automatisierter Purchase-to-Pay-Prozess der Zukunft wird Routinefälle zunehmend selbstständig verarbeiten, Risiken und Abweichungen früher erkennen und Mitarbeitern genau dort Aufgaben zuweisen, wo tatsächlich eine fachliche Entscheidung benötigt wird.
Die wichtigste Voraussetzung bleibt jedoch unverändert:
Erst einen klaren, standardisierten Prozess schaffen – dann konsequent digitalisieren und automatisieren.
Häufig gestellte Fragen zum Purchase-to-Pay-Prozess
Was ist der Purchase-to-Pay-Prozess und wie funktioniert er?
Der Purchase-to-Pay-Prozess umfasst den End-to-End-Prozess vom Beschaffungsbedarf über Bestellanforderung, Bestellung, Waren- oder Leistungseingang und Rechnungsprüfung bis zur Bezahlung des Lieferanten.
Welche Schritte umfasst der Purchase-to-Pay-Prozess?
Typische Purchase-to-Pay-Prozess Schritte sind Bedarfsmeldung, Freigabe, Bestellung, Auftragsbestätigung, Wareneingang beziehungsweise Leistungserfassung, Rechnungseingang, Rechnungsprüfung, Freigabe, Buchung und Zahlung.
Wie funktioniert der Purchase-to-Pay-Prozess SAP in SAP S/4HANA?
SAP S/4HANA verbindet Bestellanforderung, Bestellung, Wareneingang, Supplier Invoice und Kreditorenbuchhaltung miteinander. Dadurch können Beschaffungs- und Rechnungsdaten durchgängig referenziert und ausgewertet werden.
Wie lässt sich der Purchase-to-Pay-Prozess automatisieren?
Unternehmen können unter anderem Genehmigungen, Bestellerstellung, Datenaustausch mit Lieferanten, Rechnungsdatenerfassung, PO-Matching, Buchung und Zahlung automatisieren. Entscheidend sind standardisierte Prozesse und hochwertige Stammdaten.
Was ist der Unterschied zwischen Purchase-to-Pay und Procure-to-Pay?
Beide Begriffe werden in der Praxis meist synonym verwendet. Unterschiede ergeben sich eher aus unternehmensspezifischen Prozessmodellen als aus einer verbindlichen Definition.
Welche Rolle spielt die E-Rechnung im Purchase-to-Pay-Prozess?
Die E-Rechnung betrifft den Rechnungseingang. Strukturierte Rechnungsdaten können elektronisch empfangen und direkt validiert und weiterverarbeitet werden. In Deutschland müssen inländische Unternehmen seit dem 1. Januar 2025 grundsätzlich E-Rechnungen empfangen können.
Welche Herausforderungen gibt es im Purchase-to-Pay-Prozess?
Zu den häufigsten Problemen gehören lange Freigaben, fehlende Bestellungen oder Wareneingänge, Non-PO-Rechnungen, Preis- und Mengenabweichungen, schlechte Stammdaten, Medienbrüche und nicht standardisierte Ausnahmeprozesse.
Wie funktioniert der Drei-Wege-Abgleich im P2P-Prozess?
Beim Drei-Wege-Abgleich werden Bestellung, Wareneingang und Rechnung miteinander verglichen. Stimmen die relevanten Daten innerhalb definierter Toleranzen überein, kann die Rechnung weitgehend automatisiert weiterverarbeitet werden.
Wie können KI und Automatisierung den Purchase-to-Pay-Prozess verbessern?
KI kann Bedarfe klassifizieren, Einkaufswege empfehlen, Daten aus Dokumenten erfassen, Auffälligkeiten identifizieren und Mitarbeiter bei Entscheidungen unterstützen. SAP erweitert sein Procurement-Portfolio aktuell zunehmend um Joule, AI Assistants und Agenten.
Welche Purchase to Pay Prozess Software ist die richtige?
Das hängt von Prozessumfang und Systemlandschaft ab. SAP S/4HANA bildet den operativen ERP-Kern, SAP Ariba fokussiert stärker auf End-to-End-Procurement, OpenText VIM auf komplexe Eingangsrechnungsprozesse, SAP DRC auf E-Invoicing und Compliance und SAP Signavio auf Prozessanalyse.