Dokumentation

Wie aus einer Eingangsrechnung eine Vorkontierung wird, die man verantworten kann — und daraus nach Kontrolle und Freigabe eine Kontierung im Stapel: welche Stammdaten es braucht, wie der Lieferant und das Gegenkonto gefunden werden, wann preKonto selbst entscheidet und wann nicht — und was beim Korrigieren gelernt wird. Geschrieben für Menschen, die die Buchung am Ende unterschreiben.

Der Ablauf im Überblick

1. Mandant und DATEV-Kopfdaten

Ein Mandant ist eine Firma, für die kontiert wird. In einer Kanzlei sind das die Mandanten, in einem Unternehmen mit eigener Buchhaltung meist genau einer. Alles ist mandantenbezogen: Stammdaten, Belege, Buchungssätze, Regeln und Anweisungen, Exporte.

Beim Anlegen werden fünf Angaben verlangt, die alle im Kopf des DATEV-Buchungsstapels landen. Sie sind keine Formalität — mit falschen Kopfdaten importiert DATEV den Stapel entweder nicht oder in den falschen Mandanten.

Das Wirtschaftsjahr reicht vom hinterlegten Beginn ein Jahr minus einen Tag. Ein Stapel darf diese Grenze nicht überschreiten — deshalb wird pro Periode exportiert, nicht über den Jahreswechsel hinweg. Warum das so sein muss, steht in der Export-Dokumentation.

Es gibt zwei Wege zum Mandanten, und sie sind gleichrangig: das Formular in der Oberfläche, oder die KRExport_MNDT_…-Datei aus DATEV. In beiden Fällen entsteht kein Mandant, ohne dass ein Mensch die Angaben gesehen und bestätigt hat — die Datei liefert einen Vorschlag. Wie der Weg über die Datei aussieht, steht im Erstimport aus der Mandantenliste.

2. Stammdaten hochladen

Zwei Listen je Mandant. An ihnen hängt, wie gut die Vorschläge von Anfang an sind: Steht in der Kreditorenliste schon ein Standard-Gegenkonto, ist die Hauskontierung des Mandanten ab dem ersten Beleg bekannt und muss nicht erraten werden.

Optional sind bei Kreditoren ustId, iban und defaultGegenkonto, bei Gegenkonten steuersatzHinweis, erwarteterSteuersatz und automatikkonto. Jedes optionale Feld, das vorhanden ist, macht die Zuordnung sicherer — die USt-IdNr. ist die stärkste Stufe der Matching-Kaskade, und ein Standard-Gegenkonto erspart den Umweg über ein Sprachmodell vollständig.

DATEV-KRexport: ohne KI erkannt

Wer aus DATEV heraus exportiert, bekommt Dateien, deren Aufbau bekannt ist. Solche Dateien werden deterministisch geparst — kein Sprachmodell, keine Heuristik, keine Vorschau nötig. Erkannt werden sie an zwei unabhängigen Merkmalen, eines genügt:

• Dateiname nach dem Muster KRExport_KRED_… (Kreditoren), KRExport_KTO_… (Sachkonten) oder KRExport_MNDT_… (Mandant), jeweils mit Mandantennummer und Datum. Groß- und Kleinschreibung ist gleichgültig, Zusätze wie (2) stören nicht.
• Kopfzeile mit der bekannten Spaltenfolge — etwa Konto; Kontobeschriftung; SprachId für die Sachkontenliste.

Widersprechen sich Dateiname und Kopfzeile, gewinnt die Kopfzeile, und der Widerspruch wird als Hinweis gemeldet — der Inhalt ist die verlässlichere Auskunft. Umbenennen schadet deshalb nicht: Eine KRexport-CSV mit unveränderter Kopfzeile wird auch als liste.csv deterministisch geparst. Der Dateiname ist der Rückfall, wenn die Kopfzeile nicht wiedererkannt wird, und liefert zusätzlich Mandantennummer und Wirtschaftsjahresbeginn — deshalb lohnt es trotzdem, den Originalnamen mitzugeben.

Erstimport: Mandanten aus der Mandantenliste

