Triple Entry Accounting

Abstract

Classical double entry accounting has provided the foundation for accounting within the firm for many centuries. The digitally signed receipt, an innovation from financial cryptography, gives rise to exactly duplicated entries for each of 3 parties or roles, the outcome of which we call triple entry accounting. This presents a challenge to double entry bookkeeping by expanding the use of accounting from inside firms to activity between the firms. When applied to digital cash and digital assets, the approach of negotiating a single signed receipt between parties lowers costs by delivering reliable data to support stronger accounting, and makes much stronger governance possible in a way that positively impacts on the future needs of corporate and public accounting. By turning the opinions of firm owners into facts agreed between firms, triple entry bookkeeping creates the bulletproof accounting layer to support aggressive uses and adversarial users such as are found in the Bitcoin system of transactions.

1. Introduction

This paper brings together financial cryptography innovations such as the signed receipt with the standard accountancy techniques of double entry bookkeeping to create a new method of bookkeeping that we call triple entry accounting (TEA). As well as introducing the concept, the contributions of this paper include a description of one implementation based on the methodology of the signed receipt, high-level requirements on implementing triple entry accounting, and many exploratory predictions on benefits and implications.

Section 2 presents a brief backgrounder to explain the importance of double entry bookkeeping. It is aimed at the technologist, and accountancy professionals may skip this. Section 3 and Section 4 present how the signed receipt arises and why it challenges double entry bookkeeping. Section 5 looks at the patterns that emerge. Section 6 establishes requirements for a system to deliver triple entry accounting, and Section 7 closes with comments on differences, rollout and fraud.

Credits

This paper slightly refreshes a 2005 draft of the same title (Grigg 2005a) which had benefitted from comments by Graeme Burnett and Todd Boyle.

2. A Very Brief History of Accounting

Accounting or accountancy is these days thought to go back to the genesis of writing; the earliest discovered texts have been deciphered as simple lists of the counts of animal and food stock. The Sumerians of Mesopotamia, around 5000 years ago, used Cuneiform or wedge shaped markings as a base-60 number form, which we still remember as seconds and minutes, and squared, as the degrees in a circle. Mathematics and writing may well have been derived from the need to add and subtract as basic accounting for the assets and stocks of early society, thus placing accountancy at the forefront of all science.

2.1. Single Entry

Single entry bookkeeping is how ‘everyone’ would do accounting: start a list, and add in entries that describe each asset. A more advanced arrangement would be to create many lists. Each list or ‘book’ would represent a category, and each entry would record a date, an amount, and perhaps a comment. To move an asset around, one would cross it off from one list and enter it onto to another list.

Very simple, but it was a method that was fraught with the potential for errors. Worse, the errors could be either accidental, and difficult to track down and repair, or they could be fraudulent. As each entry or each list stood alone, there was nothing to stop a bad employee from simply adding more to the list; even when discovered there was nothing to say whether it was an honest mistake, or a fraud.

Accounting based on single entry bookkeeping places an important limitation on the trust of the books. Likely, only the owner’s family or in times long past, his slaves could be trusted with the enterprise’s books, leading to a supportive influence on extended families or slavery as economic enterprises.

2.2. Double Entry

Double Entry bookkeeping adds an additional important property to the accounting system; that of a clear strategy to identify errors and to remove them. Even better, it has a side effect of clearly firewalling errors as either accident or fraud.

This property is enabled by means of three features, being the separation of all books into two groups or sides, called assets and liabilities, the redundancy of the duplicative double entries with each entry having a match on the other side, and the balance sheet equation, which says that the sum of all entries on the asset side must equal the sum of all entries on the liabilities side.

A correct entry must refer to its counterpart, and its counterpart entry must exist on the other side. An entry in error might have been created for perhaps fraudulent reasons, but to be correct at the local level, it must refer to its counterpart book. If not, it can simply be eliminated as an incomplete entry. If it does refer, the existence of the other entry can be easily confirmed, or indeed recreated depending on the sense of it, and the loop is thus closed.

Previously, in single entry books, the fraudster simply added his amount to a column of choice, thereby creating or taking value. In double entry books, that amount has to come from somewhere. If it comes from nowhere, it is eliminated above as an accidental error, and if it comes from somewhere in particular, that place is identified. In this way, fraud leaves a trail; and its purpose is revealed in the other book because the value taken from that book must also have come from somewhere.

