1200 ist nicht die Bank: Ein KI-Skill für die Kontierung im SKR04

Frag ein Sprachmodell, wie Du eine Telefonrechnung über 59,50 Euro buchst, die per Lastschrift vom Bankkonto abgeht. Kontenrahmen SKR04. Die Antwort kommt schnell, mit sauberem Buchungssatz und einer kurzen Erklärung zur Vorsteuer.

Manchmal steht darin aber so etwas:

Soll 4920 Telefon                      50,00
Soll 1576 Abziehbare Vorsteuer 19 %     9,50
an Haben 1200 Bank                     59,50

Das ist ein korrekter Buchungssatz. Nur eben im SKR03. Die 1576 fällt beim Erfassen auf, weil sie im SKR04-Standard nicht vorgesehen ist. Auch die 1200 hält DATEV auf, denn im SKR04 ist sie das Sammelkonto für Forderungen aus Lieferungen und Leistungen und lässt sich nicht direkt bebuchen. Heikel ist die 4920. Im SKR04 steht sie für „Erträge aus der Herabsetzung der Pauschalwertberichtigung auf Forderungen“, ein gewöhnliches Sachkonto. Die Telefonkosten landen dann als Ertrag in der Buchhaltung, und das fällt womöglich erst beim Abschluss auf.

Eine Kontonummer, die es gibt, ist eben noch kein passendes Konto. Ob eine Software die Fehlbuchung abfängt, hängt von den Kontenfunktionen und Prüfungen ab, die dort hinterlegt sind.

Warum das passiert

Warum ein Modell die Kontenrahmen vermischt, lässt sich von außen nicht sicher sagen. Beobachten lässt sich das Ergebnis: Obwohl der SKR04 ausdrücklich genannt ist, tauchen Nummern aus dem SKR03 auf. Das Modell hat den Kontenplan nicht vor sich, es antwortet aus dem, was es gelernt hat, und sagt Dir nicht, dass es unsicher ist.

Nummern, die es im gewählten Kontenrahmen gar nicht gibt, fallen meist schon beim Erfassen auf. Schwieriger sind die Nummern, die es in beiden Kontenrahmen gibt:

Ein besserer Prompt löst das nicht zuverlässig. „Achte auf den SKR04“ hilft ein bisschen, aber das Modell hat den Kontenplan nicht vor sich. Es erinnert sich. Was fehlt, ist eine verlässliche Quelle, in der es nachschlagen muss, und eine Prüfung, die nicht vom Modell selbst kommt. Beides lässt sich in einen Skill packen.

Was ein Skill ist

Ein Skill ist ein Ordner. Darin liegt eine Datei SKILL.md mit Anweisungen für das Modell, dazu nach Bedarf Nachschlagedateien und Skripte. Programmieren musst Du nur, wenn Du ein Skript mitliefern willst.

Am Anfang der SKILL.md stehen ein Name und eine Beschreibung. Die Beschreibung ist der wichtigste Satz im ganzen Skill, denn außer dem Namen ist sie das Einzige, was das Modell dauerhaft vor sich hat. Erkennt es, dass Deine Frage zur Beschreibung passt, lädt es den Rest der Anleitung nach. Die Kontenliste oder das Prüfskript kommen erst ins Spiel, wenn die Anleitung sie verlangt. Du kannst also viele Skills installieren, ohne dass jedes Gespräch mit Buchhaltungswissen vollgestopft wird.

Zur Einordnung, welche Wege es sonst noch gibt, einer KI etwas beizubringen:

• Prompt: Gilt für ein Gespräch. Beim nächsten Mal schreibst Du ihn neu oder kopierst ihn aus einer Notiz.
• Projekt oder eigener GPT: Gilt für einen abgegrenzten Bereich. Du musst daran denken, das richtige Projekt zu öffnen.
• Skill: Ist immer verfügbar und wird geladen, wenn das Modell die Frage als passend erkennt. Er kann Dateien und ausführbare Skripte mitbringen.
• MCP-Server: Gibt dem Modell Zugriff auf Systeme, etwa auf die Sage 100. Ein Skill bringt Wissen und Arbeitsweise mit, keinen Zugriff.

Skill und MCP ergänzen sich übrigens gut. Der MCP-Server liest die offenen Belege aus der Sage 100, der Skill gibt dem Modell Deine Regeln für die Kontierung mit. Wie wir solche Zugriffe aufbauen, steht im Beitrag zu Sprachmodellen und ERP.