KRexport schreibt neben Konten- und Kreditorenliste eine dritte Datei: KRExport_MNDT_…. Sie führt Beraternummer, Mandantennummer, Wirtschaftsjahr und Namen aller Mandanten — und sonst nichts. Damit ist sie die einzige Liste, die Mandanten definiert, statt in einen hineinzuschreiben. Genau deshalb ist sie die einzige, die sich ohne vorhandenen Mandanten hochladen lässt: Auf /mandanten steht neben „Mandant anlegen“ der Weg „Mandantenliste aus DATEV hochladen“.

Der Ablauf: Datei hochladen → Liste aller enthaltenen Mandanten ansehen → anhaken, welche angelegt werden sollen → anlegen. Führt die Datei einen Mandanten mit mehreren Wirtschaftsjahren, wird trotzdem ein Mandant angelegt; das Jahr wählen Sie und können es später ändern. Mandanten, die es schon gibt, sind als „vorhanden“ markiert und werden nicht verändert — die Eindeutigkeit ist Beraternummer plus Mandantennummer, ein zweiter Durchlauf derselben Datei erzeugt also keine Dubletten.

Der Sammelexport funktioniert genauso. Kanzleien mit vielen Mandanten unter einer Beraternummer exportieren nicht hundert Dateisätze von Hand, sondern lassen ein Skript über den Ausgabeordner von KRexport laufen: Es stellt Mandantennummer und Wirtschaftsjahresbeginn als Spalten vor jede Zeile und schreibt alle Mandanten einer Kategorie in eine Datei. Bei der Mandantenliste wird dabei nicht gefiltert — der Zweck der Datei ist, alle Mandanten zu zeigen. Bei Konten- und Kreditorenlisten schon: Dort werden die Zeilen des gewählten Mandanten genommen und in der Vorschau ausgewiesen, wie viele Zeilen zu anderen Mandanten oder anderen Wirtschaftsjahren gehören. Das ist eine Feststellung, kein Fehler.

Nach der Mandantenanlage fehlen den Mandanten noch ihre Konten. Der Weg dorthin steht direkt unter dem Ergebnis: je angelegtem Mandanten ein Link auf seine Upload-Seite, wo Kontenliste KRExport_KTO_… und Kreditorenliste KRExport_KRED_… aus demselben KRexport-Lauf hineingehören.

Headless geht derselbe Erstimport über POST /api/v1/mandanten/import — der einzige Endpunkt der API, der ohne Mandanten-ID arbeitet. Auch dort in zwei Schritten: Ein Aufruf ohne Auswahl liefert nur die Vorschlagsliste, erst ein Aufruf mit Auswahl legt an.

Eine Kreditoren- oder Gegenkontenliste ohne Mandanten wird dagegen abgewiesen, mit dem Hinweis, zuerst die Mandantenliste hochzuladen oder einen Mandanten anzulegen. Solche Listen brauchen ein Ziel; ein Konto ohne Mandanten ist kein halber Import, sondern keiner.

Beliebige Listen: KI-Spaltenmapping mit Vorschau

Nicht jede Liste kommt aus DATEV. Excel-Tabellen aus dem ERP, eine CSV-Datei aus einem Vorgängersystem, ein PDF-Ausdruck des Kontenplans — dafür ordnet ein Sprachmodell die Spalten den Zielfeldern zu. Wichtig ist, was es dabei nicht tut:

• Es sieht nur die Kopfzeile und höchstens zehn Beispielzeilen, Zellen auf 60 Zeichen gekürzt. Nicht die ganze Liste.
• Es liefert nur Spaltennummern und die Zielfeldnamen — und darf nur aus den erlaubten Zielfeldern wählen. Kein Wert wird vom Modell umgeformt; Zahlen, Datumsangaben und Ja/Nein-Felder wandelt deterministischer Code um.
• Fehlt eine Pflichtspalte, wird abgebrochen statt halb importiert.