This then leads to an audit strategy. First, ensure that all entries are complete, in that they refer to their counterpart. Second, ensure that all movements of value make sense. This simple strategy created a record of transactions that permitted an accountancy of a business, without easily hiding frauds in the books themselves.

2.3. Which Came First-Double Entry or the Enterprise?

Double Entry bookkeeping is one of the greatest discoveries of commerce, and its significance is difficult to overstate. Historians think it to have been invented around the 1300s AD, although there are suggestions that it existed in some form or other as far back as the Greek empire. The earliest strong evidence is a 1494 treatise on mathematics by the Venetian Friar Luca Pacioli (Pacioli 1494). In his treatise, Pacioli documented many standard techniques, including a chapter on accounting. It was to become the basic text in double entry bookkeeping for many a year.

Double Entry bookkeeping arose in concert with the arisal of modern forms of enterprise as pioneered by the Venetian merchants. Historians have debated whether Double Entry was invented to support the dramatically expanded demands of the newer ventures then taking place surrounding the expansion of city states such as Venice, or whether Double Entry was an enabler of this expansion.

Our experiences weigh in on the side of enablement. I refer to the experiences of digital money issuers. Our own first deployment of a system was with a single entry bookkeeping system. Its failure rate even though coding was tight was such that it could not sustain more than 20 accounts before errors in accounting crept in and the system lost cohesion. This occurred within weeks of initial testing and was never capable of being fielded. The replacement double entry system was fielded in early 1996 and has never lost a transaction (although there have been some close shaves (Grigg 2005b)).

Likewise, the company DigiCash BV of the Netherlands fielded an early digital cash system into a bank in the USA. During its testing period, the original single entry accounting system had to be field replaced with a double entry system for the same reason-errors crept in and rendered the accounting underneath the digital cash system unreliable.

Another major digital money system of the 1990s, e-gold, lasted for many years on a home-built single entry accounting system. Yet, the company knew it was running on luck. Allegedly, when a cracker managed to find a flaw in the system, an overnight attack allowed the creation of many millions of dollars worth of value in digital gold. As this was more than the contractual issue of value to date, it caused dramatic contortions to the balance sheet, including putting it in breach of its user contract of one for one reserves, and at dire risk of a ‘bank run’. Luckily, the cracker deposited the created value into the account of an online game that failed shortly afterwards, so the value was able to be neutralised and monetarily cleansed, without disclosure, and without scandal.

In the opinion of this author at least, single entry bookkeeping is incapable of supporting any enterprise more sophisticated than a household. Given this, I suggest that evolution of complex enterprises required double entry as an enabler.

2.4. Computing Double Entry in Quick Time

Double Entry has always been the foundation of professional accounting systems for computers. The capability to detect, classify and correct errors is even more important to computers than it is to humans, as there is no luxury of human intervention; the distance between the user and the bits and bytes is far greater than the distance between the bookkeeper and the ink marks on his ledgers.

How Double Entry is implemented is a subject in and of itself. Computer science introduces concepts such as transactions, which are defined as units of work that are Atomic, Consistent, Isolated, and Durable (or ACID for short). The core question for computer scientists is how to add an entry to the assets side, then add an entry to the liabilities side, and not crash half way through this sequence. Or even worse, have another transaction start half way through. This makes more sense when considered in the context of the millions of entries that a computer might manage, and a very small chance that something goes wrong; eventually something does, and computers cannot handle errors of that nature very well.

For the most part, these concepts simply reduce to “how do we implement double entry bookkeeping”? As this question is well answered in the literature, we do no more than mention it here.

3. A Slightly Less Brief History of the Signed Receipt

Advances in financial cryptography in the 1990s have provided a challenge to the concept of double entry bookkeeping. The digital signature is capable of creating a record with some strong degree of reliability, at least in the senses expressed by ACID, above. A digital signature can be relied upon to keep a record safe, as it will fail to verify if any details in the record are changed.

