Accounting Domain Ontology for e-business 
rev. 2  Oct. 2001 with Dec. 2001 corollaries
Todd Boyle CPA - - Netaccount AS - -  http://www.arapxml.net/NDEAdef.htm

Contents: 

Introduction 
Using the REA Ontology  
Economic Resources (balance sheet accounts)  
Economic Events (double-entry accounting transactions)  
Economic Agents (parties)  
RFA model 
REA materialization doctrine 
Account classification of e-business events 
Uncertainty Principle 
No Replication 
NDEA: new double-entry accounting 
  1. includes Unposted information 
  2. includes economic commitments within its scope 
  3. requires native transaction attributes (dimensional data) 
  4. does not enforce balancing of "Unposted" transactions 
  5. requires that events be identified to collaboration "GroupID" 
  6. requires a standard vocabulary for GL meta model (transaction, entry, account, etc.) 
  7. does NOT require the account code be present in "Unposted" transactions 
  8. does NOT require charts of accounts codes for Posted transactions 
       if resource types or XBRL classifications are sufficient 
  9. does not prohibit deletion of unposted data in business applications 
Dec. 2001 corollaries
  10.  implies a flat row structure (NDEA cannot require 2- or 3- tier structure)
  11.  requires accounting for quantities without monetary valuation.
Possible requirements for the BCM 
Credits 

Introduction

The goal of this ontology is cataloguing the basic nature of economic processes, i.e. processes which give rise to accounting requirements. This project has two immediate objectives.

1.  identifying the best existing ontological framework for economic processes, and 
2.  identifying appropriate semantics in naming and structure for user interfaces and machine interfaces in order to accomplish accounting requirements.

Accounting requirements include such things as

1.  financial reporting/ GAAP financial statements, 
2.  tax reporting (income, sales, VAT, etc.)
3.  cash flow reports and management, 
4.  general fiscal control and internal control over the sub ledgers, and
5.  payables and receivables management and settlement.

My colleague Morten Jacobsen and I explored several approaches to this accounting ontology.  I am reporting our joint work below.  

A question arose, whether we are really building an ontology of general ledger software products, general ledger interfaces, or perhaps, business software or interfaces in general.   We rejected these subjects because they are at least once-removed from the subject of economic exchanges in nature.  However, we continually awoke finding ourselves studying symbols of things --artifacts within GL software, interfaces at the edges of GL software, and similar artifacts in business software-- instead of underlying ontology of business events, or the abstract accounting model.  

It must be said at this point that no symbol has intrinsic meaning.  All words and symbols are divorced from phenomenal reality.  They can only refer to each other, forming an entire cognitive fabric.  UML is no different than XML or HTML in this regard. Business process models are also gnostic --unable to tell developers much of anything unless they already have arcane knowledge.  Thus, BP models are a kind of telegraphy among people who already have shared concepts, enabling them to navigate alternative software designs and interface languages.

Another question which arose, was whether to produce an ontology of general ledger transactions, i.e., to explore the nature of ledger entries grouped into balancing sets.  Or, examine them empirically, and produce yet another document model or XML schema for business transactions, arranged in rows, and branded with account classifications.  (ArapXML 0.87 already represents this type of ontology.)

We also considered, and rejected, the idea of ontology of financial reporting semantics.  Obviously, IAS and US GAAP is a sort of ontology of business.  Published financial statements have normative vocabulary for most business realities.   However, these are descriptive and summarized semantics.  The study of GAAP is the study of minimum required disclosure.  It is not a goal of GAAP to eliminate ambiguity but rather, to intentionally modulate it within political compromise.   There is vanishingly little substance or insight in these reporting semantics, or their representation in XBRL taxonomies, that would be useful in software design.

