From: Todd Boyle [tboyle@rosehill.net] Sent: Tuesday, July 11, 2000 1:14 PM To: xbrl-public@egroups.com Subject: Draft Schema for General Ledger As SMEs (small/medium enterprises) begin to conduct business over the internet, their systems of storing information must change. Webledgers will dissolve the "accounting" business. The word "Accounting" doesn't mean anything. There isn't "accounting" software anymore. I'm not sure there is even *business* software. There is just commerce. Still, there must be an abstract model of your financial life, i.e. your balance sheet, whatever you want to call it. I call it a webledger, or the root ledger. When these models live on the internet reconciled with everybody elses' model, life is going to be a whole lot different... For over 25 years, business software became more and more integrated as it relentlessly pursued automation of cash, payables, receivables, and inventory across all the systems in the office. We learned after great pain, that our software had to be integrated, and "integrated accounting software" meant choosing a single vendor to supply all the modules. Now, we must unlearn that lesson, for these reasons: 1. The internet manifestly contains thousands of excellent BSPs (business service providers) which are the "software modules" for conducting business. These include every selling, purchasing, payment and admin activity formerly accomplished on desktop or LAN based software. These thousands of BSPs will not in near future, be owned by the same company, 2. There is no likelihood that all of your customers, suppliers, and services providers will use the same BSPs. This fact will cause millions of businesses to experience great pain, while, others will understand and accept this immutable fact. For the last 70+ years, the general ledger has been the absolute foundation of accounting. Classic double-entry accounting (CDEA) provides a whole set of double-entry solutions and journal entries encapsulating every possible transaction type in the business universe. The CDEA and A=L+OE system of representing business transactions was, if anything, strengthened during the past 25 years of integrated software. To repeat: millions of accountants practice, every day, this system of notation for recording and summarizing business dealings. This is a language, a set of symbols, and a whole bunch of rules that are so deeply entrenched that no other system of notation can gain market share, at the human interface level. Business systems have obviously moved on, becoming optimized for different things and paying not the least attention to CDEA. Especially in internet commerce! But when you get to the controller or the CPA or even the AP/AR clerk, whenever you have a human being, CDEA is entrenched at the user interface and in reporting. One place to begin deconstructing CDEA is the chart of accounts. 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 multiple codes such as organization structure, department, and accounting classifications. These are called "segmented" account codes, for example 5110-10A Overtime - branch 10 (peoria office) department A 5110-10B Overtime - branch 10 (peoria office) department B etc. Charts of Accounts have served multiple needs including ease of keypunching, permissions/internal control, reconcilation with external entities, and downstream reporting. Charts of Accounts are an unmanageable mess and obstacle to systems improvements in many companies. Most accounting software does not provide adequate solutions for retroactively changing or merging account codes in the chart or in the transactions databases. For example, Quickbooks enables overwriting of account codes with a new ones, and merging accounts. This is highly useful in small business but you can no longer reproduce financial reports that had been published before you changed the codes. Whenever account codes carry information for several different dimensions, companies should explore other accounting software that reports those dimensions separately. For example, the Chart of accounts should NOT encode information related to organization structure, geographic, product, party, or any other unrelated information. YES, those may be required in a general ledger. But NO, they should not be combined into the chart of accounts, especially as the need for global integration increases. I argue that general ledgers should not even have "Charts of Accounts" in future. After you strip away the tangled up mess of information combined into charts of accounts, the only remaining purpose for account codes is to reflect classifications for the GAAP domain (financial reporting). XBRL now defines the available GAAP classifications natively, in the U.S. XBRL is the universal "chart of accounts". The words "Chart" and "Account" themselves, are artificial and contrived. In the segmented example above, the user interface and the data storage for the accounting system would contain an XBRL classification, a geographic (branch) code, and an organizational (department) code. Voila. No "chart of accounts". (Why does this matter? Because owners, managers, and parties to transactions, cannot achieve economies or effective transaction processing over internet if everybody continues using incompatible naming and coding of transactions. Bear with me.) Now let's consider some emerging problems in classification of accounting transactions. The transactions need to be transported among and between 3 discrete levels of software comprising the business system of an SME: Level 1 - the SELF. the comprehensive, complete general ledger which models the enterprise (the root ledger) Level 2 - the BSP or business software module, or sub-ledger or functional module. Historically the sales journal, purchases, payroll or other journal or module, running on the desktop or local server. These functional modules are increasingly provided remotely on ASPs or BSPs or DotComs thru which we buy and sell. For example, web stores, timesheet systems, payroll services, purchasing portals, and trading hubs and marketplaces of all kinds. These BSPs enable SMEs to conduct business over the internet, integrating customers and suppliers and payment providers, making non-repudiable orders and payments without large investment in local firewalls. Level 3 - the OTHER. the 3rd parties with whom we buy or sell thru our website or BSP, or thru their website or BSP. There is a 3rd party with whom you conduct business, who insists upon data integration just like you. This is like the evolution of plant life into animals, who had eyes to see. The unconnected desktop software are vegetables--they can't understand anybody exists except themselves. They are profoundly autistic. 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 larger businesses have combined Level 1 and Level 2 in enterprise software. Large ERP/enterprises literally conduct business thru their firewalls, with third parties (the OTHER) thru EDI and other custom connections. SMEs will conduct business thru multiple services (ASPs or BSPs). They will provide summary entries in a whole variety of custom formats, which must be viewed by the root ledger 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. The unthinking assumption of every BSP and dotcom I have researched, is that every SME will have their own custom Chart of Accounts and that any interface to the root ledger, accordingly, must be visited and configured and mapped for them, by an expert. Does this sound a little like EDI? It might be a good thing if XML transactions arriving at the root ledger of the company, contain some minimal classification as to the broad category of the transaction. This could reduce the need to push custom account codes or other business attributes outward, to the subledger or module for every party, for every transaction, thru every trading hub. It would be nice if all DotComs, ASPs and BSPs could agree upon an XML schema for the general ledger, which would define unambiguously how to transmit their dealings to the root ledger by reference to the values permitted within that GL Schema alone. The alternative is years of the usual nonsense of asking the CPA what chart of accounts code to use in each case, futzing with local configurations and then configurations of the interfaces. Think about this. There WILL be a general ledger folks. It WILL have account classifications. I believe it is possible to articulate 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-- leave out the accruals, depreciation and other stuff not needed by the ecommerce community and instead, focus intensely on the business purposes which can only be provided by the root ledger, and are inherently impossible to achieve in distributed modules on multiple BSPs. Inherent root ledger requirements: ------------------------------------- - maintain fiscal control (e.g. control totals) over money and accounts receivable and payable that exist out on the remote DotComs and functional modules as well as local systems, fixed assets etc. - maintain near-realtime information of cash balances, cash flow attributes of all events which have happened, and cash flow sources and needs predicted at future dates sufficient to manage the cash flows of the business. - consolidated views of accounts receivable / accounts payable sufficient to maintain control over supplier and customer balances when the enterprise touches those same classes of customers or suppliers thru multiple points (e.g. selling locally and on web storefront; buying locally and thru web purchasing portals) - GAAP financial statements / financial reporting - timely and accurate tax reporting - consolidations and eliminations whereever multiple sub-ledgers exist, including multiple "general ledgers" on BSPs as well as companies/locations. - foreign currency translations Don't believe me? Think for yourself. Companies will conduct business via multiple BSPs, resulting in transactions stored in multiple locations. Most business processes do not inherently require any shared data, for most users. For others, the bank statement provides a unifying view. But are any of the above requirements possible without a comprehensive, combined view someplace? The answer is no. These are the classic financial controller/treasury functions. Companies will still need to implement GAAP classifications at some level. Historically, companies implemented finely granular, custom charts of accounts sufficient to enable GAAP reporting. The XBRL schema, AICPA-US-GAAP-CI-00-04-04.xsd contains over 1100 ELEMENTS classifications. Companies could implement true GAAP classifications, natively, in their accounting systems. Historically, to produce financial statements, companies often mapped their charts of accounts into the lines of their financial statements, - combining some accounts, - changing the order of some accounts, and - changing the label of other accounts. XBRL can be immediately implemented by any accounting system by storing the appropriate XBRL tag for each account into the chart of accounts table. For example if there are multiple accounts receivable, they might all be tagged with the XBRL tag, "aicpa:currentAssets.receivables" For any non-accountants reading this: accounting entries are usually stored as a collection of rows, each having an amount and an account code representing the different results of a transaction (for example the simplest sale might be a 3-line journal entry: sales 100, tax 8, account receivable 108.) There is absolutely no reason this system of notation is necessary; however there is absolutely no likelihood that millions of fulltime accountants worldwide, will change anytime soon. XBRL also enables root ledger scenarios in which BSPs encode every row of transaction *directly* with its XBRL code. Note carefully, the contrast with my previous paragraph in which the XBRL code was associated with the chart of account code. GAAP reporting can be achieved without any other "chart of accounts" than XBRL tags. SMEs always have multiple assets and liabilities which are in the nature of payables and receivables with respect to 3rd parties-- the combination of the XBRL tag and party identity would establish uniquely these accounts and their transactions. Isn't that more transparent than establishing a numeric account code? Traditional account codes were useful in data entry and other mnemonic processes which are de-emphasized in root ledger architectures. Returning to the question: what chart of account classes exist within a root ledger architecture, whenever the enterprise uses BSPs or other distributed processes? The answer appears to be nothing other than XBRL tags. XML Schema for general ledger ---------------------------------------- Then, what structures should be included, within any XML Schema for general ledger? The following would please me very much. I have simplified the root ledger to a single table, requiring no Chart of Accounts table. Here is my straw man draft, for the "R" required fields and some optional fields, of a root ledger table (which translates immediately into a very simple XML Schema for general ledger-- a completely flat set of ELEMENTs.) Host - system, host or software where this data originated. R Company - the legal entity which executed this transaction. OrgUnit - department, section etc. Geographic - branch or business location for sales tax Country - ISO 3166 (optional because default driven, in practice.) Language - ISO 10646 (optional because default driven) Journaltype - sales journal, purchase journal, etc R TransactionID - uniquely identifies this transaction (set of rows) R TransactionRow - uniquely identifies this row (e.g. line of journal) R TransactionDateTime - ISO 8601 date/time TransactionType - Actual, Budget, Forecast, TaxAdjustment (default=A) EnteredDateTime - ISO 8601 date/time User - authenticated user recorded this transaction Reference - source doc. number or index, etc. R XBRLtype - classification of this transaction for GAAP reporting R Party - uniquely identifies the reciprocal party to this transaction. Partyclass - role or type of party as customer, supplier, etc. R Amount - any number consistent with your currency. Currency - ISO 4217 Currency codes (optional because default driven) Description - explanation text or memo string etc. TransactionCode1 - user defined category, class, T-code etc. TransactionCode2 - user defined category, class, T-code etc. TransactionCode3 - user defined category, class, T-code etc. TransactionCode4 - user defined category, class, T-code etc. TransactionCode5 - user defined category, class, T-code etc. Maturity - if this is an external payable/receivable, when it is due Cleared - mark this row as matched, settled, cleared, etc. Approved - approval boolean for internal approve. Reviewed - boolean for external auditor or reviewer Employee - internal party executed this transaction Job - uniquely identifies the job, project, etc. Product - uniquely identifies the product or service. XMLdocument - any XML business doc. accompanying this transaction. Obviously, in the accounting business my XML Schema will drive somebody else to apoplexy. I am fully aware of dozens of problems with the above table design and blissfully unaware of dozens of others! Don't you just hate it, when you have to actually identify specific fields, to actually get some work done? For those .01% of companies that have more than 5 transaction codes on their GLs, let them edit the DTD and extend it. Or stuff codes into the XML document field. Or, XBRL GL schema can have 10 transaction codes and that will cover all but .001% of companies. Let the .001% eat cake. While XBRL delays the GL schema, 100% of SMBs are "eating cake". Perhaps what's lurking under the surface is a tension between developers who are already running traditional procedural code and CDEA, versus the newer developers who depend on various object-oriented structures, set oriented commands, XML transformations, etc. and hate writing code to assembling/disassemble their new data structures into bands of general ledger journal entries. Most of the new/better vertical and horizontal business modules are probably not procedural CDEA under the surface. However the new technologists are negligent in articulating any replacement for A=L+OE semantics, and the thousands of different kinds of CDEA postings currently used. Accordingly the "object" people, XML transformation whizzes, etc. basically don't have any business solution for the root ledger requirements other than CDEA. In any case, it will be very useful and worthwhile to publish a GL standard, that can transport data at least among desktop software like Quickbooks and Peachtree, and among small business BSPs on the internet. This flatfile would enable many business processes without even the need for subledgers, AR, AP, or sales/purchase journals etc. Let's get moving and define an XML schema for general ledger. It's going to be CDEA, folks. It consists of Rows. And there are going to be a potentially large, potentially arbitrary collection of fields on each row. So let's get to work. * 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