If we can assume that the the record was originally created correctly, then later errors are revealed, both of an accidental nature and of fraudulent intent, by the failure of the digital signature to verify. (Computers very rarely make accidental errors, and when they do, they are most normally done in a clumsy fashion more akin to the inkpot being spilt than a few numbers.) In this way, any change to a record that makes some sort of accounting or semantic sense is almost certainly intentional, and is likely a human error or an attempt at fraud, and a digitally signed receipt should carry enough information to indicate how to remediate.

3.1. The Digital Signature and Digital Cash

A digital signature gives us a particular property, to whit:

“at a given point in time, this information was seen and marked by the signing computer.”

There are several variants, with softer and harder claims to that property. Some simpler forms of signing include message digests with entanglement (Maniatis and Baker 2002), time-stamping servers (Haber and Stornetta 1993), and inclusion in a blockchain. Public key cryptosystems provide another form where signers hold a private key and verifiers hold a public key thus including some indication of the signer. There are many ways to attack this property, but I avoid comparisons in this essay, and assume the signature is a reliable mark of having been seen by a computer at some point in time.

Digital signatures then represent a new way to create reliable and trustworthy entries, which can be constructed into accounting systems. At first it was suggested that a variant known as the blinded signature would enable digital cash (Chaum 1992). In addition, certificates could circulate as rights or contracts, in much the same way as the share certificates of old and thus replace centralised accounting systems (Hettinga 1995). These ideas took financial cryptography part of the way there. Although they showed how to strongly verify each transaction, they stopped short of placing the digital signature in an overall framework of accountancy and governance. A needed step was to add in the redundancy implied in double entry bookkeeping in order to protect both the transacting agents and the system operators from fraud.

3.2. The Initial Role of a Receipt

Designs that derived from the characteristics of the Internet, the capabilities of cryptography and the needs of governance extended the simple receipt of

Table 1. An Example of a Simplistic Receipt.

Tags	Values	Comments
From	Alice	Alice is always the first party, by custom
To	Bob	Bob is the second party, by custom
Unit	Euro
Quantity	100	leaving aside for now euros and cents
Date	2024.01.30	the time at which this document was produced
Signature	/bob/	a mark of some form from the merchant Bob

into the digitally signed receipt of

Table 2. A Signed Receipt.

Tags	Values	Comments
Cheque	From: Alice	Alice’s Cheque is a single value within the receipt
	To: Bob
	Unit: Euro
	Qty: 100
	Date: 2024.01.30	the time at which the cheque was produced
	/alice/	Alice’s signature on her Cheque
From	Alice	Ivan duplicates the information in the Cheque
To	Bob
Unit	Euro	NB this should be hash of Euro Ricardian contract
Quantity	100
Date	2024.01.31	the time at which receipt was produced
Signature	/ivan/	Ivan signs the receipt as operator of the Receipt-issuing server

(Howland 1996). In order to develop this concept, let us assume a simple three party payment system, wherein each party holds an authorising key which can be used to sign their instructions. We call these players Alice, Bob (two users) and Ivan (the Issuer) for convenience.

When Alice wishes to transfer value to Bob in some unit or contract managed by Ivan, she enters into a computing protocol thus: She writes out the payment instruction and signs it digitally, much like a Cheque is dealt with in the physical world. She sends this to the server, Ivan, and he presumably agrees and does the transfer in his internal set of books. He also creates a receipt (see ACID, above) and signs it with his signing key. As an important part of the protocol, Ivan then reliably delivers his signed receipt to both Alice and Bob, and they can update their internal books accordingly.

3.3. The Receipt Is the Transaction

Our concept of digital value sought to eliminate as many risks as possible. This was derived simply from one of the high level requirements, that of being extremely efficient at issuance of value. Efficiency in digital issuance is primarily a function of support costs, and a major determinant of support costs is the costs of bugs, accidents, fraud and theft.

One risk that consistently blew away any design for efficient digital value at reasonable cost was the risk of insider fraud. In our model of many users and a single centralised server, the issuers of the unit of digital value (as signatory to the contract) and any governance partners such as the server operators are powerful candidates for insider fraud. Events over the last few decades such as the mutual funds scandal of 2004 (Nesfield and Grigg 2004) are canonical cases of risks that we decided to address.