Ultimately we decided that the subject of ontology is business interactions themselves.  For this we immediately returned to William E. McCarthy's ontology of economic transactions, REA.  REA is apparently the foundation of much of the architecture in the UN/CEFACT TMWG Universal Modeling Methodology and its metamodel (the UMM). REA is also the foundation of much of the thinking in the BPSS. The project adopts the ontology of economic transactions produced by McCarthy, at http://www.msu.edu/user/mccarth4/  and in particular, the diagrams in http://www.msu.edu/user/mccarth4/Alabama.doc   We found no issues with the REA ontology and we recommend the REA papers to all developers of accounting systems.

We produced a number of exercises with RDF, DAML-OIL, and DAML-S schemas for ontologies.   Bill McCarthy informed us a DAML representation of REA has been undertaken in the past.  I believe by Guido Geerts.  However, we decided to use natural language for this project, for two principle reasons.  Time availability, and, the lack of any immediately visible business software that could do profitable things with a DAML representation of economic transactions.

Using the REA ontology

The REA ontology is comprehensive, applying globally to all classes of transactions we could think of.  However it is also quite atomic and abstract, and its implications on financial reporting or general ledgers are not entirely clear. REA includes no explicit mechanism for financial reporting.  Ongoing work on REA is evident in the UMM releases in 1999 and 2000, and the work of ebXML Business Process workgroup.  REA resources and events necessary for very basic accounting realization are included in the BRV of the TMWG's UMM, excerpted below:

These tables were included in the ebXML BPSS at various points in 2000-2001 but were dropped from the May 2001 final version due to time constraints.  Members of the eBTWG BPS team informed me that REA will likely be included in the BPSS next major release (v 2.0).

Even knowing these facts, and having access to abstract models such as UML does not conclusively inform developers of accounting systems either how the GL must adapt, or how transaction recognition would occur. 

Later models are similarly process oriented.  October 11, 2001 McCarthy posted the following model to the mailing list of the ebTWG (the successor group to ebXML).  Economic commitments and events are almost the same as the 2000 model. "Claim" has been added, and stereotypes ("Types") are added for R,E, and A.  These are cited by McCarthy as the foundation of accounting recognition.   The other classes such as agreement types and BP types will also be necessary in account classification (although not entirely sufficient for GAAP determination).

Subsequently to production of this paper, Andrzej Bialecki published his REA analysis on eBTWG mailing lists - it is quite significant and useful. 

http://www.ecimf.org/contrib.html 
http://www.ecimf.org/contrib/onto/REA/index.html 
http://www.ecimf.org/contrib/onto/ST/index.html 

