Re: XFRML, ebXML, and the root ledger

[Alan Kotok <akotok@disa.org>]

Todd, et al.

You raise basic questions that our project team in ebXML, or ebXML overall, 
will need to address.  If there is any current cross-industry business 
language it is the one imposed on businesses by the accounting community, 
and it appears that XFRML is trying to represent that language in XML.  We 
cannot have these critical accounting functions left outside any ebXML 
specification, yet we also do not want ourselves put in a straightjacket 
that prevents the kind of process improvements possible through XML-based 
data exchanges.

I would like to invite Eric Cohen who is active in the XFRML activity to 
join us in a dialogue to get the issues raised by Todd out on the table and 
work through a solution.  Any comments on or objections to inviting Mr. 
Cohen?  Best regards.

Alan Kotok
akotok@disa.org
+1 703-518-4174



At 03:35 PM 3/1/00 -0800, Todd Boyle wrote:
>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