David KrauseDieser Artikel beschreibt die technische Umsetzung hinter dem Abgrenzungs-Mapper — dem Werkzeug, das eine DATEV-Summen- und Saldenliste in die 24 Knoten des Kostenartenplans überführt. Er richtet sich an Leser mit technischem Interesse; für die Anwendung selbst muss man nichts davon wissen.
1 · Das Problem: Buchungstexte sind chaotisch
Buchungstexte entstehen im Tagesgeschäft — ohne Schema, ohne Einheitlichkeit. Derselbe Sachverhalt wird von verschiedenen Personen völlig unterschiedlich beschrieben. Genau daran scheitert die klassische Stichwortsuche:
| Buchungstexte im Original | Gemeinte Kostenart |
|---|---|
| „Nachschliff Fräser 12mm" · „Fräser Schliff" · „WZ Aufbereitung" · „Schleifen VHM" · „Werkzeug Reparatur Fräser" | Verbrauchswerkzeuge Knoten 05 |
| „Strom Halle" · „Energie Nov." · „EL Verbrauch" · „Strom+Wärme" · „Gas Heizung Produktion" | Energiekosten Knoten 07 |
| „Wartung BAZ" · „Instandh. Maschine" · „Rep. CNC Fräsen" · „IH Drehzentrum" | Instandhaltung Knoten 08 |
| „Gehalt Meister" · „Lohn Einrichter" · „Bezüge Schichtführer" · „Vergütung Fertigungsleitung" | Hilfslöhne/Gehälter Knoten 06 |
Sprachmodelle sind für genau diese Art von Variation gebaut. Die naheliegende Lösung wäre, jede Buchungszeile an ein großes Cloud-Modell zu schicken. Für Buchhaltungsdaten ist das aber die schlechteste aller Optionen — dazu gleich mehr.
2 · Die Architektur: Regel vor Modell
Der wichtigste Entwurfsgrundsatz lautet: Das Sprachmodell ist die letzte Instanz, nicht die erste. Jede Buchungszeile durchläuft drei Schichten und verlässt das System, sobald eine Zuordnung feststeht.
Neun von zehn Zeilen werden von Regeln erledigt, die man lesen, prüfen und korrigieren kann. Das Modell bearbeitet nur den schwierigen Rest. Damit ist der Anteil des Systems, der prinzipiell unerklärbar bleibt, klein und eingegrenzt — und ein Fehler im Modell kann das Gesamtergebnis nur begrenzt verfälschen. Wer umgekehrt vorgeht und alles ans Modell gibt, hat ein System gebaut, dessen Ergebnisse er nicht mehr begründen kann. In der Kostenrechnung ist das disqualifizierend.
3 · Warum ein kleines Modell — und warum lokal
Für die Aufgabe „ordne einen kurzen deutschen Text einer von 24 Kategorien zu" braucht es kein Modell mit hunderten Milliarden Parametern. Ein kompaktes Modell der 0,5-Milliarden-Klasse (im Prototyp: Qwen2-0.5B, offen lizenziert) reicht aus, sobald es auf die Aufgabe feinjustiert ist. Die Vorteile sind erheblich:
| Kriterium | Lokales 0,5B-Modell | Cloud-Modell |
|---|---|---|
| Datenabfluss | keiner — läuft offline | Buchungsdaten verlassen das Haus |
| Hardware | CPU, unter 2 GB RAM | keine eigene nötig |
| Kosten je Anfrage | 0,00 € | API-Entgelt je Zeile |
| Verfügbarkeit | unabhängig von Netz und Anbieter | abhängig von beidem |
| Sprachverständnis allgemein | begrenzt | deutlich besser |
| Feintuning auf eigene Daten | möglich, geringer Aufwand | meist nicht möglich |
Der Datenschutzpunkt ist kein Nebenaspekt. Eine Summen- und Saldenliste enthält Gehaltssummen, Lieferantenbeziehungen und Margendaten. Sie an einen externen Dienst zu übertragen, wirft Fragen zur Auftragsverarbeitung auf, die sich schlicht nicht stellen, wenn die Verarbeitung den Rechner nie verlässt.
4 · LoRA: Feintuning ohne Rechenzentrum
Ein Basismodell kennt die Kostenrechnung nicht. Es muss lernen, dass „Nachschliff" zu Knoten 05 gehört und „Gewerbesteuer" in die neutrale Abgrenzung. Der klassische Weg wäre, alle Modellgewichte neu zu trainieren — teuer und für ein kleines Team unrealistisch.
LoRA (Low-Rank Adaptation) geht anders vor. Die ursprünglichen Gewichte bleiben eingefroren. Stattdessen werden kleine Zusatzmatrizen trainiert, die neben den bestehenden Schichten liegen und deren Verhalten verschieben. Der mathematische Kniff: Diese Anpassung lässt sich als Produkt zweier sehr schmaler Matrizen darstellen — statt einer vollen Matrix mit Millionen Einträgen genügen zwei mit wenigen tausend.
W0 bleibt unverändert — trainiert wird nur B·A
Praktische Folgen: Das Training läuft auf einer gewöhnlichen Grafikkarte statt auf einem Cluster. Das Ergebnis ist ein Adapter von wenigen Megabyte, nicht ein neues Gesamtmodell. Und man kann mehrere Adapter für verschiedene Aufgaben vorhalten und je nach Kontext laden — dasselbe Basismodell, unterschiedliche Spezialisierungen.
Der aufwendige Teil ist nicht das Training, sondern das Labeling: Jeder historische Buchungstext braucht die korrekte Kostenart und BAB-Spalte — nach denselben Kontierungsregeln, die auch der Mensch anwendet. Wer hier unsauber arbeitet, trainiert seine eigenen Fehler ein. Ein Modell ist immer nur so gut wie die Systematik, die man ihm zeigt.
5 · Quantisierung: von Gigabyte zu Megabyte
Ein trainiertes Modell speichert seine Gewichte üblicherweise als 16- oder 32-Bit- Gleitkommazahlen. Für die Klassifikationsaufgabe ist diese Genauigkeit Verschwendung. Bei der Quantisierung werden die Gewichte auf grobere Zahlenformate abgebildet — häufig 4 Bit pro Gewicht, blockweise mit eigenen Skalierungsfaktoren, damit der Fehler klein bleibt.
| Format | Bits/Gewicht | Größe (0,5B-Modell) | Praxis |
|---|---|---|---|
| FP16 Trainingsformat | 16 | ~1,0 GB | Referenz für Qualitätsvergleiche |
| INT8 | 8 | ~0,5 GB | Qualitätsverlust praktisch nicht messbar |
| Q4 4-Bit, blockweise | ~4,5 | ~300 MB | bewährter Kompromiss für CPU-Betrieb |
Der Effekt ist doppelt: Das Modell passt in den Arbeitsspeicher eines gewöhnlichen Bürorechners, und es wird schneller — weil bei diesen Modellgrößen nicht die Rechenleistung der Engpass ist, sondern die Speicherbandbreite. Weniger Bytes je Gewicht heißt direkt kürzere Antwortzeiten.
6 · ONNX: das Modell vom Trainingsrahmen lösen
Ein Modell wird in einem Trainings-Framework entwickelt, soll aber in einer Anwendung laufen — idealerweise ohne dass diese Anwendung die gesamte Trainingsumgebung mitschleppen muss. ONNX (Open Neural Network Exchange) ist ein herstellerunabhängiges Austauschformat: Das trainierte Modell — inklusive des eingerechneten LoRA-Adapters — wird als Rechengraph exportiert und von einer schlanken Laufzeitumgebung ausgeführt.
Für ein Werkzeug, das in einem Betrieb installiert werden soll, ist das der entscheidende Schritt zur Wartbarkeit: eine Modelldatei, eine Laufzeitbibliothek, keine Python-Abhängigkeitsketten, die bei der nächsten Aktualisierung brechen.
7 · Was das System leistet — und was nicht
Auf einem Validierungsdatensatz von 80 Buchungszeilen, die nicht im Training enthalten waren, erreichte der Prototyp folgende Werte:
| Metrik | Ergebnis | Bedeutung |
|---|---|---|
| Trefferquote | 93,7 % | 75 von 80 Zeilen korrekt zugeordnet |
| Ø Konfidenz | 87,3 % | Grundlage der 85-%-Schwelle für manuelle Prüfung |
| Falsch-Neutral-Rate | 0,0 % | keine echte Kostenposition fälschlich ausgesondert |
80 Beispiele sind ein Funktionsnachweis, keine belastbare Statistik. Der Datensatz stammt aus einem Betriebstyp; bei anderer Kontenstruktur oder anderer Buchungspraxis können die Werte deutlich abweichen. Die aussagekräftigste Zahl ist ohnehin die dritte: Dass keine echte Kostenposition fälschlich als neutral eingestuft wurde, ist wichtiger als die Trefferquote insgesamt — denn ausgesonderte Kosten fehlen später im Stundensatz und fallen niemandem auf.
8 · Die Grenzen — und warum sie bleiben sollen
Drei Dinge kann dieses System nicht, und bei zweien davon wäre es ein Fehler, es zu versuchen:
- 1Es entscheidet nicht. Die Zuordnung einer Buchung zu einer Kostenart ist eine betriebswirtschaftliche Festlegung mit Konsequenzen für Kalkulation und Preis. Das Werkzeug schlägt vor; verantwortlich bleibt der Mensch. Jede Zuordnung muss überschreibbar sein.
- 2Es rechnet nicht. Sprachmodelle sind für Zahlenverarbeitung ungeeignet — sie erzeugen plausibel aussehende Ergebnisse ohne Rechenweg. Sämtliche Beträge im Werkzeug stammen aus deterministischem Code, nicht aus dem Modell. Das Modell ordnet zu, mehr nicht.
- 3Es kennt Ihren Betrieb nicht. Ob ein Meistergehalt Fertigungsgemeinkosten oder Verwaltung ist, hängt von der Organisation ab. Solche Festlegungen gehören in das Regelwerk der Schicht 1 — dort sind sie dokumentiert und begründbar.
Der Nutzen dieser Technik liegt nicht darin, den Kalkulator zu ersetzen, sondern darin, ihm die mechanische Vorsortierung abzunehmen — damit er seine Zeit auf die Fälle verwendet, die tatsächlich Urteilsvermögen erfordern. Wer mit der Erwartung startet, das System werde die Kostenrechnung übernehmen, wird enttäuscht. Wer es als Vorsortierer mit Prüfpflicht einsetzt, gewinnt real Zeit.
9 · Aufwand und Nutzen — nüchtern
Der Aufbau eines solchen Systems kostet in erster Linie Zeit für Labeling und Regelpflege, nicht Geld für Hardware; ein gewöhnlicher Bürorechner genügt. Die Zeitersparnis in der laufenden Anwendung liegt bei einer monatlichen Abgrenzung im Bereich weniger Stunden — nennenswert, aber keine Größenordnung, die eine Stelle einspart.
Belastbare ROI-Angaben sind an dieser Stelle schwierig: Sie hängen von der Zahl der Buchungszeilen, der Kontenstruktur und davon ab, wie sauber vorher gearbeitet wurde. Wer eine dreistellige Renditezahl präsentiert, extrapoliert aus einer Handvoll Annahmen. Realistischer ist die Betrachtung, dass sich der Aufwand über die Konsistenz rechnet: Eine Abgrenzung, die jeden Monat nach denselben Regeln erfolgt und deren Zuordnungen dokumentiert sind, ist mehr wert als ein paar eingesparte Stunden — weil sie Vergleichbarkeit über Perioden erst herstellt.
Dieser Artikel fasst die technischen Kapitel aus Teil VI des Fachbuchs zusammen. Im Buch verbleibt die methodische Einordnung (Kapitel 18); die Umsetzungsdetails stehen hier, weil sie schneller veralten als der kostenrechnerische Teil.