February 13, 2005XBRLUnlike HTML, which is all about the display, XML is all about the data. The tags don't tell your browser anything, but they do describe the data they enclose. Since the data for each industry is different, companies have been busy developing trade standards for data. I've spent time writing code to parse the data for natural gas transport, for instance. Now, financial data is getting the same treatment, and the general consensus is that it's the software industry's response to Sarbox. The SEC has announced a program allowing companies to file their 10-Ks' financial data in XBRL. In a BusinessWeek issue about web services, XBRL got an article all its own. A local company, Rivet Software (profiled here), is releasing their Microsoft Office plugin that lets you take financials in Word or Excel and transform them into XBRL. It works with balance sheets, income statements, cash flows, shareholders' equity, and footnotes. In fact, even without Sarbox, XBRL (eXtensible Business Reporting Language) would probably have come of age. To give one example, financial analysts use anomalies in ratios and ratio trends to spot potential fraud. Being able to import data from many companies in the same industry at once from the SEC site will make spotting outliers a lot easier. That said, it may be that the benefit of XBRL to internal processes is being oversold a little. Companies do their mangerial accounting very differently from their financial accounting, because the metrics they're using are different. Activity-based costing, for instance, it completely different from GAAP. Also, "internal processes" can mean just about anything that ends up hitting the financial statements. The processes vary wildly across indutries and even companies. XBRL just isn't built to handle individual receipts and inventory flows. Posted by joshuasharf at February 13, 2005 08:41 AM | TrackBack |
|