Accdefi white paper - double entry contract accounting on a distributed accounting ledger

An Accdefi White Paper

26th May 2021


Accdefi is a
decentralized accounting solution using
a double entry contract (DEC) protocol

Moving Beyond Triple Accounting 

Executive Summary


One collaborative accounting system.

Original concept

Triple Accounting Protocols

Double Entry Contract

Glossary of terms

Typical Accounting Block

Using DECs

Machine Learning and Artificial Intelligence

Under the hood

Chart of Accounts



Where are we today?



Executive Summary

Accdefi defines the protocols to govern and manage a global distributed accounting ledger (“GDAL”) of accounting transactions using Double Entry Contracts (“DEC”).


One collaborative accounting system.

Imagine if every company in the world used one GDAL for recording all their accounting records, a bit like using one version of QuickBooks™?

Participants of a transaction would record the details on a shared ledger instead of recording on their own separate accounting data stores. Related participants would, using pre-agreed contracts (a DEC), be able to amend and confirm transactions and close off the transaction completely without the need to reconcile or prove balances. They could continue using existing accounting software packages and api onto the GDAL.

Every debit and credit involving another party (supplier, related entity, stakeholder or customer) would be recorded once on the same shared system instead of duplicated. The originating actor would initially own the transaction and fulfil all commercial obligations before closing the block or accounting entry with another actor through a DEC.

Other benefits would include; reducing electrical consumption due to the abolishment of mirrored accounting records held on cloud or on premise; providing complete and accurate accounting with every entry verified by a counterparty; providing a full and easy to access audit trail; providing immutable data records and so satisfy many regulatory obligations; offering documentary evidence indexed on the same blockchain distributed ledger for the purposes of audit or proof of record; providing transparent access to regulators and tax authorities[1]; allowing instant contract payments through open banking apis; allowing instant contract payments through existing digital api’s to non fiat mediums of exchange.

A transaction created from a payment, or an invoice published or received, or other journal would be immediately known to counterparts. No need to re-input or reconcile. No need to manage exceptions. Immediate banking payments. Instance tax collection. Real time financial accounting positions.

Smart Contracts to keep the integrity of the ledger and a new DEC Ricardian contract to govern transactions.


Original concept

Blockchain is a technological solution or protocol successfully developed and implemented in 2008. The initiator is unknown but the way it works suggests it was probably designed by an accountant, or someone or persons with an accounting background.

Blockchain (or Distributed Ledger Technology “DLT”) has all the hallmarks of a perfect accounting system — no deletion allowed (reversals only), fully timestamped, a complete audit history, facility of private or public versions, controlled publishing and subscription and of course second to none security.

Triple Accounting Protocols

In the mid 1980s, Yuji Ijiri[2] discussed the concept of extending double entry bookkeeping, the standard accounting protocol used today, into having a third entry which would close a double entry accounting transaction. Ricardian[3] contracts were suggested by Ian Grigg in 1996[4] and extended the triple accounting idea further through using cryptography and the ‘receipt is the transaction’. However, this was suggested 12 years before a proven blockchain protocol existed. A blockchain and its smart contracts can be utilized along with a third node or party that confirms the transaction. A Blockchain with smart contracts[5] enables this to work more efficiently if all the accounting transaction metadata is recorded and a contract or business rules (e.g using a DEC) determine how the transaction should be processed.

In the Accdefi protocol determination, the concept of a third party is not valid since the closing contract will be co-controlled by both contracting and consenting parties. Using a third party would slow down the processing of accounting transactions (what if the third person was unavailable?) and so the use of a DEC would facilitate the legal nature of the transaction.

The term Smart Contract, which broadly means verifying another computers hardware and software in this instant would also include coded rules such that books must always balance (total debits = total credits) and only known actors and known tradable assets can be recorded.

For businesses, the Ricardian DEC overlays the technological requirements of a blockchain smart contract and encapsulates rules more easily read (and created and edited) by humans (using JSON or other formats).

If Company A buys a widget from Company B there is a legal contract to deliver and pay a consideration based on rules in the DEC. In most commercial transactions there are no disputes and both parties would as a matter of course of doing business close out their own books and records: widget has been delivered and accepted and consideration made. The smart contract would verify the two actors can close the contract out and reduce the risk of bad actor or other interruption. The DEC would determine whether the transaction could go ahead (e.g Company A is not on a Government sanctions list), how it should go ahead and how it should be closed out.

Triple Accounting was postulated before blockchain and cannot easily be engineered into current blockchain ecosystems or protocols. Consequently, Accdefi uses the term Double Entry Contract.

