Subject: Re: Company centric view ends. Data goes to the Net.
Date: 07/14/2000
Author: William McCarthy <>


TO:  Accounting list members
FROM:  Bill McCarthy, Michigan State
I apologize for being late to following up on this thread.  However, college professors are an odd lot, so my tardiness is
When Todd Boyle posted the original message on REA accounting, I composed the reply shown below.  It just took me a while to get it done.  Todd invited me to post it on the list, so here it is.
Many practicing accountants will realize that Full-REA systems are just starting to be developed by people like Bob Haugen, although Price-Waterhouse does have a consulting practice based on its ideas that was detailed in the following publication:
Walker, K. B. and E. L. Denna. 1997. "Arrivederci, Pacioli? A New Accounting System Is Emerging" Management Accounting (July): 22-30  (I have no idea where to find this on the web)
For people with questions on REA design philosophies, we do have some of the old papers available at    This is not a great web site, but we hope to make it better in the next few months when I get some time.  People can also email me with questions.
There are a lot of interesting threads here.  I am glad I discovered the list.
All the best,
Bill McCarthy
Michigan State
You are a writing machine and truly a wonder.  When I look at your site, I am dazzled by your output, your chutzpah, your
intolerance for the establishment powers and the status quo, and your technical acumen.  I am constantly feeling like the rate of technological change in things like ebXML keeps me on the edge (not the leading edge, the falling off the building edge), but you seem to handle it all with élan.

Nonetheless, I think I need to restate the REA case again, because there are some misimpressions in your accounting posts.  I feel like we (the REA crowd) are finally going to make a difference in practice within the next 5-10 years; we already have made major changes in the way accounting systems are taught in college.  Twenty years ago, I thought that it would be some time around 2030 before that practice change occurred, but I didn’t see ERP, BPR, SDA, OO, and better computers happening as fast as they did.  And I had no idea that the WEB was in our future in the way it has occurred.
First, a couple of quick observations:

