Was leistet Anomalieerkennung in Buchungsdaten im Alltag der Buchhaltung?

Anomalieerkennung in Buchungsdaten ist die laufende, automatisierte Prüfung von Buchungszeilen auf Muster, die von der gewohnten Ordnung abweichen, noch während sie im ERP-System entstehen. Statt am Monatsende eine Stichprobe aus tausenden Belegen zu ziehen, sortiert der Agent auffällige Buchungen bereits während der Erfassung vor und legt sie der Buchhaltung zur Prüfung vor, bevor der Abschluss beginnt.

Im heutigen Alltag prüft die Buchhaltung meist unter Zeitdruck kurz vor Abschlusstermin: eine Handvoll Belege wird herausgegriffen, der Rest bleibt unangesehen. Wer eine Doppelzahlung oder eine Buchung auf ein ungewöhnliches Gegenkonto findet, hat oft Glück gehabt, nicht Systematik. Die laufende Prüfung verschiebt diesen Ablauf nach vorne: Auffälligkeiten liegen als Hinweis vor, sobald sie entstehen, nicht erst bei der nachträglichen Kontrolle.

Aus der Nachschau wird damit eine Vorsortierung. Die Fachkraft entscheidet weiterhin, ob eine markierte Buchung tatsächlich ein Fehler, eine Besonderheit des Geschäftsvorfalls oder unauffällig ist. Der Agent liest die Buchungszeile, bewertet sie gegen das gelernte Normalbild und meldet die Abweichung. Freigeben oder korrigieren darf er nicht, das bleibt bei der Buchhaltung.

Warum reicht eine Stichprobe im Monatsabschluss nicht mehr aus?

Eine Stichprobe reicht nicht mehr aus, weil moderne ERP-Systeme pro Monat oft zehntausende Buchungszeilen erzeugen, während eine Prüfkraft realistisch nur einen Bruchteil davon händisch ansehen kann. Kontinuierliche Prüfung schließt diese Lücke, indem sie jede Zeile automatisiert gegen ein Normalbild abgleicht und nur die auffälligen Fälle zur menschlichen Prüfung weiterreicht.

Das Missverhältnis zwischen Datenvolumen und Prüfkapazität wächst mit jedem zusätzlichen Buchungskreis, jeder neuen Tochtergesellschaft und jedem weiteren Beleg pro Kostenstelle. Eine Stichprobe von zwei oder drei Prozent kann zwar systematische Muster ausschließen, sie übersieht aber fast immer den einzelnen Ausreißer, der wirtschaftlich relevant ist, etwa eine einzelne doppelt bezahlte Rechnung mitten in einem unauffälligen Zahlungslauf.

Continuous Auditing setzt genau hier an: Es ersetzt die punktuelle Kontrolle nicht durch eine andere Kontrolle, sondern durch eine laufende Beobachtung der Buchungsdaten, deren Ergebnis in die bestehende Prüfarbeit einfließt. Das fachliche Urteil bleibt bei der Buchhaltung und der Innenrevision, die Technik liefert nur die Vorauswahl.

Wichtig ist die Abgrenzung: Anomalieerkennung in Buchungsdaten ergänzt die Stichprobenprüfung, sie ersetzt sie nicht vollständig. Auch ein trainiertes Modell kennt nur Muster, die in der Vergangenheit vorkamen, und benötigt weiterhin eine Person, die neue Geschäftsvorfälle fachlich einordnet.

Welche Auffälligkeiten findet Anomalieerkennung in Buchungsdaten typischerweise?

Anomalieerkennung in Buchungsdaten findet typischerweise Muster, die einzeln unauffällig, im Kontext aber untypisch wirken: doppelte Zahlungen, Buchungen auf seltene Gegenkonten, nachträgliche Buchungen nach Periodenschluss oder Abweichungen zwischen konzerninternen Salden. Die Bandbreite reicht über Kreditoren, Debitoren, Intercompany und Reisekosten hinweg und deckt damit unterschiedliche Fachbereiche gleichzeitig ab.

