David KrauseThis article describes the technical implementation behind the cost-abstraction mapper — the tool that transfers a DATEV trial balance into the 24 nodes of the cost-type plan. It is aimed at technically interested readers; to use the tool itself you need to know none of this.
1 · The problem: posting texts are chaotic
Posting texts arise in day-to-day work — without a scheme, without uniformity. The same matter is described completely differently by different people. This is exactly where classic keyword search fails:
| Posting texts as written | Intended cost type |
|---|---|
| "Regrind cutter 12mm" · "cutter grinding" · "tool reconditioning" · "grinding solid carbide" · "tool repair cutter" | Consumable tooling node 05 |
| "Electricity hall" · "energy Nov." · "power consumption" · "power+heat" · "gas heating production" | Energy costs node 07 |
| "Maintenance machining center" · "maint. machine" · "rep. CNC milling" · "maint. turning center" | Maintenance node 08 |
| "Salary supervisor" · "wage setter" · "pay shift leader" · "remuneration production management" | Indirect wages/salaries node 06 |
Language models are built for exactly this kind of variation. The obvious solution would be to send every posting line to a large cloud model. For accounting data, though, that is the worst of all options — more on that shortly.
2 · The architecture: rule before model
The most important design principle is: the language model is the last resort, not the first. Every posting line passes through three layers and leaves the system as soon as an assignment is settled.
Nine of ten lines are handled by rules you can read, check and correct. The model only processes the difficult remainder. That keeps the share of the system that stays fundamentally unexplainable small and bounded — and an error in the model can only distort the overall result to a limited degree. Whoever works the other way around and hands everything to the model has built a system whose results they can no longer justify. In cost accounting, that is disqualifying.
3 · Why a small model — and why local
For the task "assign a short German text to one of 24 categories" you don't need a model with hundreds of billions of parameters. A compact model of the 0.5-billion class (in the prototype: Qwen2-0.5B, openly licensed) is enough once it is fine-tuned for the task. The advantages are considerable:
| Criterion | Local 0.5B model | Cloud model |
|---|---|---|
| Data outflow | none — runs offline | posting data leaves the building |
| Hardware | CPU, under 2 GB RAM | none of your own needed |
| Cost per query | €0.00 | API fee per line |
| Availability | independent of network and provider | dependent on both |
| General language understanding | limited | markedly better |
| Fine-tuning on own data | possible, low effort | usually not possible |
The data-protection point is not a side issue. A trial balance contains salary totals, supplier relationships and margin data. Transmitting it to an external service raises data-processing questions that simply don't arise when the processing never leaves the machine.
4 · LoRA: fine-tuning without a data center
A base model does not know cost accounting. It has to learn that "regrind" belongs to node 05 and "trade tax" to the neutral abstraction. The classic route would be to retrain all model weights — expensive and unrealistic for a small team.
LoRA (Low-Rank Adaptation) takes a different path. The original weights stay frozen. Instead, small additional matrices are trained that sit alongside the existing layers and shift their behavior. The mathematical trick: this adjustment can be represented as the product of two very narrow matrices — instead of a full matrix with millions of entries, two with a few thousand suffice.
W0 stays unchanged — only B·A is trained
Practical consequences: training runs on an ordinary graphics card instead of a cluster. The result is an adapter of a few megabytes, not a whole new model. And you can keep several adapters for different tasks on hand and load them by context — the same base model, different specializations.
The demanding part is not the training but the labeling: every historical posting text needs the correct cost type and BAB column — following the same allocation rules a human applies. Whoever works sloppily here trains in their own errors. A model is only ever as good as the system you show it.
5 · Quantization: from gigabytes to megabytes
A trained model usually stores its weights as 16- or 32-bit floating-point numbers. For the classification task, that precision is waste. In quantization, the weights are mapped to coarser number formats — often 4 bits per weight, block-wise with their own scaling factors so the error stays small.
| Format | Bits/weight | Size (0.5B model) | In practice |
|---|---|---|---|
| FP16 training format | 16 | ~1.0 GB | reference for quality comparisons |
| INT8 | 8 | ~0.5 GB | quality loss practically unmeasurable |
| Q4 4-bit, block-wise | ~4.5 | ~300 MB | proven compromise for CPU operation |
The effect is twofold: the model fits into the memory of an ordinary office PC, and it gets faster — because at these model sizes the bottleneck is not compute but memory bandwidth. Fewer bytes per weight directly means shorter response times.
6 · ONNX: decoupling the model from the training framework
A model is developed in a training framework but is meant to run in an application — ideally without that application dragging the entire training environment along. ONNX (Open Neural Network Exchange) is a vendor-independent exchange format: the trained model — including the merged-in LoRA adapter — is exported as a computation graph and executed by a lean runtime.
For a tool meant to be installed at a company, this is the decisive step toward maintainability: one model file, one runtime library, no Python dependency chains that break at the next update.
7 · What the system does — and what it doesn't
On a validation set of 80 posting lines not contained in the training, the prototype achieved the following values:
| Metric | Result | Meaning |
|---|---|---|
| Hit rate | 93.7 % | 75 of 80 lines assigned correctly |
| Avg. confidence | 87.3 % | basis for the 85 % threshold for manual review |
| False-neutral rate | 0.0 % | no real cost item wrongly excluded |
80 examples are a proof of function, not a robust statistic. The data set comes from one type of company; with a different account structure or posting practice, the values can deviate markedly. The most meaningful figure is the third anyway: that no real cost item was wrongly classified as neutral matters more than the overall hit rate — because excluded costs are missing from the hour rate later and no one notices.
8 · The limits — and why they should stay
Three things this system cannot do, and for two of them it would be a mistake to try:
- 1It does not decide. Assigning a posting to a cost type is a business determination with consequences for costing and price. The tool proposes; the human remains responsible. Every assignment must be overridable.
- 2It does not calculate. Language models are unsuited to processing numbers — they produce plausible-looking results without a computation path. Every amount in the tool comes from deterministic code, not from the model. The model assigns, nothing more.
- 3It does not know your company. Whether a supervisor's salary is manufacturing overhead or administration depends on the organization. Such determinations belong in the rule set of layer 1 — where they are documented and justifiable.
The value of this technology is not in replacing the cost accountant but in taking the mechanical pre-sorting off their hands — so they spend their time on the cases that truly require judgment. Whoever starts out expecting the system to take over cost accounting will be disappointed. Whoever uses it as a pre-sorter with a review obligation gains real time.
9 · Effort and benefit — soberly
Building such a system costs primarily time for labeling and rule maintenance, not money for hardware; an ordinary office PC suffices. The time saved in ongoing use amounts, for a monthly abstraction, to a few hours — appreciable, but not an order of magnitude that saves a position.
Robust ROI figures are difficult here: they depend on the number of posting lines, the account structure and how cleanly the work was done beforehand. Whoever presents a three-digit return extrapolates from a handful of assumptions. More realistic is the view that the effort pays off through consistency: an abstraction performed every month by the same rules, with documented assignments, is worth more than a few hours saved — because it is what makes comparability across periods possible in the first place.
This article summarizes the technical chapters from Part VI of the book. The methodological framing remains in the book (Chapter 18); the implementation details are here because they date faster than the cost-accounting part.
