Invest in what drives you.

Can you make an auditor happy?

Photo of angry auditor0

It’s easy to say that “You should have known this when you started the company”, but in reality auditing of a company when it’s a small start-up with mostly costs is not really too hard on the company orthe auditor.


Add a few more companies to form a small group, spread that across the globe for legal reasons, grow quickly, get listed and suddenly you attract the attention of auditors in a whole new way and you find your financial and engineering resources pushed to the limit to comply. All this, while you as founder feel that “what is different now compared to back then – we’re using the same systems and routines”…

Of course there is a difference, but the fact of the matter is that no start-up would be able to get beyond that point if one would put those massive requirements from day one. And we all know that if we launch ten projects, it might only be that one that really takes off…

What are my lessons learned here during the years as CEO of Global Gaming group? Well, many, but when it comes to paperwork and more specifically finances and auditing – the one thing you can be sure about is that at some point in time you will need to prove every step of the road from point A to Z. And this is where the choice of technology (together with skilled finance people) can play a role and not only help you out from an auditing point of view, but in fact in all dimensions of your business.

Typically, in any system you’ll need to store data: customers, transactions, content and so on. And the de-facto way of doing this for many years – and in some cases even the required/expected way from regulators point of view – is to use a SQL database. All developers know SQL to some degree, there are a lot of vendors out there and commercial support. Great. You get going, and from a technical and commercial perspective all is going according to plan – success is imminent.

Everyone is happy except for the auditor who now wants to know “who updated this row and when”, “who has access to this table”, “where is the audit log” and so on. Since every update to a row in SQL just changes the state of that row and doesn’t leave those kind of traces, you are unable to provide this information historically.

This is where the real problems start. Your IT department gets tasked with building an audit log system which effectively duplicates data/updates. At the same time your growing team of data scientist requests more details on each update and you start feeding the same data to them as well… The whiteboard drawings become more and more complex and managing the data in multiple places creates new headaches when it comes to legal compliance.

Is there another way? Yes. Probably manyother ways, but the one that I personally have come to like is event sourcing. Some say it has been around forever, some say it’s new. Really doesn’t matter, what matters is that is a really simple concept: you store every single event/update that occurs in your system in an append only log – forever.

Up to the point in your business lifecycle where you don’t need to prove as much it really doesn’t make that much of a difference. You add events and setup a number of state stores/materialized view that effectively becomes your “tables” where you can look at the most recent version of any information – incrementally updated by the events.

BUT when the question comes “please provide which events that makes up this number” or “we would like to have these numbers for each month last year – not just the current state” you can generate these reports “simply” by replaying the events from the beginning.

It’s sad to see that many low-quality tech-talks and cat-videos online has many more views than presentations by Greg Young on the topic of event sourcing:

I do hope that you take the time to watch this (or any other of his talks), and for those auditors out there reading this – it actually contains a rare celebration of finance people, their skills and ways of thinking about data and events from techies!

So, is this a silver bullet? No. It is a feasible approach (as opposed to when storage was expensive for instance) but the fact that all events are stored forever opens up a new can of worms: legal compliance such as GDPR (i.e. right to be forgotten) and requirements from authorities (i.e. purge data of inactive customers).

Game over? Of course not, and this is in fact the topic for my next post – stay tuned!

My New Stories

Michael Åman JDI