Accountability

I repeat that all power is a trust; that we are accountable for its exercise;
that from the people and for the people all springs, and all must exist.

--Benjamin Disraeli

Although the butt of infamous jokes as boring, accounting is important
and interesting due to its relationship to accountability. Better
accounting can make for better accountability.

In this article we suggest ways to make accounting better by applying
the principles that have informed the free and open-source software
movements to both the technology and business of accounting.
Our goal is to stimulate thought on new interfaces and business
models, that, if tried, may provide more convenient and more
trustworthy accounting. We hope individuals will receive the benefit of
cheaper, more convenient, and more reliable bookkeeping. We hope charities,
governments,
and large businesses will receive the benefit or cheaper, safer bookkeeping
that will allow them to be better trusted by doing more of their business
in the light of public scrutiny and private auditing without additional costs.

We are argue that accounts, as individual parts of bookkeeping
systems, should be treated as first-class citizens of the modern
internetworked world, on par with email addresses, domain names,
hosts, and ip addresses. There should be open standards for
bookkeeping systems that allow the work of keeping books to be shared
across the internet. Even more importantly, there should be standards
and business models that allow the responsibility of bookkeeping to be
shared across many different parties, each with independent purposes,
which we argue will produce more reliable and transparent bookkeeping.
We furthermore humbly submit to the reader that the current point in
time and technological development is a fulcrum about which a
relatively small amount of work in terms of defining open standards,
writing open software, and developing business models, may initiate a
sea-change in accounting practices.

Introduction to Accounting for Computer Programmers

Although the profession of Accountancy involves a lot more,
at a basic level accounting boils down to keeping track of things so
that you can make good decisions. In this section we present
an high-altitude overview of accounting from a computer programmer's perspective.

An account is a record of a collection of
like objects. Often these objects are units of money, but they could
also be shares in a corporation, experience points in a game, or hours
of community service. An account has a balance
at any point in time that is a single numeric quantity. This quanity
can always be perfectly computed in that you know the history of the
transactions against the account. One book
defines an account to be “specific accounting record that
provides an efficient way of categorizing transactions.” We
like this definitions because it makes it very clear that the account
and its balance are a function of transactions.

Computer programmers may be familiar with the concept of a
database transaction. The database transaction
is more general than the accounting transaction, but the accounting
transaction came first. Both kinds are atomic, meaning that they
either succeed or they don't, and both kinds are durable, meaning that
there is a permanent record of them. In database jargon the permanent
record is implemented with a log; in accounting jargon the permanent
record is a valuable and primitive concept by itself: the
General Ledger. In accounting, the general
ledger (or GL) is a basic object from which accounts and balances are
implemented. In database management systems the log is an
implementation tool, not a primitive and essential concept. (Of
course, general ledger systems are normally implemented on top of a
relational database system, which can be confusing.)

By the 15th century, Italian merchants were using
double-entry bookkeeping. In this method, every
transaction is enterred into the general ledger system as a change in
quantity in two accounts. This brilliant development greatly reduces
the chance for error in the same way that a checksum does in modern
computer programming. Although still useful in terms of reducing
error, it also promotes clear thinking in accounting by implementing a
sort of conservation law for whatever is accounted. Accounts can't
just go up or down by themselves; the accounted objects come from
or go to somewhere and special accounts are used to represent these
incomes or expenses.

A fundamental accounting practice is that a transaction once enterred
never disappers. Its affect may be cancelled by a transaction that
effectively undoes it; but even if that happens the books display this.
If we record who created the transaction and why, this practice greatly
helps to keep our books clean and clear. This removes confusion for ourselves
if we revisit our books later,
and increases trust and understanding to any outside party.

Thus we see that the transaction in the general ledger is the
fundamental building block of an accounting system, and it is quite
independent of account balances. The balance of an account is the sum
of all the changes that have made against it by transactions. When we
balance a checkbook, we are computing a
balance on an account. Usually we do this for two purposes: to see
how much money we have in our account, and to make sure the bank's
opinion of this matter matches our own. Although not everyone
balances their own accounts, the principle is clear: if we agree on
the transactions, we ought to be able to agree on the balance quite
clearly. The party that keeps the general ledger may or may not be
the party that computes the balances. Some people duplicate what the
bank does on their checking account: They keep their own general
ledger (recording all deposits and checks written), and they keep
their own balances, and if their is a diagreement they resolve that
with the other party keeping this information, which is the bank.
Bank errors are rare, person errors are common (for the authors,
anyway) but having the bank and the personal records synchronized
gives great confidence. This is a primitive form of
auditing.

