Amid the dark days on Wall Street and in global markets, it seems to be up to technology to step up and deliver solid analysis and rational scrutiny. The US market regulator, the Securities and Exchange Commission (SEC), ratified a proposal on Wednesday for public companies and mutual fund companies to file their financial statements in XBRL (eXtensible Business Reporting Language). The XML-based language is also known as “Interactive Data” in financial circles and promises faster analysis with wider coverage. All things being equal, it will mitigate the poor analysis and regulation that’s been contributing to stupendously bad financial decisions.
This is a guest post by Derek Abdinor.
Companies have traditionally filed on paper, in ASCII, or in HTML: all essentially lifeless formats for conducting any meaningful comparison or analysis. With XBRL, every line item is given a tag that identifies it and its role in the financial statement. Imagine that a line item — say, “Net Income” — is tagged like a migrating goose (which frequently happens, I’m told). That goose is part of a flight of geese, which may change their course mid-flight, fly over national borders, have babies, and even join another flight. But thanks to the vital information on the goose’s tag, we never lose the original information, and we are even able to see it in the context of other information.
Financial accounts are the same. Figures get re-purposed all over the place, which leads to input errors, or worse. It’s easy to cover up information or fail to notice business risks when the analysis is relegated to a footnote somewhere, and you’re reading the annual report like a “Choose Your Own Adventure” book.
When financial data is tagged, it’s begging to get mashed up. Take a look at this comparison of executive pay, this dynamic charting, and the SEC’s own repository and viewer. Software exists that can be first used upstream with the creation of management accounts and go all the way through to taxonomy design, document tagging, and viewing. One would be able to call up income statements of two or more companies in different sectors and different countries and compare line items in seconds.
But to see XBRL simply as a means of marking up financial statements at the end of a financial reporting period is to miss the rest of the iceberg. If financial items are automatically tagged upon their creation using a system like SAP, the rich analysis can be filtered through the enterprise and to suppliers. Triggers and reports can be generated on the fly. Knowledge workers will be manipulating XBRL without knowing it by its accurate, albeit consonant-heavy, name.
XBRL, by its nature, has largely escaped the wave of Enterprise 2.0 functionality. But the openness of the data, its ability to be mashed up and displayed in previously unthought-of ways, will impress itself upon a public disillusioned with poor financial management — management that has itself partly relied on poor data. It’s time for some developer rock stars to step in and make those spreadsheets sing.
More about XBRL
Often described as being simply complex, XBRL should be approached from a technological, as well as an accounting, perspective. XBRL is simply a flavor of XML. Financial line items, totals, text, and metadata are XML elements that are mapped to a predefined schema (called a “taxonomy” in XBRL). In all cases, these taxonomies are the financial rules of accounting for that jurisdiction. Throw in XPath, XLink, and more, and you have a mature language for tagging and submitting your financials.
An introductory resource to begin with is Wikipedia, which links to the various regulatory bodies, IT initiatives, and current issues. The “XBRL in Plain English” video is specific to executive summaries.
This was a guest post by Derek Abdinor, a divisional director at motiv – the Investor and Branding agency of Ince, a large communications concern from South Africa.