In der Oberfläche folgt darauf eine Vorschau: die erkannte Spaltenzuordnung, fünf fertig zugeordnete Beispielzeilen und der Probelauf-Fehlerbericht. Erst Ihre Bestätigung schreibt Daten — und die Bestätigung ruft kein Sprachmodell mehr auf, sie arbeitet mit dem Zwischenergebnis. Wer über die API importiert, bekommt keine Vorschau: Dort ist der Aufruf ausdrücklich die Anweisung „übernimm diese Liste“, und der Importbericht in der Antwort nennt hinterher, was übersprungen wurde.

Was ein Upload niemals tut

Übernommen wird per Upsert über Mandant und Kontonummer. Drei Fälle, und der dritte ist der wichtige:

• Konto unbekannt → wird angelegt.
• Konto vorhanden und aus einem früheren Upload → wird aktualisiert, die neuere Liste gilt.
• Konto vorhanden und von Hand gepflegt → wird nicht angefasst und im Bericht als Duplikat genannt. Was ein Mensch hier eingetragen hat — etwa ein Standard-Gegenkonto, das in keiner DATEV-Liste steht — darf ein automatischer Abgleich nicht wegräumen, sonst verliert man bei jedem Sync seine Kontierungsregeln.

Und: Ein Upload löscht nie. Konten, die in der neuen Liste fehlen, bleiben stehen. Kommt eine Kontonummer in der Datei mehrfach vor, gilt das erste Vorkommen; die übrigen werden gemeldet. Ein unbrauchbares Pflichtfeld lässt die Zeile ausfallen, ein unbrauchbares optionales Feld lässt die Zeile durch und bleibt leer. Kein einzelner Fehler bricht den ganzen Import ab.

3. Belegverarbeitung: XML zuerst, KI nur wenn nötig

Was mit einem Beleg passiert, entscheidet sein Inhalt — nicht der Dateiname und nicht der Content-Type. Bei einem PDF wird wirklich in den Anhangsbaum geschaut, ob eine Rechnungs-XML eingebettet ist.

Der Grund ist nicht Sparsamkeit, sondern Genauigkeit: Bei einer XRechnung steht der Betrag als Zahl in einem benannten Feld. Da gibt es nichts zu erkennen und nichts zu verwechseln. Der Anteil dieser Belege wächst von allein, und mit ihm verschiebt sich die Arbeit von der Erkennung zur Kontierung.

Erkannt und benannt werden die ZUGFeRD-Profile MINIMUM, BASIC-WL, BASIC, EN16931, EXTENDED und XRECHNUNG.

Was danach nachgerechnet wird, ist unabhängig von der Quelle: Netto plus Umsatzsteuer gegen Brutto und die Summe der Positionen gegen Netto, jeweils auf den Cent. Prüfziffer der USt-IdNr., Prüfsumme der IBAN nach mod 97, kalendarische Gültigkeit des Rechnungsdatums, Vorhandensein der Rechnungsnummer.

Optional kommt eine zweite, unabhängige Meinung hinzu: Ist ein Zugang zum Prüfdienst finisma konfiguriert, wird ein ZUGFeRD-PDF dort gegen EN 16931 geprüft. Das Ergebnis erscheint als eigener Prüfpunkt en16931_valide. Ein „ungültig“ ist ein Blocker und schickt den Beleg in die Prüfung — es bricht die Verarbeitung aber nie ab, und ein nicht gelaufener Check erscheint ausdrücklich nicht als bestandener. Ohne Zugang läuft alles unverändert weiter, der Punkt fehlt dann einfach. Was dabei übertragen wird und an wen, steht in den häufigen Fragen.

4. Kreditor finden: die Matching-Kaskade

Der Lieferant auf der Rechnung muss einem Personenkonto Ihrer Kreditorenliste zugeordnet werden. Vier Stufen, absteigend nach Beweiskraft. Die erste, die trifft, gewinnt.

Zwei Regeln stehen über der Kaskade.

Ein ungültiger Schlüssel wird nicht verglichen. Vor Stufe 1 und 2 werden Prüfziffer bzw. Prüfsumme geprüft. Eine falsch gelesene USt-IdNr. könnte zufällig zu einem fremden Kreditor passen — und würde die Rechnung mit der höchsten Confidence der ganzen Kaskade auf ein falsches Konto buchen. Die Stufe wird deshalb übersprungen und nicht bloß schwächer bewertet.