A checking acocunt is a special and useful kind of account, because it
allows you to make decisions such as “will this check
bounce?” However, another useful kind of account is the
expense account and its mirror the
income account. The accounts are a way of
tracking ones expenses by categorizing them into groups such as money
spent on entertainment, as opposed to money spent on office supplies
or rent. In popular personal accounting software packages such as
Quicken[1] or GNUCash[2], the fact that these categories are really accounts
may be hidden and called “categories”, but for small
business systems, such as QuickBooks, they are explicitly treated as
accounts.

Although maintaining a general ledger is the bedrock of acocunting,
there are other services that are built on this bedrock. Computing
the balance of an account is one such service. Computing the balance
of all accounts at a point in time lets one compute a balance sheet. Balance sheets are valuable summaries of
the information contained in the general ledger. There are many other
reports that are similarly valuable. For example, if your expense
accounts are organized in a way that is meaningful, you can obtain
a report that shows how much money you spend on things you consider
luxuries as opposed to things you consider necessities. This might
allow you to make a decision about changing your spending. The set of
accounts that you keep is sometimes called the chart of accounts
and there is value in organizing and customizing these accounts conveniently.

Reporting is fundamental to the usefulness of accounting for several reasons,
and on several scales. To a small household or a small business owner, it lets
a small group of trusted people, or even just one person, have visibility in
to something too complex to understand without reports. For example, it
allows one to answer the question, “Did my family save money this year?”
Of course, one should probably feel blessed if this is a difficult question to
answer---for some families the finances will be so simple that the answer will
be painfully or pleasantly obvious. But certainly for most small business, it
requires some work to answer this question.

Although not always required for families, the tax laws in the USA,
and presumably elsewhere, are so complex as to require good
bookkeeping to compute the taxes that one owes the government, or lack
thereof. Furthermore, under US law, one is required to keep books that
are good enough to resolve tax issues in an audit, under threat of
penalty. This is a point worth emphasizing: the taxing authority in
the US does not demand to see your books every year, but demands that
they be good enough to support an audit if they so demand. Thus one
could argue that your own personal accounts, and certainly the
accounts of any small business in the US, are “public” in
the sense that you do not have the right to keep them secret, although
they generally will not be examined and certainly will not be examined
by the general populous in most situations. Thus few, if any,
accounts are truly private.
This suggests that there should be a global namespace for accounts.

Moreover, accounting is basic to investing in the modern sense. A
person may invest in a fruit tree without accounting, but it is hard
to imagine other forms of investment working well in the modern world
without accounting. Certainly the valuation of a firm depends on
accounting, as does the managment of that firm. Of course, one need
not personally understand accounting to purchase stock in a publicly
owned firm---it is enough to know that someone you trust understands
that accounting and believes it demonstrates a value for the firm
similar to what you intend to pay for the stock. There are certainly
examples of spectacular failures of accounting. A modern computer
programmer should understands from a design point of view what
economists and moralist also understand: the auditor of an accounting
system must not have a conflict of interest that would pressure them
to color the truth. A programmer can not test that a function
produces a correct result by calling it twice and seeing that it
returns the same thing in each case.

Charitable giving is a form of investment in a better world or
personal salvation in which one does not expect a return from your
investment in money. However, one does demand accountability. Most
people want to know not only that a charity is not corrupt, but also
that it is reasonably efficient. Just as computer programmers fully
understand that security by obscurity is foolish and reliable
systems can only be built on open-source software, we believe that
only openess can provide proof of trustworthiness in a charity.
Openess of accounting may even be a legal requirement, now that some
charities are legally attacked on the basis of sponsoring terrorism.
Less extremely, a charity may not wish it to be widely known that it
purchases support from some celebrity. We think it would certainly be
a good thing if there were a competetive atmosphere amoung charities
in which they compete for donations on the basis of the
trustworthiness, and sell their trustworthiness on the basis of
trasparent accounting. Charities, however, do not derive their right
to exist or their purpose from a citizenry, so whether they choose to
be open or secret in such matters is there own business. It would be
an advance, however, if they had technology and services available to
them to be open inexpensively.