In order to address the risk of insider fraud, the written receipt was historically introduced as being a primary source of evidence. Mostly forgotten to the buying public these days, the purpose of a written receipt in normal retail trade is not to permit returns and complaints by the customer, but rather to engage her in a protocol of documentation that binds the shop attendant into safekeeping of the monies. A good customer will notice fraud by the shop attendant and warn the owner to look out for the monies identified by the receipt; the same story applies to the invention of the cash till or register, which was originally just a box separating the owner’s takings from the monies in the shop attendant’s pockets. We extend this primary motive into the digital world by using a signed receipt to bind the Issuer into a governance protocol with the users.

We also go two steps further forward. Firstly, to completely bind Ivan’s action to Alice’s instruction, Alice’s original authorisation (her Cheque in Table 2) is also included within the Ivan’s receipt, which then includes all the evidence of both the user’s intention and the server’s action in response, and it now becomes a dominating record of the event. This principle of inclusion of material instructions, which we refer to as a Russian Dolls pattern, can be extended indefinitely. For example, a delivery manifest could include the signed receipt, which includes the payment, which could include the original invoice, which likewise could hold a purchase order.

This then means that the most efficient record keeping strategy is to drop all prior records and keep safe the signed receipt. This also applies to databases, as they can simply log the receipts, and then recover the transactional state on restart, a strategy that obviates the dependencies on relational structures on disk, the two-phase commit (or at least moves it from disk-bound to memory-bound), and brittle backup and recovery mechanisms.

This domination effects both the Issuer and the user, and allows us to state the following principle:

The User and the Issuer hold the same information.

or as a pithy aphorism attributed to Richard Gendal Brown has it:

I know that what you see is what I see.

As the signed receipt is delivered from Issuer to both users, all three parties hold the same dominating record for each event. The record can now be seen as a fact, in contrast with double entry accounts which are an opinion of the owner. This reduces support costs by dramatically reducing problems caused by differences in information.

Secondly, we bind a signed contract of issuance known as a Ricardian Contract into the receipt by replacing the unit of value (e.g., Euro) with the hash of the contract of issuance of that unit (Grigg 2004). This invention relates a digitally signed document securely to the signed receipt by means of a unique identifier called a message digest, again provided by cryptography. It provides strong binding for the unit of account, the nature of the issue, the terms, conditions and promises being made by the Issuer, and of course the identity of the Issuer.

Finally, with these enabling steps in place, we can now introduce the principle:

The Receipt is the Transaction.

Within the full record of the signed receipt, the user’s intention is expressed, and is fully confirmed by the server’s response. Both of these are covered by digital signatures, locking these data down. A reviewer such as an auditor can confirm the data, verify the signatures, and know with high confidence that the entry is factual.

4. The Signed Receipt as a Bookkeeping System

The principle of the Receipt as the Transaction has become sacrosanct over time. In our client software, the principle has been hammered into the design consistently, resulting in a simplified accounting regime, and delivering a high reliability. Issues still remain, such as the loss of receipts and the counting of balances by the client side software, but these become reasonably tractable once the goal of receipts as transactions is placed paramount in the designer’s mind.

4.1. As Single Entry

In order to calculate balances on a related set of receipts, or to present a transaction history, a book would be constructed on the fly from the set. This amounts to using the signed receipt as a basis for single entry bookkeeping. In effect, the bookkeeping is derived from the raw receipts, and this raises the question as to whether to keep the books in place.

The principles of Relational Databases provide guidance here. The fourth normal form directs that we store the primary records, in this case the set of receipts, and we construct derivative records, the accounting books, on the fly (Codd 1970).

4.2. Recovering Double Entry

Similar issues arise for Ivan the Issuer. The server has to accept each new transaction on the basis of the available balance in the effected books; for this reason Ivan needs those books to be available efficiently. Due to the greater number of receipts and books (one for each user account), both receipts and books will tend to exist, in direct contrast to fourth normal form. A meld between relationally sound sets of receipts and double entry books comes to assist here.

Alice and Bob both are granted a book each within the server’s architecture. As is customary, we place those books on the liabilities side. Receipts then can be placed in a separate single book and this could be logically placed on the assets side. Each transaction from Alice to Bob now has a logical contra entry, and is then represented in 3 places within the accounts of the server. Yet, the assets side remains in fourth normal form terms as the liabilities entries are derived, each pair from one entry on the assets side.

