Rechnungsprüfung automatisieren: Zwei von drei Belegen reichen nicht

Achtzig Prozent laufen ohne Zutun durch

Ein Großhändler für Laborbedarf hat vor zwei Jahren die Rechnungsprüfung automatisiert. Die Eingangsrechnung kommt als PDF, ein Workflow liest Positionen, Mengen und Preise aus und hält sie gegen die Bestellung im ERP. Stimmen beide überein, geht die Rechnung ohne Zwischenschritt in die Zahlungsfreigabe. Etwa achtzig Prozent laufen so durch.

Diese Quote stand in jedem Statusbericht. Sie war der Beleg dafür, dass sich das Projekt getragen hat.

Aufgefallen ist die Lücke bei einer Bestandskorrektur im Herbst. Ein Lieferant hatte über mehrere Monate Positionen abgerechnet, die er intern als Rückstand führte und nie ausgeliefert hat. Bestellung und Rechnung stimmten überein, also hat der Workflow jede dieser Rechnungen freigegeben. Was im Lager ankam, hat er nie gesehen.

Die Bestellung sagt, was Sie wollten

Der Fehler steckt nicht im Auslesen der Rechnung. Er steckt in der Wahl der Vergleichsgrundlage.

Eine Bestellung ist eine Absicht. Sie hält fest, was Sie zu welchem Preis haben wollten. Eine Rechnung ist eine Forderung. Sie hält fest, was der Lieferant abrechnen möchte. Beide Belege entstehen unabhängig davon, ob sich Ware bewegt hat.

Dazwischen liegt der Wareneingang. Er ist der einzige Beleg im Vorgang, der auf einer Beobachtung beruht: Etwas ist angekommen, in dieser Menge, an diesem Tag.

Ein Abgleich aus zwei Belegen prüft, ob der Lieferant richtig abgeschrieben hat. Mehr nicht. In der Buchhaltung heißt der vollständige Abgleich Dreiwege-Abgleich, aus Bestellung, Wareneingang und Rechnung. Der Begriff ist älter als jede Automatisierungsplattform. Der mittlere Schritt fällt trotzdem regelmäßig weg, weil er der unbequemste ist.

Warum ausgerechnet der Wareneingang fehlt

Bestellung und Rechnung liegen sauber vor. Die eine hat Ihr Einkauf erzeugt, die andere kommt als Datei ins Postfach. Beide haben eine Nummer, beide sind vollständig.

Der Wareneingang ist anders.

Er entsteht im Lager, nicht am Schreibtisch, und häufig in einem anderen System als die Bestellung. Gebucht wird zeitversetzt, manchmal am selben Tag, manchmal freitags gesammelt für die ganze Woche. Der Lieferschein liegt als Papier auf der Palette. Und eine Bestellung erzeugt selten genau einen Wareneingang, sondern drei, weil dreimal geliefert wurde.

Wer die Rechnung gegen die Bestellung hält, arbeitet mit zwei sauberen Datensätzen. Wer den Wareneingang einbezieht, arbeitet mit dem Lager. Das ist der Grund, warum dieser Schritt in Automatisierungsprojekten so oft hinten runterfällt. Technisch ist er nicht der schwierigste.

Eine Rechnung, drei Lieferungen, zwei Bestellungen

Die Zuordnung ist der zweite Grund.

Sammelrechnungen fassen Lieferungen aus mehreren Bestellungen zusammen. Teillieferungen verteilen eine Bestellung auf mehrere Rechnungen. Frachtkosten stehen als eigene Position ohne Bestellbezug darauf. Eine Gutschrift bezieht sich auf eine Rechnung, die selbst nur eine Teilmenge abgerechnet hat.

Ein Workflow, der Rechnung und Bestellung als Ganzes vergleicht, kommt damit nicht zurecht. Der Abgleich muss auf Positionsebene laufen und pro Position mitzählen, welche Menge bereits vereinnahmt und welche bereits berechnet wurde. Ohne diesen Zähler lässt sich derselbe Karton zweimal bezahlen, ohne dass ein einzelner Beleg widersprüchlich aussieht.

Toleranzen sind eine Entscheidung, keine Einstellung

Sobald der Wareneingang im Abgleich steckt, tauchen Differenzen auf, die vorher niemand gesehen hat.

Bei Meterware und bei Artikeln nach Gewicht weicht die gelieferte Menge fast immer ab. Bei der Umrechnung zwischen Verpackungseinheit und Basiseinheit entstehen Rundungsdifferenzen im Centbereich. Preise ändern sich zwischen Bestellung und Lieferung, manchmal zu Recht.

Wer die Toleranz auf null setzt, bekommt eine Ausnahmeliste, die nach zwei Wochen niemand mehr öffnet. Wer sie großzügig setzt, verschenkt bei jeder Rechnung etwas Geld. Das ist eine kaufmännische Entscheidung und gehört an einen Ort, an dem sie jemand nachlesen kann. Als Zahl in einer Filterbedingung im Workflow kann sie in einem Jahr niemand mehr erklären.

Brauchbar ist eine Toleranz in zwei Dimensionen, absolut und prozentual, und je Warengruppe unterschiedlich. Zehn Euro Abweichung bei einer Palette Handschuhe sind etwas anderes als zehn Euro bei einem Reagenz.

In der Klinik hängt daran mehr als der Betrag

Für Kliniken und für ihre Lieferanten kommt eine Schicht dazu.

Am Wareneingang werden Charge und Verfallsdatum erfasst. Nicht, weil die Buchhaltung sie braucht, sondern weil ohne sie die Rückverfolgbarkeit fehlt. Wenn der Wareneingang zu einem Häkchen wird, das jemand setzt, damit die Rechnung durchläuft, ist die Spur bei einem Rückruf genau so belastbar wie dieses Häkchen.

Eine Automatisierung, die den Wareneingang als lästige Zwischenstufe behandelt, beschädigt hier mehr als die Rechnungsprüfung.

Was wir stattdessen bauen

Keine Freigabe ohne Wareneingangsbezug. Eine Rechnungsposition ohne zugeordnete Vereinnahmung ist nicht freigegeben, sondern offen.

Drei Ergebnisse statt zwei: freigegeben, gesperrt mit Grund, ungeklärt. Der dritte Fall ist der wichtigste, weil dort die Rückstände sichtbar werden.

Abgleich auf Positionsebene mit laufenden Mengen. Bestellt, geliefert, berechnet, jeweils kumuliert über alle Belege.

Eine dokumentierte Toleranz, abgestimmt mit dem Einkauf statt mit der IT.

Ein eigener Weg für Rechnungen ohne Bestellbezug, statt sie durch dieselbe Logik zu zwingen.

Der Prüfschritt, der gefehlt hat

Bevor die Rechnungsprüfung automatisiert war, hat jemand in der Buchhaltung den Lieferschein aus dem Ordner geholt und danebengelegt. Diesen Handgriff hätte niemand als Kontrolle bezeichnet. Er stand in keiner Prozessbeschreibung.

Die Automatisierung hat ihn nicht ersetzt, sondern weggelassen. Aufgefallen ist es niemandem, weil die Durchlaufquote danach besser aussah.