1. Introduction
Triple Entry Accounting (TEA) is an innovative discovery in the field of accounting and is considered as an extension of double-entry accounting (
Grigg 2005). Between 1995 and 1997, Grigg introduced the concept of triple-entry accounting, which combined financial information from two companies into a single transaction receipt. This transaction receipt includes cryptographic signatures and constitutes the origin of triple entry (
Ibañez et al. 2023). Independent in 1997, Boyle proposed the idea of shared ledger, which allowed two parties to communicate transactions in a single shared transaction repository. The two streams converged into TEA in 2005. In traditional double-entry accounting, a receipt for a financial transaction is issued by a central party, such as a bank, to commit the transaction between a payer and a payee. Grigg questioned this traditional accounting model, arguing that the central party has excessive power and this could result in the central party committing fraud using receipts (
Simoyama et al. 2017). To mitigate this risk, the TEA model was proposed to ensure that all involved parties receive the same receipt for that financial transaction. Such a receipt includes all related parties’ signatures to ensure data integrity of the receipt.
The concept of TEA is sometimes confused with triple-entry bookkeeping (TEB). Ibañez et al. classified the distinction as bookkeeping is simply recording transactions in sequence (
Ibañez et al. 2021a) while accounting is the process of summarizing and analysing company information based on bookkeeping to help the company make decisions (
Ibañez et al. 2021b). Thus, definitions of bookkeeping and accounting are inherited by TEA and TEB. TEB systems simply use the triple-entry method to record transactions, and TEA systems add an accounting layer on the top of TEB (
Ibañez et al. 2021a). Additionally, in Grigg’s TEA, ‘entry’ represents a signature record which is a signed message by a party, or simply a signature, and TEA is a ‘signature gathering process’ (
Ibañez et al. 2023).
Grigg’s TEA concept relies on a trusted third party with the shared ledger, and this makes it challenging to implement in the real accounting world (
Singh et al. 2021). With the advent of Bitcoin (
Nakamoto 2008), it becomes practicable as the Bitcoin blockchain can replace the role of the trusted third party, making TEA increasingly viable. In other words, Bitcoin simply uses the triple-entry method to record transactions. It is worth noting that Bitcoin is a TEB system, but it can become a TEA by adding an accounting layer on top (
Ibañez et al. 2023). The accounting layer will record transactions in a systematic and controlled method to facilitate business events such as tax reporting and invoicing. In general, unspent transaction output (UTXO)-based blockchains can be regarded as TEA examples (
Grigg 2011). The blockchain-integrated TEA solutions are used to improve the efficiency of processing data, reduce the risk of human error, enable fully automated auditing, and save time and costs in reporting, tax filing, payment, and compliance (
Ibañez et al. 2021b;
Faccia and Mosteanu 2019;
Baba et al. 2021).
Not all blockchains can immediately enable TEA. Some of them need to run smart contracts to enable a TEA system, for instance, the account-based blockchains like Ethereum and managed ledgers such as Ripple (XRP ledger) (
Grigg 2017). In addition, some existing blockchain-based TEA systems are facing a scalability issue. To resolve this issue, these systems propose a second layer or off-chain solution, e.g., the Request network (
Request 2018), or to use a permissioned ledger, e.g., Hyperledger (
Ibañez et al. 2021b). The Request TEA system (
Request 2018), built on top of Ethereum blockchain, adopts an InterPlanetary File System to store data and partially use the blockchain for time stamping. These solutions can partially address the problem, but they still inherit the disadvantages of the adopted ledgers, such as the poor stability of Ethereum and the low transparency of Ripple and Hyperledger (
Joseph et al. 2022).
Recent collapses of cryptocurrencies such as FTX collapse (
Vidal-Tomás et al. 2023) and Terra luna crash (
Liu et al. 2023) may affect people’s perception of blockchain technology’s capabilities and potential, especially when solutions are deployed on cryptocurrency-powered blockchains. While cryptocurrencies are the most well-known application of blockchain technology, cryptocurrency collapses will not end blockchain itself. Blockchain has proven valuable beyond cryptocurrencies and can continue to evolve in many industries even if specific cryptocurrencies face challenges and different types of attacks appear (
Gountia 2019).
There are significant costs associated with auditing financial data. The UK publicly listed companies paid more than £1bn to audit firms in 2021 (
Financial Reporting Council 2022). It is anticipated by the Financial Reporting Council (FRC) that new auditing solutions can reduce audit fees and improve the audit quality (
Financial Reporting Council 2022). Although blockchains are decentralised, they are by no means exempt from auditing and the high associated costs. In fact, long-established regulations such as the
travel rule, which stipulates that transactions over a certain value must be reported to a financial authority, are immediately applicable to Bitcoin and other decentralised cash systems, and, therefore, an auditing system is required.
It was the goal of this paper to allow users of Bitcoin to be audited in a manner that leverages the transparency and immutability of the blockchain whilst promoting on-chain privacy. We carried this out by developing a TEA protocol on Bitcoin that is efficient and practical. The starting point is to allow users to establish an off-chain link between invoices and identity information with on-chain transactions used for payments. Users then individually submit transactions to a third-party auditor and anomalies are detected if one user submits a transaction that their counterparty does not submit. In this case, the auditor can request the identity information of the non-compliant counterparty which is provably linked to the transaction.
The advantages of our scheme are as follows.
All transactions are automatically audited in real-time. The blockchain provides transparency, immutability, and availability of transaction data.
Our protocol is private in the sense that an adversary monitoring the blockchain will learn nothing about users’ identities or the details of the invoices. This is because identity and invoice information are linked to on-chain public keys in a manner that cannot be inferred by inspecting public keys alone.
Before a payment is made, the two transacting parties exchange identity information that will be linked to a single on-chain transaction. Once the transaction is published on the blockchain, a user can use the identity information and a Simplified Payment Verification (SPV) (
Nakamoto 2008) proof to independently prove that their counterparty has taken part in the transaction.
After a predefined time period, e.g., one day, each user makes a commitment to the third-party auditor of the transactions they have made. This commitment is stored on the blockchain and, so, cannot be changed retrospectively.
A Merkle root is used for the commitment of a user’s transactions to an auditor. This makes it efficient for a user to prove that they have included a specific transaction in the commitment when challenged. It is also private in the sense that the user does not need to give information about any other transactions during such a challenge.
If all users are compliant, then they are never asked to provide identity information to the auditor. If one party is non-compliant, the compliant party can provide independent proof to the auditor of their own compliance and their counterparty’s involvement in the transaction.
The paper is organized as follows:
Section 2 provides an overview of Bitcoin as a TEB system, the travel rule, and how identity can be linked to a public key but still preserve privacy on the blockchain. In
Section 3, we outline our invoice auditing protocol including the method of embedding the invoice into the blockchain and verifying it. The protocol also describes how the auditor can efficiently and automatically check the data integrity of all related invoices. We end with a conclusion in
Section 4.
3. Invoice Auditing Protocol
In the auditing process, it is necessary to verify the accuracy and completeness of invoices. However, invoice verification can be time-consuming, and it is not easy for auditors to detect all invoices and mistakes related to these invoices. The traditional way for the auditor is to randomly select a valid sample of invoices and detect the possible mistakes from this sample. One blockchain solution has been provided to solve this issue through publishing a blockchain transaction, which includes the hash values associated with invoices (
Vincent et al. 2020). However, there is a problem with this solution that the invoices that are hashed directly on the blockchain can be easily traced if compromised. Our solution will solve this problem without including any hash values on the blockchain but still allowing stakeholders to verify the data integrity of the invoices.
We proposed an invoice-auditing protocol on top of Bitcoin, which allows entities to independently verify the invoices and auditors to efficiently match transactions associated with those invoices. This protocol can improve the auditing process and save time for auditors. Furthermore, this makes auditing automatic and checking all invoices possible (instead of a random selection). An invoice auditing overview is given in
Figure 2.
It is implemented in two stages: invoice verification and transaction matching.
Invoice verification—this makes the invoice verifiable by entities but without disclosing information of the invoice on the blockchain;
Invoice audit—this allows the auditor to audit all invoices and the related payments in an efficient way.
3.1. Invoice Verification
Invoice verification refers to the process of reviewing and verifying invoices for accuracy, completeness, and valid authorization from each party. The auditor needs to check that invoices have been approved by appropriate parties and have not been tampered with.
In our auditing model, we assumed that the invoice is recorded in a Bitcoin transaction and is independently verifiable by entities. This section will introduce how an invoice is embedded in the Bitcoin transaction and can be mutually authenticated, and then describe how the auditor verifies the data integrity of the invoice based on the transaction.
Record and Sign Invoice
We suppose that Alice and Bob are the transaction-related parties. To comply with Travel Rule and FATF regulations (
United States Department of the Treasury Financial Crimes Enforcement Network 1997;
Financial Action Task Force 2019), they need to exchange information off-chain which provably links their identity to the transaction. For example, we assume that they have a well-known public key, denoted, respectively, as
and
, to identify each other and establish an authenticated and confidential communication channel to exchange the invoices. However, it is worth noting that these two public keys,
and
are never used to send or receive any Bitcoin payments. In other words, they will not appear on the blockchain.
Bob generates an invoice ( and signs it with the private key related to . Here, we assume the Elliptic Curve Digital Signature Algorithm (ECDSA) with secp256k1 is used to sign the invoice, and the signature is denoted as . The signed invoice indicates that Bob will provide the goods or services if Alice completes the payment to the invoice . Alice can verify with the given invoice and . If is not valid, Alice will not make the payment. If is invalid because the given invoice is not one signed by Bob, Alice can require Bob to resend that should be generated with the correct invoice.
If Alice requires amendments to the invoice, Bob updates the contents of the invoice and regenerates a digital signature of each new iteration of the invoice until both parties reach a final agreement. Having arrived at an agreement, Alice verifies the signature , to ensure that Bob signs the agreed invoice.
When Alice and Bob reach an agreement about the invoice, they create new public keys to be used in the transaction. These public keys should be related to their identity and the invoice in the manner given in Equation (1). Concretely, Bob creates a public key
to receive funds and Alice creates a public key
to be used as a change address. These keys are calculated as follows.
where
, and SHA-256 is a cryptographic hash function that outputs a fixed-length 256-bit hash value.
Bob sends a payment transaction template containing to Alice. To complete the transaction, Alice adds her change address to the outputs and a funding UTXO in the input along with a valid signature. (Note that the public key used in the input UTXO may be linked to Alice’s identity as well.)
The finalised transaction is displayed in
Table 1.
described in
Section 2.3 is used by Alice to make the payment, and
is the associated signature. The value
is the payment amount that Alice agrees to pay to Bob, and
is the change that Alice will receive after completing the payment.
Note that the invoice is embedded within the public keys used in outputs of the above transaction, but it is not disclosed directly on the blockchain either in its raw form or a hash. Therefore, even if the invoice is leaked, it will be difficult to track the related transaction without the invoice-signed signature and identity-related public keys. To ensure their relationship is untraceable, signatures and public keys are not stored along with the invoice.
3.2. Invoice Audit
The auditor requests Bob to provide the following information to check the accuracy and completeness of the invoices: the shared secret , the invoice , and The auditor can then verify against . If is valid, the auditor generates the change public key using Equation (3) and compares it with in the locking script. If it matches, the auditor can confirm that the invoice embedded into the is the same as the invoice Bob provides to Alice. All invoices can be audited using this way and, more importantly, this can be carried out automatically. However, if checked only from Bob’s side, the auditor cannot be sure that Bob has provided all transactions and invoices related to Alice. Therefore, the auditor also requires Alice to report all related transaction IDs.
Transaction Compliance
The first step is for the auditor to ask for a commitment from Alice and Bob as to the transactions they have reported. To make the process more efficient, the auditor can require, e.g., Bob to gather all his transactions in a regular period, e.g., one month, to construct a Merkle tree with Merkle root
. That is, the auditor is checking the equality of transactions in batches. The auditor also requires Bob to report
using a Bitcoin transaction. As shown in
Table 2, the report transaction specifies the output to the auditor’s public key
and embeds
as an
OP_RETURN data payload. The value
is the dust value, which is the minimum amount accepted by Bitcoin nodes. We assume that the
is certified and given to Alice and Bob beforehand.
After receiving from , the auditor calculates the Merkle root of all that Bob has sent that month, and checks . If they are not equal, the auditor requires Bob to resubmit a new . The auditor also requires Alice to submit the similar report transaction including . We apply the same process to check .
The above step is intended for the audit to check that the auditor has accurately received all transactions that were reported individually by Alice and Bob. If this is the case, the auditor can then check if the transactions match. Namely, the auditor should receive the same transaction ID twice, one from Alice and the other from Bob. If a transaction ID only appears once, then the auditor knows that someone has not reported their transaction. If this is the case, the auditor asks the party who reported the transaction for the identity and invoice information about the party who did not report the transaction. Recall that this identity and invoice information is provably linked to the transaction, and available to both parties.
For example, if there is a transaction reported by Alice and not by Bob, the auditor asks Alice for the transaction, Bob’s identity information, and the invoice. The auditor can then contact Bob with evidence of non-compliance and ask him for an explanation. In our simple example, there are just two parties, Alice and Bob, and so, it is obvious who has not reported their transaction. But it easily extends to multiple parties where it becomes necessary for the auditor to specifically ask the compliant party who their non-compliant counterparty was in the transaction.