FunktionenAnomalien

Anomalien

Craken prüft jeden frisch extrahierten Beleg gegen das, was der Lieferant in der Vergangenheit gemacht hat. Weicht etwas auffällig ab, wird ein Anomalie-Ereignis erzeugt und der Beleg wandert in die Nachbearbeitung.

Die Anomalie-Typen

Beschreibung jedes Typs

ReasonBeschreibungVoreinstellungWas Sie tun
duplicate_invoiceBeleg mit gleicher Belegnummer beim selben Lieferanten existiert bereitsAnPrüfen ob wirklich doppelt; ggf. den älteren verwerfen oder als Stornorechnung kennzeichnen
iban_changeLieferanten-IBAN weicht von der zuletzt verwendeten abAnWichtig: bei IBAN-Änderung Rückruf beim Lieferanten — häufig Betrugsversuch (“CEO-Fraud”)
vat_id_changeUSt-IdNr. weicht von vorhandener abAnLieferant könnte fusioniert / umfirmiert worden sein. VIES nachprüfen (Details)
currency_changeBeleg in anderer Währung als bisherAnPlausibel? Wechselkurs prüfen, falls Buchung in EUR erfolgen soll
amount_outlierBruttobetrag liegt außerhalb des erwarteten BereichsAn (σ-Modus, 3·σ)Bei großen Lieferanten oft False Positive; pro Lieferant nachjustierbar
weekend_invoiceRechnungsdatum fällt auf Samstag/SonntagAnHäufig Erinnerungs- oder Auto-Renewal-Belege. Plausibilität prüfen

Konfiguration pro Lieferant

Im Lieferanten-Drawer unter Anomalie-Prüfungen schalten Sie pro Lieferant aus oder fein:

amount_outlier: drei Modi

Für volatile Lieferanten (Stromrechnung, Lohnabrechnung) eignet sich percentage; für Pauschalverträge (Telefon, Hosting) eher absolute mit kleinen Toleranzen.

Cold-Start: Für amount_outlier braucht Craken mindestens drei vorherige Rechnungen vom selben Lieferanten — sonst sind μ/σ nicht aussagekräftig. In dieser Frühphase werden Anomalien für diesen Typ unterdrückt.

Auflösung einer Anomalie

In der Nachbearbeitungs-Spalte sehen Sie pro Beleg die Anomalie-Plakette. Klick öffnet den Auflösungs-Dialog:

Die rationale ist ein freier Text — wird im Audit gespeichert, damit beim nächsten Prüfungs-Audit ersichtlich ist, warum ein Lieferanten- IBAN-Wechsel akzeptiert wurde.

Stille Detektoren

Drei Detektoren sind konfigurierbar (Spalten in supplier_anomaly_config), aber stehen noch nicht produktiv:

  • domain_mismatch — Absender-Domain passt nicht zum Lieferanten
  • layout_drift — PDF-Layout weicht stark vom Lieferanten-Standard ab

Diese werden in den Lieferanten-Konfig-Tabellen sichtbar, schreiben aber noch keine Events. Statushinweis: „Konfiguriert, aber noch nicht aktiv”.

Hintergrund: warum Anomalien?

Klassische Buchhaltungs-Workflows verlassen sich auf den 4-Augen-Prinzip — zwei Menschen schauen jeden Beleg an. Bei mittleren Mandaten mit 1.000+ Belegen pro Monat ist das nicht skalierbar. Anomalie-Erkennung dreht die Frage um: “Was sieht heute anders aus als sonst?” — und legt nur das auf den menschlichen Tisch.