Utilizing Blockchain as a Framework for Real-Time Accounting

Published in

Oregon Blockchain Group

13 min readApr 9, 2024

Don’t Trust, Verify

This has been the slogan of the blockchain revolution in a democratic movement from trusting our entities to verifying their activity, however as a shareholder in these entities the same is true. As a board member would you rather Trust your CTO is doing their work, or verify? Would a CEO like to Trust their CFO is complying with internal controls, or verify? The framework is not only for the people’s good, but for the entity itself to be sure objectives are being met properly and in the right way.

Blockchains in their simplest form are state machines, no not state as in a region in a country, but state in the terms of an objects position. Blockchains take snapshots of the position of economic resources on chain. Whenever users want to move any of these economic resources it must first get approved and then when it is the change is cataloged on the blockchain, thus creating a new state.

These snapshots happen in real time and their categorization is viewable by all parties involved in the chain, it stands to reason that this technology can be a key part in a system for real time accounting.

Accounting is one of the world’s oldest practices, as so some things get lost in translation, accounting research has had a fractured history creating a rifted divide between frameworks that could lead to real-time accounting. In this article I explore a framework for real-time enterprise accounting & auditing using the REA (Resource, Event, Agents) Framework by Mcarthy, TEA (Triple Entry Accounting) by Ian Grigg, Consensus Mechanisms in Hyperledger’s RAFT consensus algorithm, and blockchain primitives in Bitcoin & Ethereum for state management and arbitration events.

A Fractured History

Double entry accounting, using debits and credits, was created during the renaissance in the late 14th century forming a revolutionary system able to leave a verifiable trail of transactions which acted as a firewall protecting organizations. [ 6] Though Double entry has been used for over 600 years it is not without its faults. Double entry cannot prevent cheating, even if debits equal credits, it is possible to do so in a false or misleading manner. [6] For example inconsistent implementation & misapplication of fair value accounting contributed in many ways to the lack of transparency in subprime lending in the 2008 financial crisis [14]. To confirm the integrity of a firm’s accounting, shareholders and governments require audits, which are a costly and time-consuming exercise. Other issues outlined by McCarthy in his paper on Resource, Event, Agents illustrate:

A lack of universal classification schemes
The degree of functionality in other functional areas is too restricted, it would be difficult for a marketing team to use financial accounting data
The practice precludes maintenance and use of productivity
More can be found in source 6, 11, 7, & 9.

To correct some of these issues a second revolution of accounting took place in 1982–2008 looking into shared ledger systems, which were largely overlooked due to gaps in literature. [7]

One such gap was the creation of triple entry accounting. The term “Triple-entry bookkeeping” was coined by Yuji Ijiri in 1986, however it describes the concept as adding ‘the rate at which income is being earned’ noted as momentum. Ijiri described using trebit accounts to record changes in momentum, however his work was heavily criticized for a lack of use case.

Unaware of Ijiri’s work in 2005, Ian Griggs re-surfaced the term “Triple-entry accounting” in a working paper with a completely different meaning. Griggs, with a substantial expertise in cryptography, proposed a solution of A third-party, cryptographically secured entry that can be recorded at the same time for transactions between entities. [6] Ian Griggs outlined that ‘The cryptographic invention of the digital signature gives powerful evidentiary force to the receipt, and in practice reduces the accounting problem to one of the receipts presence or absence” [11].

Griggs idea was however impractical at the time because it was necessary to trust a third party with the shared ledger. Until a whitepaper in 2008 by Satoshi Nakamoto described a peer-to-peer shared ledger leading blockchain to become the third ledger.

Combining the REA & TEA Framework

The REA Framework

The Resource, Event, Agency model is an accounting framework that defines an organization’s resources, the events that move resources from one place to another, and the agents (people) involved in the event. REA is an accounting model created by William Mcarthy in 1982. The model is a generalized accounting framework designed to be used in a shared data environment where both accountants and non-accountants are interested in maintaining information about the same set of phenomena. It was commonly overlooked due to its omission of debits & credits, and emphasis of data modeling for business information. However, REA operates on the idea accounting data is used by a wide variety of decision makers, each needing differing amounts of quantity, aggregation, and focus depending upon their personalities, decision styles, and conceptual structure. The framework believes the availability of multiple views would allow diverse and flexible use of economic transactions.[12]

REA attempts to do this by breaking up an organization’s resources, events, and agents:

Resource — The wood a lumber yard turns into a final product, the machines used, the paper for filing, etc.
Events — Selling the product for money, a machine getting damaged, the paper being used for filing, etc.
Agents — Sales associate selling the wood, a contractor or employee operating the machinery, the manager filing the paper, etc.

