E-Commerce XBRL

In the late nineties, a consortium of companies within the accounting software industry began work to produce a set of standards that will apply to financial data produced by accounting software packages and other applications in the future. These standards are referred to as XBRL (eXtensible Business Reporting Language). The goal was to establish a commonly agreed upon standard for tagging financial data printed from any source such as accounting systems, spreadsheets, etc. This works much the same way that tags work on a web page to define fonts, indents, colors, etc. For example, the screen shot below shows a web page both in normal view, and in HTML source code view to illustrate the concept of hidden, embedded tags. 

In this case the user simply sees the phrase “Information to help you...”, however behind the scenes there are hidden tags that tell the browser which size font, font color, font type, and indent style to use when displaying this phrase. In much the same way, XBRL standards define the hidden tags that are embedded behind the scenes on financial reports so that other systems can read and interpret that data. It is anticipated that ultimately, hidden XBRL tags will allow any XBRL compliant system to automatically receive and read purchase orders, and convert them automatically to sales order. The consortium located at XBRL.ORG has developed the eXtensible Business Reporting Language (XBRL) for the preparation and exchange of business reports and data.  The initial goal of XBRL was to provide an XML-based framework that the global business information supply chain will use to create, exchange, and analyze financial reporting information including, but not limited to, regulatory filings such as annual and quarterly financial statements, general ledger information, and audit schedules. 

The XBRL Specification and the first taxonomy for financial reporting of commercial and industrial companies under US GAAP were released on July 31, 2000.  This was a major milestone for the XBRL framework. The implementation of XBRL tags that have the capability to define financial data on a purchase order is still in the works.

Does XBRL Fall Short?

When it comes to XBRL, Eric Cohen is the king  - I acknowledge his extensive knowledge and involvement with this standard. Recently, Eric corresponded with me in regards to my question - "Does  XBRL fall short?". Eric provided me with these few insightful comments regarding XBRL. I share them here as they counter some of my comments about XBRL. Thank you Eric.

On a few occasions I have raised the question regarding whether or not XBRL has progressed far enough. The consortium produced standards for identifying major categories of financial information such as revenue and expenses, but fell well short of creating the specific standards we need to support free flowing e-commerce between differing systems. Granted, I believe that their efforts are a good start, but I also believe that more refined standards are needed for tagging specific items and data fields such as customer name, seller name, customer ID, seller ID, shipping address, billing address, product IDs, product descriptions, quantities ordered, pricing, sales, tax, payment methods, etc. With these standardized tags, the folks at ACCPAC, Best Software, and Syspro, and similar companies could modify their software to produce an order or invoice with the proper embedded XBRL tags, and that order could be read and imported immediately by other products such as QuickBooks, Navision Attain, or Oracle Financials. In other words, differing accounting packages everywhere would be able to exchange orders, POs, invoices, and even payments electronically. It would be e-commerce delivered to the masses. 

A conspiracy theory nut might conjure up the explanation for the group's lack of progress towards deeper XBRL definitions. It might go like this: We know that during the XBRL initiative, the folks at Microsoft were also in the process of developing their own set of extensive tags and standards, which has now been bundled and packaged as the Microsoft BizTalk Server. In Microsoft's model, companies using two differing accounting systems such as Peachtree and ACCPAC Advantage Series can communicate with one another through a Microsoft BizTalk Server. As it stands now, Microsoft controls these standards and anyone using these standards must pay a small fee to this end. In other words, Microsoft collects a small fee for each transaction that passes through a BizTalk Server. Therefore Microsoft had a vested interest in preventing the consortium from establishing deeper standards which would become open standards for all to use. (Yes - Microsoft was a member of the XBRL consortium). 

It is a good thing that I am not a conspiracy theory nut, huh? For the record I am a big Microsoft fan and own a chunk of Microsoft stock. I believe that Microsoft's approach offers an enormous benefit in that accounting software publishers need not rewrite their software applications in order to use the Microsoft BizTalk server for linking differing accounting systems together. Further, the Microsoft BizTalk Server incorporates security and encryption standards as well - another key benefit. However, if we had deeper standards for tagging POs, orders, invoices, and payments, accounting publishers could write to those standards and ultimately, end users would be free to communicate with other end users without a middle man. 

During the XBRL development, I hosted Eric Cohen in my house in Atlanta for a few days, and we discussed the need for these deeper standards. Eric agreed with my premise that deeper XML standards are needed to support free-flowing supply chain solutions, but he provided some insightful comments that better explained the XBRL initiative. Eric explained that the XBRL  initiative was focused only on "financial reporting". The XBRL group wanted their work to be approved  and endorsed by the Financial Standards Accounting Board (FASB) and that the group thought that more detailed definitions might hurt those chances. Based on the standards that were developed, there was dissention in the ranks regarding the terminology to be used - surely deeper standards would result in more dissention.

Conclusion

XML and XBRL are very promising technologies that will not only allow our accounting systems to communicate better in the future, but also paves the way for new applications that we have not even thought of yet. You might detect from my comments above that I am frustrated that XML and XBRL standards have been slow in maturing. I think that XML and XBRL are great, and if you are in the market for accounting software, it would be time well spent to inquire and evaluate the XML and XBRL capabilities of your prospective products. 

- END -