Wo Skills funktionieren

Anthropic hat Skills für Claude eingeführt und das Format später als offenen Standard unter dem Namen Agent Skills veröffentlicht. In Claude laufen sie in der Web- und Desktop-App, in Claude Code und über die API. In der App lädst Du den Ordner als ZIP im Bereich Skills hoch (derzeit unter Customize). Voraussetzung ist dort eine aktivierte Codeausführung, und zwar für Skills generell, nicht erst für mitgelieferte Skripte.

OpenAI unterstützt das Format in Codex und inzwischen auch in ChatGPT. Auch dort wird ein Skill als Datei hochgeladen. In Enterprise- und Edu-Workspaces muss das der Admin freischalten, und was Du genau siehst, hängt von Tarif und Oberfläche ab. Ohne Skill-Unterstützung bleibt der Weg über einen eigenen GPT oder ein Projekt: Den Text aus der SKILL.md als Anweisungen hinterlegen und die übrigen Dateien als Wissen hochladen. Das Modell lädt dann nicht mehr selektiv nach. Und das Prüfskript liegt zwar bereit, läuft aber nur, wenn die Codeausführung aktiv ist und das Modell es tatsächlich aufruft.

Der Skill für die SKR04-Kontierung

Unser Beispiel macht zwei Dinge. Es findet zu einem Geschäftsvorfall das passende Konto mit vollständigem Buchungssatz, und es prüft vorhandene Buchungen. Der Aufbau:

skr04-kontierung/
├── SKILL.md                  Anweisungen für das Modell
├── references/
│   ├── konten.csv            gut 100 häufig genutzte SKR04-Konten mit Hinweisen
│   ├── verwechslungen.csv    Nummern mit anderer Bedeutung im SKR03
│   └── sonderfaelle.md       GWG, Reverse Charge, Bewirtung, Geschenke, Hotel
└── scripts/
    └── pruefe_buchung.py     Prüfskript, nur Python-Standardbibliothek

Die Beschreibung

Hier entscheidet sich, ob der Skill überhaupt benutzt wird. Sie sagt, was er kann, und vor allem, wann er greifen soll:

---
name: skr04-kontierung
description: Findet das passende Konto im DATEV-Kontenrahmen SKR04 und prüft
  Buchungssätze (Soll/Haben, Steuerbetrag, Steuersatz, verwechselte
  SKR03-Nummern). Verwenden, wenn jemand fragt, auf welches Konto ein
  Geschäftsvorfall gebucht wird, einen Buchungssatz im SKR04 haben möchte
  oder Buchungen im SKR04 prüfen lassen will. Nicht für SKR03 verwenden.
---

Wichtig ist auch der letzte Satz. Er senkt das Risiko, dass der Skill bei SKR03-Fragen anspringt und dort SKR04-Konten vorschlägt. Das wäre genau der Fehler, den er verhindern soll, nur andersherum.

Die Grundregel

Der wichtigste Absatz in der Anleitung ist kurz:

Kontonummern nie aus dem Gedächtnis nennen. Jede Nummer, die in der
Antwort vorkommt, muss vorher in references/konten.csv nachgeschlagen
worden sein. Steht ein Konto nicht in konten.csv, sag das offen und
verweise auf den Kontenplan des Mandanten. Erfinde keine Bezeichnung.

Die Anleitung verlangt also Nachschlagen statt Erinnern. Garantiert ist damit nichts, ein Modell kann eine Anweisung auch übergehen. Deshalb gibt es zusätzlich das Prüfskript. Die Anleitung erklärt dem Modell außerdem, warum: Weil es beide Kontenrahmen kennt und sie verwechselt. Das empfehlen auch die Anbieter in ihren Leitfäden, denn Modelle halten sich besser an Regeln, deren Grund sie kennen.

Danach folgt der Ablauf. Erst den Sachverhalt klären und bei Bedarf nachfragen (Steuersatz, Inland oder Ausland, Nettobetrag bei Anschaffungen, Anlass bei Bewirtung). Dann nachschlagen, Buchungssatz aufstellen, mit dem Skript prüfen und erst dann antworten.

Die Kontenliste