Mehrdeutigkeit wird nie geraten. Passen zwei Kreditoren gleich gut — bei Ähnlichkeitswerten heißt „gleich gut“: sie liegen weniger als 0,01 auseinander — ist das Ergebnis „Prüfung“ mit beiden Kandidaten, nicht der erste in der Liste. Wird kein Kreditor gefunden, bekommt die Prüfliste bis zu drei Beinah-Treffer als unverbindliche Vorschläge.

5. Gegenkonto finden: drei Schichten

Das Gegenkonto — das Sachkonto für den Aufwand — steht nicht auf der Rechnung. Dass ein Lieferant in diesem Betrieb auf 4930 gebucht wird und nicht auf 4980, ist eine Konvention des Mandanten. Drei Schichten, von der stärksten zur schwächsten Aussage:

Schicht (b) ist der wirtschaftliche Hebel: Greift das Kreditor-Default, wird gar kein Modell gefragt. Das senkt die Kosten je Beleg und macht die Ergebnisse stabil — derselbe Lieferant bekommt immer dasselbe Konto. Eine aktive Freitext-Anweisung schaltet diese Abkürzung ab: Solange eine Anweisung im Spiel ist, darf das Default nicht stillschweigend gewinnen, denn genau das könnte die Anweisung ja umstoßen wollen.

Für Schicht (c) ist entscheidend, wie gefragt wird. Das Modell bekommt die Gegenkontenliste des Mandanten als abgeschlossene Auswahl — technisch ein Enum im Antwortschema — und danach prüft ein deterministischer Check die Antwort noch einmal gegen dieselbe Liste. Ein Konto außerhalb der Liste führt nie zu einer Buchung, sondern in die Prüfung. Eine erfundene Kontonummer kann also nicht in einem Stapel landen.

Und der Deckel bei 0,84 ist mit Bedacht knapp unter der Auto-Schwelle von 0,85 gesetzt. Die Begründung ist eine sicherheitstechnische: Der Beleg gehört dem Absender. Freitextfelder — Notizen, Positionsbezeichnungen, Verwendungszweck — stehen wörtlich im Prompt. Wer sie füllt, könnte darin Anweisungen unterbringen und damit beides steuern: das vorgeschlagene Konto und die gemeldete Sicherheit. Läge der Deckel über der Schwelle, wäre die menschliche Prüfung durch einen präparierten Beleg abschaltbar. Ein Modell, das „1,0“ meldet, hat damit nichts bewiesen.

Strukturierte Regel (0,95) und Kreditor-Default (0,90) bleiben dagegen auto-fähig: Beide entstehen aus Ihren eigenen Daten und wirken deterministisch, ohne dass Belegtext ihre Höhe beeinflussen könnte.

Passen mehrere Regeln auf einen Beleg, ist die Auswahl festgelegt und nachvollziehbar: Die spezifischere gewinnt — Kreditor und Belegtext vor nur Kreditor, nur Kreditor vor nur Belegtext —, bei Gleichstand die ältere. So muss eine allgemeine Regel nicht gelöscht werden, damit eine Ausnahme greift, und eine neu angelegte Regel stößt eine bestehende, gleich spezifische nicht stillschweigend um. Eine Regel ohne Bedingung ist nicht anlegbar: Sie würde jeden Beleg des Mandanten ohne Prüfung auf ein Konto buchen. Betragsgrenzen und Datumsbedingungen gibt es nicht — die Bedingung ist ein Kreditor, eine Liste von Begriffen oder beides.

Trägt ein Gegenkonto das Kennzeichen Automatikkonto, ist der Steuerschlüssel darin schon enthalten — dann darf kein BU-Schlüssel gesetzt sein. Ein Widerspruch wird beim Bestätigen und beim Export abgewiesen, nicht stillschweigend geglättet.

6. Von der Vorkontierung zur Kontierung: die Ampel

