WIP: Thoughts on version control and bookkeeping
2022-11-01 by Evrim Öztamur

Thoughts on version control and bookkeeping

Software engineering has version control

It’s heretical not to use it (yet many don’t)

For absolutely good reason

Bookkeeping shares similarities in its process to SE

Many problems that could be helped significantly by version control

Current practices for collaboration is very primitive and in fact wasteful

Background

There is quite a bit of information we need to settle before proceeding with the discussion

We eventually need to look at some sub-processes in bookkeeping, what kind of issues they face, what information could be of assistance in following these processes

but let’s start with some facts

Journal dates versus wall time

In bookkeeping, you make journal entries that look like the one below

///TODO Basic invoice journal entry///

The journal itself has a date, which is usually when the economic transaction occurred

As such, you don’t have to book the journal today per se, it can be booked back in time, or in the future

This creates certain issues, namely with regards to closings

I will call these two timelines journal-time and wall-time from now on

///TODO Illustration from real bookkeeping of Temper?///

Closing the books

There are certain triggers which would make you want to avoid making entries before a certain date

Annual reporting

Sales tax returns

Shareholders’ requirements

Lock dates

Usually what you do in these cases is impose lock dates

A lock date prevents any journal from being booked on the journal-time before that date

Depending on your accountant’s practices, it may be engaged and lifted as see fit, with little care

Sometimes you have to lift it, it’s not something that’s a fact of life, but more like a picket fence door that you can just open

Comparing figures

So, knowing that there are two timelines, we should look at the interaction of reporting and timelines.

Reports are usually created from figures over a time range, in journal-time:

However, each report comes with an implicit wall-time of when it was prepared:

Imagine you have two reports that are the same by classification, but not by content.

It is not unlikely for these to be different:

There is nearly 5 months between these two reports, and if your payable sales tax amount is now higher, it’s imperative you figure out what’s causing the difference.

Even if your accountant is exporting a copy of your ledger for each time they prepared this report (they’re not), they will still have to use Excel to figure out which invoices (or other various journals) were included in Q2 2021 after the 18 Jul 2021 report was created.

This is a tedious process.

I would call it soul-crushing but hey, auditors seem to like that.

Collaborating on books

Well, say you’re a private accountant, and you’re using our lock dates properly, and keeping track of the figures regularly by exporting your ledger

That’s great, keep doing that!

Unfortunately, not everybody has it so easy

If you’re a public accountant or even a slighly imperfect private accountant, but you’re using lock dates, a rogue client or an accounts payable intern may still lift the lock date for innocent purposes, not engage it back

Chaos ensues. Start praying now, because you are about to get your hands dirty digging for those 495 euros and 39 cents…

Checks and balances (and fraud)

Because the processes don’t consider the two timelines, it’s not hard to slip in a couple unnoticed entries here and there.

I request my own clients to export sales tax reports before they go on around making funny changes, not because I don’t trust them to make the correct bookings, but because I have to know which bookings I will have to take a look at to verify their correctness and completeness.

A difference of € 5.25 on a report’s surface can in fact be the exchange rate difference over six bookings, clocking around € 250,000 each. Not a substantial difference, but you can only assess that if you know what the source is.

It’s really not straightforward to tell what’s going on as wall-time moves on, because the tools are designed in journal-time.

New user-experience features abstract immutability

This design choice is entirely righteous and in day-to-day processes exactly what we’re looking for.

However, bookkeeping tools obscure two things from you:

First is wall-time, which we discussed already.

Second is the journals’ individual histories. TODO

Status quo

It seems that despite these problems and a potential solution, it doesn’t seem like there’s any buzz about augmenting the process with fundamental tooling

Seemingly no interest or initivative?

Could not find anything during search

Seen other attempts at bringing it into law, varying levels of success

State of the art software..?

There’s not much, assurance dashboards are weak

Your bookkeeping software is usually sticky

It’s very rare that you will change your bookkeeping solution

Your accountant usually has their own workflow

Potential triggers are extreme events such as acquisitons or growing out of your current software package’s feature set

Path forward

Putting everything we found together, we can see a way out of this: Bring version control by boiling accountants frogs!

What can version control do for bookkeeping?

Version control could help improve the way we do bookkeeping by increasing transparency and efficiency

Transparency comes from acknowledging that companies’ books are alive and constantly mutating, and that monitoring and auditing tools are integral to exposing the books’ evolution

Efficiency is achieved chiefly by eliminating the process of comparing differences

How can we get started by augmenting our processes?

I think creating a new bookkeeping process and the tools to go with it is not going to get as much traction as augmenting the process itself.

The problem right now is that because the process and the tools are both sticky, you are better off helping people while they keep their own ways.

A good start is a reporting tool that connects with other bookkeeping software.

Not all software suites expose the necessary information or keep immutable ledgers.

Live monitoring can help with the lack of immutable ledgers, but bookkeeping software should ensure this paradigm by default. No excuses!

Essentially, this is a read-only solution by nature. As in, we can’t expect to have accountants creating branches or merging journals anytime soon. However, we can give them a taste of the powerfull diffing algorithms and interfaces.

Will we ever change the process altogether?

It’s hard to say. I would like to see a future where bookkeeping without version control seems heretical, where senior auditors sigh when they see books without an immutable ledger.

Caveats in my assessment and a wrap-up

I haven’t been doing bookkeeping for long, but the issues I described are big pain points for many. Granted, I can see people’s eyes light up when I talk to them about the concept of version control in bookkeeping.

I don’t know practices in larger firms and private bookkeeping departments, I’m merely assuming they’re weak in aiding journal-time and wall-time reconciliation procedures. I know that clients with millions in annual revenue still fail to enact lock date processes.

However, I still believe that version control would be a significant way forward in the way we do bookkeeping.

Although most processes are automated these days, things will inevitably get messy due to the two-timelines dichotomy.

Present practices simply fail to be sufficient measures against tampering.