Gegenkonto automatisch finden: SKR03/SKR04 mit KI statt Bauchgefühl
Fragen Sie drei Buchhalter, auf welches Konto eine Rechnung für Druckerpapier gehört, und Sie bekommen zwei Antworten: 4930 Bürobedarf oder 4980 sonstiger Betriebsbedarf. Beide sind fachlich vertretbar, und genau deshalb ist „das richtige Gegenkonto“ keine Eigenschaft der Rechnung, sondern eine Konvention des Unternehmens. Ein System, das Gegenkonten automatisch ermitteln soll, muss also nicht schlauer sein als ein Buchhalter — es muss die Konvention dieses Mandanten kennen und darf sie nicht überstimmen.
1. Warum es kein objektiv richtiges Gegenkonto gibt
Der Standardkontenrahmen ist ein Vorschlag, keine Vorschrift. Innerhalb der handelsrechtlichen und steuerlichen Grenzen darf ein Unternehmen frei entscheiden, wie fein es seine Aufwände gliedert. Ein Betrieb führt Werkzeug, Kleingeräte und Verbrauchsmaterial getrennt, der nächste buchte alles drei auf ein Sammelkonto. Beides ist zulässig.
Für die Automatisierung ist das eine wichtige Einsicht, weil sie die Aufgabe verändert. Die Frage ist nicht: „Welches Konto ist fachlich korrekt?“ Die Frage ist: „Welches Konto hätte die Buchhaltung dieses Mandanten genommen?“ Das erste ist eine Wissensfrage, die zweite eine Frage nach Daten. Systeme, die nur das erste beantworten, produzieren Vorschläge, die fachlich verteidigbar und im Betrieb trotzdem falsch sind — und jede Korrektur kostet mehr Zeit als eine leere Zeile.
2. SKR03 und SKR04: dieselben Aufwände, andere Nummern
SKR03 ist nach Prozessen gegliedert — Wareneingang, Kosten, Erlöse. SKR04 folgt der Bilanz- und GuV-Struktur. Fachlich beschreiben beide dieselben Sachverhalte, die Nummern haben aber nichts miteinander zu tun. Ein Auszug der Konten, die im Rechnungseingang am häufigsten vorkommen (Standardbelegung):
| Aufwand / Sachverhalt | SKR03 | SKR04 | Anmerkung für die Automatik |
|---|---|---|---|
| Bürobedarf | 4930 | 6815 | Der Klassiker — und der häufigste Streitfall gegen „sonstiger Betriebsbedarf“. |
| Werbekosten | 4600 | 6600 | Agenturen, Anzeigen, Online-Werbung. Oft eine eigene Anweisung wert. |
| Telefon | 4920 | 6805 | Stabil, monatlich, ideal für die gelernte Hauskontierung. |
| Miete unbewegliche Wirtschaftsgüter | 4210 | 6310 | Regelmäßig, gleicher Betrag — läuft nach dem ersten Beleg von allein. |
| Laufende Kfz-Betriebskosten | 4530 | 6530 | Tankstellen sind Mischkreditoren: Diesel, Wagenwäsche, Snacks. |
| Sonstiger Betriebsbedarf | 4980 | 6850 | Das Sammelkonto. Wenn es zu oft gewinnt, fehlt eine Festlegung. |
| Verbindlichkeiten aus Lieferungen und Leistungen | 1600 | 3300 | Das Sammelkonto hinter den Kreditoren — kein Gegenkonto für Aufwand. |
| Abziehbare Vorsteuer 19 % | 1576 | 1406 | Wird bei Automatikkonten gar nicht gebucht, sondern über die Kontenfunktion. |
Zwei Dinge folgen daraus. Erstens: Der Kontenrahmen ist eine Eigenschaft des Mandanten, nicht der Software. Er steht auch im DATEV-Export im Header-Feld „Sachkontenrahmen“ — mehr dazu im Artikel zum EXTF-Buchungsstapel. Zweitens: Kontierungswissen ist nicht zwischen Mandanten mit unterschiedlichem Rahmen übertragbar. „Werbeagentur → 4600“ hilft einem SKR04-Mandanten nicht; dort heißt es 6600.
Und die Nummern selbst sind nicht der ganze Kontext. Ein Konto kann in der Belegung dieses Mandanten ein Automatikkonto sein, das seine Umsatzsteuer über die Kontenfunktion mitbringt. Dann darf kein BU-Schlüssel gesetzt werden. Diese Eigenschaft gehört zur Kontenliste, nicht zur Zahl — eine Kontierung, die sie nicht mitführt, produziert Zeilen, die beim Import auffallen.
3. Die Historie als Prior — die stärkste Informationsquelle
Nehmen Sie einen realen Kreditor und zählen Sie, auf welche Konten er im vergangenen Jahr gebucht wurde. Für die meisten Lieferanten sieht das Ergebnis so aus:
Kreditor 70023 Böttcher AG 50 Belege 4930 Bürobedarf 47 ██████████████████████ 4980 Sonst. Betriebsbedarf 2 █ 0480 GWG (Drucker, 412 EUR) 1 ▌ → Hauskontierung: 4930 (94 %)
Das ist ein Prior im wörtlichen Sinn: eine Vorannahme mit Gewicht, bevor überhaupt jemand den Beleginhalt liest. Sie ist deshalb so stark, weil sie aus genau der Quelle stammt, die für die Frage zuständig ist — aus den Entscheidungen dieser Buchhaltung.
Aus der Verteilung liest man mehr als nur den Spitzenwert. Die zwei Ausreißer auf 4980 sind Rauschen; die eine Buchung auf ein GWG-Sammelkonto ist ein Signal, dass dieser Lieferant gelegentlich aktivierungspflichtige Gegenstände liefert und seine Belege einen zweiten Blick auf den Betrag verdienen. Eine Verteilung wie 26 zu 24 auf zwei Konten wäre etwas anderes: Dieser Kreditor hat keine Hauskontierung, er ist ein Mischkreditor und gehört bewusst in den Review.
4. Die Kontenliste als Enum: warum das Halluzinationen verhindert
Bleibt der Fall ohne Historie. Hier ist ein Sprachmodell tatsächlich nützlich: Es kann aus „Toner HP 216A schwarz, 4 Stück“ auf Bürobedarf schließen, ohne dass jemand eine Regel dafür geschrieben hat. Nur darf es dabei kein Konto erfinden.
Die naive Umsetzung bittet im Prompt: „Antworte mit einem Konto aus der folgenden Liste.“ Das funktioniert meistens und scheitert gelegentlich — und die Fehlerfälle sind die unangenehmsten, weil sie plausibel aussehen. Ein Modell, das 4855 vorschlägt, während dieser Mandant 0480 für geringwertige Wirtschaftsgüter führt, liefert eine Zahl, die im SKR03 existiert und in dieser Buchhaltung nicht.
Die belastbare Umsetzung macht daraus eine strukturelle Bedingung. Im Antwortschema ist gegenkonto kein String, sondern ein Enum über die Kontonummern dieses Mandanten:
{
"type": "object",
"properties": {
"gegenkonto": { "enum": ["0480","1576","4210","4600","4920","4930","4980", …] },
"buSchluessel": { "type": ["string","null"] },
"begruendung": { "type": "string" },
"konfidenz": { "type": "number", "minimum": 0, "maximum": 1 }
},
"required": ["gegenkonto", "begruendung", "konfidenz"]
}Der Unterschied ist grundsätzlich: Ein Prompt ist eine Bitte, ein Enum eine Bedingung. Ein Wert außerhalb der Liste ist keine schlechte Antwort, sondern strukturell keine Antwort.
Und weil ein Schema eine Zusage des Anbieters ist und kein Beweis — abgeschnittene Antworten, Fallback-Modelle, Bibliotheksfehler kommen vor — steht dahinter noch ein deterministischer Check: Ist das zurückgegebene Konto tatsächlich in der Gegenkontenliste des Mandanten? Fällt er durch, entsteht kein Buchungssatz, sondern ein Review-Eintrag. Ein erfundenes Konto erreicht damit nie einen Buchungsstapel.
5. Drei Schichten in fester Reihenfolge
Festlegung des Mandanten, Kreditor-Default, Modell — in dieser Reihenfolge, von der stärksten zur schwächsten Aussage:
| Schicht | Woher | Confidence | Begründung |
|---|---|---|---|
| (a) Regeln und Anweisungen | Strukturierte Regeln (Bedingung → Konto) und Freitext-Anweisungen, die der Mandant selbst hinterlegt — beides in der Oberfläche anlegbar und über die REST-API | 0,95 (strukturierte Regel) | Eine ausdrückliche Festlegung geht allem anderen vor, sonst wäre die Möglichkeit zum Nachschärfen wertlos. Nicht 1,0, weil die Bedingung einer Regel („Belegtext enthält …“) auch zufällig zutreffen kann. Eine Freitext-Anweisung trägt keine eigene Confidence: Sie ändert die Frage an das Modell, wirkt damit innerhalb von (c) und schaltet die Abkürzung in (b) ab. Eine Regel dagegen entscheidet ohne Modell — und eine Anweisung entwertet sie nicht. |
| (b) Kreditor-Default | Stammdaten-Import oder zwei bestätigte Korrekturen | 0,90 | Die Hauskontierung dieses Lieferanten. Greift sie, wird kein Modell befragt — das ist der Hebel für Kosten und Stabilität gleichzeitig. |
| (c) Sprachmodell | Rechnungsinhalt gegen die Kontenliste | höchstens 0,84 | Nur wenn (a) und (b) nichts hergeben. Die Auswahl ist ein Enum über die Kontenliste; das Ergebnis geht immer einmal durch den Review. Freitext-Anweisungen wirken hier — also ebenfalls unter dem Deckel. |
Ein Detail an dieser Reihenfolge ist nicht offensichtlich: Sobald eine Freitext-Anweisung des Mandanten im Spiel ist, darf die Abkürzung über das Kreditor-Default nicht mehr stillschweigend gewinnen. Denn genau das könnte die Anweisung ja umstoßen wollen — „ab Juli laufen die Agenturrechnungen nicht mehr auf 4980, sondern auf 4600“ wäre wirkungslos, wenn das gelernte Default weiter durchgreift.
Eine Regel schaltet eine Anweisung dagegen nicht ab — und umgekehrt auch nicht. Das Kreditor-Default ist ein Erfahrungswert, den eine Anweisung korrigieren können soll; eine Regel ist eine ausdrückliche Festlegung desselben Mandanten. Würde die schwächere Festlegung (Freitext, wirkt über das Modell, immer Review) die stärkere aushebeln (deterministisch, auto-fähig), könnte eine vergessene Anweisung stillschweigend alle Regeln entwerten und aus jedem auto-fähigen Beleg einen Prüffall machen.
Der Unterschied in der Confidence hat ebenfalls einen konkreten Grund. Strukturierte Regel (0,95) und Kreditor-Default (0,90) liegen über der Auto-Schwelle von 0,85 und dürfen ohne Rückfrage buchen: Beide entstehen aus Mandantendaten und sind vom Inhalt eines eingehenden Belegs nicht beeinflussbar. Ein Modellvorschlag ist bewusst darunter gedeckelt — Positionstexte und Notizen einer Rechnung stehen wörtlich im Prompt, und wer den Beleg schreibt, könnte darin Anweisungen unterbringen. Ein Review, den ein präparierter Beleg abschalten kann, ist kein Review.
6. Regeln und Anweisungen: wenn die Historie nichts weiß
Es gibt Konventionen, die in keiner Historie stehen, weil sie neu sind oder weil sie nicht am Kreditor hängen. Dafür gibt es zwei Werkzeuge, und der Unterschied zwischen ihnen entscheidet, ob Arbeit wegfällt oder nur leichter wird.
Strukturierte Regeln (deterministisch, auto-fähig)
Bedingung und Ergebnis, deterministisch auswertbar, ohne Modell. Die Bedingung ist eine Kombination aus Kreditor und Begriffen im Belegtext, das Ergebnis ein Gegenkonto und wahlweise ein BU-Schlüssel:
- Belegtext enthält „Reinigung“ → 4250 (SKR03) statt Sammelkonto
- Kreditor 70088 und Belegtext enthält „Porto“ → 4910
- Belegtext enthält „Bewirtung“ → 4650 mit dem passenden BU-Schlüssel
Solche Regeln sind reproduzierbar und billig, und weil sie aus Mandantendaten stammen, dürfen sie mit 0,95 automatisch buchen. Angelegt werden sie auf der Seite „Regeln und Anweisungen“ des Mandanten, über die REST-API — oder, und das ist der Weg, der im Alltag zählt, direkt aus einer Korrektur im Review: Wer dort das Gegenkonto ändert, bekommt danach das Angebot „diesen Kreditor künftig immer auf dieses Konto“ beziehungsweise „Belege mit diesem Text immer auf dieses Konto“. Das ist der Moment, in dem die Entscheidung ohnehin gefallen ist.
Angelegt wird dabei nie etwas von selbst, und das ist bewusst so: Eine Regel, die stillschweigend aus einer Korrektur entstünde, wäre Monate später eine unerklärliche Automatik — der Nutzer erinnert sich an eine Korrektur, nicht an eine Festlegung. Deshalb steht die Konsequenz im Angebot („künftige Belege dieses Kreditors werden dann ohne Prüfung gebucht“), und es braucht einen Klick.
Passen mehrere Regeln auf einen Beleg, ist die Auswahl festgelegt: Die spezifischere gewinnt (Kreditor und Belegtext > nur Kreditor > nur Belegtext), bei Gleichstand die ältere. Diese Ordnung ist die, die ein Mensch unterstellt — wer eine Ausnahme anlegt, muss die allgemeine Regel nicht löschen, damit die Ausnahme greift. Und in der Prüfansicht steht bei jeder Zeile, welche Regel entschieden hat und welche Bedingung gegriffen hat; „welche Regel hat gewonnen“ ist die Frage, die ein Buchhalter stellt, wenn ihn ein Ergebnis überrascht.
Was die Regeln nicht können, gehört genauso dazu: Es gibt keine Betragsgrenzen, keine Datumsbedingungen, keine Verknüpfung mehrerer Begriffe mit „und“. Die Bedingung ist ein Kreditor, eine Liste von Begriffen — von denen einer treffen muss — oder beides. Alles darüber wäre eine Regelsprache, und eine Regelsprache, die auch den nächsten Sonderfall ausdrücken kann, ist eine Programmiersprache.
Freitext-Anweisungen je Mandant (immer mit Review)
Sätze in normalem Deutsch, die in den Kontierungsprompt eingebettet werden — für alles, was sich nicht in Bedingung-und-Ergebnis fassen lässt:
Bei Reisekostenabrechnungen ist der Kreditor die Person auf Seite 1, nicht das abrechnende Hotel. Rechnungen unserer Konzernschwester (USt-IdNr. DE812…) laufen immer über das Verrechnungskonto, nie über Aufwand. Handwerkerrechnungen für Objekt Nord bekommen KOST1 = NORD.
Anweisungen sind ausdrucksstärker und weicher: Sie wirken über das Modell, also nicht garantiert. Dafür fangen sie genau die Fälle, an denen strukturierte Regeln scheitern. Und sie erben den Deckel der Modell-Schicht: Ein Buchungssatz, der einer Anweisung folgt, liegt bei höchstens 0,84 und geht damit immer einmal durch den Review — eine Anweisung bucht somit nie von sich aus automatisch. Der Weg zur Automatik führt über die Bestätigung: Ab der zweiten gleichen Bestätigung wird daraus die Hauskontierung des Kreditors, und die greift mit 0,90 ohne Rückfrage.
Die Mischung ist die Antwort — Regeln für das Wiederkehrende, Anweisungen für das Eigenartige. Beide werden auf derselben Seite verwaltet, und zwar aus einem Grund: Die Frage lautet nicht „wo verwalte ich Regeln“, sondern „wie schreibe ich fest, dass diese Rechnungen auf 4930 gehen“. Die Antwort darauf ist ein Vergleich, und ein Vergleich braucht beide Hälften nebeneinander.
7. Mischkreditoren: der Grenzfall, den niemand wegautomatisiert
Amazon. Der Baumarkt an der Ecke. Die Tankstelle. Der Elektronikgroßhändler. Diese Kreditoren haben keine Hauskontierung, weil sie kein Sortiment haben: Auf einer Rechnung stehen Druckerpapier, ein Werkzeugkoffer, ein Netzteil und ein Fachbuch. Die Häufigkeitsverteilung der Historie ist flach, und der stärkste Hebel der Automatisierung fällt weg.
Vier Umgangsweisen, in der Reihenfolge, in der wir sie empfehlen:
- Kreditor aufteilen. Wenn die Belegkreise sich unterscheiden — Amazon Business für die IT, Amazon für das Büro —, sind das zwei Kreditoren mit je eigener Hauskontierung. Das ist die einzige Variante, die den Fall wirklich auflöst, und sie ist eine Stammdatenentscheidung, keine KI-Frage.
- Regel auf Belegtextmuster. Enthält die Rechnung „Toner“ oder „Papier“, ist Bürobedarf ziemlich sicher. Das ist genau der Fall für eine strukturierte Regel: Kreditor plus Begriffe im Belegtext → Konto, deterministisch und auto-fähig. Funktioniert gut bei wenigen, klar getrennten Warengruppen; wird unübersichtlich, sobald man über zehn Regeln je Kreditor hinauskommt — dann ist Aufteilen (Punkt 1) die bessere Antwort.
- Positionsweise vorschlagen lassen. Bei Sammelrechnungen mit klaren Positionen kann das Modell je Position ein Konto vorschlagen. Nützlich, aber teurer und aufwändiger in der Prüfung — und viele Buchhaltungen splitten Eingangsrechnungen aus gutem Grund nicht.
- Bewusst im Review lassen. Die unterschätzte Option. Ein Kreditor mit 30 Belegen im Jahr, den ein Mensch in 15 Sekunden je Beleg prüft, kostet 7,5 Minuten Jahresaufwand. Dafür lohnt sich keine Regelpflege. Diese Kreditoren als Review-Kreditoren zu markieren, ist eine Entscheidung für Genauigkeit, nicht ein Eingeständnis von Schwäche.
8. Aus Korrekturen lernen, ohne überzureagieren
Jede Korrektur im Review ist ein Datenpunkt darüber, wie dieser Mandant wirklich bucht. Nur ist nicht jede Korrektur eine neue Konvention. Wenn jemand einen Drucker über 412 Euro aus 4930 auf ein GWG-Sammelkonto umbucht, ist das kein Grund, den Bürohändler künftig auf GWG zu buchen.
Die Schwelle, die sich in der Praxis bewährt hat, ist niedrig, aber nicht eins: Zwei aufeinanderfolgende bestätigte Buchungen desselben Kreditors auf dasselbe abweichende Konto machen aus diesem Konto die neue Hauskontierung. Zwei, weil ein Einzelfall keine Konvention ist. Nicht fünf, weil sonst ein echter Wechsel — neuer Vertrag, neue Kostenstellenstruktur — Monate braucht, bis er ankommt.
Zusätzlich sind bestätigte Buchungen die besten Beispiele für den Prompt der noch offenen Fälle: ein paar Sätze der Form „Kreditor X, Belegtext Y → Konto Z, bestätigt“ sagen mehr über die Hauskonvention als jede allgemeine Erklärung. Wichtig ist dabei die Auswahl — Beispiele desselben Kreditors zuerst, danach thematisch nahe Belege, begrenzt in der Menge, damit der Prompt nicht ins Uferlose wächst und die Kosten je Beleg stabil bleiben.
In eigene Systeme einbinden
Kontenliste rein, Buchungssatz raus
Die Gegenkontenliste wird über PUT /api/v1/mandanten/{id}/gegenkonten hochgeladen — inklusive Bezeichnungen und der Eigenschaft „Automatikkonto“ —, Rechnungen gehen an POST /api/v1/mandanten/{id}/invoices, und Korrekturen kommen über update_buchungssatz zurück, auch aus einem KI-Agenten über den MCP-Server. Kein zweiter Arbeitsplatz, kein Medienbruch.
9. Häufige Fragen zum Gegenkonto
Was ist das Gegenkonto bei einer Eingangsrechnung?
Bei einer Eingangsrechnung ist das Konto das Personenkonto des Lieferanten und das Gegenkonto das Sachkonto, auf dem der Aufwand landet — etwa 4930 Bürobedarf in SKR03 oder 6815 in SKR04. Die DATEV-Buchungszeile trennt beides in eigene Felder: Feld 7 „Konto“, Feld 8 „Gegenkonto (ohne BU-Schlüssel)“.
Kann eine KI das Gegenkonto zuverlässig bestimmen?
Für den überwiegenden Teil der Belege braucht es dafür gar keine KI: Wenn derselbe Lieferant in der Vergangenheit immer auf dasselbe Konto gebucht wurde, ist die Historie die verlässlichere Quelle als jedes Modell. Ein Sprachmodell ist für die Fälle nützlich, in denen keine Historie existiert — neuer Lieferant, neuer Sachverhalt, Mischkreditor. Dort schlägt es aus dem Rechnungsinhalt ein Konto aus der Kontenliste des Mandanten vor.
Wie verhindert man, dass ein Modell ein Konto erfindet?
Indem die Antwort nicht als Freitext, sondern als Auswahl aus einer Liste eingefordert wird. Technisch ist das ein Enum im Antwortschema, das genau die Kontonummern dieses Mandanten enthält. Ein Wert außerhalb der Liste ist dann schon strukturell keine gültige Antwort. Weil ein solches Schema eine Zusage des Anbieters und kein Beweis ist, prüft danach zusätzlich ein deterministischer Check, ob das Konto in der Liste steht.
Warum nicht den kompletten SKR03 als Auswahl vorgeben?
Weil ein vollständiger Standardkontenrahmen rund 1.400 Konten enthält, ein einzelner Mandant aber typischerweise 80 bis 150 davon benutzt. Die volle Liste vergrößert nur den Raum für plausible Fehlgriffe: 4930 „Bürobedarf“ und 4980 „Sonstiger Betriebsbedarf“ sind fachlich beide vertretbar, aber nur eines davon ist die Konvention dieses Unternehmens. Die gepflegte Mandantenliste ist die schärfere Einschränkung.
Wie unterscheidet sich SKR03 von SKR04 bei der Kontierung?
SKR03 ist nach Prozessen gegliedert (Wareneingang, Kosten, Erlöse), SKR04 nach der Bilanzstruktur. Für die Automatik ist der Unterschied vor allem, dass die Nummern völlig andere sind: Bürobedarf ist in SKR03 4930, in SKR04 6815. Deshalb ist der Kontenrahmen eine Eigenschaft des Mandanten und keine globale Einstellung — und deshalb kann man Kontierungslogik nicht von einem Mandanten auf einen anderen mit anderem Rahmen übertragen.
Wie geht das System mit Mischkreditoren wie Amazon um?
Mischkreditoren sind der ehrliche Grenzfall: Ein Konto pro Lieferant funktioniert hier nicht, weil derselbe Lieferant Büromaterial, Werkzeug, Hardware und Fachliteratur liefert. Sinnvoll sind drei Wege: den Kreditor in mehrere Kreditoren aufteilen, wenn die Belegkreise sich unterscheiden; eine strukturierte Regel auf das Belegtextmuster legen (Kreditor plus Begriffe wie „Toner“ oder „Papier“ → Konto) — die greift deterministisch und darf ohne Review buchen; oder den Kreditor bewusst als Review-Kreditor führen und die 15 Sekunden Prüfung je Beleg akzeptieren.
Was ist der Unterschied zwischen einer Regel und einer Anweisung?
Eine Regel ist Bedingung und Ergebnis: dieser Kreditor oder dieser Begriff im Belegtext, dann dieses Gegenkonto. Sie wird ohne Sprachmodell ausgewertet, greift mit Confidence 0,95 und darf deshalb automatisch buchen — passende Belege laufen ohne Review durch. Eine Anweisung ist ein Satz in normalem Deutsch („Reisekostenabrechnungen: Person auf Seite 1 ist der Kreditor“); sie wirkt über den Prompt, bleibt unter dem Deckel von 0,84 und geht deshalb immer einmal durch den Review. Daraus folgt die Wahl: Was sich als Bedingung ausdrücken lässt, gehört als Regel hinterlegt, denn nur das spart Arbeit. Alles, was einen ganzen Satz braucht, gehört als Anweisung hinterlegt. Beides wird in preKonto auf derselben Seite verwaltet, damit die Entscheidung dort fällt, wo der Unterschied steht.
Wie lege ich eine Kontierungsregel an?
Am bequemsten aus einer Korrektur: Wer im Review das Gegenkonto ändert, bekommt danach das Angebot, daraus eine Regel zu machen — „diesen Kreditor künftig immer auf dieses Konto“ oder „Belege mit diesem Text immer auf dieses Konto“. Das ist der Moment, in dem die Entscheidung ohnehin getroffen ist. Angelegt wird nichts von selbst: Eine stillschweigend erzeugte Regel wäre Monate später eine unerklärliche Automatik, deshalb steht die Konsequenz im Angebot und es braucht einen Klick. Unabhängig davon lassen sich Regeln auf der Seite „Regeln und Anweisungen“ des Mandanten anlegen, ändern, deaktivieren und löschen — und über die REST-API unter /api/v1/mandanten/{id}/regeln.
Was passiert, wenn mehrere Regeln auf denselben Beleg passen?
Die spezifischere gewinnt: Kreditor und Belegtext schlägt nur Kreditor, und nur Kreditor schlägt nur Belegtext. Bei gleicher Spezifität gewinnt die ältere. Beides ist so gewählt, dass die Antwort auf „welche Regel hat gewonnen“ vorhersagbar bleibt: Wer eine Ausnahme zu einer bestehenden Regel anlegt, muss die allgemeine nicht löschen, damit die Ausnahme wirkt — und eine neu angelegte Regel stößt eine gleich spezifische bestehende nicht stillschweigend um. Die Prüfansicht nennt bei einer automatisch gebuchten Zeile, welche Regel entschieden hat und welche Bedingung gegriffen hat.
Was passiert, wenn ich im Review ein Konto korrigiere?
Die Korrektur wird als solche markiert und fließt als Lernsignal zurück. Fallen für denselben Kreditor zwei bestätigte Buchungen konsistent auf dasselbe abweichende Konto, wird dieses Konto zur neuen Hauskontierung. Zwei und nicht eine, damit ein einzelner Sonderfall die Konvention nicht umschreibt.
Wie hoch dürfen die Kosten je Beleg sein, damit sich das rechnet?
Der Vergleichsanker im Markt liegt bei rund 5 Cent je Buchungssatz für den DATEV-Automatisierungsservice und deutlich höher bei Kanzleiwerkzeugen wie Finmatics, die je Zeile im Bereich von 25 bis 40 Cent liegen. Weil die Historie den größten Teil der Belege ohne Modellaufruf erklärt, fallen KI-Kosten nur für die Reste an — das ist der eigentliche Grund, warum die Schichtung nach Kreditor-Default vor Modell nicht nur genauer, sondern auch billiger ist.
Weiterlesen
- Rechnungen automatisch kontieren: was 2026 wirklich funktioniert
Die Matching-Kaskade, die Review-Schwelle und die Auto-Quoten, die im Markt tatsächlich belegt sind: 76 bis 85 Prozent. - DATEV-Buchungsstapel (EXTF) selbst erzeugen: Format, Fallstricke, Praxis
31 Header-Felder, 125 Felder je Buchungszeile, Belegdatum ohne Jahr: die Feldreferenz und die typischen Importfehler.
Quellen und Grundlagen
- DATEV: Standardkontenrahmen SKR03 und SKR04 in der Standardbelegung, einschließlich Kontenfunktionen und Automatikkonten
- DATEV-Dokument 9211385: Satzbeschreibung Buchungsstapel, Felder „Konto“, „Gegenkonto (ohne BU-Schlüssel)“ und „BU-Schlüssel“
- Finmatics: 76 % vollautomatische Buchungserstellung nach etwa sechs Monaten Lernphase; Candis: 85 % vorkontierte Rechnungen nach 30 Tagen
- § 6 Abs. 2 und 2a EStG zu geringwertigen Wirtschaftsgütern und Sammelposten