David Krause18.1 Cloud AI or local AI?
| Criterion | Local model | Cloud model |
|---|---|---|
| Data outflow | none — runs offline | booking data leaves the house |
| Cost per request | €0.00 | 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 | mostly not possible |
A trial balance contains salary totals, supplier relationships and margin data. Transmitting it to an external service raises data-processing questions that simply do not arise when the processing never leaves the machine.
18.2 The architectural principle: rule before model
The most important design principle is: the language model is the last instance, not the first. Every booking line passes through three layers and leaves the system as soon as an allocation is settled.
| Layer | Method | Share |
|---|---|---|
| 1 | account-number lookup — SKR03 account 4110 is always direct labor | ~75 % |
| 2 | rule set on the booking text | ~15 % |
| 3 | language model with confidence threshold | ~8 % |
Nine out of ten lines are handled by rules that can be read, checked and corrected. That keeps the unexplainable share small and contained. Whoever does it the other way round has built a system whose results they can no longer justify — to the auditor as much as to management.
18.3 Three sensible use cases
Not every task is suited to AI. It makes sense where many similar cases are decided by clear rules — with an AI fallback only for the borderline cases.
| Use case | Task | Approach | Time saved |
|---|---|---|---|
| SKR account allocation | regrind account → tooling costs (not maintenance!) | rule-based + AI fallback | 4–5 h → <30 min |
| Booking-text classification | "mill regrind" → cost type 05 | LoRA on company vocabulary | 6 h → <15 min |
| Cost-cutoff proposal | neutral vs. operational expense | rule set + classifier | 3 h → <20 min |
18.4 Quantification: what local AI brings — in euros and hours
The use cases above can be quantified. The basis is the reference company; the assumptions are deliberately conservative.
18.4.1 Time saved before / after
| Task | manual | with AI | saving |
|---|---|---|---|
| Allocate DATEV export to cost types (300–500 lines) | 4–6 h | <10 min | ~5.5 h |
| Classify booking texts | 6 h | <15 min | ~5.75 h |
| Check cost cutoff on trial balance | 3 h | <20 min | ~2.7 h |
| Total per monthly close | ~14 h | ~0.75 h | ~13 h |
18.4.2 Investment costs
| Item | one-off | recurring | Note |
|---|---|---|---|
| Hardware: mini-PC / NUC (32 GB RAM) | €400–700 | €0 | unlimited runtime |
| Software: Python, Transformers, ONNX | €0 | €0 | open source, no license |
| Setup / fine-tuning (one-off) | €400 | €0 | or in-house |
| Total | ~€1,100 | €0/year | no running costs |
18.4.3 ROI calculation
Saving/month = 8 h × €60/h = €480
Saving/year = €480 × 12 = €5,760
Payback = €1,100 / €480 = < 2.3 months
ROI year 1 = (5,760 − 1,100) / 1,100 = 424 %
The figures apply to a company with a regular monthly close and recurring allocation effort. For smaller companies with few bookings the absolute saving is lower — but the investment stays low, so the build-up usually still pays for itself within a year. What matters is not the ROI percentage but that recurring, error-prone hand work disappears.
18.5 GDPR checklist: using local AI in a legally sound way
Even with local AI — where no data leaves the company — there are data-protection requirements. "AUTO" means: local AI meets the point automatically; "TODO" means action needed.
- ✓No data transfer to third parties — all data stays on your own serverAUTO
- ✓No data-processing agreement needed (no external provider)AUTO
- ✓No third-country transfer (US cloud eliminated)AUTO
- ☐Manage access rights to the AI machine in the authorization conceptTODO
- ☐Add the processing activity to the Art. 30 recordTODO
- ☐Deletion concept also for local training/cache dataTODO
18.6 The limits — and why they should stay
- 1It does not decide. Allocating a booking is a business determination with consequences for costing and price. The human veto is a design condition, not a comfort feature.
- 2It does not calculate. Language models produce plausible-looking results without a checkable calculation path. All amounts come from deterministic code.
- 3It does not know your company. Whether a supervisor's salary is manufacturing overhead or administration depends on the organization — that belongs in layer 1, documented and justifiable.
The technical implementation — model selection, LoRA fine-tuning, quantization, ONNX export — is deliberately not in the book, because it goes out of date within months. You will find it as a separate article, together with the cost-cutoff mapper (in German) to try out directly.
