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:
- Q4 2021 sales tax report for Pikepike, Inc. — 1 Oct 2021–31 Dec 2021
- Balance sheet on 31 Dec 2018 — Incorporation–31 Dec 2018
- Monthly cash flow statement for first half of 2022 — 1 Jan 2022–30 Jun 2022
However, each report comes with an implicit wall-time of when it was prepared:
- Q4 2021 sales tax report for Pikepike, Inc. — 22 Jan 2022
- Balance sheet on 31 Dec 2018 — 15 Mar 2020
- Monthly cash flow statement for first half of 2022 — 3 Aug 2022
Imagine you have two reports that are the same by classification, but not by content.
It is not unlikely for these to be different:
- Q2 2021 sales tax report for Pikepike, Inc. — 18 Jul 2021
- Q2 2021 sales tax report for Pikepike, Inc. — 14 Dec 2021
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.