Here are other links.
http://www.supplychainlinks.com/Rea4scm.htm
http://jeffsutherland.org/oopsla98/nakamura.html
http://jeffsutherland.com/oopsla96/mccarthy.html
http://st-www.cs.uiuc.edu/users/johnson/business-transactions/mccarthy.html
http://jeffsutherland.org/oopsla/mccarthy.html
http://jeffsutherland.org/oopsla97/haugen.html
http://homepage.interaccess.com/~linkage/
http://homepage.interaccess.com/~linkage/REAsupplychains.htm
http://st-www.cs.uiuc.edu/users/johnson/bus-obj.html

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.

What follows is my subjective opinion. Don't even read this until you
have reviewed the links above.

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. It was way ahead of its time. For anybody who 
really wants to know what makes things tick, it's a goldmine.

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 non-accountants.

3. Its aggregation level for stored information is too high. Accounting
data is used by a widevariety 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-accoutnatns, thus leading to inconsistency plus information gaps and
overlaps.

McCarthy's goal was to move accounting away from a position
of being an independent and non-integrated information system,
twoards 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.)

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. 

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 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.

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. 

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. 

Certainly, 5 million accountants in the US are not going to go back to 
school for remedial education to learn the new recording semantics. 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.

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.

Of course it's true, that Controllers hate software that can't deliver 
accurate numbers by the 10th after monthend. 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.

---

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.

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 
beatifully 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.

* Todd F. Boyle CPA http://www.GLDialtone.com/
* tboyle@rosehill.net Kirkland WA (425) 827-3107
* XML accounting, WebLedgers, ASPs, GL dialtone, whatever it takes