Not all accounting entries involve a third party. Examples include: a fixed asset amortization; or a balance sheet entry that does not involve movement of cash. In these cases the DEC would be of a simpler nature. For example, the DEC may refer to current account reporting and guidelines such as the type of asset that can be amortized and the periods allowed.

Given all the accounting entries are recorded on the GDAL (balances and backings), financial position reporting can follow any guidelines. These may be recorded off chain (e.g a reporting database) or the journal entries are reversible and flagged.

Double Entry Contract

Double entry usually implies a debit amount needs to equal a credit amount in the same Chart of Accounts. A Double Entry Contract is the term used to describe the business rules, the terms and conditions to be able to close the transaction and so offer a complete life cycle of the transaction. This goes beyond the existing concept of a Ricardian contract but still achieves the same outcome of a legal contract being executed.

Most accounting entries can be templated and these could form part of the DEC. Further governance would be undertaken to validate the balancing entries, the actors, the currencies, the account period and the chart of accounts. Initially creating global Ricardian contracts for accounting entries would be a near impossible task and so it is anticipated only basic templates would exist (e.g calculation of sales tax). Over time the DECs would become more complex and driven by ML and AI.

Glossary of terms




Global Distributed Accounting Ledger (“GDAL”)

GDAL is a blockchain record store of multiple Participant published Accounting Records

Local Distributed Accounting Ledger. (“LDAL”)

LDAL is a permissioned locally owned and controlled ledger blockchain by a Primary Participant and may be a subset of the GDAL.

A group of companies with common ownership use a LDAL blockchain record store to record accounting Records before publishing to the GDAL

Triple Entry Accounting (“TEA”)

The Accounting Records appended to a blockchain when two Participants agree to an CBA


A legal entity or natural person who conducts Commercial Business Activities and is identified uniquely by, for example, a globally recognised Legal Entity Identifier (“LEI”). A Publishing Participant can append and update the GDAL.

ABC Example Incorporated

XYZ Sole Trader

Commercial Business Activity (“CBA”)

An activity that generates debits and credits in the normal course of business

Buying or selling goods and services; cash movements; investor registers

Double Entry Contract (“DEC”)

Business rules derived from the CBA and other rules used to validate and control transaction processing

Checking risk factors, sanctions lists or credit ratings

Internal Accounting

Where the Primary Participant is also the Secondary Participant.

Accounting entries involving:

revaluations; impairments; amortizations;


closing period journals;

opening period journals;


and accruals.

Primary Participant (“AC1”)

The Participant who is the Primary owner of its Accounting Records

ABC Example Incorporated sells a widget to XYZ Sole Trader

Secondary Participant (“AC2”)

The Participant who conducts business with the Primary Participant.

XYZ Sole Trader buys a widget from ABC Example Incorporated. A subsidiary of a holding company, AC1, would be an AC2.

Publishing Participant (“ACN”)

a Participant not directly involved with the CBA who is delegated authority to append to the GDAL by one or more Participants

Tax authority; a Bank; a Government agent

Subscribing Participant (“G1”)

a Participant not directly involved with the CBA who is delegated authority to view the GDAL by one or more Participants

a Government agent; a research institution

Group Participant

A Secondary Participant that is related to the Primary Participant

The Primary Participant is a holding company and the Secondary Participant is a subsidiary


A peer-to-peer

network, storing data in packages called “blocks,”

each with a unique

“hash”(cryptographic signature) logically dependent on the hash of the previous block, (“Forward”) to which it is connected, forming a linear chain of blocks. A new block can only be added after cryptographic verification by the network, which ensures that there is only one chain of blocks,

and thus, a single set of shared facts.

Bank (“BN1”)

A Bank which provides banking facilities to a Primary Participant

Bank (“BN2”)

A Bank which provides banking facilities to a Secondary Participant

Accounting Records

A commercial transaction derived from a CBA described in terms of debits and credits and recorded using existing accounting principles. Also known as bookkeeping because the transaction is recorded in a “book.” The book where transaction raw data is first recorded – sequentially – is called a journal. Accounting records are different from bookkeeping records in that transactions are recorded analytically, rather than sequentially: transactions are classified so that the resulting record shows information that is meaningful for business life (for instance, it facilitates decision-making or financial reporting). Thus, the accounting process takes the information of the journal and posts it in a second book, where information is organized analytically. This book is known as ledger. In consequence, accounting happens in ledgers, whereas

bookkeeping is limited to journals.