1. For the vast majority of transactions, REA is incredibly simple with just one “fits on a page” pattern.  This simplicity
fits the scientific principle of Ockham’s Razor or as it is better known in Dilbert terms: the “KISS” principle. If you give me a room of managers for one hour, I can teach them REA in a way that will have them building value creation diagrams of their firms with ease.  It is the way entrepreneurs think, so it comes naturally.  Adapting REA to things like extremely complex debt or equity issues is hard, but so is it with the traditional double-entry model.  I would need a while to work out a conceptually clean solution to the latest spate of derivatives, but that solution would be representationally and mathematically robust (actually, most of the current modeling work in the market could be adapted in with modifications if I could get developers to let me see the guts of the model).
2. REA was unrealistically inefficient for practice when it was proposed in 1982.  However, here are its enabling technologies of the last few years:

  • hardware technology (faster processing speeds, better direct retrieval methods,  cheaper storage, and (especially) better source data automation),
  • software technology (widespread adaptation of object-orientation with pattern driven analysis and design components),
  • business methods (business process engineering, activity-based costing rationale, and enterprise-wide coordination of resource flows),
  • business organizational forms (virtual companies and limited life independent ventures), and
  • communication environments (e-commerce with its need for consistent inter-enterprise semantics, active ontologies, and especially the need for external models (trading portals or webledgers).

In a sense, these enabling technologies are like those that occurred in Venice 500+ years ago that “technically enabled” and “commercially impelled” the widespread use of double entry (Arabic numerals, negative arithmetic, the printing press).
3. The duality link looks like it works a lot like the double-classification of traditional accounting, but it is more
encompassing.  Besides the business process pattern, the value chain specification, the integrated ability to include
types/commitments, and the multidimensionality, this duality vs. double-entry is the biggest difference for traditionalists.  

For example, counter to what you had in one of your posts, a credit sale would have an inventory decrement, but no claim or accounts-receivable entered.  When the cash (and/or the sale return) comes in, the exchange is complete.  If this strikes you as heresy, because it doesn’t balance arithmetically right now, we can give you an instantaneous “claim” view as a safety blanket, but you might be surprised at how you don’t need it if you just try to be comfortable without it.  

The claim can be materialized if you need a A=L+OE financial statement.  There is no loss of “control”; as a matter of fact the transaction controls get tighter because the patterned nature of representation makes deviations (planned or accidental) from types and commitments easier to catch.  BTW, this transaction would also have other decrements (like the time of the
salesperson; the truck use in delivering the goods, the consumption of advertising service, etc.).  

Present double-entry doesn’t allow direct representation of these decrements and instead insists on procedural conventions (which in REA are implementation compromises) like matching and absorption which used to work in most cases but often don’t anymore.  Procedures are complicated and they can’t be pattern-matched.  They also tend to become entrenched and inflexible so they remain in use even when people can’t remember or justify their original rationale.  Anybody want to explain the business rationale for sum-of-years-digits depreciation or R&D expensing as a representation scheme to an entrepreneur ? (not as tax write-off methods or public reporting methods presently allowed; we can make those “views” as long as somebody will accept them).  This is why source data automation is one of the enabling technologies of REA; it enables better representation of reality and entrepreneurial purpose.  Many duality links still need to be compromised underneath the conceptual schema level with REA (and their compromised implementation might be akin to the traditional procedural solution, so the matching expertise of present CPAs still might have residual value for years to come), but the number of those needed compromises is gradually diminishing.  We might never get to “full-REA” even with STAR WARS technology, but we are getting closer all the time.
But REA has been around an awful long time, at least 15 years. It has been studied to death by everybody from big 5 CPA firms to OOP developers.
This is actually not true.  With the exception of PW-GENEVA, Haugen’s company, and a bunch of other relatively small
companies, we have never really had a major developer give an honest and sincere attempt at directed REA.  Even when the whole project thinks like REA, a big general ledger goes back in at the end of the project, and the journalizing mindset starts to creep toward the data entry front-end of the corporation instead of staying at the financial reporting back end where it belongs. 

The trouble is always the same, from the IBM San Francisco project to SAP to Dodge.  They are just too scared or mentally incapable of breaking out and being really different (if they were all engineers, they would still keep their slide rules and abacuses on their desk, even while they used calculators, because such things were an important part of what was used before).  In terms of one of my favorite classroom quotes from Shaw (which I think I saw on your site too once):  

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself.  Therefore, all progress depends on the unreasonable man.
George Bernard Shaw, Man and Superman, “Maxims for
Revolutionists: Reason” (1903)

This is why we have so few “directed” REA systems.  However, if you look at modern ERP software as being on a continuum with double-entry journals and ledgers at one end and REA at the other, the ERP systems are much closer to REA because they have drifted that way because of market demands.  For that matter, so have integrative file-based systems with feeders to a G/L. Something like Quickbooks is about a fifth of the way across the chasm.  As it adapts to integrated use, the WWW, and supply chains, it will come further across.  Why not be “unreasonable” and just start on the REA side and compromise back to what current entrepreneurial rationale and representation technology allows?
The problem with REA is it's mis-labeled, as an accounting system.
It is really a high-level, and very generalized model for business objects, or business systems. It establishes a number of abstractions that generalize business events. It guides developers in the creation of software objects.
This is not true and true <g>.  Its original name touted it as an accounting system meant for a shared user environment, and it can do everything that a traditional system can do (although for some small and insular firms, its computational inefficiencies with extra data etc. will make a more simple and traditional accounting system preferable).  Why do resource tracking systems that work well with HR, logistics, marketing, etc. have to be labeled “non-accounting”?  What is wrong with doing it in an integrated fashion?  Can’t accountants reclaim their primacy as enterprise guardians of value-added activities?  Are we doomed to be just the guardians of a smaller and smaller part of the corporate database?
It was way ahead of its time. For anybody who really wants to 
know what makes things tick, it's a goldmine.
Thank you; thank you!

REA was created in 1980 apparently in response to circumstances that no longer exist, in my opinion. For example, McCarthy identified the following weaknesses in the conventional accounting model.

1. Its dimensions are limited. Most accounting measurements are 
expressed in monetary terms, a practice that precludes
maintenance and use of productivity, performance, reliability,
and other multidimensinal data.
2. Its classification schemes are not always appropriate. The
Chart of Accounts for a particular enterprise represents all of
the categories into which information concerning economic affairs
 may be placed. This will often lead to data being left out or
classified in a manner that hides its nature from
3. Its aggregation level for stored information is too high.
Accounting data is used by a wide variety of decision makers, each 
needing differing amounts of quantity, aggregation, and focus
depending on their personalities, decision styles, and conceptual 
structures. Therefore information concerning economic events and 
objects should be kept in as elementary a form as possible to be
 aggregated later by the eventual user.
4. Its degree of integration with the other functional areas of
an enterprise is too restricted. Information concerning the same set 
of phenomena will often be maintained separately by
accountants and non-accountants, thus leading to inconsistency
plus information gaps and overlaps.

I disagree.  Numbers 1, 2,  & 4 are as valid as ever.  Really, really, really long account codes with spreadsheet roll-ups have mitigated #3, but these codes are unintelligible outside of the accounting department and certainly outside of the firm.  That only exacerbates #2 and #4.  Sales by product, by salesperson, by distribution channel, by warehouse, etc. should be modeled with symbols that represent products, salespeople, warehouses, etc. (not with positions in a code block), so everybody understands them.

McCarthy's goal was to move accounting away from a position of being an independent and non-integrated information system, towards a position of being a constituent part of an enterprise database system.  Regardless of the merits of the REA model you can see it begins with the objective of creating a complete business information system. (So was everybody else in 1980, inventing SQL etc. which of course  made countless fortunes, made Larry Ellison the 2nd
richest man on earth, etc.)
True for me on the goal; true for Ellison and untrue for me on the riches.  I am a college professor and putting all your best
efforts and best ideas in the public domain is not the road to great riches.  Maybe I will change some day if people like you
keep reminding me how nonsensical it is to teach/research accounting systems instead of building/selling them.  My greatest teacher (databases) was part of the SQL development effort at IBM-San Jose; I probably should have followed him into practice when he left university life.

