XFRML, ebXML, and the root ledger

["Todd Boyle" <tboyle@rosehill.net>]

The XFRML workgroup http://www.xfrml.org is nearing release of its 
vocabulary for financial reporting.  (I am not associated with XFRML.)

This is XML for GAAP (Generally Accepted Accounting Principles)
for financial statements in the U.S. i.e. for statutory reporting
for publicly listed companies as well as SMEs.  See the website for 
draft tag sets and demo applications.

I understand XFRML workgroup are actively considering at this time, 
the issue of flatness vs. hierarchic structure in their schema.  Any 
comments on that?

...

The significance of the XFRML release may be far reaching. For example,
it will be inevitable that definitions or usage of the vocabulary 
must be forthcoming from the AICPA in some fashion; in the past
the definitions of GAAP terminology (although legally binding), were
copyrighted by FASB and cost hundreds of dollars.  

Financial data in XFRML format may enable automation of downstream
processes such as tax returns, and all kinds of boutique financial 
analyses beyond the financial statements.  The need to publish and
manipulate financial statements in multiple formats (.doc's, .html, 
edgar, excel, .txt, .ppt and so forth) will certainly be reduced. 

ASPs and accounting systems that can effectively store transactions 
in a way that is mapped to XFRML tags, will obviously deliver better
reports out of the box.  

=========

ebXML workgroups should consider the interrelationship between your
XML Schema for General Ledger and downstream XML such as XFRML that
emanate from the resulting transactions.  

I don't claim to have any easy answers but suppose you release, as
did OAG, an XML spec calling for an Account Code (here are the OAGIS
elements in JELINE with their content models:)

GLNOMACCT, BUSNAREA?, COSTCENTER?, DEPARTMENT?, DESCRIPTN?, DIVISION?, 
ELEMENT*, FUND?, GEOGRAPHY?, GLENTITYD?, ITEM?, PRODCTLINE?, 
PRODORDER?, PROFITCTR?, PROJACTVTY?, PROJECT?, PROJRESEL*, 
REASONCODE?, REF*, SALESORDID?, UNIT?, WAREHOUSE?, WORKORDER?

The notion of an "Account Code" may be obsolete; the Chart of Accounts
has historically been overloaded with multiple uses. It has often been
an intricate, denormallized table combining values such as org. structure
and department, with accounting classifications.  Chart of Accounts
has served multiple needs including ease of keypunching, internal
control, reconcilation with external entities, and downstream
reporting.  No wonder Charts of Accounts are an unmanageable mess.

Account codes need to be burst out into several different attributes
representing their real uses. General Ledgers should not have 
"Charts of Accounts" in future.  Chart of accounts is supposed to
be the classification choices for the GAAP domain. That's called 
XFRML, in the U.S. now isn't it?  Do you see what I mean?

There will be 3 levels within the accounting system of SMEs:

Level 1 - the SELF.  the root ledger
Level 2 - the BSP or functional modules.  Usually on DotComs thru which 
we buy and sell, such as web stores, timesheet systems, payroll services,
purchasing portals and vertical marketplaces of all kinds.
Level 3 - the OTHER.  the 3rd parties with whom we buy or sell thru
our website or BSP, or thru their website or BSP.

Obviously there are many XML vocabularies between level 2 and 3.  

However, Level 1 will exist for SMEs in a way that it has never
existed for B2B commerce, EDI and so forth because you, in larger
businesses, have combined Level 1 and Level 2 in your enterprise
software.  You're literally conducting business thru your firewall,
with third parties (the OTHER).

SMEs will conduct business thru multiple services (ASPs or BSPs).  We 
will download summary entries from them as though they were subledgers.
These General Journal postings will need to contain classifications
for posting to our "general ledger".  This will really be a Root Ledger 
since some of these DotComs will themselves be General Ledgers having 
trial balances.

It might be a good thing if ebXML transactions arriving at the root
ledger of the enterprise, contain classification values closer to the
real nature of the transaction.  This could reduce the need to push
COA codes or other business attributes outward, to the subledger or
module.   It would be nice if all DotComs, ASPs and BSPs could determine
how to transmit their dealings to the root ledger by reference to the
GL Schema alone.   Without the usual nonsense of asking the CPA what
chart of accounts code to use in this case.

Should we be thinking about a "standard chart of accounts" coded into
the GL Schema?  It might have only 20 codes. These are never very 
abstract.  They are always Payables and Receivables of various kinds 
(including notes receivable etc.) and of various expected maturities.  
Even a cash account or merchant card receivable is really a type of 
receivable.  Maybe this is the direction we need to go, to strip 
away the accruals and other stuff not needed by the ecommerce community 
and instead, focus intensely on what is the purpose of the Root Ledger
to maintain fiscal control over money and liquidity and ARs and APs 
that exist out on the remote DotComs and functional modules.


There will still need to be GAAP classification applied at some level, 
but lets concentrate that in the root ledger. 

The decoupling of tagging utilized in posting incoming transactions
from the determination of GAAP reporting classifications on the
downstream side is nothing new.  But I suspect there are opportunities
for further streamlining of our data model.

Hello?  hello?  is anybody still listening??  heh heh!  
Too much expresso at lunch, 


* Todd F. Boyle CPA    http://www.GLDialtone.com/
* International Accounting Services LLC    tboyle@rosehill.net
* 9745-128th Av NE, Kirkland WA 98033       (425) 827-3107
* XML accounting, WebLedgers, ASPs, GL dialtone, whatever it takes