Bis hierher ist alles Vorkontierung: ein Vorschlag mit Konten, Steuerschlüssel und Belegfeldern. Ob daraus eine Kontierung wird — also etwas, das in den Buchungsstapel geht —, entscheidet die Ampel. Und dahinter steht die Regel, die das Verhältnis von KI und Verantwortung bestimmt: Die Selbsteinschätzung eines Sprachmodells allein setzt einen Buchungssatz nie auf „automatisch“. Ein Modell ist bei einer falsch gelesenen Zahl genauso überzeugt wie bei einer richtigen. Über „automatisch“ entscheiden ausschließlich nachrechenbare Prüfungen.

Die Ampel

Die Gesamtconfidence ist das Minimum der bewerteten Einzelfelder, nicht ihr Durchschnitt. Ein Durchschnitt würde ein einzelnes unsicheres Feld hinter acht sicheren verstecken — genau der Fall, den die Prüfung abfangen soll.

Die Prüfungen

Ein Prüfergebnis hat eine Schwere: blocker verhindert „automatisch“, hinweis wird nur angezeigt. Die Schwere hängt am konkreten Ergebnis, nicht am Namen der Prüfung — eine fehlende IBAN ist ein Hinweis, eine vorhandene mit falscher Prüfsumme ein Blocker. Das ist der Unterschied zwischen „steht nicht drauf“ und „ist falsch“.

Warum ein KI-Vorschlag immer in die Prüfung geht

Weil die Obergrenzen es erzwingen. Ein Gegenkonto aus dem Sprachmodell trägt höchstens 0,84, ein Kreditor aus der Namensähnlichkeit höchstens 0,80 — beide unter der Schwelle von 0,85. Und weil die Gesamtconfidence das Minimum ist, zieht ein solches Feld den ganzen Satz unter die Schwelle. Das ist keine Einstellung, die man versehentlich verschiebt: Der Vorschlag kann seine eigene Bewertung nicht anheben, weil die Grenze nach der Antwort angewendet wird.

Der praktische Nebeneffekt: Der Aufwand fällt einmal je Lieferant an, nicht einmal je Beleg. Nach der ersten Prüfung ist die Zuordnung bekannt, und der nächste Beleg desselben Lieferanten läuft über Schicht (b) — deterministisch und auto-fähig.

7. Korrigieren und Lernen

In der Prüfliste stehen die Sätze, die eine Entscheidung brauchen — mit der Begründung, warum. Zwei Handlungen:

• Bestätigen heißt „der Vorschlag stimmt“.
• Korrigieren heißt „das ist falsch, so ist es richtig“. Der Satz wird als Korrektur markiert.

Der Unterschied wird festgehalten, und zwar aus einem handfesten Grund: Er ist die einzige ehrliche Grundlage für die Frage, wie gut die Automatik wirklich arbeitet. Eine Oberfläche, die beides über einen Knopf abbildet, macht die Fälle im Nachhinein ununterscheidbar. Deshalb sind Korrigieren und Freigeben in der Oberfläche auch zwei Schritte: Wer etwas geändert hat, soll die Änderung noch einmal ansehen.

Nicht korrigierbar sind Betrag und Belegdatum. Sie stehen so auf der Rechnung. Stimmt der Betrag nicht, ist die Extraktion falsch, und die Antwort darauf ist ein neuer Verarbeitungslauf — nicht ein überschriebener Wert, der nirgends mehr mit dem Beleg übereinstimmt.

Was gelernt wird

Bewusst simpel und erklärbar: kein Training, kein zweites Modell, keine Statistik, die niemand nachvollziehen kann. Zwei Mechanismen, die man in einem Satz versteht.

1. Das Kreditor-Default. Tragen die letzten zwei bestätigten Buchungssätze eines Kreditors dasselbe Gegenkonto und weicht es vom bisherigen Default ab, wird das Default nachgezogen und als gelernt gekennzeichnet.

2. Beispiele im Prompt. Bestätigte Sätze desselben Kreditors — sonst die mit dem ähnlichsten Belegtext — gehen als Beispiele in die Kontierung: höchstens zehn insgesamt, höchstens fünf davon vom gleichen Kreditor. So sieht das Modell Ihre Konvention, statt sie zu erraten.

