Standardised Reporting: From Rolf Hichert to ISO 24896 and TRUECHART+
I still remember the exact feeling of that afternoon.
I was sitting across from Rolf Hichert. He spoke quietly, almost academically, about something most people in our industry treated as a matter of taste: charts, tables, colours, layouts. He was not interested in making reports look nicer. He was interested in making them mean the same thing every time, for every reader, under pressure.
“What looks the same must mean the same.”
That sentence stayed with me. It was the moment the direction of my professional life quietly changed.
At the time, I was already deep in the world of management information and planning systems. I had seen enough board packs and monthly reports to know that the visual language was usually the weakest link. Different teams used different colours for the same scenarios. Axes were truncated when it suited the narrative. Variances were shown in ways that made the story easier to sell. The numbers themselves might have been correct, but the way they were presented was not always reliable. Under time pressure, that unreliability became risk.
Rolf had already spent years turning this observation into a coherent system. The ideas that later became the International Business Communication Standards and now underpin ISO 24896 were still taking clearer shape then. For me, it was not theory. It was a practical challenge I could not ignore: if reporting is supposed to support decisions, then the notation itself has to be as rigorous as the underlying data.
That is where the story of TRUECHART really begins.
The Early Years of TRUECHART Around Lake Constance
The first versions were built in our home region around Lake Constance. Small team. Limited budget. A lot of late nights and a stubborn belief that this had to be possible.
Existing BI tools were not designed for proper semantic notation. You could force certain visual conventions with enough effort, but the moment the underlying platform was updated or a new requirement arrived, the consistency collapsed.
Customers often liked the idea of clearer reports until they realised it meant giving up their favourite decorative charts or the freedom to “shape” the visual story. Internal discussions were sometimes harder than external ones. “Do we really need solid, outlined and hatched?” “Is it worth the fight to kill the pie charts and the traffic lights?”
We kept going because the alternative felt worse: accepting that reporting would remain a soft, political layer on top of hard numbers.
I did not want another consulting offering that produced nice slides for a few weeks and then faded. I wanted the standard to become executable, something that lived in the software so that ordinary report creators could apply it without becoming notation experts themselves.
Those Lake Constance years were not glamorous. They were the necessary foundation. Many of the core ideas that still sit at the heart of the product family, consistent scenario coding, proper scaling, clean variance displays and the refusal to treat visualisation as decoration, were forged there under real constraints.
Turning Standardised Reporting Into Software
Consulting alone was never going to be enough. As long as the knowledge lived primarily in the heads of a few certified people, the standard remained fragile. It had to live in the code.
So we made the decision to build a full software development capability alongside the consulting business. Erfurt became that place.
Protecting a product team from the daily pressure of client delivery while still keeping them close enough to real reporting problems is harder than it sounds. We had to create space for deep technical work without losing the connection to the actual pain points of controllers, CFOs and management teams.
In Erfurt, the engine matured. The charting logic, the layout rules, the early collaboration features and the stubborn insistence on IBCS compliance, even when it made development slower, became part of the DNA of what later became TRUECHART.
It was the moment we stopped being consultants who also built tools and started treating standardised reporting as a product category in its own right.
Singapore, South Africa and the Partnership Behind TRUECHART
In 2019, Bastian Lossen and I founded TRUECHART Pte. Ltd. in Singapore. Shortly afterwards, we took the decision that still feels bold when I look back: the permanent home of the software development organisation would be in South Africa.
2020 was not an easy year to move a core product team across continents. Yet it turned out to be one of the best strategic choices we made.
The South African team became the guardians of the notation engine. They gave the product the scale, focus and long-term ownership it needed. Meanwhile, the rest of the group continued the equally important work of implementation, change management and helping organisations actually adopt clearer reporting practices.
Bastian and I bring different strengths. That difference is part of the reason the product survived the long years when large parts of the market were still largely indifferent to standards. He sees the commercial and strategic picture with a clarity I admire. I remained the stubborn product person who refused to compromise on the core principle.
Together, we kept going.
The Long Road to TRUECHART+
TRUECHART+ is the version I always wanted to build.
The earlier generations did the hard, necessary work of bringing proper notation into environments that were never designed for it, first in Qlik, later also in Power BI, with supporting components such as SLICERBAR and MENUBAR helping to structure the overall experience.
Those versions proved that IBCS-compliant reporting could be made practical at enterprise scale. They earned the certifications. They created the reference implementations. They also accumulated technical debt and usability friction that only a complete re-architecture could resolve.
TRUECHART+ finally makes the standard feel more native. Visual design, pivoting, Light Planning and consistent notation live in one coherent experience.
The goal was never to add more features for their own sake. The goal was to reduce the distance between the principle and daily practice, so that the right visual language becomes the path of least resistance rather than an extra effort.
Why ISO 24896 Makes Standardised Reporting More Relevant Than Ever
When Bastian published his article last month about why AI makes a reporting standard critical for banks, he put into precise words something I have felt for a long time.
As long as only humans were reading the reports, inconsistency was costly but manageable. Analysts learned the local visual dialect. Decision makers compensated. Misunderstandings happened, but they were human misunderstandings. The moment large language models and agentic systems start reading, summarising and commenting on the same reports, visual inconsistency becomes a different kind of problem. An AI system that has to interpret constantly changing conventions has a less reliable foundation. A shared, formalised notation, the kind now captured in ISO 24896, gives both humans and machines a clearer and more consistent signal.
That is why the long road was worth it. What began as a conversation about clearer charts has become infrastructure for a world in which both people and algorithms need to extract the right message quickly and without visual spin.
I am proud of the work the teams have done over more than a decade and a half. I am even more interested in what becomes possible now that the standard is no longer a niche proposal but an international reference, and the tools are finally catching up.
The window for low-friction adoption that Bastian described is real. It will not stay open indefinitely. Organisations that treat the visual language of reporting as part of their decision infrastructure rather than a matter of personal preference will be better positioned, both for their people and for their AI systems.
That is the work I chose fifteen years ago after one conversation with Rolf Hichert. I would choose it again.
If you are looking at how ISO 24896 and standardised reporting could fit into your own BI landscape, book a 30-minute exploration call with us. We can look at where you are today, which parts of your reporting would benefit most from a common notation and what a practical path towards consistent reporting could look like.