Setting aside matters of national security, which is the only
objection one is likely to hear to this assertion, governments are the
ultimate example of entities that should have transparent accounting.
We think there is nearly universal consensus that governments should
be publicly accountable for their actions, and their spending in
particular. Transparent accounting is to government what quality
assurance and testing are to software. It does not actually assure
inerrant behavior or efficiency; but it helps. We think it would be a
good thing if transparent accounting were conveniently supported by
both technology and businesses employing technology, so that
governments would have few excuses for not utilizing transparent,
completely public accounting for almost all of their activity

A Programmer's Data Analysis of Bookkeeping

We assume the the reader has a passing familiarity with the pinciples of
accounting-those taught in an introductory textbook or by doing your own
books for a small business or household.
Let us review that a modern bookkeeping system has the folling properties
that are different than other data types a programmer may be used to:

they are append only,

they have a universallly accepted double entry convention,

they ought to be access controlled in all cases,

they are always shared in one way or another, and

they require a naming convention.

A Perfectly Transparent Accounting System

In this section we perform the thought-experiment of imagining
the perfect accounting system. This means imagining
technological systems, such as networks and user interfaces,
as well as cultural systems, such as the existence of business
to provide services we want that do not yet exist. In the next
section we will explore the possibilities of reifying such technological
systems and cultural systems.

We would like our accounting system to be
inexpensive, reliable, secure, and easy-to-use. Let us
consider how these qualities apply to an accounting system.

Inexpensive. We would like our accounting system to be
so inexpensive that it cost us a lot less than the value
of the time we will spend interacting with a perfect system.
Gratis would be good; but that what really matters, both
to individuals, charties, corporations, and governments,
is that the cost should be low compared to unavoidable cost
of managing our accounts, given a perfectly usable system.

Reliable. We want our system to be durable and available.
We want it to never lose data, and to not miscompute things.
We want our abilities to create transactions to never be
impeded. We want to be able to get accurate reports in
a timely manner.

Secure. The most important thing is that our system
be indelible. We want the difficulty of making the
record of a transaction disapper to require an international
conspiracy of many human beings cooperating in a complicated
way. Secondly, we want transaction in our system to only be made
under authorized circumstances by authorized persons. We want it
to be impossible to gain illegal access by an internet based
attack (we'll accept breaking mature open-source cryptography
systems as the definition of impossible.)
We want damage possible due to subverting an employee
or stealing there authorization knowledge to be small.
We will accept some inconvenience in this matter, such as occasionally
delaying an employee making an authorized transaction
because it unusual in nature. We want unauthorized reading of the ledger and
balances to be difficult as well, although this is less important.
We want changes in security to be secure. For example, we want the
ability to give an auditor read access to our ledger on a strictly
temporary basis.

Usable. We want our frustration getting the system to
organize our accounts the way we want them to be low compared
to the trouble of figuring this out conceptually. We want
both customized and standardized reports to be easy to produce
quickly. We want to be able to submit transactions by hand very
easily; if we are a large organization, we want our programmers
to be able to submit transactions very easily.

Fundamental Services

What business models can support and are supported by tranparent
accounting? One business might attempt to provide all the
functionality that transparent accounting provides. However, it seems
that the nature of the trust relationships that tranparent accounting
demands at a social level argue in favor of business models where
functionality is spread, at least potentially, across independent
entities. For example, clearly the firm that maintains the general
ledger should not also perform auditing. To obtain reliability, the
use of several independent, or indeed blind, general ledger systems is
in order. Since there probably should only be one user interface
provider used for one accounting system at one time, clearly the firms
that provide GL systems are separable from the firms that provide user
interface services.

