It usually begins with a simple table. A few rows, a few columns—enough to keep track of things. You know what came in, what went out, and who was responsible for what.
A year later, the table has become a system. Two years later, it’s several systems that are supposed to talk to one another but only partly do. And eventually, someone is sitting there at the end of the month trying to figure out why two numbers don’t match even though they’re supposed to describe the same thing.
This isn’t an isolated case. It’s the normal state of commercial software.
The more a company grows, the more systems get added. One for invoices, one for payments, one for inventory, one for customers. Each one works on its own. But gaps emerge between them—small inconsistencies that only become visible when someone brings all the numbers together. And that’s when the real work begins: not running the business, but checking the business. Posting adjustments. Reconciling. Looking for errors that nobody made intentionally but that still exist because no system truly trusts another.
The Pain
Most commercial systems are designed to manage numbers. They store what happened. They calculate totals, generate documents, and export reports. What they rarely do is explain why a number is what it is. Who caused it. Which decision lies behind it. Which other number it is connected to.
That leads to a peculiar contradiction. Every year the software becomes more capable, faster, more comprehensive—and at the same time, trust in what it produces declines. Not because it calculates incorrectly. But because once a number has passed through three or four different systems, nobody can say exactly how it came to be. So people check it. Verify it. A second system builds checksums for the first. And at the end of the chain, a person manually compares what the machines should have resolved long ago.
Control becomes the answer to distrust. And distrust emerges because systems grow without their traceability growing with them. You end up with more software—but not with greater confidence that it’s correct.
For a small company, that’s annoying. For a growing company, it becomes the real cost factor: time that doesn’t go into the business itself, but into verifying the business. People whose job is to repair what the systems themselves could have prevented.
Our Question
What if commercial software didn’t manage numbers first, but responsibility? Not: What is the amount? But: Who made this decision, and for what reason? What if every accounting entry were more than just a result? What if it remained visible how it came into being—which other decision it is connected to, which process triggered it?
Maybe commercial software doesn’t need better control. Maybe it needs more trust—but trust that can be justified because the relationships between decisions remain intact instead of disappearing into separate systems.
That question is what led to Steuerjan.
A Different Assumption
Steuerjan doesn’t assume that a number stands on its own. It assumes that every commercial decision is part of a larger context—an invoice is connected to a delivery, a delivery to an order, an order to a customer’s request. If those relationships remain intact instead of being lost at every system boundary, you no longer have to guess at the end of the month why something is the way it is. You can trace it.
That changes the fundamental question of commercial software. It’s no longer: How do we prevent someone from making a mistake? Instead it becomes: How do we ensure that every decision keeps its own story, so that if a mistake happens, it becomes visible immediately instead of remaining hidden for months?
Control assumes distrust. You check because you don’t know whether something is correct. Responsibility assumes something different: that at any moment, you can trace who made a decision and why. One approach tries to find errors afterward. The other tries to keep them visible from the very beginning.
That also means that once a decision has been made, it cannot later be changed without leaving a trace. Not because the people working with the system aren’t trusted, but because a number only has value if it is certain that it has remained unchanged since the moment it came into existence. Once something has been recorded, it remains traceable—even if it later turns out that a correction is necessary. The correction then becomes part of the story itself, not its replacement. That is exactly what ultimately makes a system credible to third parties, without ever having to claim that credibility explicitly.
For a company, that doesn’t mean less diligence. It means a different kind of diligence—one that doesn’t begin at the end of the chain, but accompanies every step from the start because it is built into the structure of the software instead of being added afterward.
What Remains
Whether this will actually prove itself in the day-to-day life of a growing company the way it feels in theory remains to be seen. Steuerjan is still in its early stages, much remains open, and some ideas will likely turn out to be too ambitious. But the question behind it remains, regardless of what the tool ultimately becomes.
Maybe the real difference between control and trust isn’t how much you verify. Maybe it’s whether you still need to verify anything at all in order to know what’s true.
