March 01, 2020 – Nicolas Zermati – 7-minute read

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:

  • the inventory,
  • the memorandum,
  • the journal, and
  • the ledger.

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:

split ledger view

You can see three entries:

  • John Doe paying for an upcoming rental,
  • Nicolas Z. being paid for this rental when it is done, and
  • Insurance being paid commissions for a bunch of rentals.

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:

  • an account, prefixed by To for debits and by By for credits,
  • a reference to the Memorandum page number (M-53),
  • a reference to the Ledger Account page number (L-000001-1),
  • an amount, either in the credit or in the debit column, and
  • more details about the transactions.

Here is the page 34 of the Journal:

split ledger view

We have four entries:

  • John receives €100 from Stripe, following his credit-card payment,
  • John splits this €100 between each party involved in Rental #5043,
  • Nicolas Z. gives €60 to Stripe, to receive a bank transfer, and
  • Insurance gives €1,000 to Stripe too, to receive a bank transfer.

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:

  • a reference to the Journal page number (J-34),
  • a description mentioning the other party from the Journal transaction and
  • an amount, either in the credit or in the debit column.

The sum of debits, from all Ledger Accounts, must be the same as the sum of credits.

split ledger view

We our Ledger Accounts:

  • John Doe received €100 from Stripe and then gave it all to others accounts.
  • Nicolas Z. received €60 from John Doe and then gave it all to Stripe.
  • Stripe gave €100 to John Doe, received €60 from Nicolas Z., and received €1,000 from the Insurance.
  • The Insurance received €20 and then gave €1,000 to Stripe.
  • Assistance and Getaround received €10 from John’s Doe.

With that information, we can tell that:

  • we are good with John Doe and Nicolas Z., we don’t owe them, they don’t owe us,
  • we owe Stripe €1,050, that’s most likely an anomaly because transactions are missing,
  • Insurance owes us €980, but that’s the same kind of anomaly,
  • we owe €10 to the Assistance provider, they haven’t been paid, and
  • we owe €10 to ourselves, Getaround, they haven’t been paid either.

Much more

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.

What about tech?


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!

Did you enjoy this post? Join Getaround's engineering team!
View openings