Will include details such as the Primary Participant and the Secondary Participant, an amount, a currency, Metadata, transaction date, account and reporting information

Accounting Body

A legal entity that prescribes accounting standards and guidance on the layout and content of financial statements.

International Financial Reporting Standards (IFRS) is such a body.

Chart of Accounts

A list of accounts, each having a unique identifier.

1234 is designated a “creditors” account. 1235 is designated an “accruals” account.

Neural Network

The algorithms used to determine whether a transaction can be closed using blockchain data elements

An output is where a Secondary Participant fails to meet Primary Participant onboarding criteria


A subset of the Block String which contains metadata relating to a Primary Participant

Examples include an invoice number, a link to a document held on a blockchain, a cost center, or department number

Account Identifier

A Debit Account or a Credit Account flag assigned to an amount

d=debit, c=credit

Block String

The data contained within a single block identified by a unique identifier, Bn


A new block, identified as n,  appended to the GDAL

Currency (“CCY”)

A currency or medium of exchange

ISO 4217 or any list of currencies used in a CBA


When a CBA has resulted in a transaction and the counterparty Participants have confirmed full execution and Accounting Records reflect the transaction

A Widget has been purchased, delivery confirmed, consideration made, taxes paid and other settlement agreed by all publishing Participants

Typical Accounting Block

A block would be grouped by a unique journal hash d7. Some attributes of the transaction would be static and others dynamic such as the status of the transaction as determined by the DEC. Replicated data such as the currency or medium of exchange such as fiat or digital representation (d4) would only be stored once to keep the blocks small. Certain other metadata could be masked further for the purposes of security such as the actor participants. References to other BlockchainA[6] blocks via smart contract will ensure the integrity of the accounting transactions.

Private Keys (device derived) are controlled by the owner Actor and assigned to other Actors.

Reference is made to other chains using BlockchainA protocols (Actor, Assignment, Asset, Agreement, Address of backing documents, Accounting Cost) and the DEC where:

Actor = Actors who can participate in the transaction. Counterparties such as banks, tax collectors, regulators.

Assignment = Controls in the DEC on who is assigned CRU rights.

Asset = The digital or physical asset being transacted

Agreement = the DEC contract details

Address = location of fragmented files

Accounting Cost = cost of the transaction (economic and ESG)

Using DECs

Accounting records are usually in the form of debits and credits, based on a protocol invented by the Venetians or in India[7] before that. Capitalism relies entirely on debits and credits. Most accounting systems use terminology from these pre digital days such as “books” and “ledgers” and “journals” and accountants are trained to process accounting records using such nomenclature and then spend much time “reconciling” accounts to third party accounts such as bank statements, creditor and debtor statements, and inter-company accounts. Blockchain changes this and instead of multiple T accounts created in non normalized database structures, there will be one long string of blocks. Keeping the nodes to only validating certain blocks makes the ecosystem more scalable where side chains are encouraged and reporting databases are used for fast indexed searching[8].

Let’s assume there is one primary blockchain, the GDAL. This will record all the stakeholders (Actors), the amounts, the currencies, the metadata and the unique account identifiers relating to a transaction (external or internal). This will be shared by the owner with immediate counterparts or other interested parties through the auto exchange of private keys. Every record will be protected differently. When transactions have been completed, the DEC is executed by all parties and the block is locked on the blockchain. Given all the parties are using the same blockchain records, reconciliations are eliminated. Debtors and creditors have full visibility on their balances as do Banks, as a stakeholder, who can transact based on DEC business rules. Auditors also have full visibility of all stakeholders. Company Registrars can api directly to the blockchain. As can the courts. As can tax authorities. And most importantly, accountants can concentrate on forward planning instead of fire fighting history.

A blockchain gives the owners control of their books and records. It reduces the risks of private financial accounts being spied on by untrusted cloud companies or hosting services. There are no restrictions — unlimited users, unlimited legal entities, all the currencies (fiat or digital), immutable backups, currency conversions and consolidated accounts (GAAP / IFRS[9]). Invoices and other documents can be stored (or linked) on document storage blockchains such as Gvanta.

Legal entities (Incorporated Companies etc) can share the same information. Auditors will have better reliance on the balances and government agencies and regulators have instance access to financial positions and reporting. This would result in instant tax collection and instant breach reporting along with more frequent reporting to stakeholders. The key advantages will be

A typical DEC could have rules on

Machine Learning and Artificial Intelligence

