Chapter 9: The Ivory Tower

We have reviewed what I learned in school about the basics of computers and bookkeeping and financial reporting. We have explored whether an alternative to the standard general ledger and journal entries could provide the financial statements. We reflected on what else might be considered the book of record besides the general ledger. We considered using just the journal entries which meant we didn’t have to store balances because the computer can add them up quite efficiently. This system could generate the financial statements at any point in time. We no longer have to close the books in order to have the Income Statement.

We then considered a different set of “journal entries” as the book of record, something close to single sided accounting. This reduced the number of rows we had to record to get to the same answer. But both of these approaches are still pretty focused on the accounting process; the information we captured wasn’t expanded to other attributes very easily.

We then analyzed the system in terms of all information needs, not just the accounting needs. This last approach, in a certain sense, placed the accounting function for automobile related transactions right in the middle of a car maintenance system. We could, therefore, from the same data, produce not only car maintenance reports, like cost per mile driven, but also the data needed for financial reports as well. We could do this without having duplicated the data in a car maintenance system and a separate financial system, or having tried to put that data back together to show the reports after it had been captured and stored separately.

We’ve shown that the financial information in our personal financial system can be stored in different forms, and yet produce the basic financial information needed. Neither of the last two systems have much resemblance to Pacioli’s system, or something that would immediately qualify for most accountants as the book of record. But all the information needed is there.

However, moving from the ivory towers of academia to the real world teaches there are a lot of reasons why things have developed the way they have; and changing all that is not easy or inexpensive.

As noted, one reason is that accounting is tradition bound. The other though, is that although computers are much more efficient at math than humans, they still have limited capacities: The space on the white board is limited, the speed of the data transfer from disk is slow, and the verboseness of the language or meeting procedures dictates processing speed.

The pure unadulterated academic theory could require massive amounts of storage and processing power, and experience shows is impractical to implement at scale. This is because the volume of data needed to recreate the ledger if no summarization process were performed at all is very large.

This need to balance computing and storage costs with the broader use of data was recognized by McCarthy in his original 1982 paper: “To this point in the paper, events accounting has been viewed in terms of maximum temporal generality with all transaction data being maintained indefinitely. During design of an actual system, quite obviously, consideration of both decision usefulness and storage costs would temper these requirements somewhat and identify places where temporal summation of event data might be appropriate. An important point to remember about REA accounting model in this respect is that modifications to the ideal (complete events system) are made knowingly and only after an exhaustive cost-benefit analysis of all (not just accounting) data usage has indicated that the adjustments make economic sense. Imperfections are the result of deliberate choice. Such a process is in sharp contrast where traditional summations are routinely directed by reporting cycles. In REA terms, closing summations are usually derived data or viewed data, and they should be treated as such.”¹

Both accounting tradition and computer scalability have resulted in few practical implementations of the theory over the years.²

I remember meeting with Eric in his office after the last class I took from him. Eric asked me how I had felt about the final exam. I don’t remember doing poorly on it, but not acing it either. I sensed he wanted to understand what I had learned from the class, and how to improve his explanation of the topics; I don’t think I provided much insight. Yet I do remember feeling as if the material all made sense to me, but I just wasn’t sure why it all mattered. If what he explained was possible, what was all the fuss about? We should just do it. With more practical experience, I would come to understand why it wasn’t that easy.

I also remember another time in Eric’s class. It seems he had returned from a consulting trip and had learned more about how the theory was being advanced on a project. I vaguely remember him handing out a picture that looked something like the following, and saying the technology feasibility of the approach was much more possible than he had previously thought.

Figure 27. Event Repository Architecture

To take my understanding further, I needed to study with the person who had drawn that picture.