REA defines that elements of the general ledger normally are classified as either balance sheet accounts, which represent monetary stocks of goods, services, and claims at a particular time, or income statement accounts, which represent monetary flows of these same items over a period of time. This basic dichotomy points correctly toward classification of accounting phenomenon into two generalized categories: stock objects and flow transactions, or, state and state transitions. [12]

The REA construction consists of 3 main phases:

Requirement analysis — This is a data collecting process to create a local view of divisional needs. It is a process during which analysis interviews the user community and review existing documents to identify present and future information needs.
View Modeling — a process where the data base designer takes the local views and creates a semantic data model to create a global enterprise view
View integration — The completed development of the data model

Example implementation of a REA Framework

The REA framework also classifies ‘Economic Agents’ and ‘Economic Units’ Economic units are described as the parties involved both inside and outside of the company, and their specific participation in economic events. These Agents and Units will be an important part of the framework discussed later.

The REA framework omits the use of debits & credits stating, “they are not essential aspects of an accounting system”. However, the REA framework does harp on duality, the link between incremental & decremental movement in the resource set of the enterprise. Debits & Credits do support duality quite well, their idea being that money must flow from somewhere, it is possible that to integrate both frameworks in a verifiable way we can use another framework known as Triple entry accounting.

The TEA framework

The triple-entry accounting system proposed by Grigg is a distributed ledger system based on a three-way consensus mechanism. It relies on three-sided signed receipts to reach an agreement on registration [9]. Originally Griggs determined the ‘triple’ to be a third party however with the creation of blockchain ‘Triple’ doesn’t represent any third party; rather it represents an extra component added to the credit and debit system. What is missing next, one needs a linkage factor that could connect these two separate double entries. In the blockchain-based system, there are three entries of the accounting transaction: the debit side, the credit side, and the cryptographic signature of the transaction. [9]

Illustration of a blockchain based triple entry accounting scheme

Adding in Blockchain

Satoshi Nakamoto’s Bitcoin created a pivotal part of the triple entry accounting framework as a peer-to-peer verifiable source of account. However, to implement the benefits of REA in terms of information form & departmental needs there were features that were lacking until the creation of Ethereum utilizing smart contracts, a term Ian Griggs described earlier as Ricardian contracts.

Looking at the modular blockchain there are three sections:

Consensus Layer — This is the means of which peers/nodes in the network decide how to verify a transaction is correct
Execution & Settlement Layer — Once the transactions are confirmed the actual movement of resources must take place in the execution layer
Data Availability Layer — This is where the state & state transitions are stored so that new contracts can call on old data

Illustration of Modular blockchain from Celestia documentation

Taking the modular blockchain & over laying it with our frameworks we can construct a potential real time accounting system using:

Consensus Layer — REA Framework
Execution & Settlement Layer — TEA Framework
Data Availability Layer — Merkle Tree Storage

The REA, TEA, Blockchain Framework

Some of the many draw backs of utilizing blockchains is privacy issues. Blockchains are open source to all people & enterprises generally don’t want their information flowing through the public. This is why this framework focuses on a permissioned (private) blockchain that is viewable only to enterprise agents. This not only allows privacy but the ability for the enterprise to tinker with features to make their recording more efficient all set up with the REA Framework.

The REA Framework works on generalization. Breaking down the REA Framework: Economic Resources & Events will rely on our TEA system, Economic Agents & Units will represent our peer/node system, & REA will set up the rules.

Generalization from Mccarthy’s REA framework

Requirements Analysis

Requirements analysis will largely stay the same. This involves summarizing individual answers of agents (employees) of the organization to decide what data points they need. The main difference here is we will take extra note of the “local views” that exist in the system and use them later. We will also take specific note of the Economic Agents & Units in the system, these represent parties both inside and outside the organization with specific participation in economic events.

View Modeling

Utilizing generalization, we will generalize these events into accounts which will be managed by a dedicated smart contract. By connecting financial accounts smart contracts would allow for us to write in the semantic translation of the view modeling process into our blockchain & confirm that these rules are followed in those accounts. We could have a free flowing blockchain that catches all transactions, but in my opinion that is too messy, cohesion of information into smart contracts allows for localized pockets of information and it can more easily be traced that a resource is in a contract that it should be a part of. Furthermore, by applying smart contracts, invoice preparation can be automated.

For Example, the contract will first check the blockchain to confirm that the goods are in stock and that the necessary resources are available to make the payment and an invoice will be paid automatically. Another interesting point highlighted by Rîndaşu (2019) about smart contracts is their potential to streamline accounting processes and thus provide an improvement in performance reporting costs [9].

View Integration

With the creation of our REA framework, we now have a way to describe our economic resources, the smart contracts that coincide with them, and the participants within our network. Using this in the event of “Stock flows”/State Transitions/Transactions we can have a record of the debit side, credit side, the economic agent, and the economic unit signed by a cryptographic hash.