Typische Fundstellen aus der Praxis sind:

Keine dieser Fundstellen ist für sich genommen ein Beweis für einen Fehler oder gar Betrug. Sie ist ein Hinweis, den eine Fachkraft mit Kontext aus dem Geschäftsvorfall bewerten muss. Ein Agent, der Belege liest und Muster erkennt, kann etwa bei der intelligenten Dokumentenverarbeitung auf Vorarbeiten zurückgreifen, die Beleginhalte bereits strukturiert vorliegen haben, bevor die Anomalieprüfung ansetzt.

Wie unterscheiden sich regelbasierte und lernende Verfahren?

Regelbasierte Verfahren prüfen Buchungen gegen fest hinterlegte Bedingungen wie ein Betragslimit, eine Zahlung an ein Konto ohne Stammsatz oder eine Buchung am Wochenende. Lernende und statistische Verfahren beschreiben zunächst, wie normale Buchungen aussehen, etwa über Streuung und Abstände zwischen Datenpunkten, und melden dann, was davon deutlich abweicht. Beide Ansätze ergänzen sich, sie schließen sich nicht aus.

Feste Regeln finden sich in praktisch jedem Prüfleitfaden. Sie sind nachvollziehbar und lassen sich einer Fachkraft in einem Satz erklären, kennen aber nur, was jemand zuvor niedergeschrieben hat. Ein neues Betrugsmuster, das keine der hinterlegten Grenzen verletzt, bleibt unentdeckt, bis jemand die Regel nachträgt.

Statistische Verfahren wie das Benford-Gesetz prüfen, ob die Verteilung erster Ziffern in Beträgen der erwarteten natürlichen Verteilung entspricht, ein Ansatz, der im Berufsstand der Wirtschaftsprüfung seit langem etabliert ist. Unüberwachtes Lernen geht einen Schritt weiter: Es benötigt keine vorher gelabelten Betrugsfälle, sondern gruppiert Buchungen nach Ähnlichkeit und markiert, was sich von jeder Gruppe deutlich entfernt. Das ist besonders wertvoll, weil echte Betrugsfälle in der Praxis selten in ausreichender Zahl vorliegen, um ein Modell klassisch zu trainieren.

In der Praxis kombiniert ANCUD IT beide Schichten: feste Regeln fangen die eindeutigen Fälle sofort ab, lernende Verfahren decken die diffuseren Muster auf, die keine Regel vorhersehen konnte.

Welche Daten braucht Anomalieerkennung in Buchungsdaten?

Anomalieerkennung in Buchungsdaten braucht in erster Linie das Buchungsjournal mit allen Belegzeilen, den zugehörigen Kontenplan sowie Kreditoren- und Debitorenstammdaten. Hinzu kommen, wo vorhanden, Bestell- und Wareneingangsdaten, Benutzerkennungen der Erfassenden und die verwendeten Belegarten. Ohne diese Breite an Bezugsdaten lässt sich eine Buchung nicht in ihren Kontext einordnen.

Genauso wichtig wie die Breite ist die Historie: Ein Modell kann nur erkennen, was vom Normalen abweicht, wenn es zuvor genügend unauffällige Buchungen desselben Unternehmens gesehen hat. Ein neu eingeführtes System ohne Vergangenheitsdaten hat zunächst kein verlässliches Normalbild und liefert entsprechend mehr Fehlalarme, bis genug Historie vorliegt.

Vor der eigentlichen Einführung steht deshalb eine Vorarbeit, die oft unterschätzt wird: die Prüfung der Datenqualität. Uneinheitliche Kontenzuordnungen, fehlende Belegarten oder Lücken in den Stammdaten verzerren das Normalbild, bevor überhaupt eine Anomalie gesucht wird. Diese Bestandsaufnahme gehört fachlich in den Bereich Data Engineering, das die Datenbasis so aufbereitet, dass die Anomalieprüfung darauf verlässlich arbeiten kann.

