Zum Inhalt springen
AiGENCY
Blog

Belegautomation mit DATEV: wie der Ablauf in der Praxis aussieht

Belegerfassung ist der Prozess, den fast jeder Betrieb hat und fast niemand gern zeigt. Er läuft, er kostet, und niemand kann auf Anhieb sagen wie viel. Deshalb zuerst die Rechnung, dann der Ablauf, dann die Stelle, an der fertige Tools regelmäßig scheitern.

4 Min. LesezeitMark Simon

Wo die 13 Stunden pro Woche hingehen

Rechnen wir mit einem Betrieb, bei dem täglich 40 Belege eingehen: Eingangsrechnungen, Lieferscheine, Auftragsbestätigungen. Pro Beleg vergehen im Schnitt vier Minuten mit Handarbeit: öffnen, Lieferant erkennen, Nummer und Datum abtippen, Positionen prüfen, gegen die Bestellung halten, Konto und Steuersatz setzen, ablegen. Das sind 160 Minuten am Tag und damit gut 13 Stunden pro Woche, in denen jemand ausschließlich Daten von einem Medium ins andere überträgt.

Vier Minuten klingen nach wenig, und genau das ist das Problem. Kein einzelner Beleg rechtfertigt eine Diskussion. Die Summe schon: 13 Stunden pro Woche sind über ein Jahr gerechnet mehr als ein Drittel einer Vollzeitstelle, verteilt auf zwei bis vier Personen, die eigentlich für etwas anderes eingestellt wurden. Diese Verteilung ist der Grund, warum der Posten in keiner Kostenstelle auftaucht.

Bevor irgendetwas gebaut wird, wird diese Zahl im konkreten Betrieb erhoben. Nicht geschätzt, sondern gezählt: wie viele Belege pro Tag, wie lange dauert ein Durchlauf tatsächlich, wie oft kommt ein Fall vor, der Rückfragen braucht. Ohne diese Basis lässt sich hinterher nicht sagen, ob sich etwas verbessert hat.

Was der Workflow Schritt für Schritt macht

Der Beleg kommt per Mail, Scan oder Upload herein und löst den Workflow aus. Im ersten Schritt wird ausgelesen: Lieferant, Belegnummer, Datum, die einzelnen Positionen, Netto, Steuersatz und Brutto. Das ist mehr als Zeichenerkennung. Klassische OCR liest, dass irgendwo die Zahl 1.190,00 steht. Was gebraucht wird, ist die Information, dass es sich dabei um den Bruttobetrag handelt und nicht um eine Positionssumme.

Im zweiten Schritt folgt der Abgleich. Passt der Beleg zu einer offenen Bestellung, stimmen Menge und Preis mit dem überein, was bestellt wurde, ist die ausgewiesene Umsatzsteuer plausibel. Erst danach kommt der dritte Schritt: die Übergabe an DATEV oder das vorhandene Buchhaltungssystem, mit Konto und Steuersatz, sodass der Vorgang gebucht ankommt und nicht als Datei in einem Eingangsordner liegen bleibt.

Parallel dazu läuft der Fehlerpfad. Was passiert, wenn der Scan unlesbar ist, wenn eine Artikelnummer nicht existiert, wenn DATEV nicht antwortet. Jeder dieser Fälle hat eine definierte Reaktion: markieren, benachrichtigen, erneut versuchen. Ein Belegworkflow ohne Fehlerpfad produziert stille Lücken in der Buchhaltung, und die fallen erst beim Jahresabschluss auf.

Ein Detail, das im Alltag mehr Zeit spart als die Erkennung selbst: der Workflow schreibt nicht nur das Ergebnis, sondern auch den Weg dorthin mit. Zu jedem gebuchten Beleg ist nachvollziehbar, gegen welche Bestellung abgeglichen wurde, welche Regel gegriffen hat und wann das passiert ist. Wer im Nachhinein eine Buchung erklären muss, sucht damit Minuten statt Stunden, und bei einer Prüfung ist genau diese Nachvollziehbarkeit die Frage, die gestellt wird.

Warum fertige OCR-Tools an Sonderfällen scheitern

Am Markt gibt es funktionierende Standardlösungen. Buchhaltungs-Suiten mit eingebauter Erfassung, spezialisierte OCR-Anbieter, Erkennungsdienste mit hoher Trefferquote auf normierten Rechnungen. Solange die Belege dem Standard entsprechen und der eigene Kontenrahmen zum Modell des Anbieters passt, ist das der schnellere Weg, und ich sage das im Audit auch so.

Der Standard endet an drei Stellen. Erstens bei branchenspezifischen Positionen: Positionen mit Zuschlägen, Gebindegrößen oder Umrechnungen, die im Modell des Anbieters nicht vorgesehen sind. Zweitens bei abweichenden Lieferantenformaten, wenn ein wichtiger Lieferant seit Jahren ein Layout schickt, das kein Standardmodell kennt. Drittens bei eigener Freigabelogik, wenn ab bestimmten Beträgen jemand zeichnen muss, der im Tool gar nicht vorgesehen ist.

An diesen drei Stellen fängt die Handarbeit wieder an, und zwar an genau den Belegen, die am meisten Zeit kosten. Deshalb baue ich Belegautomation als eigenen Workflow: die Feldlogik wird an das vorhandene System angepasst statt umgekehrt, und die Sonderfälle sind Teil der Konstruktion statt ihr Ausnahmefall. Kosten pro Beleg fallen dabei nicht an, es gibt die einmalige Setup-Fee und den Betrieb.

Was bewusst beim Menschen bleibt

Ein realistischer Wert aus laufenden Projekten sind 80 bis 90 Prozent Durchlaufquote: so viele Belege gehen von der Erfassung bis zur Buchung durch, ohne dass jemand sie anfasst. Der Rest wird markiert und einer Person zur Prüfung vorgelegt. Diese Trennung ist der eigentliche Punkt der Konstruktion, nicht ein Zugeständnis an unfertige Technik.

Markiert wird alles, wofür es keine eindeutige Regel gibt: Beträge, die von der Bestellung abweichen, Lieferanten ohne hinterlegte Zuordnung, Positionen ohne Match, unplausible Steuersätze. Der Workflow rät nicht. Ein System, das im Zweifel eine Buchung erfindet, ist schlimmer als eines, das nachfragt, weil der Fehler dann in den Zahlen steht und nicht in einer Aufgabenliste.

Wer 100 Prozent verspricht, hat die Sonderfälle nicht durchgerechnet. Und selbst wenn es technisch ginge, wäre es die falsche Zielgröße: die 13 Stunden pro Woche entstehen nicht durch die schwierigen Belege, sondern durch die vielen einfachen. Genau die holt der Workflow raus. Die Handvoll Fälle, die Erfahrung brauchen, bleiben bei den Leuten, die diese Erfahrung haben.

Darf ich messen, wie die Seite genutzt wird?

Mit PostHog sehe ich, welche Seiten gelesen werden und wo jemand abspringt, auch als Aufzeichnung von Klicks, Mausbewegungen und Scrollen. Dafür speichert PostHog eine Kennung in deinem Browser. Das passiert nur, wenn du zustimmst. Ohne Zustimmung funktioniert die Seite genauso.

Details in der Datenschutzerklärung