Distributed Accounting Ledgers
There is an infectious decentralisation epidemic sweeping the globe — the blockchain inspires us all to root out and disrupt the rent collecting oligarchs!
Is decentralisation appropriate in all cases? When it comes to solving real world problems decentralisation isn’t always the best solution.
This is the first in a series of posts in which I aim to discuss what’s wrong with accounting and audit and how distributed ledgers may help to solve some of these problems.
What is accounting and why do we need it?
Naturally, I turn to Wikipedia, which states
“Accounting, or accountancy, is the measurement, processing and communication of financial information about economic entities”
Yes, I’d agree with that. Accounting is set of rules or a grammar to aid in the description of real-world business events. Double entry book keeping and the basic accounting principles are the foundation of this grammar.
Just to dispel any ambiguities, an accounting ledger should be viewed as an append-only immutable database table.
I would also add, that for me, accounting also covers the processes and controls which must exist and be operating effectively to enable the honest recording, processing and reporting of real world business events in a ledger. For most companies, this involves investing in ERP systems and employing an army of clerks and developers to keep it all ticking over.
For the purpose of this post, I’ll take the universe of entities to mean any legal person (natural or otherwise) that needs to record business activities. All of these entities have an incentive to maintain records. The de minimis requirement common to all entities is the payment of tax, therefore entities must keep records to calculate the correct amount. Also, it goes without saying that for managers interested in monitoring the performance of their business, keeping honest records is a must! Other entities have more onerous requirements; annual accounts filing, quarterly reporting, due diligence, regulatory reporting — the list is actually endless.
Consumers are not required to maintain a ledger, though from a purist stance, consumer activities can be modelled using double entry bookkeeping. The majority don’t bother as there is no requirement to do so.
Some in the crypto-currency community have an acute disdain for such reporting and regulations. I can empathise but the reality is that for serious enterprises, reporting requirements and regulations exist and entities have no choice but comply. Non-compliance results in fines (JPMorgan client money breach), repetitional loss (Tesco) or even worse, a material loss of assets (Enron). The appropriateness of these reporting requirements and regulations is a discussion for another post.
What’s the problem with accounting?
It turns out there is only one big problem and we have solution for it already.
“How can we trust that an entity’s accounts an honest reflection of reality?”
The solution, of course, is financial audit. Audit has its own problems which are the subject of another post — here is a taster:
There are other issues with accounting but they are not considered serious enough to warrant a fully mobilised war effort. Here are a few which I see:
- Companies maintain their own private ledgers where they unilaterally record their own interpretation of real world events. This results in data duplication and inter-ledger inconsistencies. Accountants and auditors try to fix this problem with time consuming reconciliations. Todd Boyle wrote about data duplication back in 2001 and his comments are still very relevant today. Last week, Richard Brown posted an interesting article on how distributed ledgers may be relevant in this respect.
- Complexity. Financial accounting controls are really complex for large enterprises. Much of it is needless — I call this ERP spaghetti.
- ERP Systems. ERP system vendors are still in the stone age. This might attract some criticism but through my years in audit I hated the clunky interfaces and abysmal reporting capabilities. Clients could barely use the systems to run simple reports! Interoperability capabilities are generally poor — this is why businesses spend so much on integration. The advent of cloud accounting is fixing this for the SME market.
- Time consuming, manual and error prone. A product of all the above. Accounting remains a mostly manual process and humans make a lot of errors. As an ex-auditor we regularly found multi-million pound errors; fat fingers, double counting and huge reconciling items no-one knew how to deal with! It doesn’t have to be this way — much of it could be automated.
- Fraud. Even if humans don’t make errors, it’s still relatively easy for them to fudge the numbers, if they want to or are forced to. Through my fraud investigation experience, I can tell you it is exceedingly difficult and frustrating to retrospectively find accounting fraud.
- Auditing difficulty. Double entry accounting records are difficult to audit. Imagine a auditing a ledger with millions journals for the year! Audit becomes a complex ass covering exercise.
Put simply, the basics of accounting have not changed for hundreds of years.
Today, the issues enumerated above are solved by formulating new rules, employing more clerks and investing in more IT infrastructure. This is the wrong approach.
I believe most of the above are solvable by doing three things;
Make accounting of a business activity an integral part of that activity. Instead of treating it as a separate process. What if the invoice was the journal?
Sharing data between entities. Any business transaction involves an agreement of value by one or more parties. Privacy is not a problem as all parties should be recording the same data.
Using cloud accounting ledgers. Large enterprises maintain simple private ledgers. APIs allow for easy integration and the development of plug-ins.
Bitcoin achieves the first two things for cash payments.
By creating and signing a Bitcoin transaction, one generates a proof (which is consensus verified) that the transaction happened and they had the rights & obligations to the unspent transaction outputs referenced in the transaction.
One can easily prove to anyone that they have the rights and obligations to a specific wallet by signing a message using the wallet’s private key.
Both parties to a Bitcoin transaction share the same ledger — the block chain. It follows that, with a bit of effort, any accounting for Bitcoin transactions can be performed algorithmically using pointers from a local ledger to the Bitcoin block chain. This is a clue for later.
What’ the ideal accounting ledger?
We are a long way off the ideal ledger. Cloud accounting packages are taking small steps but there is still much progress to be made. Here’s my take:
- Lightweight and simple to use. I believe this would take the form of a cloud accounting package; a simple immutable append-only database to record journals and a set of API end-points which allow developers to build applications on top of the ledger.
- Easy interoperability with other ledgers and data stores. Entities can easily share and agree data with their counter-parties as opposed to unilaterally recording multiple versions of events and reconciling afterwards. Ledgers now rarely duplicate data.
- Forces honesty. If counter-parties share records, it becomes more difficult to fudge things.
- Facilitates a continuous audit process. If data is shared, then most transactions are audited as and when they happen, or soon after.
- Complete. If it’s not in the ledger, it doesn’t exist. Bitcoin does this well.
- Sensible approach to valuation. Instead of, absolute valuations, use a valuation distribution. Banks do this with VaR reports.
- Internet of Things integration. Auditors can ascertain existence and rights & obligation through direct communication with an entity’s assets. E.g. “I’m a widget machine and I belong to Bob Ltd, here’s a digital signature to prove it”.
- Integrating reporting. A means to take the ledger and spit out US GAAP accounts, IFRS accounts or a tax compliance report at the click of a button. Aside from valuation, most rules are very prescriptive and can be implemented by an algorithm. Some ERP systems attempt this already.
That’s an ambitious list of requirements.
Lets start with the low hanging fruit, sharing, which features in at least 4 of the above.
What if we can merge sharing with Make accounting of a business activity an integral part of that activity? It turns out we can.
Transactions and Adjustments
I’m not suggesting that companies ditch their locally maintained ledgers and start recording everything on a blockchain.
Distributed ledgers are not appropriate for the majority of accounting workflows, however they do have a place.
I find that most in the crypto community don’t get that accounting is a different beast to issuing tokens and regulating their transfer (Bitcoin).
Share certificates and other transferable agreements sit in this Bitcoin bucket, however accounting journals don’t, this generally includes invoices in my opinion.
With accounting, there’s no requirement for tokens as we just create and destroy value at will through journal entries. Account balances rise and fall as business is conducted. Things that are accountable can clearly be represented with tokens however, such as money, shares and option agreements.
The existence of accounting principles dictate that the treatment of cash will always differ to the accounting of business activities (P&L versus cash flow statement), therefore using a Bitcoin like system is inappropriate as it does not allow us to effectively model the accruals concept, for example.
Assuming there exists an appropriate distributed ledger for things that are accountable, we need to consider which journals will sit in this distributed ledger. There are two broad types:
- Transactional journals pertaining to an agreed transfer of value with counter-parties.
- Adjustment journals which are used to maintain the accounting grammar. There is no counter-party involvement. They may or may not depend 3rd party data e.g. valuations.
It follows that adjustment journals depend on transactional journals, for example, one cannot post an accrual if there is no expense to accrue. One can procedurally assert the validity of these adjustments through simple rules based on the accounting grammar.
We assert that adjustment journals always depend on transactional journals. If we can agree on transactions the accounting and audit gets much easier for all involved.
It seems that as adjustment journals do not involve counter-parties they are best confined to a local ledger. There are other reasons why this should be the case but I won’t discuss them here.
So now we have the concept of a local cloud ledger and a bunch of accountable transactions which may sit in a distributed ledger.
Transaction Pointers
If we had an accepted place to store transactional data then we can just store pointers to that data in our local ledgers. Bitcoin does this for cash, I’m building Triplentry for invoices and BitShares exists for issuance and transfer of share certificates. See below:
The distributed ledgers store digitally signed receipts. The receipt is the transaction. Ian Grigg and Todd Boyle coined the term Triple Entry Accounting which describes the digitally signed receipt.
The receipt can be viewed as an immutable record held by a third party, proving all parties agree to the transaction. It follows that each party to the transaction can procedurally generate the local double entry for the transaction, on demand.
Entities may wish to store additional meta data about a transaction which they point to in a distributed ledger.
All these distributed ledgers combine the act of performing the transaction with the accounting of the transaction — this is the Triple Entry magic!
Richard Brown touched on this in his last blog post — perhaps there may exist a distributed ledger for all transactions, e.g. Ethereum?
It seems more likely to me that there will be a ledger for each type of thing. The inherent complexity of building a system to deal with all accountable things and successfully integrate with existing accounting workflows is a massive challenge!
Putting it all together
In some ways the technology is the easy bit. Bringing it to market is a different challenge altogether:
- How do we integrate the distributed ledger with existing legacy accounting software and accounting workflows? This is always easier said than done.
- How distributed does the ledger actually have to be? The whole point of this article was to discuss distributed ledgers but of course the same functionality could be achieved with a centralised ledger.
- What’s the incentive for companies to use distributed ledgers? Reduced cost, more assurance, less fraud. Are these enough to warrant implementing a new system?
- How will regulators and industry incumbents react?
- How do we handle privacy and security of data? Richard Brown touched on this. By design, decentralised ledgers are public and this is not always appropriate for accounting.
I hope to answer some of these questions in coming blog posts and with the release of my first product, Triplentry. I will leave the implementation discussion for another post.
Thanks to Ian Grigg for his comments on this blog post.