Lernsignale sind ausschließlich bestätigte Sätze. Ein Entwurf in der Prüfliste sagt nichts, solange ihn niemand freigegeben hat. Und beide Mechanismen ändern nur das, was ein Mensch mit einer Freigabe bestätigt hat — Sie können jedes gelernte Default in den Stammdaten von Hand überschreiben, und ein solcher Eintrag wird von späteren Uploads nicht wieder plattgemacht.

8. Regeln und Anweisungen: nachschärfen ohne Programmieren

Manche Konventionen kann man aus keiner Historie ablesen und in keine Kontenliste schreiben. Dafür gibt es zwei Werkzeuge, und beide stehen auf derselben Seite — Regeln und Anweisungen —, weil die Wahl zwischen ihnen dort fällt.

Regeln: Bedingung → Konto, ohne Sprachmodell

Eine Regel hat eine Bedingung und ein Ergebnis. Die Bedingung ist ein Kreditor, eine Liste von Begriffen im Belegtext — einer davon muss vorkommen — oder beides. Das Ergebnis ist ein Gegenkonto und wahlweise ein BU-Schlüssel. Sie wird ohne KI ausgewertet, greift mit 0,95 und darf deshalb ohne Prüfung buchen.

Kreditor 70088 und Belegtext enthält „Porto“   →  4910
Belegtext enthält „Reinigung“                  →  4250

Bei einer automatisch gebuchten Zeile nennt die Prüfansicht, WELCHE Regel entschieden hat und WELCHE Bedingung gegriffen hat — „welche Regel hat gewonnen“ ist die Frage, die ein Buchhalter stellt, wenn ein Ergebnis ihn überrascht, und sie muss beantwortbar sein, ohne eine Liste zu durchsuchen.

Anweisungen: Sätze in normalem Deutsch, immer mit Prüfung

Für alles, was sich nicht in Bedingung und Ergebnis fassen lässt, gibt es Anweisungen: Freitext-Regeln je Mandant, in normalen Sätzen.

Wenn es eine Reisekostenabrechnung ist, muss immer die Person
auf der ersten Seite als Kreditor eingetragen werden.

Das Beispiel ist der Musterfall, weil es ein Problem löst, an dem sonst jede Automatik scheitert. Auf einer Reisekostenabrechnung stehen viele Firmennamen — Hotel, Bahn, Restaurant. Der Kreditor ist aber keiner davon, sondern der Mitarbeiter, der die Auslagen ersetzt bekommt. Es gibt kein Merkmal auf dem Beleg, aus dem sich diese Konvention ableiten ließe; sie muss jemand hinschreiben. Danach gilt sie für jeden solchen Beleg dieses Mandanten.

Eine gute Anweisung nennt eine Bedingung und eine Folge und ist so knapp wie möglich. Je Beleg wird protokolliert, wie viele Anweisungen wirksam waren — bei einem überraschenden Vorschlag ist das der erste Ort, an dem man nachsieht.

Und die Faustregel für die Wahl: Lässt sich der Fall als Bedingung aufschreiben, nehmen Sie eine Regel — nur die spart den Klick. Braucht er einen ganzen Satz, nehmen Sie eine Anweisung — sie spart das Nachdenken, nicht den Klick.

9. Export nach DATEV

Am Ende steht eine Datei: ein DATEV-Buchungsstapel im EXTF-Format für einen Zeitraum. Enthalten sind alle Sätze mit Status auto und bestaetigt; alles auf review bleibt liegen.

Vor dem Schreiben läuft die strengste Prüfung der ganzen Kette — Kontolängen des Mandanten, Gegenkonto in der Kontenliste, „Automatikkonto ⇒ kein BU-Schlüssel“, Wirtschaftsjahr-Grenze. Der Grund ist einfach: Was hier durchgeht, merkt vor dem DATEV-Import niemand mehr.

Festschreibung bleibt ausnahmslos 0. Ein festgeschriebener Stapel ist in DATEV nicht mehr korrigierbar; diese Entscheidung gehört dem Steuerberater und nicht einem Export. Deshalb ist es eine Konstante und keine Option.