Auch personenbezogene Daten, etwa in Reisekostenbelegen mit Namen und Kostenstelle einzelner Mitarbeitender, fließen in die Buchungsdaten ein. Sie werden im Rahmen der Datenschutz-Grundverordnung nur zweckgebunden verarbeitet und nicht für andere Auswertungen weiterverwendet.

Wie lässt sich Anomalieerkennung an SAP oder DATEV anbinden?

Anomalieerkennung in Buchungsdaten lässt sich über einen regelmäßigen Export oder eine Schnittstelle an SAP oder DATEV anbinden, ohne dass eine zusätzliche Systemebene entsteht. Die Buchungsdaten bleiben in ihrem Ursprungssystem, der Agent liest sie dort aus, bewertet sie und spielt die Ergebnisse als Hinweis in die gewohnte Oberfläche oder Aufgabenliste zurück.

Für SAP-Landschaften bedeutet das meist einen Abzug aus dem Buchungsjournal, ergänzt um Stammdaten aus Kreditoren- und Debitorenbuchhaltung, der regelmäßig aktualisiert wird. Bei DATEV-Umgebungen greift der Agent auf die dort geführte Datenprüfung zurück oder ergänzt sie um zusätzliche, unternehmensspezifische Muster, die ein Standardmodul nicht vorsieht. In beiden Fällen bleibt das ERP-System die alleinige Quelle der Wahrheit für Buchungen.

Der Rücklauf ist der eigentlich entscheidende Punkt: Ein Hinweis, der in einem separaten Tool liegt, das niemand öffnet, bringt keinen Nutzen. Deshalb landen die markierten Buchungen als Aufgabe oder Kommentar dort, wo die Buchhaltung ohnehin arbeitet, etwa als Ticket im bestehenden Workflow oder als Markierung direkt im Buchungssatz. Wie ein solcher Rücklauf technisch zuverlässig funktioniert, hängt von der jeweiligen Schnittstelle ab und ist Teil der technischen Bestandsaufnahme, mit der ANCUD IT jedes Anbindungsprojekt beginnt, ähnlich wie bei der Anbindung externer Werkzeuge über Mcp Integrationen und externe Tools.

Diese Vorgehensweise vermeidet ein Risiko, das bei Zusatzsoftware häufig entsteht: eine zweite, parallele Wahrheit neben dem ERP-System, die niemand pflegt und die im Zweifel widersprüchliche Zahlen liefert.

Ist Betrugserkennung dasselbe wie Anomalieerkennung in Buchungsdaten?

Nein. Anomalieerkennung in Buchungsdaten ist eine Methode, die statistisch auffällige Buchungszeilen findet, etwa ungewöhnliche Beträge, seltene Kontenkombinationen oder Buchungen zu untypischen Zeiten. Betrug ist nur einer von vielen möglichen Erklärungen für eine solche Auffälligkeit. Häufiger stecken Tippfehler, ein neuer Lieferant ohne Stammsatz oder ein Sonderfall im Monatsabschluss hinter dem Hinweis.

Die meisten gemeldeten Auffälligkeiten sind harmlos. Eine ungewöhnlich hohe Rechnung kann eine Jahresrechnung sein, eine Buchung am Wochenende ein Nachtrag aus dem Reisekostenlauf. Wer intern kommuniziert, dass ein System Betrug erkennt, erzeugt Erwartungen und Ängste, die dem eigentlichen Zweck schaden. Richtig formuliert lautet die Aufgabe: ungewöhnliche Muster sichtbar machen, damit ein Mensch sie einordnet.

Diese Abgrenzung hat Folgen für die Kommunikation im Unternehmen. Wird ein System zur Anomalieerkennung in Buchungsdaten eingeführt, sollte die Personalvertretung von Anfang an wissen, dass es um Datenqualität und Kontrollsicherung geht, nicht um die Überwachung einzelner Mitarbeitender. Das senkt Widerstände und verhindert, dass ein technisches Werkzeug als Misstrauensinstrument wahrgenommen wird.