Over the years, REA has morphed and improved, accumulating corrections and enhancements which is good, particularly in the area of value networks that span enterprises.  REA has some incredibly great memes and it's good to study. Dualities for
example are the reciprocal of any event. i.e. for any exchange of a resource that happens in the transaction space, there is an
offsetting energy exchange someplace.  

Classic Double-Entry Accounting also attempts to be Newtonian this way (every action has a reaction). But REA is much better, and broader, along different dimensions. REA just goes right down to business with descriptors for the newtonian reaction, instead of trying to shoehorn it someplace into a trial balance.
Thanks for the kudos.  You seem to be cooking here (but remember that some double-entry is classificational as opposed to causal; in REA, everything is causal).  


In other words, REA is actually a more accurate set of semantics to describe reality, a better map of the territory, than CDEA. For example a first event might be the transfer of a product from one party to another. Under CDEA a  transaction would be generated, Debit AR, Credit Sales. REA tells you there was an event, a resource of goods transferred out, and a resource of a receivable transferred in. There is always a reciprocal event (a "duality") in REA. Obviously it might be a payment of money to settle the receivable. That's another CDEA transaction. It's also another REA event, I think.
See duality comment above.  This description is not quite true.
I don't have any problem with REA and I'm only puzzled why McCarthy seems to have a problem with CDEA. CDEA is just a little thing that runs alongside a business system and accumulates numbers and audit trail, for the trial balance for statutory reporting. That's all it is.
I actually think CDEA was wonderful for its time; it just needs to be replaced with a “minimal” G/L idea (like Lawson software). Also, many of its conventions need severe re-examination, and REA forces this with every new implementation.  You seem to be championing the cause of keeping the journal mindset restricted to reporting, so maybe we don’t have such a big difference.

The REA model claims to achieve aggregate measures for analysis, financial reporting and tax reporting under what they call
"conclusion materialization." And it claims to eliminate the requirements to set up Charts of Accounts up front, or put
account numbers on transactions, by encoding that knowledge in servers someplace. I would LOVE to see how this system describes all of the countless thousands of types of different transactions that have all been figured out and integrated into CDEA over the years, without piggybacking on all those political and legal decisions.
You are exactly right.  In many cases, REA systems do have to piggyback on those political and legal decisions.  

You might be surprised however, at how much of that political/legal rationale can be abstracted and applied without CDEA. 

As a matter of fact, when I am trying to figure out complex modeling decisions that involve what accountants call allocation decisions, I usually go back to accounting theorists of the early twentieth century (1900-1960) and read what they had to say.  Those theorists usually speak in clear business terms, not bookkeeping rules, and their insights are marvelous.  The biggest difference however (this is really, really important) is that many of those legal/political are actually embedded in REA as implementation compromises to a fully represented value chain.  Those compromises are always revisited when technology allows upgrading, so known distortions (like absorbing OH based on labor) are never institutionalized or mindlessly passed on.  We have a phrase for this methodology: Full-REA minimizes errors of omission in implementation; any compromises should be errors of commission.
Certainly, 5 million accountants in the US are not going to go
back to school for remedial education to learn the new recording semantics.
We might disagree here.  REA is not hard and I can demonstrate its core components in 1-2 hours and get people using REA databases in two more.  The two leading accounting systems texts teach REA and a host of others are changing. 

