Transparent Accounting

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.

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

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:

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.

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:

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.

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.

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.

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:

A piece of syntax 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 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.

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?