For companies to operate, they have to know their customers (“KYC”). Instead of relying on the trust of others (e.g credit ratings agencies, insurance companies, historical accounting information etc), having access to real time accounting would reduce the time and effort and speed up due diligence. AI and neural networks will enable peer to peer relationships to be onboarded and off boarded much faster and with far less risk.

AI will be able to determine the probability of success and failure of companies and ensure resource allocation is optimised. Machine Learning will speed up the processing, learning to create template blocks based on past experiences.

Under the hood

Chart of Accounts


Company A will have a chart of accounts[10]. This is a familiar concept and is a list of account numbers and descriptions to which a debit and / or credit can be applied. There may be restrictions such as currency type, who has write and edit access, or whether manual adjustments can be made. The chart of accounts is often Company specific but may also follow layouts and formats based on regulatory demands.

This chart of accounts can be held on a blockchain called the AccountChart chain. The chart of accounts will map to a legal entity, the index held in the Actor chain.



Transactions can be recorded on a public DLT and a mirror or private copy that auto reconciles to a private DLT. The legal entity may want to record only balances and not transactions on a public DLT such as payroll information. The format is a flat JSON and each transaction will have a debit credit flag, Actor identifiers, Amounts, Currencies (fiat or non-fiat), Dates and an account number identifier that maps to the AccountChart chain. Bookkeeping entries recording transactions are often called Journals[11].



Private keys will control which part of the public ledger a counterparty can access. If Company A buys a widget from Company B, the creditor and debtor accounting entries will be created and on instruction by Company A, another Actor (Bank or payment service company) who has access to this transaction will execute a payment.

Where are we today?

We have a proof of concept with one GDAL and a journal processing engine using an off premise chart of accounts and third party FX rate conversions.

Despite the huge benefits, including substantial cost savings, adoption is the biggest barrier to this being successful. Disrupting a $20bn software market dominated by Microsoft is a challenge. The barriers to entry are huge and there is little appetite for change. For the ecosystem to promote value, it would need everyone to use it. However, the rise of Decentralized Finance (“DeFi”) which would benefit from a GDAL could disrupt and change the market. The rise of real time digital tax payments by governments and more demanding reporting beyond the existing slow moving and archaic reporting standards, could be some of the drivers to global adoption. The key reasons to adopt the GDAL and DEC protocols are the reduced cost, real time financial and regulatory reporting and offering the backbone to all of the DeFi ecosystem.


One GDAL will transcend borders and speed up commerce. DECs will transform the way we account. Today, every commercial transaction we perform is usually recorded somewhere whether it is Excel, SAP or Sage - and much of it is duplicated and wrong. Debits and Credits are agnostic to system, currency or platform. Accdefi is creating the world’s first open source platform with DEC protocols.

For full adoption, a model that gives users tokens or rewards for transactions would scale the use case. Having the ability to create blocks from existing software packages like Xero, Oracle or Quickbooks would reduce onboard risk and allow users to become comfortable with the new process.


All accessed in 2021 Triple entry accounting system: A revolution with blockchain Triple-Entry Accounting

Ijiri, Yuji. "A Framework for Triple-Entry Bookkeeping." The Accounting Review 61, no. 4 (1986): 745-59. Accessed May 24, 2021.

Juan Ignacio Ibañez, Chris N. Bayer, Paolo Tasca, Jiahua Xu “Triple-entry Accounting, Blockchain and Next of Kin: Towards a Standardization of Ledger Terminology” Cornell University (Year: 2021)

Institute of Chartered Accountants in England and Wales.
“Blockchain and the Future of Accountancy.” (Year: 2018)

Christidis, Konstantinos, and Michael Devetsikiotis. "Blockchains and smart contracts for the internet of things." Ieee Access 4 (2016): 2292-2303. (Year: 2016).

Yann LeCun, Yoshua Bengio, Geoffrey Hinton. Deep learning (Year:2015)

Jun Dai; Miklos A. Vasarhelyi Journal of Information Systems “Toward Blockchain-Based Accounting and Assurance” (Year: 2017)

Daniel E. O'Leary. Configuring blockchain architectures for transaction information in blockchain consortiums: The case of accounting and supply chain systems (Year: 2017)

Manlu Liu; Kean Wu; Jennifer Jie Xu “How Will Blockchain Technology Impact Auditing and Accounting: Permissionless versus Permissioned Blockchain Current Issues in Auditing” (Year: 2019)

Copyright © 2021, and/or its affiliates. All rights reserved. Accdefi is a trading name of Grandeo Limited. a UK based blockchain specialist.

Steven Garner is a Fellow of the Institute of Chartered Accountants in England and Wales.

This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.