Die konten.csv ist bewusst kein vollständiger Kontenrahmen. Sie enthält die Konten, die im Alltag eines typischen mittelständischen Betriebs immer wieder vorkommen, und zu vielen einen Hinweis aus der Praxis:

konto;bezeichnung;art;satz;steuer;auto;hinweis
1406;Abziehbare Vorsteuer 19 %;steuer;19;vst;;
4400;Erlöse 19 % USt;ertrag;19;;AM;
6400;Versicherungen;aufwand;;;;Versicherungsbeiträge enthalten in der Regel …
6610;Geschenke abzugsfähig ohne § 37b EStG;aufwand;;;;Freigrenze von 50 Euro …

Die Spalten art, satz und steuer braucht das Prüfskript. Den Hinweis liest das Modell und gibt ihn weiter, wenn das Konto vorkommt. Gerade bei Versicherungen hilft das: Die Rechnung sieht aus wie jede andere, nur steckt darin eben keine Vorsteuer. Bei Geschenken steht im Hinweis, dass die 50 Euro eine Freigrenze sind und dass es vom Vorsteuerabzug abhängt, ob netto oder brutto zählt.

Das Prüfskript

Rechnen ist keine Stärke von Sprachmodellen, und ob 9,50 genau 19 % von 50,00 sind, soll nicht von der Modellantwort abhängen. Deshalb prüft ein kleines Python-Skript den fertigen Buchungssatz. Das Modell schreibt die Buchung in eine Datei, ruft das Skript auf und liest das Ergebnis. Für das Beispiel vom Anfang:

$ python scripts/pruefe_buchung.py buchung.txt
FEHLER: Konto 1576 gibt es im SKR04 nicht. Im SKR03 ist es „Abziehbare
  Vorsteuer 19 %“, im SKR04 entspricht das 1406 Abziehbare Vorsteuer 19 %.
WARNUNG: Konto 4920 ist im SKR04 „Erträge aus der Herabsetzung der
  Pauschalwertberichtigung auf Forderungen“. Im SKR03 steht 4920 für
  „Telefon“, das wäre im SKR04 6805 Telefon. Der Buchungstext enthält
  „telefon“. Prüfen, welches gemeint ist.
WARNUNG: Konto 1200 ist im SKR04 „Forderungen aus Lieferungen und
  Leistungen“. Im SKR03 steht 1200 für „Bank“, das wäre im SKR04 1800 Bank.
  Der Buchungstext enthält „bank“. Prüfen, welches gemeint ist.

Das Skript prüft außerdem, ob Soll und Haben übereinstimmen, ob der Steuerbetrag zur Bemessungsgrundlage passt und ob der Steuersatz des Steuerkontos zum Erlöskonto gehört. Erlöse auf 4300 mit 7 % und Steuer auf 3806 mit 19 % sind ein Fehler, auch wenn die Summen stimmen. Bei Reverse Charge auf Eingangsrechnungen muss die Umsatzsteuer nach § 13b UStG gebucht sein. Die Vorsteuer in gleicher Höhe gehört nur dazu, soweit der Betrieb zum Vorsteuerabzug berechtigt ist. Das weiß das Skript nicht, deshalb gibt es bei fehlender Vorsteuer eine Warnung statt eines Fehlers. Und wenn im Buchungstext „Irland“ oder „ohne USt“ steht, aber gar keine Steuer gebucht wurde, gibt es eine Warnung.

Die Abstufung in Fehler, Warnung und Hinweis ist wichtig. Ein Konto, das nicht in der Kurzliste steht, ist kein Fehler, sondern ein Hinweis, im Kontenplan des Mandanten nachzusehen. Als Fehler meldet das Skript nur Nummern, die in der Verwechslungstabelle als SKR03-Konto ohne Gegenstück im SKR04 hinterlegt sind, wie die 1576. Konto 1200 ist im SKR04 völlig in Ordnung, wenn Du eine Ausgangsrechnung buchst. Das Skript meldet es nur, wenn der Buchungstext nach Bank klingt und das eigentliche Bankkonto 1800 nicht in der Buchung vorkommt. Ein Skript, das bei jeder zweiten Buchung warnt, liest nach drei Tagen niemand mehr.

Es ist dieselbe Aufteilung wie bei unserem Buchungsvorschlag aus Belegen: Was sich als Regel formulieren lässt, gehört in eine Regel. Das Modell schlägt die Kontierung vor, das Skript rechnet nach.

