Procure to Pay ist der durchgängige Zyklus vom erkannten Bedarf bis zur Zahlung: Anforderung, Bestellung, Wareneingang, Rechnung und Zahlungsausgleich.
Procure to Pay, meist als P2P abgekürzt, ist der vollständige Geschäftszyklus, der beginnt, sobald jemand im Unternehmen einen Bedarf feststellt, und endet, wenn der Lieferant bezahlt und der Vorgang in der Buchhaltung ausgeglichen ist. Die Standardschritte sind Bestellanforderung, Genehmigung, Bestellung, Waren- oder Leistungseingang, Rechnungseingang, Abgleich, Buchung und Zahlung. Der Zyklus umfasst bewusst zwei Bereiche, die getrennt gemessen werden, den Einkauf in der ersten Hälfte und die Kreditorenbuchhaltung in der zweiten, und genau an dieser Übergabe entstehen die meisten Probleme.
Jeder Bruch zwischen diesen Schritten wird zu Liquiditätsbindung oder Risiko. Eine Beschaffung ohne Bestellung hinterlässt in der Kreditorenbuchhaltung eine Rechnung, die niemand erwartet hat und gegen die nichts abgeglichen werden kann. Sie bleibt in der Klärung liegen, während die Zahlungsfrist verstreicht. Ein nicht gebuchter Wareneingang bedeutet, dass die Ware im Lager liegt, die Verbindlichkeit aber nicht in der Bilanz steht, und die Periode schliesst zu niedrig ab. Verspätete Genehmigungen schieben Rechnungen aus dem Skontofenster und danach über die Fälligkeit hinaus, was auf der einen Seite Geld und auf der anderen Seite Lieferantenvertrauen kostet.
Business Central deckt das transaktionale Rückgrat im Standard ab: Bestellungen, Lager- oder Direktwareneingänge, Einkaufsrechnungen, die Übernahme gebuchter Eingangszeilen über «Eingangszeilen holen», Kreditorenposten sowie das Zahlungsausgangsbuchblatt mit Zahlungsvorschlag und SEPA-Zahlungsdateien. Die native Genehmigungsworkflow-Engine leitet Einkaufsbelege an die in der Genehmigungsbenutzer-Einrichtung hinterlegten Genehmiger weiter, inklusive Betragsgrenzen. Dünner ist der Standard am Anfang und bei den Ausnahmen: Es gibt keinen Anforderungsbeleg für Bedarfsträger ohne Einkaufsrolle, kein Lieferantenportal, keine Vertragsablage und keine Liste, die jede blockierte Rechnung mit ihrem Grund zeigt. Diese Lücken werden über Erweiterungen oder Prozessdisziplin geschlossen. Der eigene Leitfaden zur Beschaffungsautomatisierung geht darauf im Detail ein.
Ein Instandhaltungsleiter benötigt Ersatzpumpen und meldet den Bedarf am 3. März. Ein Einkäufer erstellt die Bestellung PO-104217 bei Alpine Technik über 6 Stück zu CHF 780, insgesamt CHF 4 680, Zahlungsbedingung 30 Tage netto. Die Pumpen treffen am 17. März ein, der Wareneingang wird am selben Tag gebucht. Die Rechnung vom 18. März wird gegen Bestellung und Wareneingang abgeglichen und mit Fälligkeit 17. April gebucht. Vom Bedarf bis zum Zahlungsausgang vergehen 45 Tage: 14 Tage Lieferzeit, ein Tag zwischen Wareneingang und Rechnungsdatum sowie 30 Tage Zahlungsziel, das das Unternehmen bewusst ausschöpft.
Die wiederkehrenden Schwachstellen sind Rechnungen ohne Bestellung, Wareneingänge, die Tage nach der physischen Anlieferung erfasst werden, und Genehmiger im Urlaub ohne hinterlegte Vertretung. Teams verfolgen vier Kennzahlen statt einer: den Anteil des Volumens mit Bestellung, den Anteil der Rechnungen, die ohne manuellen Eingriff durch den Abgleich laufen, die durchschnittliche Dauer von Rechnungseingang bis Buchung und die Anzahl aktuell blockierter Rechnungen. Eine einzelne durchschnittliche Durchlaufzeit verdeckt alle vier und zeigt nicht, wo einzugreifen ist.
content[5] = (kein sechstes Element; das Array endet nach den fünf echten Absätzen, zuletzt "Die wiederkehrenden Schwachstellen sind Rechnungen ohne Bestellung, Wareneingänge, die Tage nach der physischen Anlieferung erfasst werden, und Genehmiger im Urlaub ohne hinterlegte Vertretung. Teams verfolgen vier Kennzahlen statt einer: den Anteil des Volumens mit Bestellung, den Anteil der Rechnungen, die ohne manuellen Eingriff durch den Abgleich laufen, die durchschnittliche Dauer von Rechnungseingang bis Buchung und die Anzahl aktuell blockierter Rechnungen. Eine einzelne durchschnittliche Durchlaufzeit verdeckt alle vier und zeigt nicht, wo einzugreifen ist." Der FAQ-Block wird aus dem `faq`-Array erzeugt, es tritt nichts an die Stelle des Platzhalters.)
Nein. Source to Pay ist breiter und stellt dem Zyklus die Beschaffungsmarktarbeit voran: Lieferantensuche, Ausschreibung, Verhandlung und Vertragsvergabe. Procure to Pay beginnt erst, wenn Lieferant und Preis feststehen.
Nicht zwingend. BC verarbeitet Bestellungen, Wareneingänge, Rechnungen und Zahlungen nativ. Die eigentliche Frage ist, ob Sie zusätzlich Bestellanforderungen, Lieferanten-Selfservice und Ausnahmesteuerung benötigen. Bei wenigen Einkäufern läuft der gesamte Zyklus oft allein in BC.
Die KI-Tools von Zentriq automatisieren viele der manuellen Prozesse rund um procure to pay (p2p, vom bedarf bis zur zahlung) in Business Central. Mehr über den Zentriq Agent erfahren oder Zentriq PunchOut ausprobieren um zu sehen, wie KI den Einkauf in BC vereinfacht.