Deloitte showed one way hash recording can work to verify the integrity of records using blockchain. “One approach is to generate a hash string of the file [stock-flow/state transition in our framework]. That hash string represents the digital fingerprint of that file. Next that fingerprint is immutably timestamped by writing it into the blockchain via a transaction.” [2] Another way an enterprise can do this is by setting up their own consensus mechanism using divisions or personnel to confirm transactions & signatures then write them to their personal blockchain.

What makes the REA framework so powerful is that with its ability to dissect local views, economic agents, and economic units we can construct an enterprise wise immutable blockchain by constructing a validator set that consists of any mix of local views, economic agents, and economic units.

Consensus

We can think of economic units as divisions and the controller of that division as the divisional manager. We can also think of economic agents as employees, as far down as associates, or as high up as the executive branch. Finally, we can think of local views as regions in the enterprise that require specific data. In this way the divisional manager, employee, or region could be a peer in this network & communicate with other divisional peers, a scheme that works well with Hyperledger’s consensus algorithm RAFT.

RAFT is a modern, leader election consensus algorithm utilized by a blockchain accounting system called Hyperledger. In RAFT nodes can be a leader, follower, or a candidate. Once a leader is elected all messages are sent to the leader, once that happens:

The leader propagates the messages to all the nodes
The nodes then validate and write the messages.
When the leader receives responses from all the nodes the message is committed & broadcasted through the network
The follower nodes commit the message (Transaction)

Diagram from source 13 on HyperLedger RAFT consensus

Utilizing this system different divisional managers could represent nodes on the network and go through a leader election process to commit messages to nodes. This can also be extrapolated to numerous customizations: Leaders are only allowed to be executive members, divisional managers act as nodes/Leaders, all employees can become nodes and be randomly voted as a leader! The election can be random, RAFT doesn’t allow a leader to serve more than one “term”, but the enterprise can adjust if needed.

This consensus mechanism adds a check on malicious actors. If a malicious manager tried to push transactions to the system, it must send the account changes to the other nodes or managers on the network and show/convince them the account had changed. If the accounts were not changed evenly, i.e. product didn’t leave inventory and cash didn’t increase in a bank account, the transaction would be known as false. What’s more, with the participant features the network would be able to tell what individual attempted to act maliciously.

Finally, we are left with a theoretical scheme to create the rules of our blockchain, execute and catalog transactions, and offer a verifiable proof of history of events.

In this diagram we illustrate an example transaction of buying wood from a hardware store.

The REA framework sets up our base, what resources we have, who participants are, and what to do when “stock-flow” events occur.
It takes these ideas and internalizes them into smart contracts for management and connects actual real-world accounts such as inventory and bank accounts into the contract — later used for verification.
When a purchase occurs the data model is triggered and gathers the information of what accounts are moving and what accounts need to be debited & credited.
The account movements are cataloged along with the participant and sent to our consensus mechanism.
Here in consensus is our network of managers, employees, etc. Our original transactor is selected as the leader, and the follower nodes verifies that the accounts have changed and that a piece of wood has left the inventory section & cash has been or is being processed in the bank account.
The signature is then written on a blockchain and settled for booking in our blockchain ledger.
An auditor or manager is then able to look at the ledger and find transactions where they occurred, what account they went to, and who was involved. Then can check the real accounts if said event occurred or the consensus mechanism.

What’s even better is, thanks to REA economic agents, at the end of a reporting period you would not only have a general ledger of accounts but a general ledger of economic agents’ participation i.e. a general ledger of internal controls.

Discussion:

Just some subtopics I was curious about.

Ian Griggs mentions in his article “Auditing issues arise where construction of the books derives from the receipts, and normalization issues arise when a receipt is lost. These are issues for future research” This could be a solution for Merkle/Verkler tree storage due to the fact transactions from any reporting period can be derived from a root hash.
Arbitration are events where disputes or legal action take place. If a dispute were to arise and adjustments to the chain were needed, permissioned blockchains could more often use the fork capacity of their blockchain. Meaning the entity could back log their transactions from a point, fork the chain, make the arbitration changes, then add back the back logged transactions to make the chain whole again.
Whistle blowers can be incentivized by the enterprise chain. If an employee were to find an error in the chain’s consensus, settlement, or execution they could attest to the chain. If the review process is complete and an error is found the employee can be rewarded as an incentive for employees to monitor chain integrity.

Conclusion

Digitalization within accounting is still in relatively early stages, we are faced with a growing number of companies who have millions of transactions a week, and fewer and fewer people are graduating in the accounting profession. In this article I explored my idea of how to further automation but also verification within the accounting system. All in all, it was a fun thought experiment and an idea I want to build on more. But above that, I believe the accounting profession needs to change for the future world to keep up, protect consumers, and attract more people to the profession.