All companies handle money transactions. The law enforces companies to maintain and publish records of those transactions. Those records are called books and the act of maintaining them is called bookkeeping.
At Getaround, our business-model generates a lot of transactions. We receive and route customer’s money to various partners. For that part, we decided to build digital books in our platform in order to do its part in the company’s bookkeeping.
In this article, I’ll tell you about bookkeeping techniques from the 15th century and how close they are to programming concepts we use everyday.
This technique was formalized in the 15th century by Luca Pacioli. It has been used way before that though. Pacioli’s work has been translated by Jeremy Cripps in an online available text. In a nutshell, it is a simple, powerful, flexible, and mature accounting system. It describes various documents, called books:
Those documents provides guidelines to record and control economic activities.
I’ll skip the inventory and introduce only the last three books.
This book keeps track of business operations in a chronological order. Each entry includes all the details related to the operation: « The who, what, why, how, when, and where need to be answered ».
An entry, page 53 of the Memorandum, could look like this:
You can see three entries:
Each entry match a different business operation.
Because merchants were not always around, their employees would write those entries in the Memorandum. The knowledge from the Memorandum will be transferred to the Journal and to the Ledger later.
Each Memorandum entry leads to at least one entry in the Journal. Each entry in the Journal represents a transaction, it has multiple lines and each line has:
To for debits and by By for credits,M-53),L-000001-1),Here is the page 34 of the Journal:
We have four entries:
When an account gives money, we record a credit. When an account receives money we record a debit.
It can be a bit surprising to see that John starts by receiving €100. From John’s perspective, he just gave something. But from the merchant’s perspective, John’s internal account just received €100! Same when we want to pay €60 to Nicolas. It is €60 that are going out from Nicolas Z.’s internal account.
To ensure consistency, there is a single rule: for a transaction, the credits must be equal to the debits. This rule makes it easy to avoid mistakes like disappearance of resources.
The Ledger has many sections representing Ledger Accounts. Each account has a
reference, in this example, I used a number (#123456) and a name.
The goal of a Ledger Account is to keep track of operations that happen on that specific account. The choices of the accounts will have an impact on what we’ll be able to monitor with the Ledger.
Each entry in the Ledger is coming from a line in the Journal. It has:
J-34),The sum of debits, from all Ledger Accounts, must be the same as the sum of credits.
We our Ledger Accounts:
With that information, we can tell that:
There is much more to say about this system but that’s more or less all I need for the rest of this article. If you’re interested there is still Jeremy Cripps’ interpretation of Luca Pacioli’s writing.
The first thing that I admire in that work is that it is generic. No matter the nature of your business, those guidelines can help you to solve a technical problem. The solution will adapt to the specifics of your business.
It really looks like a framework like Ruby on Rails. If you follow the conventions, you will benefit from the work of a whole community and from the wisdom of those who tried to solve the same problems before you.
Those books I described are very close to a database.
The reference system that ties entries from different books together is comparable to foreign keys. Information is split between books, sometimes denormalized, sometimes referenced.
A Ledger represents the same information that we have in the Journal but optimized for different use-cases. A Ledger is like a projection, like a materialized view. It creates read-models optimized for certain use-cases, certain consistency checks.
The Memorandum and the Journal are used by different people and for different purposes. There is a context for business operations and another for the accounting. That looks like some Domain-Driven-Design to me.
We don’t want the Memorandum to be impacted by the Journal unavailability. We don’t want to need the Memorandum when searching informations in the Journal. And finally, we don’t want to have them synchronized all the time. We’re talking about asynchrony and eventual consistency here!
One of the important properties of those books is that entries were immutable. Each book is an append-only log of events and transactions. This looks very much like an event-driven architecture.
When there is some mistake or something to update, it has to be through compensating transactions rather than amending past transactions.
Double-entry-bookkeeping was in use way before the 15th century. Being relatively simple was one of the key to longevity. A complex solution would be dead by now, but this is still the foundation of most financial systems today!
Another key is certainly its robustness. The process leaves little room for error. It exposes a clear set of rules to follow and provides guarantees about the information the system will deliver.
Italian merchants knew a lot about how to build information systems. I wonder if there are other disciplines that refined systems, like accounting, over centuries, without any computer, and to end up with such mature models. If you have other examples, in any other field, please reach out to me!
Discovering such simple, effective, and flexible tools is truly inspiring. In my opinion, it is totally relevant to guide the design of modern software systems as we’re still solving the same problems!