XBRL (eXtensible Business Reporting Language) has been described as the universal business language, but so far, it’s about as oft-spoken as Latin. In essence, XBRL brings context to numbers by tagging financial data points with information about that data, in effect standardizing it. The idea: to enable businesses to prepare, exchange, and analyze financial statements and the information they contain.
In theory, XBRL should be a money-saver for publicly traded companies, since the digitization of data eliminates the need for rekeying or prepping numbers when companies consolidate their books.
XBRL-enabled data will also allow companies to easily benchmark their performance against peers. Imagine importing electronic data on 10 competitors and being able to analyze it at once and with confidence versus poring over paper reports, keying in data, and wondering how each company defines a given data point. (For more on anticipated benefits, see end of this article.)
Where It’s At
In August 2000, the Journal of Accountancy ran a cover story on XBRL, predicting the standard would “revolutionize how business information is reported, used, and calculated.” We’re fast approaching 2004, and still no sign of the revolution.
What’s the hang-up? For starters, a universal reporting standard can’t gain much momentum if nobody can agree on the standard. Indeed, if there’s no meeting of the minds on the definition of, say, fair market value, then the whole idea of a universal language for business goes out the window. And as Paul Giardina, executive vice president of marketing at software maker Cartesis, points out, global XBRL standards have yet to sync up.
Last month, however, the industry consortium pushing XBRL in the United States—cleverly called XBRL US—rolled out XBRL 2.1. That incarnation includes its latest GAAP-based taxonomies (or definitions) of financial data. Version 2.1 should give a boost to the XBRL movement in the United States. In Europe, government agencies have been pushing for the adoption of XML-based business-reporting standards. The government imprimatur, in turn, has fueled corporate interest in the standard.
In the United States, however, few government agencies have cottoned to XBRL. The Federal Deposit Insurance Corp. has announced that all call reports are to be filed in XBRL starting with the third quarter of next year. Officials there say the move will shave about 25 percent off the cost of processing the reports. It could also have a knock-on effect, with banks encouraging their corporate customers to file loan data in XBRL format.
But the Securities and Exchange Commission has been downright indifferent to XBRL. When asked about the standard, John Nestor, an SEC spokesman, would only say: “XBRL is one of the technologies we’re looking at. Each has its comparative advantages and potential disadvantages.”
Not exactly a testimonial. Some observers say the SEC may create its own XML-based standard, much as the Internal Revenue Service did. Given that prospect, it’s not surprising that few vendors have jumped on the XBRL bandwagon. Microsoft (which submits XBRL versions of its financial statements to the SEC) did include an XBRL plug-in in its latest version of Excel. And PeopleSoft’s general-ledger and global-consolidation products are capable of receiving XBRL-tagged information.
To date, however, XBRL is at the opposite end of the hype spectrum from Sarbanes-Oxley. OneSource Applink, a subscription service, is an exception: it offers clients access to an XBRL-tagged database of some 780,000 public and private companies. One customer, an insurance company, accesses the database when pricing premiums. Mark Israel, chief architect at OneSource Information Services Inc., says the insurer can price a policy in minutes rather than days.
Where It’s Headed in 2004
Paul Penler, vice chairman of XBRL US, believes it will take 6 to 12 months before makers of financial software incorporate XBRL 2.1 into their applications. The forecast is backed up by a study conducted by Penler’s group, which found that 14 of the top 21 financial-software makers already have XBRL-enabled applications or plan to have them by December 2004.
Most of those programs, however, will support only export functions. For benchmarking purposes—the true attraction of meta-data for finance executives—software vendors will need to add import capabilities to their XBRL-enabled applications. Until they do, or until the SEC or a market giant like Wal-Mart requires XBRL data from constituencies, the XML business standard will remain “a nice-to-have,” says Giardina of Cartesis.
That’s not to say XBRL won’t win some converts. Penler predicts 2004 will be the year of the XBRL-enabled earnings release. He does concede, however, that internal reporting in XBRL probably won’t take off until 2005 or 2006. And in an apparent nod to the difficulties of getting a consensus on financial standards, he notes, “It could be the end of the decade before all financial information is XBRL-enabled.”
For now, the revolution is on hold.
The Case for XBRL
Among the benefits cited by the XBRL international consortium are:
- A standards-based method for preparing, publishing (in a variety of formats), exchanging, and analyzing financial statements.
- Freely licensed.
- Benefits all users of the financial information supply chain: public and private companies, the accounting profession, regulators, analysts, the investment community, capital markets and lenders, and others.
- Does not require a company to disclose any additional information beyond that which it normally discloses under existing accounting standards.
- Reduces the need to enter financial information more than once, reducing the risk of data-entry error and eliminating the need to manually key information for various formats (print, company Web site, EDGAR filing, and so on).
- Leverages the efficiencies of the Internet by making Web browser searches more accurate and relevant. (More than 80 percent of major U.S. public companies provide some type of financial disclosure on the Internet.)