How to Recover The Flexibility of Paper In Ledgers
What paper-based ledgers got right about flexibility that got lost when we moved everything to computers
Imagine if paper had just been discovered.
A new storage medium, local-first, with unlimited battery life, more schemaless than any database out there. Multi-model: you can store text as well as drawings and pictures. Lossless serialization and O(1) read latency to the nearest page (O(log n) otherwise).
A killer app in every aspect.
We call the systems that keep track of a company’s finances ledgers, paying homage to the notebook that was open in some corner of the office table during the workday1. 16th-century Venetian merchants ran multiple books, each updated independently throughout the day by different clerks (concurrently, and without locks), and reconciled them at the end of the day.
They had already invented CRDT centuries before it was formally defined in 2011.
But now that we have computers, most of this work is done for us, and we’ve lost a few things in the translation.
It’s a bit disheartening. Because the irony of treating paper as a new technology is that we already had it for a long time. And now that we’ve “migrated” everything to the computer, we’ve left behind unique traits about it that are far superior than what computers have to replace it.
Case in point: everything is now archived in folders or stored in containers.
Both are clearly metaphors of what people used to do with paper, but these weren’t the only things we do with paper.
I’m a very analog person, and I have paper spread out all over my desk, and none of it is archived or stored. Many engineers, if they saw that, would be prone to organizing, categorizing, and compiling all this paper.
They can’t see paper for what it is; they only see computerized reality. And that’s how we lost something that 16th-century clerks had: task management across transactions.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. You’re already subscribed to free newsletters that “teach” you how to get a job as a software engineer.
But you don’t want to get a job; you already have one. What you want is to learn how to be great at your job. Especially as a payments engineer, where stakes are sky-high, and the margin for error is razor-thin.
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful, and more successful payments engineer. And we do that by cutting off one sliver of it and extracting tactics from it.
In today’s article, I’m going to make the case that many ledger systems are missing a piece of the puzzle that would make them ten times more useful. Not surprisingly, I’ve called this missing piece the Folio entity: a piece of data that relates multiple transactions across time, aiding reconciliation efforts, facilitating changes in revenue recognition frameworks, and making ledgers entries way easier to understand beyond their metadata.
Here’s what you can expect in today’s article:
The limits of Transactions as the highest abstraction for ledgers
The case for the Folio entity
Why Folios aren’t containers of Transactions
The soundness of older, paper-based architectures for ledgers
Enough intro, let’s dive in.
