cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
e49662106b
wallet/docs/triple_entry_accounting-by_Iang.mhtml

1507 lines
44 KiB
Mason
Raw Normal View History

leaving potentially inconvenient history behind
2022-02-16 00:53:01 -05:00
From: <Saved by Blink>
Snapshot-Content-Location: https://iang.org/papers/triple_entry.html#index
Subject: Triple Entry Accounting
Date: Sat, 3 Oct 2020 06:02:11 -0000
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html";
boundary="----MultipartBoundary--ZJLbQ4mRwLhAHsHENVppcDUXKvpxlvNoq0H6MRFUAo----"
------MultipartBoundary--ZJLbQ4mRwLhAHsHENVppcDUXKvpxlvNoq0H6MRFUAo----
Content-Type: text/html
Content-ID: <frame-79941C4E8BDF0F4E0BDA317EB334908B@mhtml.blink>
Content-Transfer-Encoding: quoted-printable
Content-Location: https://iang.org/papers/triple_entry.html#index
<html><!-- page.pl --><head><meta http-equiv=3D"Content-Type" content=3D"te=
xt/html; charset=3Dwindows-1252">
<title>Triple Entry Accounting</title>
</head>
<body>
<br><br>
<center>
<u><i>Work - in - Progress</i></u>
<br><br>
<font size=3D"+2"><strong>
Triple Entry Accounting
</strong></font>
<br><br>
<font size=3D"+1">
Ian Grigg<br>
<i>Systemics, Inc.</i><br>
</font>
<br>
2005
<br><br>
</center>
<!-- PS_DROP -->
<!-- /PS_DROP -->
<center>
<b><big>$Revision: 1.7 $</big></b><br>
<small>$Date: 2005/12/25 23:04:21 $</small>
</center>
<div><br><br><br><blockquote>
<p> <b>Abstract: </b>
The digitally signed receipt, an innovation from
financial cryptography, presents a challenge
to classical double entry bookkeeping. Rather
than compete, the two melded together
form a stronger system. Expanding the usage of
accounting into the wider domain of digital cash
gives 3 local entries for each of 3 roles,
the result of which I call
<i>triple entry accounting</i>.
</p>
<p>
This system creates bullet proof accounting
systems for aggressive uses and users.
It not only lowers costs by delivering
reliable and supported accounting,
it makes much stronger governance possible
in a way that positively impacts on the future
needs of corporate and public accounting.
</p>
</blockquote><br><br></div>
<h2><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"int=
ro">Introduction</a></h2>
<p>
This paper brings together financial cryptography
innovations such as the Signed Receipt with the
standard accountancy techniques of double entry
bookkeeping.
</p>
<p>
The first section presents a brief backgrounder
to explain the importance of double entry
bookkeeping. It is aimed at the technologist,
and accountancy professionals may skip this.
The second section presents how the Signed
Receipt arises and why it challenges double
entry bookkeeping.
</p>
<p>
The third section integrates the two together
and the Conclusion attempts to predict wider
ramifications into Governance issues.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"cre=
dits">Credits</a></h3>
<p>
This paper benefitted from comments by
Graeme Burnett and Todd Boyle
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_TB" nam=
e=3D"back_TB">TB</a>]</small>.
</p>
<h2><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"acc=
t">A Very Brief History of Accounting</a></h2>
<p>
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 <i>Cuneiform</i>
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 themselves
may well have been derived from the
need to add, subtract and indeed
account for the basic assets and
stocks of early society.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"sin=
gle">Single Entry</a></h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"dou=
ble">Double Entry</a></h3>
<p>
<a href=3D"http://en.wikipedia.org/wiki/Double-entry_book-keeping">
Double Entry bookkeeping</a>
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 <i>either</i>
accident <i>or</i> fraud.
</p>
<p>
This property is enabled by means of three features,
being the separation of all books into two groups
or sides, called <i>assets</i> and <i>liabilities</i>,
the redundancy of the duplicative
<i>double entries</i> with each entry
having a match on the other side,
and the <i>balance sheet equation</i>, which says that
the sum of all entries on the asset side
must equal the sum of all entries on the
liabilities side.
</p>
<p>
A correct entry must refer to its counterparty, 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 counterparty book.
If not, it can simply be eliminated as an incomplete
entry.
If it does refer, the existance of the other entry
can be easily confirmed, or indeed recreated depending
on the sense of it, and the loop is thus closed.
</p>
<p>
Previously, in single entry books, the fraudster
simply added his amount to a column of choice.
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.
</p>
<p>
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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"dou=
ble">Which Came First - Double Entry or the Enterprise?</a></h3>
<p>
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
<a href=3D"http://www-groups.dcs.st-andrews.ac.uk/~history/Mathematicians/P=
acioli.html">
Luca Pacioli</a>
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_LP" na=
me=3D"back_LP">LP</a>]</small>.
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.
</p>
<p>
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.
</p>
<p>
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
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_IG1" n=
ame=3D"back_IG1">IG1</a>]</small>).
</p>
<p>
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.
</p>
<p>
Another major digital money system lasted for many
years on a single entry accounting system. Yet,
the company knew it was running on luck. 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. 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
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.
</p>
<p>
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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"dou=
ble">Computing Double Entry in Quick Time</a></h3>
<p>
Double Entry has always been the foundation
of 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.
</p>
<p>
How Double Entry is implemented is a
subject in and of itself.
Computer science introduces concepts such
as <i>transactions</i>,
which are defined as units of work that are
<i>atomic</i>, <i>consistent</i>,
<i>isolated</i>, and <i>durable</i>
(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.
</p>
<p>
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.
</p>
<h2><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"rec=
eipt">A Slightly Less Brief History of the Signed Receipt</a></h2>
<p>
Recent advances in financial cryptography 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 reliabilty, 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.
</p><p>
</p><p>
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.
(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 an attempt at fraud, and a
digital signature makes this obvious.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"dig=
icash">The Digital Signature and Digital Cash</a></h3>
<p>
A digital signature gives us a particular property,
to whit:
</p>
<blockquote><i>
"at a given point in time, this information
was seen and marked by the signing computer."
</i></blockquote>
<p>
There are several variants,
with softer and harder claims to that property.
For example, <i>message digests</i> with
<i>entanglement</i> form one simple and
effective form of signature, and
<i>public key cryptosystems</i> provide
another form where signers hold a private
key and verifiers hold a public key
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_MB" na=
me=3D"back_MB">MB</a>]</small>.
There are also many ways to attack the
basic property.
In this essay I avoid
comparisons, and assume the basic property
as a reliable mark of having been seen by
a computer at some point in time.
</p>
<p>
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
<i>blinded signature</i>
would enable digital cash
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_DC" na=
me=3D"back_DC">DC</a>]</small>.
Then, <i>certificates</i> would
circulate as rights or contracts, in much
the same way as the share certificates
of old and thus replace centralised accounting
systems
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_RAH" n=
ame=3D"back_RAH">RAH</a>]</small>.
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 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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"rec=
eipt">The Initial Role of a Receipt</a></h3>
<table cellspacing=3D"30" width=3D"50%" align=3D"right">
<tbody><tr><td>
<table border=3D"1" cellpadding=3D"10">
<tbody><tr><td bgcolor=3D"#F0F0F0">
<p align=3D"center"><i>1: An Interim Receipt</i></p>
<center>
<table bgcolor=3D"#99FFFF" border=3D"1">
<tbody><tr><td>
<table cellspacing=3D"5">
<tbody><tr>
<td>From</td>
<td>Alice</td>
</tr><tr>
<td>To</td>
<td>Bob</td>
</tr><tr>
<td>Unit</td>
<td>Euro</td>
</tr><tr>
<td>Quantity</td>
<td>100</td>
</tr><tr>
<td>Date</td>
<td>2005.12.25</td>
</tr>
</tbody></table>
</td></tr>
<tr><td>
<table cellspacing=3D"5">
<tbody><tr>
<td><i>digital signature</i></td>
</tr>
</tbody></table>
</td></tr>
</tbody></table></center>
</td></tr>
</tbody></table>
</td></tr>
</tbody></table>
<p>
Designs that derived from the characteristics of
the Internet, the capabilities of cryptography
and the needs of governance
led to the development of the
<i>signed receipt</i>
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_GH" na=
me=3D"back_GH">GH</a>]</small>.
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 <i>Alice</i>, <i>Bob</i> (two users)
and <i>Ivan</i> (the Issuer)
for convenience.
</p>
<p>
When Alice wishes to transfer value to Bob in some
unit or contract managed by Ivan, 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 then issues a receipt and signs it with his
signing key.
As an important part of the protocol,
Ivan then reliably delivers the
signed receipt to both Alice and Bob,
and they can update their internal books
accordingly.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"cla=
sh">The Receipt <i>is</i> the Transaction</a></h3>
<p>
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 fraud and theft.
</p>
<p>
One risk that consistently blew away any
design for efficient digital value at
reasonable cost was the risk of <i>insider fraud</i>.
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 years such as the mutual
funds and stockgate scandals are canonical cases
of risks that we decided to address.
</p>
<table cellspacing=3D"30" width=3D"50%" align=3D"right">
<tbody><tr><td>
<table border=3D"1" cellpadding=3D"10">
<tbody><tr><td bgcolor=3D"#F0F0F0">
<p align=3D"center"><i>2: A Signed Receipt</i></p>
<center><table bgcolor=3D"#99FFFF" border=3D"1">
<tbody><tr><td>
<table cellspacing=3D"5">
<tbody><tr>
<td>User's Cheque</td>
<td>
<table bgcolor=3D"#FFBBFF" border=3D"1">
<tbody><tr><td>
<table>
<tbody><tr><td>
</td>
</tr><tr>
<td>From</td>
<td>Alice</td>
</tr><tr>
<td>To</td>
<td>Bob</td>
</tr><tr>
<td>Unit</td>
<td>Euro</td>
</tr><tr>
<td>Qty</td>
<td>100</td>
</tr><tr>
<td>Com</td>
<td>Pens</td>
</tr>
</tbody></table>
</td></tr>
<tr><td>
<table cellspacing=3D"5">
<tbody><tr>
<td><i>Alice's sig</i></td>
</tr>
</tbody></table>
</td></tr>
</tbody></table>
</td>
</tr><tr>
<td>From</td>
<td>Alice</td>
</tr><tr>
<td>To</td>
<td>Bob</td>
</tr><tr>
<td>Unit</td>
<td>Euro</td>
</tr><tr>
<td>Quantity</td>
<td>100</td>
</tr><tr>
<td>Date</td>
<td>2005.04.10</td>
</tr>
</tbody></table>
</td></tr>
<tr><td>
<table cellspacing=3D"5">
<tbody><tr>
<td><i>Ivan's signature</i></td>
</tr>
</tbody></table>
</td></tr>
</tbody></table></center>
</td></tr>
</tbody></table>
</td></tr>
</tbody></table>
<p>
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.
</p>
<p>
We also go several steps further forward.
Firstly, to achieve a complete binding,
Alice's original authorisation
is also included within the record.
The receipt then includes all the
evidence of both the user's
intention and the server's action
in response, and it now becomes a
<i>dominating record</i> of the event.
This then means that the most efficient
record keeping strategy is to drop all
prior records and keep safe the signed
receipt.
</p>
<p>
This domination effects both the Issuer and the
user, and allows us to state the following principle:
</p>
<blockquote><i>
The User and the Issuer hold the same information.
</i></blockquote>
<p>
As the signed receipt is delivered from Issuer
to both users, all three parties hold the same
dominating record for each event. This reduces
support costs by dramatically reducing problems
caused by differences in information.
</p>
<p>
Secondly, we bind a signed contract
of issuance known as a
<i>Ricardian Contract</i>
into the receipt
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_IG2" nam=
e=3D"back_IG2">IG2</a>]</small>.
This invention relates a digitally signed
document securely to the signed receipt by
means of a unique identifier called a
<i>message digest</i>,
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.
</p>
<p>
Finally, with these enabling steps in place,
we can now introduce the principle:
</p>
<blockquote><i>
The Receipt </i>is<i> the Transaction.
</i></blockquote>
<p>
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
two sets of data, and can verify the signatures.
</p>
<h2><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"cla=
sh">The Signed Receipt as a Bookkeeping system</a></h2>
<p>
The principle of the Receipt as the Transaction
has become sacrosact 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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"sr1=
">As Single Entry</a></h3>
<p>
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.
</p>
<p>
The principles of Relational Databases
provide guidance here.
The <i>fourth normal form</i>
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
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_4NF" n=
ame=3D"back_4NF">4NF</a>]</small>.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"sr2=
">Recovering Double Entry</a></h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"sr3=
">Triple Entry Accounting</a></h3>
<p>
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 cryptographic
invention of the digital signature gives powerful
evidentiary force to the receipt, and in practice
reduces the accounting problem to one of the
receipt's presence or its absence. This problem
is solved by sharing the records - each of the
agents has a good copy.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
We term this <i>triple entry bookkeeping</i>.
Although the digitally signed receipt dominates
in information
terms, in processing terms it falls short. Double
entry book keeping 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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"con=
c">Software Considerations</a></h3>
<p>
The precise layout of the entries in software
and data terms is not settled,
and may ultimately become one of
those ephemeral <i>implementation issues</i>.
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.
</p>
<p>
Auditing issues arise where construction
of the books derives from the receipts,
and normalisation issues arise when a
receipt is lost. These are issues for
future research.
</p>
<p>
Likewise, it is worth stating that
the technique of signing receipts works
both with private key signatures and also
with entanglement message digest signatures;
whether the security aspects of these
techniques is adequate to task is dependent
on the business environment.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"rol=
es">Roles of the Agents</a></h3>
<p>
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.
</p>
<p>
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 <i>internal
money</i>, then experience shows that
benefits accrue to the organisation.
</p>
<p>
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 <i>market maker</i>, exchanging
payments in internal money for payments in
external money to outside suppliers.
</p>
<p>
We have operated this system on a small scale.
Rather than be inefficient on such a small
scale, the system has generated dramatic
savings in coordination. 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, formal and informal agents work
to <i>exchange</i> 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.
</p>
<p>
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 relevence back to the corporate world.
</p>
<h2><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"poc=
"> Patterns of Commerce </a> </h2>
<p>
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
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_1" nam=
e=3D"back_1">1</a>]</small>.
His starting premises were that:
</p>
<ol><li><p>
The major need is not accounting or payments, per se,
but patterns of exchange - complex patterns of trade;
</p></li><li><p>
Small businesses could not afford large complex
systems that understood these patterns;
</p></li><li><p>
They would not lock themselves into proprietary
frameworks;
</p></li></ol>
<p>
From those foundations, Boyle concluded that
therefore what is needed is a shared access repository
that provides arms-length access. Fundamentally, 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.
</p>
<p>
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 repository service's GLT.
</p>
<p>
The Shared Transaction Repository ("STR") 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.
</p>
<p>
Boyle's ideas are logically comparable to Grigg and Howland's,
although they arive 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.
</p>
<h3> <a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"po=
c_inv"> Extending the Humble Invoice </a> </h3>
<p>
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.
</p>
<p>
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.
</p>
<h3> <a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"po=
c_tx"> Patterns of Transactions </a> </h3>
<p>
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
<i>the Receipt <u>is</u> the Transaction</i>
could be extended into
<i>The Invoice <u>is</u> the Transaction</i>.
</p>
<p>
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 PO message,
the customer then waits for fulfillment.
</p>
<p>
There is a large body of science and literature
built around these <i>patterns of transactions</i>.
These have been adopted by the Business Process
workgroup of ebXML 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. It is to that we now turn.
</p>
<h2> <a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"po=
c_req"> The Requirements of Triple Entry Accounting </a> </h2>
<p>
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.
</p>
<p>
Below are the list of requirements that we
believed to be important
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_2" nam=
e=3D"back_2">2</a>]</small>
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_3" nam=
e=3D"back_3">3</a>]</small>.
</p>
<p>
<b>1. Strong Psuedonymity, At Least</b>.
As there are many cycles in the patterns, the
system must support a clear relationship of
participants. At the minimum this requires
a nymous architecture of the nature of Ricardo
or AADS. (This requirement is very clear,
but space prevents any discussion of it.)
</p>
<p>
<b>2. Entry Signing</b>.
In order to neutralise the threats to and by the
parties, a mechanism that freezes and confirms
the basic data is needed.
This is signing, and we require that all entries
are capable of carrying digital signatures
(see 1, above, which suggests public key signatures).
</p>
<p>
<b>3. Message Passing</b>.
The system is fundamentally one of message passing,
in contrast to much of the net's connection based
architecture.
Boyle recognised early on that a critical
component was the generic message passing nature,
and Systemics proposed and built this
into Ricardo over the period 2001-2004
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_4" name=
=3D"back_4">4</a>]</small>.
</p>
<p>
<b>4. Entry Enlargement and Migration</b>.
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.
</p>
<p>
<b>5. Local Entry Storage and Reports</b>.
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 instrinsic reconciliation
on a demand or live basis.
</p>
<p>
<b>6. Integrated Hard Payments</b>.
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.
</p>
<p>
<b>7 Integrated Application-Level Messaging</b>.
As distinct to the messaging at the lower protocol
levels (1 above), there is a requirement for Alice and Bob
to be able to communicate. That is because the
vast majority of the patterns turns around the
basic communications of the agents. There is no
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
payments.
</p>
<h2><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"con=
c">Conclusion</a></h2>
<p>
Double Entry bookkeeping provides evidence of
intent and origin, leading to strategies for
dealing with errors of accident and fraud.
The financial cryptography invention of the
signed receipt provides the same benefits,
and thus challenges the 800 year reign of
double entry.
Indeed, in evidentiary terms, the signed receipt
is more powerful than double entry records due to
the technical qualities of its signature.
</p>
<p>
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
<i>the entry <u>is</u> the transaction</i>.
This results in three
active agents who are charged with securing
the signed entry as their most important
record of transaction.
</p>
<p>
Secondly, the software ramifications of the
triple entry system that are less convenient than that
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.
</p>
<p>
Both of these imperitives 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 <i>triple entry bookkeeping</i>
is useful to describe the advance on the older form.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"con=
c_ag">Drawing in the Agents</a></h3>
<p>
To fully benefit from triple entry bookkeeping,
we have to expand accounting systems out to
agents and offer them direct capabilities to
do transactions.
That is, we make the agents stakeholders by
giving them internal money
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_5" name=
=3D"back_5">5</a>]</small>.
Use of digital cash to do company accounts
empowers the use of this concept 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.
</p>
<h3><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"con=
c_fraud">Solving Frauds</a></h3>
<p>
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: the mutual funds scandal
would have shown a clear audit trail of transactions
and thus late timing and otherwise perverted or
dropped transactions would have been clearly
identified or eliminated completely
<small>[<a href=3D"https://iang.org/papers/triple_entry.html#ref_NG" na=
me=3D"back_NG">NG</a>]</small>.
The emerging scandal in the USA known as
<i>Stockgate</i> would have been impossible
as forgery of shares and value for manipulative
trading purposes is revealed by signed receipts.
Likewise, Barings would still be a force in
investment banking if accounts had been
organised around easily transparent digital cash
with open and irreducible signed receipts that
evidence invisible accounts (<i>88888</i>).
Enron style scandals would have permitted more
direct "follow the money" governance lifting
the veil on various innovative but economically
meaningless swaps.
</p>
<h2><a href=3D"https://iang.org/papers/triple_entry.html#index" name=3D"ref=
"> References </a></h2>
<font size=3D"-1">
<p>
<b><a name=3D"ref_TB">[TB]</a></b>
A draft form of this paper credited Todd Boyle
as an author, but this was later withdrawn at
his request due to wider differences between
the views.
</p>
<p>
<b><a name=3D"ref_LP">[LP]</a></b>
Friar Luca Pacioli,
<cite><a href=3D"http://www.acsac.org/2001/papers/110.pdf">
Summa de Arithmetica, Geometria,
Proportioni et Proportionalita
</a></cite>
1494, Venice.
</p>
<p>
<b><a name=3D"ref_IG1">[IG1]</a></b>
Ian Grigg
"<a href=3D"http://www.financialcryptography.com/mt/archives/000442.html">
The Twilight Zone
</a>,"
<cite>Financial Cryptography blog</cite>
16th April 2005
</p>
<p>
<b><a name=3D"ref_MB">[MB]</a></b>
Entanglement is discussed in:
Petros Maniatis and Mary Baker,
"Secure History Preservation through Timeline Entanglement,"
Proc. <cite>11th USENIX Security Symposium</cite>,
August 2002.
</p>
<p>
<b><a name=3D"ref_DC">[DC]</a></b>
David Chaum,
"Achieving Electronic Privacy,"
<cite>Scientific American</cite>,
v. 267, n. 2 Aug 1992.
</p>
<p>
<b><a name=3D"ref_RAH">[RAH]</a></b>
Robert A. Hettinga
"<a href=3D"http://www.shipwright.com/rants/rant_02.html">
The Book-Entry/Certificate Distinction
</a>"
1995, Cypherpunks
</p>
<p>
<b><a name=3D"ref_GH">[GH]</a></b>
Gary Howland
"<a href=3D"http://www.systemics.com/docs/sox/overview.html">
Development of an Open and Flexible Payment System
</a>
1996, Amsterdam, NL.
</p>
<p>
<b><a name=3D"ref_IG2">[IG2]</a></b>
Ian Grigg
"<a href=3D"http://iang.org/papers/ricardian_contract.html">
The Ricardian Contract
</a>,"
<cite>First IEEE International
Workshop on Electronic Contracting</cite>
(WEC) 6th July 2004
</p>
<p>
<b><a name=3D"ref_4NF">[4NF]</a></b>
E.F. Codd,
"<a href=3D"https://iang.org/papers/triple_entry.html">
A Relational Model of Data for Large Shared Data Banks
</a>,"
<cite>Comm. ACM</cite> 13 (6), June 1970, pp. 377-387.
</p>
<p>
<b><a name=3D"ref_1">[1]</a></b>
Todd Boyle,
"<a href=3D"http://ledgerism.net/GLT-GLR.htm">
GLT and GLR: conceptual architecture for general ledgers</a>,"
Ledgerism.net, 1997-2005.
</p>
<p>
<b><a name=3D"ref_2">[2]</a></b>
Todd Boyle,
"<a href=3D"http://www.ledgerism.net/STR.htm">
STR software specification</a>,"
Goals, 1-5.
This section adopts that numbering convention.
</p>
<p>
<b><a name=3D"ref_3">[3]</a></b>
Ian Grigg,
various design and requirements documents,
Systemics, unpublished.
</p>
<p>
<b><a name=3D"ref_4">[4]</a></b>
A substantial part of the programming and design was conducted
by Edwin Woudt (first demo, SOX layers, UI)
and Jeroen van Gelderen
(message passing client architecture).
</p>
<p>
<b><a name=3D"ref_5">[5]</a></b>
Using internal money instead of an accounting system
is not a new idea but has only been recently experienced:
Ian Grigg,
<a href=3D"http://iang.org/rants/systemics_psd.html">
How we raised capital at 0%, saved our
creditors from an accounting nightmare, gave our suppliers
a discount and got to bed before midnight.</a>
Informal essay (rant), 7 Jul 2003.
</p>
<p>
<b><a name=3D"ref_NG">[NG]</a></b>
James Nesfield and Ian Grigg
"<a href=3D"http://iang.org/papers/mutual_funds.html">
Mutual Funds and Financial Flaws
</a>,"
<cite>U.S. Senate Finance Subcommittee</cite>
27th January, 2004
</p>
</font>
</body></html>
------MultipartBoundary--ZJLbQ4mRwLhAHsHENVppcDUXKvpxlvNoq0H6MRFUAo------
Reference in New Issue Copy Permalink