What can a financial controller do to make XBRL work better

4th April 2013

Thousands of smaller US public companies will tag data in their annual reports for the first time this year. But getting it right may not be easy, as FSN writer Lesley Meall discovers.

 

 

 

The eXtensible Business Reporting Language better known as XBRL has always been an emotive subject for finance professionals - even before the world’s regulators started mandating its use. CFO descriptions of it range from the derogatory “money-sucking compliance monster” to the more positive “financial accounting on steroids”. Businesses have struggled to realise the potential of XBRL – to improve internal reporting and/or communication with investors and analysts – and as more companies are forced to adopt it, the noise from (well-meaning) evangelists seems to be drowned out by rumblings of discontent – not least in the United States (US). 

In November 2012 when Financial Executives International held a conference in New York it asked a round table of chief accounting officers and controllers if they thought that the XBRL process added value. The response, a resounding ‘No!’, came from experienced XBRL filers including Susan Grafton (of Best Buy), Stephen Cosgrove (of Johnson & Johnson) and Nick Cyprus (of General Motors). One of them described XBRL as “causing a lot more costs than it is worth”, and even attributed many of the delays and errors that result in amended quarterly (10QA) reports to XBRL problems. 

It wasn’t meant to be this way. When US CPA Charles Hoffman came up with the idea that led to XBRL, it was expected to benefit businesses in all areas of internal and external reporting and analysis; now it’s just another compliance burden. “Most businesses use of XBRL is compliance-driven,” says Jonathan Cobb, tax technology director, KPMG. As ‘use-case’ taxonomies (such as US GAAP) are used to define XBRL tags, and the software to produce tagged compliance reports cannot generally be used to improve internal reporting, exploiting XBRL for the latter is challenging. 

Learning from your mistakes

Since 2009, taking a three year phased approach, the US Securities and Exchange Commission (SEC) has mandated progressively more companies to apply XBRL tags to quarterly (10Q) and annual filings (10K) and during 2013 many smaller registrants will be doing the latter for the first time. It isn’t easy to fit corporate financial data from unique financial statements into a standardised set of tags, using the 15,000 elements available in the US GAAP taxonomy – and the SEC has acknowledged that the learning curve is steep. 

Since the largest public companies began submitting XBRL, the SEC has collected 35 million financial facts in 63,000 separate filings by 10,000 filers, but it is only just starting (in 2013) to scrutinise the detail-tagged 10Ks from approximately 7,000 public companies, (about 80 percent of all filers). Even so, it has already found plenty of common and very simple mistakes: more detail on these is available in its observations and it recently updated its useful (and extensive) FAQ on interactive data disclosures here.   

XBRL US (the non-profit behind XBRL business reporting standards in the US) has done some detailed analysis. It has looked at 57,057 XBRL filings by 9,134 companies and found 899,000 data issues and errors, and it has produced a white paper Avoiding Common Errors in XBRL Creation which is available here. During 2013, the Financial Accounting Standards Board has also issued a number of implementation guides for XBRL, focusing on areas such as segmental reporting and subsequent event disclosures, and it has published a reference guide – all here. 

Getting XBRL filing correct can be a slow process. According to Campbell Pryde, president of XBRL US, it takes around two and a half years for companies to get their data quality issues sorted out. Fortunately, smaller companies now filing for the first time will have some time to get it right. Their liability is limited for inaccurate and misleading XBRL filings for a period (as was the case with earlier XBRL filers) under SEC Rule 406T (b)(2), but as this provision ends on October 31 2014 all reporting companies may want to focus on the quality of their tagging. 

“Ensuring accuracy of XBRL filings with the SEC is gaining traction with the end of the limited liability clause,” says Sneha Rajagopal, VP of XBRL services at Data Tracks (which offers various XBRL services). “Companies should review the tags used, validate the document for completeness and structure, independently,” he suggests, whether they are building their XBRL-tagged documents in-house or some of all of the process is being outsourced to an XBRL service provider, document management vendor or financial printer. 

Meanwhile, if you who want to explore the non-compliance potential of XBRL you might appreciate XBRL- why bother by Emily Huang, one of the founders of Rivet Software, a vendor that focuses on both the creation and consumption of XBRL. She observes that many of the US companies that don’t find XBRL useful are also companies that have taken the document management or financial printer route to compliance. So maybe XBRL has become a compliance nightmare rather than a financial reporting dream because financial controllers lack vision. Maybe not.

OTHER NEWS

SECTORS

CATEGORIES