Case study · document processing
Receipt capture, account assignment and tax filing, automated.
Document processing · bookkeeping · ELSTER
Receipts arrived as PDFs, as photos and as email attachments — and every line was entered by hand. The result is a system that reads the receipt, knows the account assignment from history, and files the tax return directly with the tax office.
Project facts
- Client
- Techlogia — sole proprietorship, Berlin
- Sector
- IT services, several business units
- Timeframe
- in production since December 2025
- Scope
- Receipt capture, learned account assignment, income-surplus reporting, ELSTER submission via ERiC, GoBD audit log
We keep running the system ourselves and work with it every day. What is described here comes from daily use — not from a hand-over after which nobody looks again.
Starting point
Every line by hand, month after month
Receipts arrive as PDFs, as camera photos, as email attachments. For each one, five fields were entered by hand: supplier, document date, gross amount, VAT rate, category. The effort grows steadily with the number of receipts, and the mistakes always happen in the same places — transposed digits in the amount, the wrong tax rate, and with foreign suppliers the overlooked reverse charge under section 13b of the German VAT Act.
Implementation
Three layers — and only one of them costs AI
The obvious solution would have been to send every receipt through a model. We deliberately did not: it costs money on every single receipt, and something simpler covers most of the work.
- 01
Layer 1 — The AI reads the receipt
A vision model receives the PDF or the photo and returns a JSON object: supplier, date, gross amount, tax rate, category — plus whether this is a foreign service, and its own confidence. Answers that do not match the permitted values are discarded rather than guessed; the field then stays empty and a person decides.
- 02
Layer 2 — Categorisation learns from history
If a supplier has been assigned a category before, the system proposes the same one again. That is a plain database query: deterministic, traceable, with no model call and no cost. A safeguard belongs to it — a single booking is not enough; only from the second does an assignment count as practice. Otherwise a one-off mistake cements itself.
- 03
Layer 3 — A knowledge store instead of a vector database
Tax rules looked up once and business-specific decisions sit as topics in an ordinary table and go into the prompt before the query. For a business with a manageable number of rules, that needs no vector database — that would be extra infrastructure for someone to run and keep current.
The principle: the machine proposes, a person confirms
No receipt is booked without confirmation. The system fills in the form, a person checks and saves. In bookkeeping that is not caution but obligation — and it is why a misreading here never becomes a silent error in the books.
Result
94 percent run without an AI call
After a good six months in operation, 94 percent of bookings benefit from the deterministic layer — no model call is needed for them. The AI is needed for the rest: new suppliers, unusual receipts, cross-border cases. That is exactly where it earns its keep, and exactly where a rule would not have helped.
What is published is a share. Receipt volumes and amounts from the client's bookkeeping stay confidential — here as in any other project.
94 %
of bookings draw on a learned assignment
Filing with the tax office
ELSTER via ERiC — the part almost nobody builds themselves
Most solutions stop at the export and leave the rest to the accountant or a form in the browser. We submit directly through ERiC, the official library behind ELSTER.
A native library on ARM servers
ERiC is not available for the ARM architecture our servers run on. Rather than lifting the whole application to x86 for it, the library runs in a small separate service alongside. The application sends it XML and the data type; it validates or submits and answers. If it is not set up, the feature switches off cleanly instead of throwing errors.
Validate first, then submit
Every submission runs in two stages: validate without sending, and only then send. What the tax office returns — return code and transfer ticket — is stored as proof, together with the raw response. Without a transfer ticket a filing counts as not having happened.
Verified labels instead of guessed line numbers
The line numbers of the official income-surplus form change from year to year; one new line shifts all the following ones. The export therefore outputs the semantic position labels, not the numbers. That is less convenient and still correct next year.
Data protection
What goes where
In document processing this is the first question a business asks — so the answer is here in full.
- 01
If someone uses the AI capture, the receipt image is transmitted to the model provider. That is processing outside the EU and must be agreed before use.
- 02
The learned categorisation, the knowledge store and the entire bookkeeping work without that transfer. Anyone who leaves the AI capture switched off loses convenience, not function.
- 03
The submission to the tax office leaves our network only towards ELSTER. The ERiC service is not reachable from outside.
- 04
Every creation, finalisation and cancellation lands in an unalterable log — traceable under the German GoBD rules.
In use
Technology
- Python
- FastAPI
- SQLAlchemy
- Claude Vision
- MariaDB
- ERiC (ELSTER)
- Docker
- Hetzner (Falkenstein/Nürnberg)
Transferable?
What of this matters for a client project
Receipts are just one example. The same split works wherever documents have to become structured data: delivery notes, forms, orders, emails. What matters is not the model but the question of which part of the work genuinely needs one — and which part a rule solves more cheaply, faster and more traceably.
Get in Touch
Have a project?
Let's bring your idea to life together. We're happy to advise you with no obligation.