Rechnungsfreigabe: warum OCR die Durchlaufzeit nicht halbiert

Die Rechnungsfreigabe ist der Verwaltungsprozess mit den meisten Automatisierungsprojekten — und mit der höchsten Quote an Projekten, deren Business Case im Nachhinein nicht eintritt. Der Grund lässt sich an einem durchgerechneten Modell zeigen.

Hinweis: Die folgenden Zahlen stammen aus einem Beispielmodell, nicht aus einem realen Mandat. Sie sind so gewählt, dass sie typischen Größenordnungen im Mittelstand entsprechen. Setzen Sie Ihre eigenen ein — das Muster bleibt.

Das Ausgangsmodell

Ein Unternehmen verarbeitet 1200 Eingangsrechnungen im Monat, also rund 60 an einem Arbeitstag. Der Prozess hat fünf Schritte:

Rechnet man nur die Bearbeitungszeiten zusammen, kommt man auf rund 20 bis 30 Minuten je Rechnung. Die tatsächliche Durchlaufzeit vom Eingang bis zur Zahlungsfreigabe liegt in solchen Konstellationen regelmäßig bei acht bis zwölf Arbeitstagen.

Zwischen 25 Minuten und zehn Tagen liegen etwa drei Größenordnungen. Diese Lücke ist der eigentliche Gegenstand des Projekts — und sie besteht fast vollständig aus Wartezeit.

Wo die Wartezeit entsteht

Verteilt man die zehn Tage auf die Schritte, ergibt sich ein Bild, das in dieser Form fast immer entsteht:

• Posteingang bis Erfassung: unter einem Tag. Die Kapazität reicht.
• Erfassung: ein bis zwei Tage. Auslastung um 80 %, also spürbar, aber beherrschbar.
• Warten auf sachliche Freigabe: fünf bis acht Tage. Hier steckt der Prozess.
• Kontierung und Prüfung: unter einem Tag.
• Warten auf den nächsten Zahllauf: im Schnitt 1,5 Tage.

Der Grund für die Freigabe ist strukturell und hat nichts mit Faulheit zu tun: Die Freigabe ist kein Vollzeitjob. Sie ist eine Nebentätigkeit von 14 Personen, die ihre Hauptaufgabe haben. Jede von ihnen bearbeitet Freigaben, wenn sie dazu kommt — typischerweise einmal am Tag, manchmal seltener, während Urlaub gar nicht.

Damit hat dieser Schritt zwei Eigenschaften, die zusammen tödlich sind:

1. Sehr hohe Streuung. Eine Rechnung wird in zehn Minuten freigegeben oder in sechs Tagen. Die Streuung ist der Haupttreiber der Wartezeit — sie geht quadratisch in die Warteschlangenformel ein.
2. Keine Vertretung. Fällt eine Person aus, wartet ihr Anteil, bis sie zurück ist. Es gibt keinen Pool, der übernimmt.

Was OCR tatsächlich bewirkt

Der übliche Projektvorschlag lautet: Belegerkennung einführen, Rechnungsdaten automatisch ins ERP übernehmen, Erfassungszeit von 10 auf 2 Minuten senken.

Die Tabelle rechnet: 8 Minuten × 1200 Rechnungen × 12 Monate = 1920 Stunden im Jahr. Bei 55 €/h sind das 105.600 €. Das Projekt ist genehmigt.

Was tatsächlich passiert:

Die Erfassung wird schneller — deutlich. Das ist kein Marketingversprechen, sondern tritt ein. Die Auslastung der Kreditorenbuchhaltung fällt von 80 % auf unter 30 %.

Die Durchlaufzeit sinkt um etwa einen Tag. Von zehn auf neun. Denn die Erfassung war nie der Engpass.

Und dann wird es schlechter, bevor es besser wird. Vorher gab die Erfassung etwa 60 Rechnungen am Tag an die Freigabe weiter, gleichmäßig verteilt. Jetzt kommen sie in Schüben — sobald der Scan durch ist, alle auf einmal. Die Freigabe, die vorher durch die Erfassung gedrosselt wurde, bekommt nun die volle Menge und die volle Schwankung. Ihre Wartezeit steigt.