Andrzej Bialecki <abial@webgiro.com>, is Chief System Architect
of WebGiro AB, Sweden ( http://www.webgiro.com )

Economic Resources (balance sheet accounts)

Over the past several years, the term "Economic Resource" has become stable in the business modeling community surrounding the UMM and ebXML.  The UMM makes crystal clear that Economic Resources includes all types of cash, receivables, inventory, supplies, etc.   This is the starting point for our view that an REA business system is a new variety of general ledger, having Economic Resources as its asset accounts.   The ALOE model itself is suspiciously little other than a list of assets; an argument exists to abolish ALOE.

Labor

Labor is an  Economic Resource within the meta model and REA itself.  This is slightly troublesome from a classic GAAP viewpoint; in GAAP accounting, labor, itself, does not exist as an asset or liability until the point in time it is rendered, and at that instant, a financial asset disappears and in most cases, it is a writeoff (expense is recognized).  For over 100 years, CEOs have tried to record balance sheet assets, and in the case of manufactured goods and other specific circumstances, this is GAAP.  No e-commerce meta model is likely to capture the true cost of labor anyway, for, even if a Taylorian hell of timekeeping were implemented, every employee has numerous, complex benefit costs.

We are confident nevertheless, that GL views of a REA business application can be maintained in which any Labor Resource table is allocated between capitalized portions and current expense, no more or less badly than is done in today's cost accounting systems.  For example, the labor table may be allowed to run into negative balances, and be  replenished (to zero) with positive monetary and quantity values periodically, such as at measurement dates. 

Economic Events (double-entry accounting transactions)

The term, "Economic Event", is not quite as stable in this modeling community.  It is certainly stable in the UMM and REA model semantics.  However, the word "event" has many different connotations; for example it has a different meaning in ISO RM/ODP.  Within the worksheets and other parts in Chapter 3 of the UMM, furthermore, the terms "Initiator Resource Flow" and "Terminator Resource Flow" are being used instead of "Economic Events".   One can only conclude, these are really transactions in the CDEA sense, because duality is enforced in the UMM meta model, para 8.25 (well formedness rules): resource flows are only permitted within dual relations i.e. they must be reciprocated.  

Note however, simultaneity is not enforced in REA.  This is inevitable, for any business system that manages real transfers of goods or services, since it is physically impossible to transfer both resources at one instant.  In fact the majority of interparty transfers are not requited (e.g. settled) for many days.  

REA provides some approaches for generating ALOE views even when unrequited transfers exist at period ends (dualities that span periods), under a doctrine called claims materialization.   However, the GL view of an REA  business system is natively out of balance, with respect to any open dualities at the point in time the view is constructed. 

Note, further, that the GL view of an REA system is out of balance in any case, unless the cost of resources surrendered in an exchange is equal to the value of those received.  Clearly that is the exception not the rule. 

Economic Agents (parties)

The REA term "Economic Agent" is not used in the UMM meta model semantics. As you can see, the term "PartnerType" has been adopted as of this time.  Examples such as "receiving partner" and "shipping partner" have been used in the worksheets, while the model semantics 8.2.5 cites "manufacturer, distributor, retailer, carrier, financier and end user" as PartnerTypes.  

The ISO 10746 Enterprise Viewpoint language has "agents" but they are not synonymous with "economic agent" or  "partnerTypes".  The ISO 10746 synonym would be "party roles".  It is interesting to peek at one diagram from the large RM/ODP specification, FCD-15414 annex A, "Overall Structure of an Enterprise Specification", 9-9-2000:

RFA model 

One might playfully entertain the idea of an RM/ODP'ish expression of REA, in which the UML diagram is renamed to align with RM/ODP but also, is a 3-dimensional model made of balsa wood blocks and toothpicks.  The 3rd dimension is time.   In other words, look at the extended REA model above as, changing over time as trading partners evaluate each other and figure out whether, and how, to do business.

(The second and third rows are identical to the extended REA model above, other than naming.  What this model adds is the communication stage which precedes the Typing stage.  The communication stage is where CRM happens, and where essential Party IDs and Product IDs first may become available to a business process runtime.)

REA materialization doctrine

McCarthy and other REA modelers have produced at least four detailed prescriptions or roadmaps for classic financial reporting (Assets=Liabilities + Owner's Equity or ALOE).  They are the 1987 McCarthy-Denny paper, the 1999 REACH paper, 1999 Ventura MDB, and a 2001 unpublished draft paper.  The primary resource tables of course contain running balances sufficient for some of the asset accounts in ALOE reporting.  The "Materialization" doctrine, in general, prescribes procedures to calculate the rest of the balances of the balance sheet and income statement, rather than maintaining those accounts continuously in declarative structures such as CDEA database tables.  For example, sales to Customer X might be calculated as the change in his AR plus cash received. 

An REA application may maintain accounts not essential to business collaboration such as normal period expense (e.g., advertising expense), as two (as opposed to one) economic events with one event showing the acquisition of a resource, and the other showing the consumption of that resource (McCarthy 1982, p.573).

Performance problems are reported at several points in the literature. Authors report that the materialization approaches presented in the papers are infeasable under current computer resources.  Clearly, however, REA principles have found adoption in the e-business modeling community.  That is, REA has been found suitable and feasable as an abstract model for collaborative, e-business processes.  One might assume these developers are not  planning to use REA as a comprehensive GL or financial reporting platform but rather for the development of specific, collaborative software objects.

Account classification of e-business events

Bob Elliot's model for the accountant's "value chain" identifies five stages, or sequential processes:

In e-business, of course, stages 1, 2, and 3 are well within reach of automation, since not only is every step of the business process captured in machines, but it is also more or less forced into agreement with trading partners, in arms-length exchanges.  Capturing this value is the purpose and goal of GL Ontology project.  To reach those gains, we want to capture REA, ebXML and UMM business processes into GL views.  Since they cannot be immediately viewed as a traditional GL we want to relax the rules imposed by most GLs.

The difference between B2B data and GL data can be summed up in two words: the accounting classifications.  The only thing irretrievably missing from all of the worlds' POs, invoices, orders etc. is the accounting classifications, such as  chart of accounts codes or classifications within an XBRL taxonomy. Account codes are today, assigned to almost all sales, purchase, etc. transactions automatically, but only after an accountant or integrator has configured their GL and application software with them.  Designing charts of accounts is one of the great, fun activities of CPAs and controllers. 

It is safe to say, no consensus exists in any public discussion, as to how Charts of Accounts classifications may be systematically assigned to REA transactions.  Rather, the consensus today is that each company will integrate their B2B systems themselves, and make independent decisions not only with respect to private choices like charts of accounts, but also with respect to the timing of recognition of resource flows, and the character (classification) of those flows. The eBTWG's BCP&MC project appears to tighten up this somewhat.  

Essentially, business software has always encompassed wider scope of information than the general ledger-- modeling greater descriptive detail of business processes than current notions of a general ledger.  Business software has always, furthermore, modeled the lifecycle of transactions over time (e.g. order/fulfillment/settlement among many patterns.)  Finally-- decades of experience have modeled e-business interactions such as EDI.  These megatrends are well known, and unsurprising.  They can be observed in all business software markets. 

Yet, the general ledger has remained, steadfastly, as a place where transactions are logged only after completion, and only after all balancing components of a particular exchange are known with some certainty.  These megatrends are not a new thing, discovered by ebXML.

1. Business processes often come in patterns such as the order, fulfillment, and payment that span time.
2. These patterns can include multiple messages and commitments, as well as resource flows.
3. Some of these events do not cause economic transfers to be recognized, but some do.
4. Even if an economic transfer is recognized, different GAAP classifications are possible for the same event.
5. GAAP classification is not the same thing as event recognition, it is much harder.
6. the GAAP classification (e.g. chart of accounts or XBRL codes) can be assigned at runtime only after considering numerous factors.  The diagram below is not comprehensive, but illustrates some points.

The above diagram, translated into English, says: 

• Transactions can be stored or represented in CDEA, as a GL, at the time they are executed.
• If a product catalog or other resource table is sufficiently descriptive, and the terms of contracts such as payment terms are also sufficiently descriptive, the GL classifications can be pretty good.
• However, GAAP classifications cannot always be correctly determined by machines at that time because not all companies implement GAAP the same, and the intentions and circumstances of the company affect GAAP classification.
• If the company and its policies are sufficiently described, and GAAP rules are sufficiently encoded, then a GAAP classification engine can improve classfications very much. 
• Any GL will still be wise to provide a General Journal for Accountants to make manual reclassifications and intentional changes such as allocations.  

Some influential thinkers within ebXML BP modeling (McCarthy, Haugen, others) have adopted within scope that a mechanism of event recognition should be available to parties in exchanges (both parties recognize economic  movements with consistent character, quantity, dates, etc.)  

However it is my understanding, decisions when and how to book the transactions under GAAP are out of scope and will be left to the parties internally. The goals of the current BCP teams should be of great interest to GL developers, because of the way they have deconstructed the formation of business transactions.  For example, an economic commitment to do an action with 10 widgets at a date and location is the essence of what POs and other legacy documents are trying to express.  If the REA ontology is correct, and if objects for the commitment and its realization event can be developed to view and manage them in GL views based on the ontology, those objects may be of great long term value. You are getting closer to a rootledger-subledger architecture that does more than just the GAAP financial statements. You're getting closer to a unified framework for the federation of the BCM object with other BCMs (multiple BCMs in the same company) as well as with legacy applications.  GL developers should gladly drop their existing constraints for double-entry or whatever else is blocking progress, in order to make the GL reflect the formation of business processes instead of a static repository for completed ones.  

Further, the ebXML BPSS undertakes to track the dualities of economic transfers, enabling the creation of claims when unreciprocated states exist.  The journalizing of these events is not slated for work by the ebXML workgroups however, as far as I can see.   I have floated the idea that parties composing BPs or CPAs might as well compose (private) templates for the automatic posting of GL entries at that time but the response has not been positive.

I have suggested that an addition box be added on the REA diagram for transaction journal (into which, event notifications are put.) This doesn't need to be double entry, balanced, or include accounting classification or other things like taxes which are impossible for the BP model to know. But there should be boxes on the REA diagram
for the parties to provide transaction templates to do those things, such as

- a box containing transaction templates for simple blank journal entries,
- a box containing the accounts required by the templates,
- a posting rules box telling the criteria that trigger a claims
materialization or other balancing component,
- a box to store the formulas for computing those balancing components.

These boxes would be private to the trading partner and as such, the other trading partner does not need to know of their existence since he cannot rely on them.   But that does not mean, they don't exist.

In particular, the REA model explicitly does not undertake to compose any balancing entries.  For example an inventory movement may occur reducing inventory by 80 and increasing AR by 100.   REA is about the modeling of exchange activities and events not recording the 20 profit. One can readily appreciate that simple devices and event components such as barcode readers at a loading dock, might be highly valuable in automating a business process,  but that automation will be screwed up if the server is expected to go and find AR information, determine taxes and other data necessary to post CDEA entries for every scan.  (SMEs' accounting software even computes COGS on the fly for every sale.)  BPSS is looking like a single entry system that will dribble out all the necessary information (eventually) but not in neat CDEA entries.  

Uncertainty principle

There seem to be two intrinsic principles apply to any system that interacts with external parties (B2B or B2C  automation):

1.  The earlier in the business process a B2B system begins, the more reversals and exceptions will arise.  This is a natural reflection of the fact that formation of purchases and sales are often tentative at first. 

2.  Efforts to disambiguate terms of transactions before the realization of sale, i.e. before fulfillment, sometimes result in lost sales, therefore, reversals, corrections, and exceptions will be a system requirement for the long-term.

Taking these realities into account, good general ledgers do not cripple the efficiency of business operations in the process of journalizing  double entry views for accounting and financial reporting.  Bad general ledgers cripple them. Or at least, impose non-zero labor costs, delays, and inflexibility.

No Replication 

The ideal general ledger, like other business systems, does not create replicas of transaction events that are already stored in the business system.  Issues of backup and of security are addressed as independent questions in modern business systems.  You don't need these replicas.

The best practice for GL design in 2001 is that the GL is an index or view of transactions in indigenous business systems.  Business systems that handle the formation of transaction (rather than journalizing completed ones) must accommodate a lot of changes, reversals and failures.  The ebXML BCM (business collaboration manager) software is intended to be flexible and usable in business, and would be much more complex if required to model the  posting of every journal that may have been posted by the GL replica, in order to generate reversing entries and corrections with every exception or change in transactions.

An updating of the CDEA methodology itself is necessary, to what we might call new double entry accounting (NDEA). The high-level goal is to extend the traditional GL model to handle interactive business processes between trading partners.  NDEA must enable any business software including the BCM, to represent its transactions externally in GL format, appearing to be a sub-ledger or general ledger, without disrupting its actual operation or forcing it to perform unnecessary processing.  In other words, the NDEA architecture needs to provide a GL format that is sufficiently expressive for the ebXML BCM or any other business system to represent its business state and business history of events.  In GAAP this is called the "financial position and results of operations".  The NDEA instance must be a complete and comprehensive picture of the economic events that have been realized by that system.

NDEA: new double-entry accounting
An expanded concept of the classic double-entry accounting (CDEA)

This unified format is also intended to enable the replication or entry of business data from business applications into NDEA GLs even if that data is not compliant with traditional, CDEA rules.   

NDEA continues to insist that business data be in the form of balanced double-entries with correct account codes or other classification mechanism, before it is Posted, as entries in the trial balance.  There is no abandonment of CDEA.  However, the NDEA GL accepts, and embraces, other information into its view and into its storage in consolidation and other replication types of activities.

Following is the first draft of NDEA extensions to CDEA:

1.  The NDEA ledger includes (permits entry) of Unposted as well as Posted information.  Unposted information is subject to fewer constraints, and may include any valid business information formatted as a GL entry or entries.  "Posted" information however, is fully compliant traditional double entry GL data with account classifications.  For example, an NDEA GL may have a boolean "IsPosted" flag, to distinguish between real CDEA trial balance and other business reports. 

2.  NDEA includes economic commitments within its scope. 

3.  NDEA Requires descriptive structure and vocabulary for native transaction attributes associated with transactions and transaction entry rows, when they are material.  There are a fairly manageable number of independent dimensions that recur in most economic exchanges.  Native attributes of business transactions might include

who - parties and their roles in relationship to a GL transaction (individuals as well as organization units on both sides of the economic exchange)
what - product or service or financial instrument, etc. associated with this monetary amount
when - the point(s) in time the transaction was negotiated, ordered, fulfilled, settled, entered, posted, approved, reversed, audited, etc.
where - location created, executed, posted, delivered, taxable, etc.
why - immediate purpose being duality, the expectation of reciprocal flow,
why - business purpose, budget classification, business segment, accountability, etc. and
how - applications, authority, chain of custody of the information prior to, during and after execution of a transaction

In other words, NDEA requires structures for party, product, location, budget, and other dimensional data within the GL.  These dimensions are the foundation for broader use of GL data in management reporting (fact table as data warehouse), as well as the automation of accounting classification.   

4.  Does not enforce balanced journal entries (require balanced books) at time of entry of "unposted" transactions.  Acknowledges that single entries to the books are an inherent part of unfinished business processes.  Enforces, however, that a single entry must be accompanied by an identifier to its previous or anticipated, future related entry(ies).  This may include references to contract, party, collaboration instance, or other data sufficient for generating a balancing claim.   (Enforces balanced entries only as part of the  closing of books stage of the value chain.)  The suggested name for this identifier, which associates entry rows into balanced transactions, is "TransactionID".

5.  In principle, NDEA requires that events be identified to either the transaction or the business collaboration pattern instance to which they belong.  Historically, an entry was only identified (i.e. associated with) its balancing siblings in a transaction.  To serve as the information component in external interactions requires that events be associated with their associated or reciprocal movements,  within a collaboration.  A possible, suggested name for this identifier which associates the multiple transactions within the same collaboration is "GroupID".

For example, a shipment is an event in REA for which a claim (a receivable) may be materialized at the same moment, to post a balanced accounting entry.  This shipment/receivable event needs an identifier to connect it with a later payment.  In general, all entries in NDEA may be viewed as within transactions and all transactions as within collaborations.  Thus, the e-business community may find that the GroupID is a requirement, even though in cash-and-carry, there may be no associated transactions since both reciprocal movements occur at the same time.

6. Requires a standard vocabulary for three-tier general ledger meta model (transactionSet, transaction, entry row, account, etc.  This implies a standard vocabulary for resource types, which are equivalent in some regards, to accounts.)   Reasonable people disagree over the need for standardization of terminology or behaviors for these particular elements, since they typically do not occur between reciprocal parties in e-Business.  Indeed, most B2B vocabularies such as xCBL have no elements for these. Notwithstanding, these particular elements are clearly needed in internal integration -- which is among the goals of NDEA.

7.  No longer Requires the account code or classification be present at time of entry of unposted transactions, i.e., the NDEA GL contains data at earlier points in the business process than the point at which GAAP classifications are present or in some case possible.

8.  No longer Requires charts of accounts, or account codes at all, even for Posted transactions, if resource types or XBRL classifications are applied sufficiently for financial reporting objectives.

9.  Deletion of data - Many business applications, in widespread use, permit the deletion of data.  Data in systems touching customers or supporting business processes prior to execution of exchanges, often contain information which is tentative, ambiguous, and not correct.  NDEA cannot impose constraints such as nondeletion upon native business application that find it necessary to allow deletion.  Furthermore, the NDEA GL may be required to reflect the deletion of data, if it is to be accurately in synch with real applications. 

The intent of the NDEA specification is to provide a framework for those native business applications to represent their tentative economic commitments and events in NDEA views, facilitating business intelligence.  It is implementation decision whether an NDEA application maintains logs or audit trail, for deletions of unposted data.  This area requires further research. 

The CDEA subset of an NDEA GL does not abandon accounting constraints such as the audit trail and other Invariants, in the 1998 OMG GL specification.    

Dec. 2001 corollaries

10.  Implies a flat row structure (NDEA cannot require 2- or 3- tier structure) - The NDEA model must function within a flat single-entry assumption.  NDEA encompasses individual debit or credit entries without any constraint for balancing, or association with dual movements or GroupID, at points in time earlier than any balancing sibling entries, dual movements, etc.   One of the usage scenarios of NDEA is support of ebXML business processes at runtime, in which atomic movements need to be recorded which do not share information with any other entry past or future. 

Even when balancing sibling entries are anticipated at a later time, it may be difficult for accountants or software applications to compose a transaction header until those future rows of data in the journal entry are known.

11.  Requires accounting entries for quantities without monetary valuation.  Actors in business processes such as fulfillment often generate data about movements of economic resources, in circumstances where valuations are not available for reasons of security, expediency, system resources, etc.  Many other circumstances exist where monetary valuations of resources are impractical or impossible to determine, such as movements of assemblies prior to job costing, sale of inventory before all of its costs have been booked, etc.  

NDEA accommodates all movements of all resources that are material; this goal is no different than the traditional goal of accounting.  It is the goal of the NDEA model, to serve as a unified event notification whenever a commitment or economic event has occurred in an ebXML or REA business process. 

Possible requirements for the BCM 
...internal integration of B2B applications

The BCM (implementation of the ebXML BPSS) may be defined as that software application which an owner users to participate in ebXML business processes, i.e. to respond to queries, and to receive, view, and manage all information connected with the ebXML business process and its collaborations.   In many cases the "BCM" will be some e-business modules, messageware layer, and purchasing or selling modules as an integrated whole. 

The BCM (and perhaps the BPSS specification itself) may also require change:

My personal view is that the BCM should position itself to behave as a subledger in its own right, and publish a standard interface that is usable by all business modules equally.  Whether that format is a GL format such as the ArapXML NDEA format is not  important.  What is more important is the BP workgroups consider a single unified message structure for communicating resource flows and commitments which must include the monetary valuation of each resource flow and commitment. 

TB.

credits

Thanks to Bill McCarthy and his REA school, who were the source of most of these ideas, Morten Jacobsen, of Netaccount who provided additional key concepts, and permission to post publicly, Netaccount who funded these research, Bob Haugen for his relentless insistence on the truth in business processes, Eric Cohen for his years of dedication to the XBRL General Ledger schema project, and Robert Lemense and others in UN/CEFACT D14 who forged the international EDI message for Ledger and accounting Entries out of countless considerations and constraints. 

I am not trying to paint myself into the picture with all these professionals, or blame them for anything I've written above.  Just admitting, most everything in this writing came from someplace else.