Please ensure Javascript is enabled for purposes of website accessibility

The SEC’s Tumultuous Love Affair with XBRL

Did the SEC commit to XBRL half-heartedly? Are they waiting for something better to come along? In the beginning, it was easy to argue yes. Fast forward 6 years and the SEC is still holding on to the XBRL — for better or worse. And, as flawed as it may be, XBRL/iXBRL looks like it is here to stay.

Going Concern last wrote about XBRL in 2011… claiming that XBRL is really happening. Recall that:

XBRL, the acronym for eXtensible Business Reporting Language, means that the data contained within financial reports is constructed as individual elements, rather than blocks of text. Each piece of data comes with an identifying tag and is linked to accounting definitions or rules. So, a number that makes up annual revenue has a different identity than a number that goes into payroll expense. The result? The data becomes “computer readable,” or interactive, so analysts, investors and regulators can easily compare one set of financial data to another.

I’m here to confirm, it did indeed happen. And, here’s an update on what we have to show for it after 6 years.

iXBRL is spicing things up

While plain-vanilla XBRL is still around, in June 2016 the SEC started allowing firms to file using inline XBRL (basically XBRL 2.0, which integrates tagging into a company’s required HTML filings rather than keeping it separate). According to a recent article PwC’s James Dreyer wrote for CFO.com:

iXBRL offers numerous specific benefits, for both public companies and users of public-company financial information. By putting this information into a single unified document, iXBRL can help companies streamline their reporting processes, decrease preparation costs, eliminate the risk of errors, and improve the quality of structured data.

The SEC’s voluntary pilot program to use iXBRL rather than XBRL will run until 2020. Then, the SEC is going to decree if the new filing format lives up to the hype of being better than ever.

Data tagging errors still exist

Unfortunately, “better than ever” is a relative term. The bar was low to begin with. In 2013, Chairman of the House Oversight Committee Rep. Darrell Issa said that as many as 1.4 million XBRL errors occurred. Even with the new and improved iXBRL to streamline tagging, errors and miscategorization may cause some headaches.

According to attorney Gary Emmanuel as quoted in Inside Counsel:

[XBRL is] a data format that has been plagued by problems since its introduction… since the XBRL exhibit is generated after the completion of the conversion process of a Word document into EDGAR format, this has resulted in discrepancies between the XBRL information and EDGAR file that slipped through the review process.

He did admit that there may be brighter days ahead, saying:

Inline XBRL allows the XBRL generation process to be conducted at the same time as conversion of the Word document into EDGAR format thereby streamlining the entire process. By incorporating XBRL into the main EDGAR document, rather than as a separate file, it is hoped that this will result in more accurate XBRL data, reduced XBRL generation costs, and a shorter EDGAR conversion process.”

iXBRL lacks oversight and assurance

Relying on XBRL/iXBRL tagged data is still iffy, after almost a decade. The idea of structured, machine-readable data from every company in the world is a glorious thought. Oh, the insight you could gather. So long as it’s accurate!

But, there’s no oversight to guarantee its accuracy. There are no required assurance services that focus on verifying the accuracy of XBRL tagging. It’s a free-for-all. For example, who cares if the independent audit report is clean when the tag for revenue is swapped with net income? Right now, no one.

Rob Blake, who helped with the early creation of XBRL, told CFO.com in late 2013 that the SEC needs to put “some teeth around really bad XBRL submissions” by punishing companies for inaccuracies. He thinks that’s really the only way to get CFOs to provide accurate data.

Sure, the blame always lands on the CFO. But, maybe, it’s the responsibility of the vendors who supply disclosure-management solutions to ensure that tagging is idiot proof? At the very least, Dreyer recommended that the CFO gets a SOC 1 from the iXBRL software vendor.

Or, maybe it’s everyone’s responsibility, at every level? Is education the only way to ensure errors don’t trickle into SEC filings? After all, the resources are readily available and the XBRL gurus (aka the Taxonomy Architecture Guidance Taskforce) even update their glossary regularly. A new glossary version was just released last week.

I guess we will have to wait and see if the SEC plans to force people to switch to iXBRL in 2020. I know, it’s a nail-biter. My guess is it will be pushed off until 2025 at least. Did I mention the SEC was half-hearted about XBRL?

Image: iStockPhoto/XtockImages