Der Engpass ist nicht verschwunden. Er ist gewandert — und die eingesparte Zeit steht als Wartezeit vor der Fachabteilung.

Die Ersparnis, die wirklich da ist

Missverstehen Sie das nicht: Die 1920 Stunden sind echt. Sie sind nur nicht das, was der Business Case behauptet hat.

• Was eintritt: Kapazität in der Kreditorenbuchhaltung. Das ist wertvoll — für Wachstum ohne Neueinstellung, für Skontonutzung, für Qualität.
• Was nicht eintritt: die versprochene Halbierung der Durchlaufzeit. Und daran wird das Projekt gemessen, weil die Fachabteilungen darüber klagen.

Die Differenz zwischen beidem ist der Grund, warum ein technisch erfolgreiches Projekt als Enttäuschung endet.

Was die Durchlaufzeit wirklich senkt

Alle wirksamen Maßnahmen setzen an der Freigabe an, und keine davon ist ein Softwarekauf:

1. Wertgrenzen. Rechnungen unter einem Schwellenwert brauchen keine sachliche Einzelfreigabe, sondern eine Stichprobe im Nachhinein. In typischen Verteilungen macht die Hälfte der Belege einen kleinen Teil des Volumens aus — sie bindet aber die Hälfte aller Freigabevorgänge.

2. Vertretungsregeln mit Automatik. Keine manuelle Weiterleitung, sondern: nach X Tagen ohne Reaktion geht die Rechnung an die Vertretung. Das kappt die lange Flanke der Verteilung — und die ist es, die den Mittelwert kaputt macht.

3. Sammelfreigabe zu festen Zeiten. Statt „wenn ich dazu komme“ ein täglicher fester Slot. Das senkt die Streuung drastisch, ohne dass jemand mehr arbeitet.

4. Freigabe vor der Erfassung. Der Klassiker unter den Reihenfolgefehlern: Erst wird sorgfältig erfasst, dann stellt sich heraus, dass die Rechnung strittig ist. Eine kurze sachliche Prüfung vorne im Prozess spart die Erfassung aller strittigen Fälle.

Maßnahme 3 ist erfahrungsgemäß die wirksamste im Verhältnis zum Aufwand — und die, die in keinem Angebot steht, weil sie sich nicht verkaufen lässt.

Die Reihenfolge, die funktioniert

1. Erst messen, wo die Zeit liegt. Bestand vor jedem Schritt zählen, durch Tagesdurchsatz teilen. Das kostet einen Vormittag und beantwortet die Kernfrage.
2. Dann die Freigabe entlasten. Wertgrenzen, Vertretung, feste Slots. Kein Budget nötig.
3. Dann erneut messen. Der Engpass sitzt jetzt woanders — vermutlich in der Erfassung.
4. Dann automatisieren. Jetzt trifft die Automatisierung den echten Engpass, und die Ersparnis erscheint auch in der Durchlaufzeit.

Wer in dieser Reihenfolge vorgeht, kauft dieselbe Software — bekommt aber ein Projekt, das hält, was der Business Case versprochen hat.

Warum man das durchspielen sollte, bevor man es kauft

Der beschriebene Effekt — Engpass wandert, Ersparnis verpufft — ist in einer Tabelle nicht sichtbar, weil eine Tabelle jeden Schritt für sich rechnet. In einem Simulationsmodell sieht man ihn in Sekunden: Man senkt die Erfassungsdauer, und die Warteschlange vor der Freigabe wächst vor den eigenen Augen.

Genau dafür ist FlowVisual gebaut. Der Prozess oben ist in etwa einer halben Stunde modelliert; danach kostet die Frage „was passiert, wenn wir OCR einführen?“ einen Klick — und die Antwort kommt mit P10–P90-Spanne, statt als eine Zahl, die niemand verteidigen kann.