By extension, a more sophisticated client-side software agent, working for Alice or Bob, could employ the same techniques. At this extreme, entries are now in place in three separate locations, and each holding potentially three records.

4.3. Triple Entry Accounting

The digitally signed receipt, with the entire authorisation for a transaction, represents a dramatic challenge to double entry bookkeeping at least at the conceptual level. The combination of protocols and cryptographic signatures gives powerful evidentiary force to the signed receipt, and in practice reduces the accounting problem to one of the receipt’s presence or its absence-knowing that we have the full set. This problem can be solved by sharing the records—each of the agents has a good copy—or by employing a blockchain.

In some strict sense of relational database theory, double entry book keeping is now redundant; it is normalised away by the fourth normal form. Yet this is more a statement of theory than practice, and in the software systems that we have built, the two remain together, working mostly hand in hand.

Which leads to the pairs of double entries connected by the central list of receipts; three entries for each transaction. Not only is each accounting agent led to keep three entries, the natural roles of a transaction are of three parties, leading to three by three entries.

We term this method triple entry bookkeeping. Although the digitally signed receipt dominates in information terms, in processing terms it falls short. Double entry bookkeeping fills in the processing gap, and thus the two will work better together than apart. In this sense, our term of triple entry bookkeeping recommends an advance in accounting, rather than a revolution.

4.4. Software Considerations

The precise layout of the entries in software and data terms is not settled, and may be seen to be implementation issues in the short to medium turn, and ultimately issues of standardisation. The signed receipts may form a natural asset-side contra account, or they may be a separate non-book list underlying the bookkeeping system and its two sides.

Auditing issues arise where construction of the books derives from the receipts, and normalisation issues arise when a receipt is lost, although note that the blockchain design has substantially mitigated the problem of lost receipts. These are issues for ongoing research.

Likewise, it is worth stating that the technique of signing receipts works as well with private key signatures, with entanglement, with timestamping servers, and also with entry of the receipt into a blockchain; whether the security aspects of these techniques is adequate to task is dependent on the overall business environment.

4.5. Roles of the Agents

It will be noted that the above design of triple entry bookkeeping assumed that Alice and Bob were agents of some independence. This was made possible, and reflected the usage of the system as a digital cash system, and not as a classical accounting system.

Far from reducing the relevance of this work to the accounting profession, it introduces digital cash as an alternate to corporate bookkeeping. If an accounting system for a corporation or other administrative entity is recast as a system of digital cash, or internal money, then experience shows that benefits accrue to the organisation.

Although the core of the system looks exactly like an accounting system, each department’s books are pushed out as digital cash accounts. Departments no longer work so much with budgets as have control over their own corporate money. Fundamental governance control is still held within the accounting department by dint of their operation of the system, and by the limited scope of the money as only being usable within the organisation; the accounting department might step in as a market maker, exchanging payments in internal money for payments in external money to outside suppliers.

We have operated this system on a small scale (Grigg 2003). Rather than be inefficient on such a small scale, the system has generated dramatic savings in economics coordination within the firm. No longer are bills and salaries paid using conventional monies; many transactions are dealt with by internal money transfers and at the edges of the corporation, agents work to exchange between internal money and external money. Paperwork reduces dramatically, as the records of the money system are reliable enough to quickly resolve questions even years after the event.

The innovations present in internal money go beyond the present paper, but suffice to say that they answer the obvious question of why this design of triple entry accounting sprung from the world of digital cash, and has relevance back to the corporate world.

5. Patterns of Commerce

Todd Boyle looked at a similar problem from the point of view of small business needs in an Internet age, and reached the same conclusion-triple entry accounting-as well as coining the term (Boyle 2001). He started from the rather stunning observation that for every trade record in one firm, there is a matching trade record in the counterparty firm. Why can’t they be the same?

His starting premises were that:

• The major need is not accounting or payments per se, but patterns of exchange-complex patterns of trade;
• Small businesses could not afford large complex systems that understood these patterns;
• They would not lock themselves into proprietary frameworks.

From those foundations, Boyle concluded that therefore what is needed is a shared access repository that provides arms-length access. Functionally, this repository is akin to the classic double-entry accounting ledger of transaction rows (GLT, for General Ledger-Transactions), yet its entries are dynamic and shared.