Verdachtsmomente, die sich aus einem Hinweis ergeben, gehören in einen geregelten Prozess, nicht in informelle Nachfragen. Ein bestehendes Hinweisgebersystem kann hier die richtige Anlaufstelle sein, wenn ein Hinweis über die reine Buchungsprüfung hinausgeht und einen Verdacht auf vorsätzliches Handeln nahelegt.

Wie viele Fehlalarme muss man einkalkulieren?

Eine feste Quote lässt sich nicht seriös nennen, sie hängt von Datenqualität, gewählten Schwellwerten und Branche ab. Realistisch ist, dass ein relevanter Anteil der gemeldeten Auffälligkeiten bei näherer Prüfung unauffällig ist. Wer das von Anfang an einplant, vermeidet Enttäuschung und legt den Fokus richtig: auf den Umgang mit Fehlalarmen, nicht auf ihre vollständige Vermeidung.

Jeder Fehlalarm bindet Zeit in der Sachbearbeitung, die den Hinweis prüfen und dokumentieren muss, warum er unbedenklich ist. Ohne Steuerung wächst diese Prüflast schneller als der Nutzen der Anomalieerkennung in Buchungsdaten. Deshalb gehört die Reduktion von Fehlalarmen von Beginn an in die Einführung, nicht erst in eine spätere Optimierungsrunde.

Wirksame Gegenmaßnahmen setzen an mehreren Stellen an. Schwellwerte lassen sich schrittweise anpassen, statt jede kleine Abweichung sofort zu melden. Eine Priorisierung nach Betragshöhe, Kontobereich oder Risikofeld sorgt dafür, dass zuerst geprüft wird, was wirklich Gewicht hat. Rückmeldungen der Prüfenden, ob ein Hinweis berechtigt war, fließen in die Bewertung der nächsten Läufe ein und schärfen die Erkennung mit der Zeit.

Zusätzlich helfen nachvollziehbare Begründungstexte zu jedem Hinweis: Welche Regel oder welches Muster hat ausgelöst, welche Werte weichen wovon ab. Das verkürzt die Prüfzeit, weil die Sachbearbeitung nicht erst rekonstruieren muss, warum eine Buchung markiert wurde, sondern direkt mit der fachlichen Einordnung beginnen kann.

Wer entscheidet, was mit einem Hinweis passiert?

Über einen Hinweis aus der Anomalieerkennung in Buchungsdaten entscheidet nie das System selbst, sondern die zuständige Fachperson im etablierten Freigabeprozess. In der Praxis prüft zunächst die Sachbearbeitung Kreditoren oder die Hauptbuchhaltung den konkreten Beleg, bei Verdacht auf schwerwiegende Abweichungen schaltet sich die interne Revision ein, in Ausnahmefällen die Geschäftsführung.

Diese Aufteilung folgt dem Vier-Augen-Prinzip und der Funktionstrennung, die in der Finanzbuchhaltung ohnehin gelten: Wer eine Buchung erfasst, prüft nicht allein den zugehörigen Hinweis, und wer einen Hinweis abschließend bewertet, ist nicht dieselbe Person, die die ursprüngliche Zahlung ausgelöst hat. Diese Trennung bleibt bei automatisierter Prüfung unverändert bestehen, sie wird durch das System eher gestützt als ersetzt.

Bei einem begründeten Verdacht greift ein definierter Eskalationsweg: von der Sachbearbeitung über die Hauptbuchhaltung zur internen Revision, bei gravierenden Fällen mit Meldung an die Geschäftsführung. Dieser Weg sollte vor der Einführung schriftlich festgelegt werden, damit im Einzelfall keine Unsicherheit über Zuständigkeiten entsteht.

