From: Todd Boyle [tboyle@rosehill.net] Sent: Tuesday, May 30, 2000 1:44 PM To: xbrl-public@egroups.com Subject: [xbrl-public] CDEA General Ledger schema Hi folks. Lets start talking about the General Ledger schema. Here is some discussion. * It's going to be a classic double-entry journal schema, * It's going to be used pervasively between software objects within midrange systems as well as heterogeneous systems on the internet, and * As accounting systems move from company centric to ecommerce models, it's going to support information for both parties to transactions in a more symmetric design, representative of the global transaction fabric. Under "classic" double entry accounting (CDEA), a transaction is a collection of two or more rows whose debits equal credits. Each row of a journal entry has attributes that everybody can agree on (date, account code, description, etc.) and a long list of other attributes that begins with everybody agreeing, and descends into progressively less consensus, around the 10th or 15th attribute. But that's CDEA. One of the weaknesses of CDEA is that in the absence of good software objects, it always pushes a lot of "complexity" to the bookkeepers' head. Historically the bookkeeper needed to know the debit/credit procedure for every type of transaction. Paper bookkeeping solutions never got to the point where printed ledger pages existed for more than 3 or 4 types of transactions (General Journal, Sales Journal, Disbursements Journal, etc.) Printing companies created others but they were more trouble than they were worth. So, bookkeepers hand-crafted most transactions. A good bookkeeper would know how to post any transaction, into a balanced, multi-line journal entry. We now know that any software that requires users to apply CDEA accounting skills must die, in the small business space, because it's uneconomic. The leading edge has gone much further towards elimination of manual bookkeeping itself. What we're going to see on the internet is a lot of "software objects" that do 100 clever types of transactions, and emit them to the back end accounting system. A good XML schema will free these developers to do what they do best. Software that presents a CDEA approach to the user is unusable by most small businesses-- it's optimized only for accountants. The surviving software packages have at least 10 to 20 different transaction types encoded into business objects: Quotes, Sales Orders, Sales Invoice, Purchase Order, Receive Payment, Receive Goods, etc etc. Internet transaction types such as receive and approve bills, represent another new set of user interface and business objects. Subscribers will use a large number of diverse service providers (BSPs) on the internet to create transactions. The level of complexity and granularity of those "business objects" and in their user interfaces, must not be constrained. In designing general ledgers to support diverse transactions, surely, it is unwise to attempt to accommodate each of these particular transaction types with its own table definition, and XML schemas for interfacing with the originating BSP on the internet. There are such a variety of different business services that you need something flexible enough to accomodate new requirements. I submit that a CDEA structure should be adopted for the back end design of general ledgers in the internet age. - any interfaces between objects in which transactions are passed, - the database schema of the webledger, and - especially, in the XML schema by which transactions are sent/received to heterogeneous systems. In other words, the lingua franca for passing any transaction is that it should be encapsulated as a set of rows adding to zero, in which each row has a transction ID, amount, and other attributes. Complete transaction rows should have attributes indicating - "account code" classification. identifies the source context and reality of the transaction unambiguously, within a taxonomy that is sufficiently expressive that both parties to a transaction may agree on the classification of the transaction - "XBRL code" classfication of the transaction into statutory GAAP categories for downstream reporting (yeah this sounds bizarre but that's where we're going: automation of GAAP financial reporting) - "date" of execution of transaction So, what I'm saying is, YES, build complex software objects that present good interfaces to the user, sheltering them from CDEA. And YES, design those objects to present good interfaces to other objects, to shield those objects from complexity. and the way to do that may be CDEA, in these back end interfaces. Classic double entry accounting is a methodology and metadata framework capable of representing every kind of business transaction and financial state change that can exist in the problem space. Developers who are building best-of-breed business platforms are never going to be sufficiently aware of the nearly endless diversity of other business and financial transactions that exist on the internet, that they will have to interface with in future years. - downstream interfaces where the BSPs application must push incompleted transaction results (Accounts Receivable, Accounts Payable, unfulfilled orders, etc.) - downstream interfaces where cash and payments instructions or notifications must be delivered - downstream interface to the entity's root ledger for statutory reporting. - sideways interfaces where the BSP must make its services and functionality available to other BSPs and vice versa. BSP developers are less likely to have the educational background or experience to appreciate the history behind statutory accounting (GAAP) requirements. Accordingly, they are prone to building some new and creative vocabularies and transaction storages that are genetically flawed and will never reach adulthood. When they want to post new and wonderous transaction types like partnership allocations, cost accounting entries, multicompany entries, etc. these designs will choke. Webheads haven't got a prayer of getting these all correct, without help from accountants. When they encounter each new challenge, even within the narrow domains of their website or business, they will choke. These developers will be completely unaware of the information required in the system, for cash management, cash flow statement, financial instruments, multicurrency accounting, accounting for income taxes, or dozens of other intricate and unlovely problems until year-end, when the phone starts ringing. So, they will undergo version upgrades that are so costly and disruptive, they will be rendered uneconomic and the platforms will die. These flawed platforms will have difficulty interoperating as peers in the e-commerce environment, when all these diverse ecommerce platforms are interconnected into a grand integration. These integrations will inevitably converge around classic double entry consolidation accounting because there just isn't anything else out there which is sufficiently comprehensive, and because to achieve statutory accounting, most of the marketplace is going to require serious GAAP compliant information anyway. What's even more sobering is the fact that even when accountants and academics have nearly unlimited resources to design new, dedicated accounting transaction structures, it has been impossible to get them deployed. Here read this paper by Dr. Emanuel F. Schwarz http://accountingnet.com/research/solutions/private/accounting/soac980622p.a sp We need to agree on an CDEA XML schema to carry accounting transactions. OAGIS post journal is close. smbXML schema is close. But nobody has published a well-balanced midrange double-entry schema, This has been too long. I'll try harder next time. Todd * 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