Auf einen Blick: Procure-to-Pay und Spend Management lösen dasselbe Problem in umgekehrter Reihenfolge. Im Procure-to-Pay ist die Rechnung der Vorgang: Sie kommt an, wird geprüft, freigegeben und dann bezahlt. Im Spend Management ist die Zahlung der Vorgang: Die Karte wurde belastet, das Abo hat abgebucht — und der Beleg wird hinterhergeholt. Daraus folgt die Entscheidung, an der die meisten Einführungen scheitern: Ein Prozess mit einem einzigen Statusfeld funktioniert nur in der ersten Welt. In der zweiten brauchst du zwei Achsen — den Vorgang und den Beleg, getrennt.
Procure-to-Pay in einem Satz
Procure-to-Pay (P2P) ist der Weg von der Bestellung bis zur bezahlten Rechnung. Bedarf, Bestellung, Wareneingang, Rechnungseingang, Prüfung, Freigabe, Zahlung, Buchung — in dieser Reihenfolge, und jeder Schritt setzt den vorigen voraus.
Das Objekt in diesem Prozess ist die Rechnung. Sie ist der Grund, warum es den Vorgang überhaupt gibt, und alles andere hängt an ihr. Deshalb reicht hier genau ein Status: Eine Rechnung ist erfasst, in Prüfung, freigegeben, bezahlt oder abgelehnt. Ein „fehlender Beleg" ist in dieser Welt kein denkbarer Zustand — ohne Rechnung gibt es keinen Vorgang.
Spend Management in einem Satz
Spend Management ist die Steuerung von Ausgaben, die bereits stattgefunden haben oder jederzeit stattfinden können. Firmenkarten mit Limits, Software-Abos, Auslagen, Marktplätze, Plattformgebühren.
Das Objekt ist hier die Zahlung. Der Beleg ist ein Attribut davon — etwas, das dazukommt oder eben fehlt. Und die Freigabe passiert nicht je Vorgang, sondern vorab über Limits und Regeln: Wer eine Karte mit Monatslimit hat, braucht für den Bürobedarf keine Unterschrift.
Der Unterschied in einer Tabelle
| Procure-to-Pay / Kreditorenbuchhaltung | Spend Management | |
|---|---|---|
| Anker des Vorgangs | die Rechnung | die Zahlung |
| Reihenfolge | Rechnung → Prüfung → Freigabe → Zahlung | Zahlung → Beleg hinterherholen |
| Der Beleg ist … | der Vorgang selbst | ein Attribut der Zahlung |
| Freigabe | vor der Zahlung, oft mehrstufig | vorab über Limits, nicht je Beleg |
| Typische Auslöser | Lieferantenrechnung, Bestellung | Firmenkarte, Abo, Auslage, Plattform |
| Ein Statusfeld genügt? | ja | nein |
Beide Disziplinen sind richtig. Die Frage ist nicht, welche besser ist, sondern welche dein Unternehmen tatsächlich betreibt — und die meisten kleineren Unternehmen betreiben überwiegend die zweite, ohne es so zu nennen.
Warum die Reihenfolge alles entscheidet
Hier liegt der Punkt, an dem viele Prozessmodelle kippen.
Bei einer klassischen Lieferantenrechnung mit Überweisung kommt die Rechnung zuerst und die Zahlung danach. Bei einer Kartenzahlung, einem Software-Abo, einem Kauf über eine Plattform oder einer Zahlung per PayPal ist es genau umgekehrt: Erst fließt das Geld, dann existiert vielleicht ein Beleg. Und bei vielen Plattformen existiert er nur hinter einem Login, aus dem ihn jemand von Hand holen muss.
Daraus folgt ein Satz, der die ganze Modellierung trägt: Eine Prozessleiter, deren Reihenfolge in der Mehrheit deiner Fälle nicht gilt, sortiert nichts. Sie erzeugt Zeilen, die auf Stufe 1 stehen, obwohl das Geld längst weg ist — und niemand weiß mehr, ob das ein Fehler ist oder normal.
Die Schritte des Procure-to-Pay-Prozesses
Für die Fälle, in denen die Reihenfolge stimmt, sieht der Prozess so aus:
| Schritt | Was passiert | Was schiefgeht |
|---|---|---|
| Bedarf | Jemand meldet an, dass etwas gebraucht wird | Wird mündlich geregelt und taucht nie auf |
| Bestellung | Bestellung geht raus, mit Nummer und Betrag | Bestellt wird ohne Bestellung — „ich hab das schnell geordert" |
| Wareneingang | Lieferung wird erfasst | Niemand quittiert, die Rechnung ist später nicht prüfbar |
| Rechnungseingang | Rechnung trifft ein und wird erfasst | Sie landet im persönlichen Postfach statt im Prozess |
| Prüfung und Freigabe | Sachlich und rechnerisch richtig? Wer gibt frei? | Liegt zwei Wochen, Skontofrist verfällt |
| Zahlung | Überweisung, Verbuchung | Doppelzahlung, weil dieselbe Rechnung zweimal kam |
Wie schnell dieser Weg durchlaufen wird, lässt sich messen — die Kreditorenlaufzeit sagt, wie viele Tage im Schnitt zwischen Rechnung und Zahlung liegen. Der Zusammenhang mit der Liquiditätsplanung ist direkt: Jeder Tag, den eine Rechnung länger liegt, ist ein Tag, an dem das Geld noch da ist.
Source-to-Pay, Purchase-to-Pay, Procure-to-Pay: dieselben Wörter, andere Grenzen
Die drei Begriffe werden durcheinander benutzt. Sie unterscheiden sich darin, wo der Prozess anfängt:
| Begriff | Fängt an bei | Endet bei |
|---|---|---|
| Source-to-Pay (S2P) | Lieferantensuche, Ausschreibung, Vertrag | bezahlte Rechnung |
| Procure-to-Pay (P2P) | Bedarf und Bestellung | bezahlte Rechnung |
| Purchase-to-Pay | Bestellung | bezahlte Rechnung |
Purchase-to-Pay und Procure-to-Pay meinen in der Praxis fast immer dasselbe; Source-to-Pay nimmt den Einkauf davor mit hinein. Für ein Unternehmen ohne eigene Einkaufsabteilung ist die Unterscheidung folgenlos — dort gibt es weder Ausschreibung noch Lieferantenmanagement.
Der Drei-Wege-Abgleich — und wann er nichts bringt
Der 3-Way-Match ist die Kernkontrolle im Procure-to-Pay: Bestellung, Wareneingang und Rechnung müssen in Menge und Preis übereinstimmen. Stimmen alle drei, kann die Rechnung ohne weitere Prüfung durchlaufen.
Der Abgleich setzt allerdings voraus, dass es alle drei Dokumente gibt. Ohne Bestellungen ist er nicht halb so gut, sondern gar nicht vorhanden. Wer Software-Abos, Kartenzahlungen und Plattformgebühren abwickelt, hat keine Bestellung und keinen Wareneingang — für diesen Teil des Ausgabenvolumens ist der 3-Way-Match schlicht nicht die richtige Kontrolle. Die richtige Kontrolle dort heißt Limit, Regel und Beleganforderung.
Das ist kein Argument gegen den Abgleich. Es ist ein Argument dafür, ihn auf den Teil anzuwenden, für den er gebaut wurde.
Warum ein einziges Statusfeld nicht reicht
Die naheliegende Idee ist, alles in eine Leiter zu packen: Rechnung da → freigegeben → bezahlt → gebucht → an die Kanzlei übergeben. Das fühlt sich sauber an, weil eine Zeile dann genau einen Stand hat.
Es scheitert an zwei Stellen:
- Die Stufen laufen nicht im Gleichschritt. Eine Kartenzahlung ist bezahlt, bevor irgendetwas anderes passiert ist. Eine Abo-Rechnung ist an die Kanzlei übergeben, obwohl sie nie freigegeben wurde — es gab nichts freizugeben.
- Zwei Spalten sagen dasselbe. Wer eine Leiter mit einer Stufe „Beleg fehlt" baut und daneben eine Spalte „Beleg vorhanden" führt, hat dieselbe Tatsache zweimal aufgeschrieben. Der Test dafür ist simpel: Zeig mir alles, was angefordert wurde und einen Beleg hat. Auf einer einzigen Achse schließen sich diese beiden Zustände gegenseitig aus, obwohl sie in Wirklichkeit gleichzeitig wahr sind.
Der Beleg ist ein Attribut, kein Zustand
Der Belegzustand gehört auf eine eigene Achse, getrennt vom Bearbeitungsstand des Vorgangs. Das ist die eine Entscheidung, in der die etablierten Systeme übereinstimmen — unabhängig voneinander und mit unterschiedlichen Worten.
Stand September 2026, nach der öffentlichen Dokumentation der Anbieter:
| System | Belegachse | Getrennte Vorgangsachse |
|---|---|---|
| Spendesk | eigener Belegzustand, mehrstufig (gültig, ungültig, fehlt, verloren gemeldet) | Freigabe und Export laufen getrennt daneben |
| Ramp | fehlender Beleg als Regelverstoß mit Erinnerung, nicht als Status | „Requirements completed" als eigenes Feld |
| Pleo | „Needs details" als Rückläufer | Export-Warteschlange getrennt davon |
| Candis | Freigabe als Schrittzähler („Schritt 2 von 4") | Beleg und Freigabe getrennt |
| DATEV Unternehmen online | Belegtyp und Rechnungstyp als eigene Filter | Freigabestatus als dritter, unabhängiger Filter |
Fünf Systeme, fünf Vokabulare, dieselbe Struktur. Das ist ein stärkeres Argument als jede Meinung: Wer dieses Problem ernsthaft gelöst hat, hat es so gelöst.
Wie der Belegfluss darunter praktisch aussieht — Erfassung, OCR, revisionssichere Ablage — steht im Belegmanagement und in Belege digitalisieren.
Der Grund gehört an die Stufe, nicht in die Stufe
Die zweite Regel, die sich aus derselben Beobachtung ergibt: Wenn ein Vorgang hängt, ist „hängt" der Zustand und warum er hängt eine Begründung — keine eigene Stufe.
Fehlender Beleg, unklare Kontierung, Freigabe steht aus, Export fehlgeschlagen: Das sind vier Gründe für denselben Zustand. Wer sie zu vier Stufen macht, bekommt eine Leiter, die sich nicht mehr ordnen lässt, weil zwei Gründe gleichzeitig gelten können. Wer sie als Begründung an eine Stufe hängt, kann beides auswerten — wie viele hängen, und woran.
Was passiert ist, ist ein Ereignis. Was offen ist, wird abgeleitet
Ein Statusfeld, das überschrieben wird, hat keine Historie. Es sagt, dass etwas eingereicht wurde, aber nicht wann und durch wen.
Für die Ergonomie ist das ärgerlich. Sobald aber Belege digital aufbewahrt werden, ist es mehr als das: Unveränderbarkeit ist ein Kernprinzip der GoBD. Ein angehängtes Ereignis mit Zeitstempel erfüllt diesen Anspruch; ein Feld, das von „offen" auf „eingereicht" springt, nicht. Was für dich konkret gilt und welche Fristen greifen, steht in GoBD-konforme Buchhaltung — und gehört im Zweifel mit deiner Steuerberatung durchgesprochen, nicht mit einem Softwareanbieter.
Praktisch heißt das: Speichere die Ereignisse (Beleg eingegangen, Zahlung erfolgt, angefordert, übergeben) und leite den Stand daraus ab, statt ihn zu speichern. Dann gibt es genau eine Spalte „Stand", sie gilt für jede Zeile, und sie kann sich nicht widersprechen.
Die PBC-Liste: Wirtschaftsprüfer haben das Problem zuerst gehabt
Wer Belege anfordert, führt eine Anforderungsliste — und dafür gibt es seit Jahrzehnten ein etabliertes Muster. In der Wirtschaftsprüfung heißt es PBC-Liste (Prepared By Client), auch Client Request List.
Ihr Status hat drei Werte:
Pending → Received → Reviewed
Der dritte ist der interessante. „Der Anfordernde hat es akzeptiert" ist eine andere Tatsache als „das Dokument existiert" — und sie kann nur der Anfordernde setzen. Genau diese Unterscheidung fehlt in selbstgebauten Listen fast immer: Dort gilt ein Beleg als erledigt, sobald irgendetwas hochgeladen wurde.
Der Zustand, der fast überall fehlt: Zurückweisung
Jedes ernsthafte Rechnungssystem kann eine Rechnung ablehnen oder zurückstellen. In selbstgebauten Belegprozessen fehlt dieser Zustand fast immer — und er wird gebraucht, sobald jemand den falschen Beleg schickt.
Der häufigste Fall ist strukturell: Eine Zahlungsquittung belegt den Zahlweg, nicht den Kauf. Eine PayPal-Bestätigung sagt, dass Geld geflossen ist, aber nicht, was gekauft wurde und mit welchem Steuersatz. Für die Buchhaltung braucht es die Rechnung des Händlers.
Ohne einen Zustand „zurückgewiesen, weil …" landet dieser Rückläufer in einer Chatnachricht — und die Liste behauptet weiter, der Beleg sei da.
E-Rechnung: warum ein PDF bald das falsche Original ist
Zwei Termine, die jeden Belegprozess betreffen:
- Seit dem 1. Januar 2025 muss jedes inländische Unternehmen E-Rechnungen von anderen inländischen Unternehmen empfangen können. Für den Empfang gibt es keine Übergangsfrist.
- Für das Versenden gilt eine Staffel: Bis Ende 2026 dürfen alle noch anders abrechnen; 2027 nur noch Unternehmen mit bis zu 800.000 Euro Vorjahresumsatz; ab dem 1. Januar 2028 alle.
Für die Belegachse ist daran eine Sache entscheidend: Eine XRechnung ist ein strukturiertes XML, und dieses XML ist das rechtliche Original. Ein daraus erzeugtes PDF ist eine Kopie. Ein Prozess, der stillschweigend annimmt, ein Beleg sei ein PDF, stuft ab diesem Punkt das bessere Dokument als fehlend ein.
Das ist heute in vielen Unternehmen noch folgenlos, weil kaum ein Lieferant freiwillig umgestellt hat. Es wird in dem Moment relevant, in dem der erste es tut — und das ist seit Anfang 2025 zulässig. Formate und Fristen im Detail stehen in E-Rechnung-Pflicht und, für den DATEV-Weg, in E-Rechnung in DATEV.
Was davon für dein Unternehmen gilt
| Wenn bei dir … | dann brauchst du … |
|---|---|
| die meisten Ausgaben über Karte, Abo und Plattform laufen | Spend Management: Limits statt Einzelfreigaben, Belegachse getrennt vom Vorgang |
| Lieferantenrechnungen mit Bestellungen dominieren | Procure-to-Pay: Bestellbezug, 3-Way-Match, mehrstufige Freigabe |
| beides vorkommt (der Normalfall) | einen Vorgangsstand, der für beide Welten gilt — und den Beleg als eigenes Merkmal |
| genau eine Person freigibt | keine Freigabestufe. Ein Klick, den sich jemand selbst erteilt, zeichnet nichts auf |
Die letzte Zeile ist die, die am häufigsten falsch entschieden wird. Freigabeworkflows aus Konzernsoftware setzen mehrere Menschen voraus. In einem Unternehmen, in dem eine Person entscheidet, erzeugen sie Klicks ohne Aussage.
Angrenzende Bausteine, je nachdem wo dein Volumen liegt: Software-Abos managen, Spesenmanagement, Reisekostenabrechnung und Kostenstellen und Budgets. Der Überbau steht im Ausgabenmanagement-Guide.
Werkzeuge für die Ausgabenseite
Welches Werkzeug passt, hängt daran, welche der beiden Disziplinen bei dir überwiegt — und die meisten Unternehmen brauchen zwei davon nebeneinander, nicht eins für alles.
| Wenn bei dir überwiegt … | dann brauchst du … | zum Beispiel |
|---|---|---|
| Firmenkarten, Abos, Auslagen | Spend Management: Limits, Regeln, eigene Belegachse | Pleo, Moss, Circula |
| Lieferantenrechnungen mit Freigaben | Rechnungseingang mit Freigabeworkflow und Vorkontierung | Candis |
| die Frage, was davon nächsten Monat aufs Konto durchschlägt | Liquiditätsplanung neben der Ausgabenseite | finban |
Was finban dabei macht — und was nicht
finban ist keine Procure-to-Pay-Software. Es gibt keine Bestellungen, keinen Wareneingang, keinen 3-Way-Match und keine mehrstufige Rechnungsfreigabe. Wer diesen Prozess braucht, braucht ein anderes Werkzeug daneben.
Was finban macht, ist die Seite danach: Aus bezahlten und geplanten Ausgaben wird eine Vorschau auf den Kontostand. Bankkonten laufen per Open Banking mit, Lexware Office und sevdesk sind nativ angebunden, offene Posten aus DATEV kommen per Datei-Import dazu. Geplant wird in wenigen eigenen Kategorien, nicht auf Kontonummern — wiederkehrende Abos und Fixkosten stehen damit im selben Verlauf wie alles andere.
Die Verbindung zur Ausgabenseite ist konkret: Eine Rechnung, die in der Offene-Posten-Liste steht, ist eine Zahlung, die in einem bestimmten Monat fällig wird. Die Belegfrage — hat jemand das PDF — beantwortet finban nicht; dafür sind Werkzeuge wie Pleo oder Candis gebaut. Beide Seiten zusammen ergeben das Bild: was ausgegeben wurde, und was das für die nächsten Monate heißt.
Wie Debitoren- und Kreditorenseite zusammenhängen, steht ausführlich in Accounts Receivable und Accounts Payable.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Procure-to-Pay und Spend Management?
Die Reihenfolge. Im Procure-to-Pay kommt die Rechnung zuerst und wird vor der Zahlung geprüft und freigegeben. Im Spend Management ist die Zahlung bereits erfolgt — über Firmenkarte, Abo oder Plattform — und der Beleg wird danach beschafft. Daraus folgt, dass im Procure-to-Pay ein Statusfeld genügt, im Spend Management aber nicht: Dort ist der Beleg ein Merkmal der Zahlung, kein Bearbeitungsstand.
Was bedeutet P2P im Einkauf?
P2P steht für Procure-to-Pay, also den durchgängigen Prozess von der Bedarfsmeldung über Bestellung und Wareneingang bis zur geprüften, freigegebenen und bezahlten Rechnung. Die Abkürzung wird gelegentlich auch für Purchase-to-Pay benutzt; in der Praxis meinen beide dasselbe.
Was ist der Unterschied zwischen Source-to-Pay und Procure-to-Pay?
Source-to-Pay beginnt früher. Es schließt Lieferantensuche, Ausschreibung, Verhandlung und Vertrag mit ein, also den Einkauf vor der ersten Bestellung. Procure-to-Pay setzt bei Bedarf und Bestellung an. Für Unternehmen ohne eigene Einkaufsabteilung ist die Unterscheidung ohne praktische Folge.
Was ist ein 3-Way-Match?
Der Abgleich von Bestellung, Wareneingang und Rechnung in Menge und Preis. Stimmen alle drei überein, kann die Rechnung ohne Einzelprüfung durchlaufen. Der Abgleich setzt voraus, dass Bestellungen existieren — für Kartenzahlungen, Abos und Plattformgebühren gibt es ihn deshalb nicht.
Warum reicht ein einziges Statusfeld für Belege nicht?
Weil zwei Dinge gleichzeitig wahr sein können: Ein Vorgang kann angefordert sein und einen Beleg haben. Auf einer einzigen Achse schließen sich diese Zustände gegenseitig aus. Der praktische Test ist die Frage „Zeig mir alles, was angefordert wurde und schon einen Beleg hat" — lässt sie sich nicht beantworten, sind zwei Achsen nötig.
Braucht ein kleines Unternehmen eine Rechnungsfreigabe?
Nur, wenn mehr als eine Person entscheidet. Eine Freigabestufe, die sich dieselbe Person selbst erteilt, die die Ausgabe veranlasst hat, zeichnet keine Kontrolle auf — sie erzeugt einen Klick. Sinnvoll wird ein Freigabeschritt ab dem Punkt, an dem jemand etwas freigibt, das jemand anderes ausgelöst hat.
Reicht eine PayPal-Quittung als Beleg?
Eine Zahlungsbestätigung belegt, dass Geld geflossen ist — nicht, was gekauft wurde und mit welchem Steuersatz. Für die Buchhaltung ist in der Regel die Rechnung des Händlers nötig. Ob im Einzelfall etwas anderes gilt, entscheidet deine Steuerberatung; finban gibt dazu keine Auskunft.
Ab wann muss ich E-Rechnungen empfangen können?
Seit dem 1. Januar 2025, ohne Übergangsfrist, für Rechnungen von anderen inländischen Unternehmen. Beim Versenden gilt eine Staffel: bis Ende 2026 für alle offen, 2027 noch für Unternehmen bis 800.000 Euro Vorjahresumsatz, ab dem 1. Januar 2028 verpflichtend für alle.
Ist eine XRechnung als PDF gültig?
Nein. Bei einer XRechnung ist das strukturierte XML das Original; ein daraus erzeugtes PDF ist eine Kopie und ersetzt es für die Aufbewahrung nicht. Belegprozesse, die stillschweigend ein PDF erwarten, stufen das eigentliche Original deshalb als fehlend ein.
Was ist eine PBC-Liste?
PBC steht für „Prepared By Client" — die Liste der Unterlagen, die ein Prüfer beim Mandanten anfordert. Ihr Status hat typischerweise drei Werte: Pending, Received und Reviewed. Der dritte Wert trennt „ein Dokument ist da" von „der Anfordernde hat es akzeptiert", und genau diese Trennung fehlt in selbstgebauten Anforderungslisten meist.