Der Agent liefert den Hinweis und die dazugehörige Begründung. Entscheiden, ob eine Zahlung gestoppt oder eine Buchung korrigiert wird, darf er nicht. Diese Grenze ist bewusst gesetzt, weil Entscheidungen mit finanzieller Wirkung bei Menschen bleiben, die für ihre Einschätzung persönlich verantwortlich sind.

Wie bleibt Anomalieerkennung in Buchungsdaten nachvollziehbar und prüfungsfest?

Nachvollziehbar bleibt sie, wenn jeder Prüflauf, jeder verwendete Schwellwert, jede Bewertung eines Hinweises und die dafür zuständige Person dauerhaft protokolliert werden. Diese Protokollierung ist keine Kür, sondern ergibt sich aus den Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, kurz GoBD, die Nachvollziehbarkeit und Nachprüfbarkeit von Verarbeitungen fordern, auf denen buchhalterische Entscheidungen aufbauen.

Die Buchführungspflicht selbst ergibt sich aus dem Handelsgesetzbuch, insbesondere aus den Paragrafen 238 bis 241a HGB. Eine Anomalieerkennung in Buchungsdaten greift in diese Buchführung nicht ein, sie liefert Hinweise auf Basis vorhandener Daten. Damit dieser unterstützende Charakter im Prüfungsfall belegt werden kann, muss lückenlos dokumentiert sein, welche Version des Systems mit welchen Parametern gelaufen ist.

In der Praxis bedeutet das ein Protokoll, das zu jedem Lauf mindestens vier Angaben enthält: den Zeitpunkt und Umfang des Prüflaufs, den zu diesem Zeitpunkt gültigen Parameterstand, die Bewertung jedes einzelnen Hinweises und die Person, die diese Bewertung vorgenommen hat. Diese Protokolle sind Bestandteil der Verfahrensdokumentation und stehen bei einer Prüfung ebenso zur Verfügung wie die Buchungsdaten selbst.

Technisch lässt sich diese Protokollierung mit vorhandenen Werkzeugen abbilden, etwa über eine durchsuchbare Ablage von Prüfläufen, wie sie auch für andere Auswertungen mit Elasticsearch üblich ist. Wichtig ist, dass die Ablage lückenlos und unveränderbar ist, nicht welches Werkzeug im Hintergrund läuft.

Wie ordnen Wirtschaftsprüfer und interne Revision solche Analysen ein?

Sie ordnen sie als Erweiterung eines etablierten Verfahrens ein, das in der Abschlussprüfung unter dem Begriff Journal Entry Testing bekannt ist: die systematische Prüfung von Buchungszeilen auf Auffälligkeiten. Datenanalysen dieser Art gehören seit Jahren zum Handwerkszeug der Prüfungspraxis, statistische Auffälligkeitsprüfungen etwa nach dem Benford-Gesetz werden im Berufsstand schon lange verwendet.

Anomalieerkennung in Buchungsdaten ersetzt die Stichprobenprüfung nicht vollständig, sie verändert aber deren Ausgangspunkt. Statt eine zufällige oder risikoorientierte Stichprobe aus der Gesamtheit zu ziehen, liegt bereits eine Vorauswahl risikobehafteter Buchungen vor, auf die sich die Prüfung konzentrieren kann. Das verändert die Prüfungstiefe, nicht die Prüfungspflicht selbst.

Entscheidend ist das Zusammenspiel mit dem internen Kontrollsystem. Eine Auffälligkeit, die von der Anomalieerkennung gemeldet wird, ersetzt keine funktionierende Freigabe- und Kontrollstruktur, sie ergänzt sie um eine zusätzliche, datengestützte Perspektive. Wo Kontrollen im Unternehmen bereits sauber dokumentiert sind, lässt sich die automatisierte Auffälligkeitsprüfung daran andocken, ohne bestehende Abläufe umzubauen.

Für die interne Revision bedeutet das vor allem eines: mehr Transparenz über Muster, die bei rein manueller Stichprobe unentdeckt geblieben wären, bei gleichbleibender Verantwortung für die fachliche Bewertung jedes Einzelfalls.

