The trigger was not the price, it was the typing
Renting bookkeeping software costs under ten euros a month. Nobody fails at that. What actually hurts is the work the software leaves behind.
The routine looked like it does in most small firms: download the bank statement, collect receipts, assign every item by hand, review everything again at the end of the quarter. The software adds up correctly, but it does not do the assigning, and the assigning is the work. At roughly a thousand entries a year that is several evenings nobody schedules and that always arrive at the wrong moment.
The second point matters more and only shows up later: the data sits in someone else's system, in a shape you do not control. While everything works, that is irrelevant. The moment you want to do something of your own with it, an analysis the vendor did not anticipate, it stops.
What the system takes over, and where it stops
It pulls bank transactions, matches them against a pattern, proposes an assignment and then waits. Confirmation is manual.
Bank transactions arrive on their own
Every morning the connected accounts are pulled. There are currently 1,066 entries on file. No export, no CSV, no uploading. This is the part that saves the most time and is the least interesting to build.
dailyAssignment is proposed, not decided
Recurring entries are recognised by pattern and an assignment is proposed. The proposal stays open until a human confirms it. That order is not a convenience; under German tax-advice law it is the line that must not be crossed.
importantInvoice numbers cannot develop gaps
Outgoing invoices are produced in the same system and numbered sequentially. A gap in the sequence is the first thing an audit asks about; it cannot arise if the number is issued at creation rather than typed by a person.
Receipts have a state
Every receipt is either open, checked or assigned. That sounds trivial, but it is the difference between bookkeeping and a folder. You can see what is outstanding at any time instead of finding out in December.
No third-party libraries
The system runs on the language's standard library, with no purchased packages. That is unusual and was a deliberate choice: what has no dependencies cannot break when someone else's library updates. A bookkeeping system has to still start in eight years.
deliberateWhat you must not do, and why that is commercially right anyway
This is where it stops being fun for vendors. Deciding for someone else how a receipt is to be booked is assistance in tax matters, and that requires a licence in Germany.
Section 6 no. 3 of the German Tax Consultancy Act permits mechanical steps in keeping books, and explicitly excludes two things from that permission: coding receipts and issuing booking instructions. No. 4 permits booking ongoing transactions, but only for people with a commercial qualification and at least three years of practice in bookkeeping.
For a software house the consequence is simple. A program may propose. A person from the software house may not confirm on the client's behalf. So every proposal stays open until the business itself agrees, and nothing is filed without that agreement. This is not a cautious reading, it is how every vendor in this market operates.
What is worth noticing is that the same line is the better business. Doing bookkeeping for others is selling hours: every additional client brings as much work as the first. Building a system is work once and operation afterwards. The law pushes you in the direction you should be going anyway.
A program may propose. The business must confirm. That single ordering is what separates delivering software from giving tax advice.
The three requirements where building your own actually fails
The programming is not the hard part. The hard part is the obligations that only surface when an audit asks about them.
All three are solvable, none is secret, and none solves itself. Anyone considering building their own should answer these first and think about programming second, not the other way round.
Immutability
Once recorded, an entry must not be changeable without a trace. A correction has to remain visible as a correction, with the original content alongside it. Retrofitting this rebuilds half the system; designing for it costs almost nothing. This is where home-grown solutions fail most often.
GoBDProcess documentation
How the bookkeeping works has to be written down: where data comes from, who confirms what, how backups run, what happens when something fails. For a self-built system this documentation is not optional, and unlike with purchased software nobody supplies it. It has to be written, and it has to be true.
GoBDRetention across years
Booking records must be retained far longer than a typical software project lives. The question is not whether the system runs today, but whether the data is still readable in eight years when nobody remembers how it was built. That is the real reason for avoiding third-party libraries.
When it pays off, and where the limit sits
We would do it again and we build it for others too. There is one condition, and it has nothing to do with company size.
The condition is repetition. A system pays off as soon as the same transaction occurs often enough in the same shape for a pattern to describe it. For us that is several hundred entries a year, almost all following the same handful of patterns. Where that repetition is missing, no system helps, because a system can only propose what it has seen before. Four cases where we advise against it:
- When every transaction looks different. Volume is not the deciding factor, recurrence is. A hundred near-identical receipts is a good case; twenty completely different ones is not.
- While the processes are still moving. A system encodes what is stable today. Rebuilding your business model at the same time cements a state that will not exist in six months.
- If nobody in the company can touch the system later. A solution only one person understands is a risk, not an asset.
- If bookkeeping already sits entirely with your accountant and works well there. Then bookkeeping is not the bottleneck, and the money belongs where things actually jam.
- If the expectation is paying less tax. A system changes nothing about what is taxable. It changes how much time recording costs and how quickly you know where you stand.
What carries over to other processes
Bookkeeping is only the example here. The pattern holds for any process where a person walks the same road from A to B over and over.
What matters is not whether a task is complicated, but whether it repeats and whether it ends in a judgement a human has to make. The repeating part belongs in the system. The judgement stays with the person and is presented to them, instead of making them go looking for it.
We made exactly that split measurable in our ongoing index of routine office work: each month we count how much salary German mid-sized companies advertise for roles whose core tasks the German labour-market institute rates as automatable. The data sits openly alongside so anyone can recheck it.
If you are facing the same decision, the trade-off between building it yourself and having it operated is set out under build it yourself or have it operated.