There is also a strong grass roots movement toward incorporating a business process and value chain (BP & VC) approach to introductory accounting along with CDEA.  I think that BP & VC is actually much easier to understand than is double-entry.  Most MBA students agree with me, and managers seem to find the idea of an “entrepreneur script” fairly intuitive.  CDEA seems easy to you and to my colleagues here at MSU because you are so familiar with its intricacies.  This familiarity leads to strange myopia, like people here who teach that the best way to formulate credit policies is to chart the fluctuating balances in the bad-debt-expense account (as opposed to looking at the customers, sales, cash receipts, and products plus their various type groupings).
Nor is it necessary. REA is a software model for the back-end, I think. It is not an
accounting methodology. There is no "REA Balance Sheet", "REA User Interface", "REA Journal Entry" etc.
There is an REA methodology and we do have prototypes with user interfaces and sample balance sheets.  No journal entries though; you got that one right.

REA adherents have sometimes been heard pointing the finger at accountants in industry, or public firms, who use their positions to extract rents, control purchase decisions on business software systems, etc. and point at mentally inflexible accountants who operate by rote, and are incapable of other semantic systems, etc.
By REA adherent, I assume you mean me, and I am guilty, guilty, and more guilty on this count.  My friends, including Haugen, tell me that 9/10 of the time I would deliberately cross the street to pick a fight with a traditional academic accountant. Practicing accountants are different; I usually try to learn from them because they are walking reservoirs of non-CDEA business sense, even though most are too set in their ways for my tastes. I am trying to spend less time in combat these days, but some “rumbles” are just too good to walk away from.  Some day I will learn.


Of course it's true, that Controllers hate software that can't deliver accurate numbers by the 10th after month-end. They see
anything new and fight it, just because it's new, and they know that CEOs will often not pay for the extra work for new systems. I have been a controller. I can relate. Staff accountants also fight anything that creates *more* havoc than they already have--anything new has to have either an incremental adoption scenario that is nondisruptive, or, if its a total rip-and-replace then the company has to hire additional people for the transition. CEOs never spend money on
admin/overhead. Thus, corporate accountants are difficult customers when management shoves a bunch of extra, unpaid work at them.

Controllers must protect their troops from chaos coming from outside the department. Otherwise lose their loyalty and support for his objectives. So, the real failure of REA is that they didn't cost-justify a whole rip-and-replace to CEOs. Microsoft and the ERP vendors got in there with their COM story, and their ERP story, and lied about the cost, mostly.
REAL FAILURE??? Our inability to change the accounting world entirely by direct revolution can’t be characterized as a failure yet. Give us 20 more years (and maybe a few more technology surprises) at least.  My change strategy of one student and one peer-reviewed paper at a time has probably been misguided, but teaching is what I do best.  I might quit academe if I felt that I could make this all happen quicker.  On the other hand (as already mentioned), I think the world is gradually moving away from traditional accounting and toward REA anyway, so evolution might overtake revolution.


After a long time you realize, the issue isn't whether such political issues exist, but rather, how to design business software that meets the requirements of business. So, REA vs CDEA is just a distraction.

I agree.  However, I would note that politics never matters to those in control because they are safely entrenched.  Why should the existing accounting establishment care if it hard to get new ideas aired?  They already have all the answers anyway. 

Resources, Events and Agents are cool. The model has lots of applications and there is no conflict with statutory financial
reporting at all. REA is coming into increasing focus as an SCM solution, a solution for logistical and financial information
systems which spans enterprises.  

Anything like REA which enables value networks can be supported beautifully by a web ledger. You could have very big Supply  Chains, with big international manufacturers which would function by spitting out the inventory, payables and receivables, etc. transactions to any webledger that has an XML interface. The manufacturer could run the webledgers as little independent business systems, or harvest the balances or transactions from them.
You almost sound more optimistic than me here.  I still need to sit down and figure out the webledger/REA interface out in its entirety.  My initial reaction is that we are in synch in a lot of ways.  This will be a high priority for me.