Was bedeutet der Datenschutz bei Anomalieerkennung in Buchungsdaten?

Buchungsdaten enthalten häufig personenbezogene Angaben, etwa Erfasserkennungen oder Reisekostenbelege einzelner Mitarbeitender. Sobald diese Daten für die Anomalieerkennung in Buchungsdaten ausgewertet werden, greift die Datenschutz-Grundverordnung, weil personenbezogene Daten zu einem bestimmten, dokumentierten Zweck verarbeitet werden. Diese Zweckbindung muss vor der Einführung klar formuliert sein: Prüfung von Buchungsmustern, nicht Bewertung einzelner Personen.

Wer im Unternehmen einen Hinweis sehen darf, sollte über Rollenrechte geregelt sein. Die Sachbearbeitung sieht in der Regel nur Hinweise aus ihrem Zuständigkeitsbereich, die interne Revision einen breiteren Ausschnitt, ohne dass jede Person im Buchhaltungsteam Zugriff auf sämtliche Auffälligkeiten der gesamten Abteilung hat. Diese Abstufung verhindert, dass ein Prüfwerkzeug zu einem allgemeinen Überwachungsinstrument wird.

Weil die Auswertung von Erfasserkennungen mittelbar Rückschlüsse auf Arbeitsverhalten zulassen kann, gehört die Mitbestimmung frühzeitig in die Einführung. In vielen Betrieben ist das eine Frage der Betriebsvereinbarung, nicht der IT-Konfiguration allein. Wird dieser Schritt übersprungen, drohen spätere Konflikte, die sich mit rechtzeitiger Beteiligung vermeiden lassen.

Diese Sorgfalt ist keine Formalität, sie schafft Vertrauen in ein System, das Kontrollqualität verbessern soll, ohne einzelne Mitarbeitende unter Generalverdacht zu stellen.

Wie sieht ein realistischer Pilot für Anomalieerkennung in Buchungsdaten aus?

Ein realistischer Pilot beschränkt sich auf einen Buchungskreis und einen abgeschlossenen Zeitraum von meist zwei bis vier Quartalen. Die Anomalieerkennung in Buchungsdaten läuft dabei nicht live, sondern als Rückschau: Bekannte, bereits geklärte Auffälligkeiten aus dieser Periode dienen als Testfälle, an denen sich prüfen lässt, ob das System sie erkannt hätte und wie viele zusätzliche Hinweise es ohne Vorwissen liefert.

Die Fachabteilung kennt aus abgeschlossenen Perioden meist mehrere Fälle, die im Nachhinein als Fehlbuchung, Doppelzahlung oder Abgrenzungsfehler bewertet wurden. Diese Fälle bilden den Maßstab: Ein Pilot, der sie zuverlässig markiert und gleichzeitig nicht Hunderte plausibler Buchungen als auffällig einstuft, hat seine Aufgabe erfüllt. Ein Pilot, der beides verfehlt, zeigt das vor der Investition in einen Wirkbetrieb.

Vor dem Start werden Abnahmekriterien schriftlich festgehalten: welcher Anteil der bekannten Fälle mindestens gefunden werden muss, wie viele zusätzliche Hinweise pro Woche als vertretbar gelten und wer die Bewertung der Ergebnisse übernimmt. Diese Kriterien verhindern, dass ein Pilot am Ende nach Gefühl statt nach vereinbarten Maßstäben beurteilt wird.

Für die technische Anbindung wird geprüft, welche Datenexporte aus SAP oder DATEV bereits bestehen und ob sie für den gewählten Zeitraum vollständig sind. Bestehende Auswertungen und Prüfroutinen aus der Qualitätssicherung bleiben dabei Ausgangspunkt, nicht Ersatz für eine neue, parallel aufgebaute Landschaft.

Woran erkennt man, dass Anomalieerkennung in Buchungsdaten wirkt?