In our view, there ought to be five distinct business models in play to
provide transparent accounting. Of course, the number of firms providing
these five basic services might overlap in a complex way at any given point in
time, so that a give customer might employ more or fewer firms. The five
basic services are:

General Ledger (GL) systems

User Interface and Balance (UIB) systems

Auditor (AUD) systems

General Ledger Aggregator (AGG) systems

Access Management (ACM) systems

Traparent Accounting Consultancy (TAC) systems.

Each of these must be considered in turn, but let us
first imagine how they will be used.

Figure 1. Relationships

Relationships

In figure Relationships, we have tried to show the relationships
between these services that help the customer manage their basic
relationship with the their own data, which is stored in the General
Ledgers (GL) systems. An arrowhead represents significant information flow
in the direction of the arrow.
Firstly, the customer uses a consultant (TAC), in the
form of an (inexpensive) book or (expensive) firm to choose a cocktail
of GL systems that are believed to be independent, reliable and fast.
A cloud of GL systems are independently engaged and begin recording
transactions against the customer's books.

But the GL systems, even if independent, should not be trusted. So
the customer employs an independent auditor (AUD). The job of the auditor
is straigtfoward---to report any discrepancy between the GL systems
soon enough that the cause of the discrepancy can be easily determined.
In addition to measuring consistency, the auditor measures speed.
The auditor gives confidence to the customer. The value the auditor provides
is based on the perception of their independence and efficiency.

The customers needs a good mechanism for examining their books.
At the time of this writing, that means good software that presents
a good user interface and computes balances (UIB). The UIB provides
value to the customer based on the quality of the user interface it provides.

Finally, an aggregator of GL services (AGG) is used at transaction
entry time. It provides the basic services of being a single point of
communication to the GL systems and makes some determination of
sufficiency to mark the transaction as committed, such as enough of
the GL services reporting the transaction committed that the aggregator
is willing to complete the committing of the transaction.

A set of tests should be available to keep everybody honest. For
example, an aggregator might be tempted to make themselves look fast
and reliable by guessing transactions that are likely to succeed and
reporting them committed before, in fact, the GL systems have reported
the commit. The auditor (AUD) and/or the consultant (TAC) should
provide pressure against this by asking the GLs to intentionally
introduce transitory failure. Similarly, the UIB will no doubt use a
variety of caching strategies. However, it is not appropriate for a
UIB to implement its own GL for this purpose. The UIB should be fast
and reliable but should mind its own business, and that is not the business
of the GLs. Likewise, an auditor might be tempted to employ its own GL---after all, by so doing it has yet another check on the GLs employed by the customer.
We do not pretend to know yet as set of tests or policies that can completely
prevent this kind of thing, but suspect it can be minimized. Certainly,
the separation of functionality into independent services allows each to
be tested in ways that they could not be if they formed a single point
of failure for an accounting system. For instance, it would be uncomfortable
to feed disinformation to your own accounting staff to be sure they track
it correctly, but that could be a common practice if a large number of
GLs were maintained to insure test their independence.

Access Control

This idea of testing independence leads us inexorably to notions of privacy
and access control. We hope to make accounting more public and less private.
However, privacy and access control will play an important role in any
accounting system.

It is interesting to imagine systems where such is not required; but
for most organizations, the creation of transactions must be strictly
authorized and authenticated. We cannot imagine the business models and services that these services may produce.

How is access control handled now? In many cases, poorly. For
example, many families and small organizations keep their finances
on a machine which is physically secured, but not effectively secured in
other ways. For examples, how many children, of whatever age, are
capable of examining their parents bookkeeping by virtue of being inside
the physical barrier that is the only security? Likewise, the disaster
recovery of such systems is minimal, although that may be a mixed blessing.
Another problem common to small organization is the transience of
authorized figures relative to the permanence of the bookkeeping system.
For small organizations, this causes confusion---such as when
someone dies.

For large companies, the controls are probably better but what is at risk
is much greater.

Business Models

We will now conjecture about the business models we have proposed
around the five fundamental services: consulting, ledgering, auditing,
balancing, and aggregating.