Eine Grenze bleibt: Ob das Skript wirklich aufgerufen wird, entscheidet am Ende das Modell. Der Skill fordert die Prüfung an, erzwingen kann er sie nicht. Verbindlich wird sie erst, wenn die Anwendung drumherum eine Buchung nur nach einem Prüflauf ohne Fehler zur Übernahme freigibt.

So entwickelst Du Deinen eigenen Skill

Der SKR04-Skill ist ein Beispiel. Das Vorgehen passt für fast alles, wo Dein Unternehmen eigenes Wissen oder eigene Regeln hat.

1. Mit einem echten Fehler anfangen. Nicht mit der Idee „die KI soll Buchhaltung können“, sondern mit einer konkreten Stelle, an der sie danebenliegt. Sammle ein paar Beispiele, bei denen die Antwort falsch oder unvollständig war.
2. Die Beschreibung zuerst schreiben. Wann soll der Skill greifen, wann ausdrücklich nicht? Wenn Du das nicht in zwei, drei Sätzen sagen kannst, ist der Skill zu breit.
3. Wissen in Dateien, nicht in die Anleitung. Listen, Tabellen und Sonderfälle gehören in eigene Dateien unter references/. Die SKILL.md beschreibt nur, wann welche Datei zu lesen ist. So bleibt sie kurz und übersichtlich.
4. Alles Prüfbare in ein Skript. Summen, Formate, Plausibilitäten. Kommt das Skript ohne zusätzliche Pakete aus, läuft es in den Sandboxen der Anbieter am zuverlässigsten.
5. Mit und ohne Skill vergleichen. Stell dieselben zehn Fragen einmal ohne und einmal mit Skill. Wenn Du keinen Unterschied siehst, schließt der Skill keine Lücke.
6. Pflegen. Jede falsche Antwort, die trotz Skill durchrutscht, wird zu einer neuen Zeile in der Liste oder einer neuen Prüfregel.

Noch etwas zur Sicherheit: Skills können Skripte ausführen. Installier deshalb nur Skills, deren Inhalt Du gelesen hast oder deren Herkunft Du vertraust. Bei unserem kannst Du jede Zeile auf GitHub nachlesen.

Was der Skill nicht kann

Er kennt Deinen Kontenplan nicht. Viele Unternehmen arbeiten mit eigenen Unterkonten, abweichenden Bezeichnungen oder einer angepassten Kontenzuordnung, gerade in der Sage 100. Wenn Du den Skill im eigenen Betrieb nutzen willst, nimm die konten.csv als Vorlage und ergänze sie um Eure Konten. Der Aufwand ist überschaubar und bringt mehr als jede Verbesserung an der Anleitung.

Er weiß auch nicht, ob Deine Software die Steuer automatisch rechnet. Im DATEV-Standard sind Konten wie 4400 oder 5400 Automatikkonten, dort wird brutto gebucht und die Steuer separat herausgerechnet. Der Skill schreibt Buchungssätze in der Lehrbuchform mit separater Steuerzeile und weist bei Automatikkonten darauf hin.

Und er ersetzt keine Steuerberatung. Ob eine Anschaffung sofort Aufwand ist, ob eine Bewirtung abzugsfähig ist oder ob § 13b greift, hängt vom Einzelfall ab. Der Skill nennt das Prinzip und ein passendes Beispielkonto. Bei wesentlichen Beträgen gehört die Frage trotzdem zur Steuerberatung.

Den Skill herunterladen

Den kompletten Skill mit Kontenliste, Verwechslungstabelle, Sonderfällen, Prüfskript und Beispielbuchungen gibt es als Open Source auf GitHub. Lade den Ordner skr04-kontierung als ZIP in Claude hoch oder kopiere ihn in Dein Skill-Verzeichnis. Das Prüfskript kannst Du auch ganz ohne KI auf der Kommandozeile nutzen.

Fehlt ein Konto, das bei Dir ständig vorkommt, oder ist ein Hinweis fachlich ungenau? Dann freuen wir uns über ein Issue oder einen Pull Request. Wer lieber ohne KI nachschlägt, findet die Konten auch in unserem SKR04-Kontenrahmen und den Vergleich zwischen SKR03 und SKR04 im Browser.