Wirkung zeigt sich nicht an einer Kennzahl allein, sondern an mehreren beobachtbaren Veränderungen: Ein wachsender Anteil der gemeldeten Hinweise wird tatsächlich bewertet statt liegen gelassen, die Zeit von der Meldung bis zur Klärung sinkt, nachträgliche Korrekturbuchungen werden seltener, und jeder Prüfschritt lässt sich im Nachhinein nachvollziehen. Ohne belegte Zahlen bleibt jede genaue Prozentangabe hier Spekulation.

Ein erstes Anzeichen ist die Bearbeitungsquote: Werden die Hinweise der Anomalieerkennung in Buchungsdaten tatsächlich von der Buchhaltung durchgesehen und kommentiert, oder sammeln sie sich unbearbeitet in einer Warteschlange? Eine sinkende Zahl offener, unbearbeiteter Hinweise deutet darauf, dass das System in den Arbeitsalltag eingebunden ist statt daneben zu laufen.

Ein zweites Anzeichen ist die Zeit bis zur Klärung eines Falls. Wenn ein Hinweis zur Rechnungsprüfung oder zu einer auffälligen Kontenbewegung schneller einer eindeutigen Erklärung zugeordnet wird als vorher bei manueller Stichprobenprüfung, spricht das für eine sinnvolle Vorfilterung. Ein drittes Anzeichen sind seltenere nachträgliche Korrekturen nach Periodenabschluss, weil Auffälligkeiten früher auffallen.

Am wichtigsten für Revision und Wirtschaftsprüfung ist ein viertes Merkmal: dokumentierte Prüfwege. Jeder Hinweis, jede Bewertung und jede Entscheidung, warum eine Buchung als unauffällig eingestuft wurde, muss sich im Nachhinein rekonstruieren lassen. Ohne diese Protokollierung bleibt jede vermeintliche Wirkung unbelegt.

Was kostet Anomalieerkennung in Buchungsdaten?

Pauschale Preise lassen sich für Anomalieerkennung in Buchungsdaten seriös nicht nennen, weil Zahl der Buchungskreise, Datenqualität, Schnittstellenlage, Betriebsmodell und Betreuungsaufwand die Kosten sehr unterschiedlich beeinflussen. Belastbare Aussagen entstehen erst nach einer technischen Bestandsaufnahme der vorhandenen Systeme und Daten.

Ein Unternehmen mit einem einzigen Buchungskreis und sauber strukturierten SAP-Exporten hat einen anderen Aufwand als ein Konzern mit zehn Gesellschaften, unterschiedlichen Kontenplänen und mehreren ERP-Systemen nebeneinander. Auch die Frage, ob die Lösung im eigenen Rechenzentrum, in einer bestehenden Cloud-Umgebung oder als betreuter Betrieb läuft, wirkt sich auf laufende Kosten stärker aus als auf die Einführung selbst.

Ein oft unterschätzter Faktor ist der Betreuungsaufwand nach dem Start: Wer pflegt Regeln und Schwellwerte, wer reagiert auf neue Buchungskreise oder geänderte Kontenpläne, und wie viel davon übernimmt der Betrieb aus dem IT Service Management. Diese Faktoren fasst die folgende Übersicht zusammen.

Wie lange dauert die Einführung von Anomalieerkennung in Buchungsdaten?

Ein realistischer Zeitrahmen für die Einführung von Anomalieerkennung in Buchungsdaten liegt je nach Ausgangslage bei mehreren Monaten, verteilt auf fünf Phasen: Datenzugang, Aufbau eines Normalbildes, Kalibrierung, Parallelbetrieb und Übergabe. Feste Zusagen sind ohne Kenntnis der Systemlandschaft nicht seriös, da Freigaben und Datenexporte oft außerhalb des Projekts liegen.