At first glance consulting appears the most straightforward. This
is a professional consulting service, similar to those that we are
familiar with already, such as tax preparation, bookkeeping, and financial
advising. Providers of these services range from large firms that
charge a lot and presumably do a lot, or at least pay a lot of people
to do it, to free pamphlets. At one level, transparent accounting
should be the same. But the notion of automated verification of
services creates a more interesting and solid thing for consultants
to do: to actively manage the mix of services
that a customer employs. Valuable service can be provided by measuring
not the reputation, but the current quality
of auditor, for example, by auditing the auditor.

The General Ledger systems are straightforward in terms of business
function. The also seem straightforward in terms of pricing. Until a
liquid market is established, cost plus markup makes sense as a pricing
model. Note that some large firms will have a built in advantage in
this market; but the market as a whole will resist monopolies, as any
given customer will explicitly seek geographic and cultural diversity
in its General Ledger systems. This service is very regular across
time, and a per-unit time fee seems to match it well.

The aggregaters and UI/Balancers are the services which is most
closely similar to traditional software. These services might be
provided by a software system that had no time-based service
component. For example, a perpetual-use license might be purchased
for a one-time lump-sum. This makes sense only if the interfaces for
the whole system are so well-defined and standardized that a customer
does not assume too much risk in this purchase, as this purchase tends
to guarantee poor service after the sale. A more traditional approach
might be the model of "pay more than you would normally because you
know I'm going to be around and I'll sell you an upgrade in a while" model.
In any case, there will be free and open-source software competing in
this market, and that will tend to decrease prices. However, a good
user interface is relatively easy to sell---this would be a market
in which products could be highly differentiated.

Our hope is that auditors, providing the most basic service of
checking the consistency of GL systems, won't make much money. The
purpose of transparent accounting is to be transparent. It should be
easy to see where the money/karma points go. But, of course, the
word "audit" today implies much more than that. For example, a charity
that purports to provide humanitarian aid to a corrupt region of the
world ought to have transparent accounting at the electronic level.
It ought also to be accountable at the belly level. An audit firm
might audit that a purchase of food actually worked by finding the
people who were actually fed by it. This would be a powerful random
sampling. Strong auditing of this kind would allow audit firms to
differentiate themselves.

Interfaces

Good interfaces to services create interoperability and compatibility;
compatibility allows competition; competition creates liquidity;
liquidity creates markets; markets create convenience. Transparent
accounting will provide the greatest good to the greatest number
when there are strong, liquid markets of service providers and
consumers. Therefore we should create good
interfaces.

Bookkeeping systems and accounts should have public naming systems.
We propose a new schema “accts”. This schema would be
followed by a tree-constructed name of a bookkeeping system similar
to the domain name convention. Although there is no need to ever map
the name of a bookkeeping system to a IP address, and indeed one never
should, it will be useful to follow this convention.

Although there is no need for a centralized nameing authority, some
bookkeepers may wish to submit to a central authority to avoid
name collision on the possibility that they may someday wish to
unambiguously refer to the two similarly named accounts.

So a particular bookkeeping system might be called
“accts://robandmike.net”. Within a given namespace,
perhaps that governed by domains of the same name, this would be an
unambiguous prefix for accounts that we might keep. We might have an
account like:

might be a valid syntax for transfering 400 similar object from and
account called “royalties” to an account called
“checking”. This request could of course be mapped to an http
request, if one were so crass as to suggest an implementation of
such an abstract notion.

Any system of accounts has a fixed and consistent set of accounts that
have existence that is carefully delineated in time. So it any point
in time it might by possible to name a request like
“accts://robandmike.net?chartofaccounts” and expect
this request to be responded to with a list of all of the accounts
that exist within the system at that time. Further refinements would
be to include a different time than right now in the request.
We therefore will need a format for such requests, and a format
for the answers.

If we imagine XML as the format in which we will define our formats,
we can list a number of schema that we will have to define:

The naming of bookkeeping namespaces

The naming of accounts within bookkeeping spaces

The requests that we imagine a General Ledger service
to support

The requests that we expect a balance computation system to support

The requests that we expect an aggregation system to support,
including the registration and deletion of GL systems and their
URLs

The requests that we expect an audit system to support, that
at least express our desires in terms of an audit policy.

The ability to describes sets of GL systems, that will be
utilized by other formats