Simple examples will help. When Alice forms a transaction, she enters it into her software. Every GLT transaction requires naming her external counterparty, Bob. When she posts the transaction, her software stores it in her local GLT and also submits it to the Shared Transaction Repository’s (STR) GLT.

The STR, as a shared service, then forwards the transaction on to Bob. Both Bob and Alice are now expected to store the handle to the transaction as an index or stub, and the STR then stores the entire transaction.

Boyle’s ideas are logically comparable to Grigg and Howland’s, although they arrive from different directions (the STR is Grigg’s Ivan, above) and are not totally equivalent. Where the latter limited themselves to payments, the accuracy of amounts, and protection with hard cryptographic shells, Boyle looked at wider patterns of transactions, and showed that the STR could mediate these transactions, if the core shared data could be extracted and made into a single shared record. Boyle’s focus was on the economic substance of the transaction.

5.1. Extending the Humble Invoice

Imagine a simple invoicing procedure. Alice creates an invoice and posts it to her software (GLT). As she has named Bob, the GLT automatically posts it to Ivan, the STR, and he forwards it to Bob. At this point Bob has a decision to make, accept or reject. Assuming acceptance, his software can then respond by sending an acceptance message to Ivan. The STR now assembles an accepted invoice record to replace the earlier speculative invoice record and posts that threeways. At some related time (to do with payment policy) Bob also posts a separate transaction to pay for the invoice. This could operate in much the same way as a separate transaction, linking directly to the original invoice.

Now, as the payment links back, and the invoice is a live transaction within the three entries in the three accounting systems, it is possible for a new updated invoice record to refer back to the payment activity. When the payment clears, the new record can again replace the older unpaid copy and promulgate to all three parties.

5.2. Patterns of Transactions

Software could be written to facilitate and monitor this flow and similar flows. If the payments system is sufficiently flexible, and integrated with the needs of the users, if might be possible to merge the above invoice with the payment itself, at the receipts level. Seen in this light, the signed receipt of Ricardo is simply the smallest and simplest pattern within the more general set of patterns. We could then suggest that the narrow principle of the Receipt is the Transaction could be extended into The Invoice is the Transaction.

A particular transaction in business almost never stands alone. They come in patterns. For example offers and acceptances form a wider transaction but seldom encapsulate the entire fulfillment and payment cycle. Even if there has been a payment accompanying a Purchase Order message, the customer then waits for fulfillment.

There is a large body of science and literature built around these patterns of transactions. These have been adopted by the Business Process workgroup of ebXML, the work of the Resource-Entity-Agent school (McCarthy 1982), and other standards bodies, where they are called “Commercial Transactions”. Where however the present work distinguishes itself is in breaking down these transactions into the atomic elements, to which we now turn.

6. The Requirements of Triple Entry Accounting

The implementation of Triple Entry Accounting will in time evolve to support patterns of transactions. What has become clear is that double entry does not sufficiently support these patterns, as it is a framework that breaks down as soon as the number of parties exceeds one. Yet, even as double entry is “broken” on the net and unable to support commercial demands, triple entry is not widely understood, nor are the infrastructure requirements that it imposes well recognised.

Below are the list of requirements that we believed to be important (Boyle 2000; Grigg 1996).