Die erste Phase, der Datenzugang, hängt stark von internen Freigaben ab: Wer darf Exporte aus SAP oder DATEV bereitstellen, und in welcher Form liegen historische Buchungsdaten vor. Diese Phase dauert oft länger als die eigentliche technische Arbeit, weil sie von Terminen in der IT-Abteilung und der Revision abhängt, nicht vom Projektteam allein.

In der zweiten Phase entsteht aus historischen, abgeschlossenen Perioden ein Normalbild der üblichen Buchungsmuster. Die dritte Phase kalibriert Schwellwerte anhand bekannter Fälle, damit weder zu viele noch zu wenige Hinweise entstehen. Im Parallelbetrieb läuft das System neben der bestehenden Prüfpraxis, bevor die Übergabe in den Regelbetrieb erfolgt.

Jede Phase kann sich verlängern, wenn Datenexporte nachgebessert werden müssen oder zusätzliche Buchungskreise aufgenommen werden. Ein transparenter Zeitplan macht diese Abhängigkeiten sichtbar, statt sie zu verschweigen.

Welche Rolle spielt der Betrieb nach dem Start?

Nach dem Start beginnt die eigentliche Daueraufgabe: Regeln und Modelle müssen gepflegt werden, weil sich Kontenpläne ändern, neue Gesellschaften hinzukommen und sich Geschäftsvorfälle verschieben. Ohne diese Pflege veraltet das Normalbild, und die Anomalieerkennung in Buchungsdaten meldet entweder zu viele belanglose Fälle oder übersieht neue Muster.

Ein geänderter Kontenplan, etwa durch eine Umstrukturierung oder eine neue Gesellschaft nach einer Akquisition, verändert die Datenbasis, auf der das System sein Normalbild gebildet hat. Solche Änderungen müssen dem Betrieb gemeldet werden, damit Schwellwerte und Regeln nachjustiert werden, statt stillschweigend an Genauigkeit zu verlieren.

Auch die Prüfläufe selbst brauchen Überwachung: Läuft die Auswertung planmäßig, liefert sie vollständige Daten, und werden Fehler im Datenexport erkannt, bevor sie sich als scheinbare Anomalien zeigen. Diese technische Überwachung ist eine andere Aufgabe als die fachliche Bewertung der Hinweise und gehört organisatorisch häufig zum laufenden Betrieb aus dem Problem Management.

Wer im Unternehmen für diese Aufgaben zuständig ist, sollte von Anfang an feststehen: IT-Betrieb für die technische Überwachung, Fachbereich für die inhaltliche Bewertung der Schwellwerte. Ohne klare Zuständigkeit bleibt die Pflege liegen, bis das System an Aussagekraft verliert.

Wie fängt man mit Anomalieerkennung in Buchungsdaten an?

Der erste Schritt ist eine Bestandsaufnahme, kein Werkzeugkauf: Welche Buchungskreise gibt es, welche Daten stehen in welcher Qualität zur Verfügung, welche Prüfroutinen laufen bereits, und wer ist für Freigaben und Bewertung zuständig. Erst danach lässt sich beurteilen, ob und wie Anomalieerkennung in Buchungsdaten sinnvoll eingeführt wird.

Diese Bestandsaufnahme klärt konkrete Fragen: Liegen Exporte aus SAP oder DATEV bereits strukturiert vor oder müssen sie erst aufgebaut werden. Gibt es aus abgeschlossenen Perioden bekannte Fälle, die als Testmaßstab dienen können. Und welche Rollen in Buchhaltung, Revision und IT sollen künftig Hinweise bewerten und Schwellwerte pflegen.

Aus dieser Klärung entsteht eine belastbare Grundlage für einen begrenzten Piloten statt eines pauschalen Projektauftrags. Wer diesen Schritt überspringt und direkt ein System beschafft, riskiert eine Lösung, die an der eigenen Datenlage vorbeigeht. Die Empfehlung lautet deshalb, mit dieser Bestandsaufnahme zu beginnen und danach über Umfang und Zeitplan zu entscheiden.