A format for describing transactions that takes into account
authentication and authorization.

Entrepreneurship for these Models based on the Interfaces

The question of actually building business that make money around
these business models and interfaces is of course both much harder and more
interesting than the hypothetical models themselves. We hope the reader
agrees that our speculation has some value, even as he or she
sprinkles salt on it.

We think the easiest way to make money from these ideas would be
for the firms or organizations that have very large resources and
credibility to undertake all of these models in such a way that they
insure competition. For example, the GNU project and IBM are two very
different organizations that are capable of this and obviously would
approach it from different directions. IBM might immediately implement
the services as functional business and openly publish interfaces in such
a way that competition was invited. GNU might publish interfaces and
encourages other parties, such as IBM, to implement the service-level business
using free software.

It seems to us that powerful organizations might very well wish to
outsource their accounting under these mechanisms, but would also have
the ability to essentially implement private versions of the services.
For example, a large business or government might employ a for-profit
GL system and an outside Auditor while still implementing its own
Auditor and GL system that would serve as redundancy until other
players were reliably implementing these business models.
Gradually, as the outside systems prove themselves and develop redundancy,
the customer might transfer its trust from its own people to those who
are outsiders.

An important similar intermediate step would be for customers to
outsource their accounting, but to do so not on the public internet
but on their own private networks. Thus they would pay a GL services
to deploy equipment on their own premises so that physical security could
be relied upon until they have faith in software security provided outside.

Once the GL system was standardized, there would be a motivation for
world-wide implementaiton of GL systems, since world-wide distribution
would decrease risk. Since GL system would be easy to run, we foresee
many competitors in this market.

A different approach would be for a GL vendor to serve the low-end market,
such as small charities and businesses. This approach would be based on
greater security than physical security can provide in such settings, and
on the potential cost savings over in-house implementation. The existence
of trustworthy auditing services would propel this approach. There is
no reason in principle why a free-software solution might not provide this
trust. For example, if any person could run software that performed an
audit whenever they liked, and this software was open-source and had the
opinion of a large body of open-source developers behind it, then it
might not be necessary for anyone to have undertaken providing this services
independently.

The User Interface/Balancer service would be different, in that here
we would see free solutions servicing the low-end market and luxury
non-free versions servicing the high-end market. Just as exists
today, these approaches would overlap with market dominance a
psychological difference that would allow these systems to compete in
an interesting way.

The Transparent Accounting Consultant would be at the heart of this mass
of software, as humans always are. Just as evangelism has affected other
markets, so too enthusiasm and knowledge that is not yet widely disseminated
would be key to the success of the whole enterprise. The Consultants may
hope for profit in some cases and satisfaction in others.

It seems to us that individual entrepreneurs might hope to make
successful businesses of any of these services. This would of course
entail tremendous risk, but the rewards would be substantial; everyone
modern system needs accounting. Since the earliest forms of writing evolved
for the same purpose, apparently, this statement could be even broader.

Questions and Exercises

We wonder: would a charity be willing to say to its patrons,
“Yes, it grieves us to pay 10% of our incoming gifts to our auditing
firm, but we think you are wiser to allow us to distribute your gift
than some less-well-audited charity?”

Is it possible to build a cryptographically strong GL system
against which it is possible to implement efficient UI/Balance and
Aggregation services but which would be completely private in other
respects?

Is it possible to intentionally send erroneous data to a GL system
and escrow these errors into a separate system, so that no GL system could
cheat by reading data from a different GL system?

How would one construct a private bookkeeping system that had a
public face? For example, the modern public-traded corporation keeps
its day-to-day dealing private but must publish summaries according to
generally accepted practices. Could one construct an efficient system
for this that would be completely auditable, if, for example, the SEC
chose to investigate such a firm?

How much money would IBM make if they defined interfaces as
open standards, implemented those standards with services backed by
their reputation, and invited competition to ignite a sea-change to
transparent accounting?

For whom, if anyone, would the ideas in the paper, if brought to
fruition, provide an Inexpensive, Secure, Reliable and Usable
accounting system as defined above?

How difficult would it be to create a set of useful reference
implementations for this entire system?