• Strong Pseudonymity, At Least. As there are many cycles in the patterns, the system must support a clear relationship of participants. At the minimum this requires a pseudonymous architecture, as today exemplified by blockchain. (This requirement is very clear, but space prevents any discussion of it).
• Entry Signing. In order to neutralise the threats to and by the parties, a mechanism that freezes, confirms and timestamps the basic data is needed. This is digital signing, and we require that all entries are capable of carrying digital signatures (see 1, above, which suggests public key signatures, but also note that we interpret digital signing to include timestamping (Haber and Stornetta 1993), and entry into a blockchain).
• Message Passing. The system is fundamentally one of message passing, in contrast to much of the net’s connection based architecture, and in contrast to balance-based designs seen in mainstream finance. Boyle recognised early on that a critical component was the generic message passing nature, and Systemics proposed, built and revised message passing into Ricardo over successive generations (Howland 1996)1.
• Entry Enlargement and Migration. Each new version of a message coming in represents an entry that is either to be updated or added. As each message adds to a prior conversation, the stored entry needs to enlarge and absorb the new information, while preserving the other properties. Methods include inclusion, in the sense of Russian Dolls; hash- and block-id linking; and evolving state machines (smart contracts) along the lines of Corda (Brown et al. 2016).
• Local Entry Storage and Reports. TEA needs the persistent saving and responsive availability of entries. In practice, this is the classical accounting general ledger, at least in storage terms. It needs to bend somewhat to handle much more flexible entries, and its report capabilities become more key as they conduct intrinsic reconciliation on a demand or live basis.
• Integrated Hard Payments. Trade can only be as efficient as the payment. That means that the payment must be at least as efficient as every other part; which in practice means that a payment system should be built-in at the infrastructure level. C.f., Ricardo or Bitcoin (Nakamoto 2008), which sport payments as first class citizens, unlike for example layer 2 or external fiat units such as CBDCs.
• Integrated Application-Level Messaging. As distinct to the messaging at the lower protocol levels (3 above), there is a requirement for Alice and Bob to be able to communicate. That is because the vast majority of the patterns turn around the basic communications of the agents. There is little point in establishing a better payment and invoice mechanism than the means of communication and negotiation. This concept is perhaps best seen in the SWIFT system which is a messaging system, first and foremost, to deliver instructions for parties to make payments.
• Define the set. This original paper focussed on the single transaction, and left alone the question of defining the set of all transactions. In a client-server environment, hash chaining, audits, recovery cycles and governance can be useful tools to define the set, but it should also be noted that blockchain includes the definition of the set as a direct outcome of the design for a decentralised shared ledger.

7. Conclusions

Double Entry bookkeeping provides evidence of intent and origin, leading to strategies for dealing with errors of accident and fraud (Pacioli 1494). The financial cryptography invention of the signed receipt provides the same benefits and more. Indeed, in evidentiary terms, the signed receipt is more powerful than double entry records due to the technical qualities of its signature and its agreement between the three parties. In this way, triple entry accounting challenges the 500 year reign of double entry; that which double entry did inside the firm, triple entry does between firms; what double entry did for the firm, triple entry does for the economy.

There remain some weaknesses in strict comparison with double entry bookkeeping. Firstly, in the Ricardo instantiation of triple entry accounting, the receipts themselves may be lost or removed, and for this reason we stress as a principle that the entry is the transaction. This results in three active agents who are charged with securing the signed entry as their most important record of transaction (noting that blockchain designs mitigate this issue of Requirement 8 above).

Secondly, the analysis ramifications of the triple entry system are less convenient than those offered by double entry bookkeeping. For this reason, we expand the information held in the receipt into a set of double entry books; in this way we have the best of both worlds on each node: the evidentiary power of the signed entries and the convenience and local crosschecking power of the double entry concept.

Both of these imperatives meld signed receipts in with double entry bookkeeping. As we end up with a logical arrangement of three by three entries, we feel the term triple entry bookkeeping is useful to describe the advance on the older form.

7.1. Drawing in the Agents

To fully benefit from triple entry bookkeeping, we have to expand accounting systems out to agents and offer them direct capabilities to do transactions. One method by which we can make agents into stakeholders is by giving them internal money (Grigg 2003). Use of digital cash to do company accounts can act as a general replacement for accounting using books and departmental budgets, and is an enabler for verifying and auditing the centralised accounts system by way of signed receipts.

7.2. Solving Frauds

Once there, governance receives substantial benefits. Accounts are now much more difficult to change, and much more transparent. It is our opinion that various scandals and failures of governance would have been impossible given these techniques: finance could show a clear audit trail of transactions and thus the late timing and otherwise perverted or dropped transactions of the 2004 mutual funds scandal would have been clearly identified or eliminated completely (Nesfield and Grigg 2004). Likewise, accounting failures such as Barings, Enron, the Great Financial Crisis of 2008, Madoff, Mt.Gox, FTX and the Post Office scandal would have been impossible or substantially mitigated if the enterprises had been built on the strong evidentiary basis of signed receipts that are transparent, impossible to forge, and permit the more powerful “follow the money” techniques now seen in blockchain.