« Awesome Renderings of Public Company Financial Information | Main | Data Modeler of 2020: Adaptations Data Modelers Should Consider »

Financial Reporting Supply Chain: Stop Making the SEC the Scapegoat

Merrill posted a good article on their blog, Adoption and Use of XBRL in SEC Financial Disclosure and Regulation.  The article is an interview with Hudson Hollister, executive director of the Data Transparency Coalition.

This is Merrill's summary of the article:

The SEC’s adoption of XBRL for financial disclosure and regulation is part of a wider movement to shift US government information from documents to structured, searchable data. To get a sense of where the SEC’s commitment to XBRL use now stands, Dimensions spoke by telephone with one of structured data’s leading proponents, Hudson Hollister. As the founder and executive director of the Data Transparency Coalition (DTC), Mr. Hollister leads an alliance of organizations trying to persuade policymakers to adopt structured data for the collection, storage, and use of information by all areas of the federal government. Before founding the Coalition, he served as counsel to the Committee on Oversight and Government Reform in the US House of Representatives and as an Attorney Fellow in the Office of Interactive Disclosure at the SEC.

One of the questions asked in this interview was, "What is your assessment of the SEC’s approach to XBRL adoption?"  Mr. Hollister's answer:

"So far, the SEC’s adoption of XBRL, six years ago, has been a failure. Now, I would not call it an unmitigated failure. Certainly, private-sector innovators such as Calcbench have shown that, despite its quality problems, XBRL-tagged information can still be made very valuable and useful to investors."

I disagree with Mr. Hollister's assessment. If anyone failed, it is the entire financial reporting supply chain.  In particular, it is the member of XBRL International that sold the SEC a bill of goods and did not follow through and deliver what was promised.  Besides, I don't think this is a failure.  Yet.

When NASA put a man on the moon, a lot of rockets blew up on the launch pad in the process.  Converting from the current document-oriented disclosures of unstructured information which has been in place for almost a hundred years to a data-oriented disclosure of structured information will be a process.

Contrast what the SEC is doing with XBRL-based public company financial reporting with what the health care industry is doing with electronic medical records.  NPR (National Public Radio) has a story, Sharing Patient Records Is Still A Digital Dilemma For Doctors, about the problems with electronic medical records systems talking with one another.  In that story the following statements are made:

"…most electronic medical records systems can't talk to one another…"
"…cash for clunkers bill…"
"…get the systems in…next thing is to get the systems to talk to each other…"
"…we need to be working of the same standard…"
"…we know how magical it can be…."

There are a lot of parallels between electronic medical records and digital financial reporting.  Both are part of an even bigger reality for business professionals: things are going digital and business professionals are going to have to change some things about how they work.

Business professionals are having a hard time understanding that they are in charge of "going digital" and that they need to make things work the way they want and need things to work.  That means business professionals need to understand their role in making this work.  See this document which I am starting to call Knowledge Engineering 101 for Business Professionals.

I have mentioned this before but I think XBRL-based public company financial filings to the SEC is way, way ahead of electronic medical records.  The SEC has gone through the "get the systems in…" phase and now needs to go through the "…get the systems to talk to each other…" phase.

Does XBRL-based digital financial reporting of public companies to the SEC work perfectly?  No.  Far from it.  However, XBRL technical syntax interoperability is 99.99%.  Fundamental financial reporting semantics consistency is 98% over all, but only about 55% of all public companies meet all of these basic consistency constraints.  That needs to be improved and there are specific measurements which can be made to track progress toward success.  The disclosures are likely in similar condition.

But this is in no way a failure.  Yet.  This can only be considered a failure if the SEC is not learning anything.  I think they are learning plenty.  The truth be known, no one involved (including XBRL International, AICPA, FASB, XBRL-US, SEC, creation tool software vendors, data aggregators) in the process of getting XBRL-based digital financial reporting up and running for the SEC completely understood all of the moving pieces of the puzzle.  Me among them.  I knew a lot, but when we created the US GAAP XBRL Taxonomy Architecture, we did not know everything we needed to know.  That is easy to see now.

Did the SEC make mistakes?  That is hard to say.  Christopher Cox took advantage of a situation and got the SEC to mandate XBRL, probably too quickly.  But here we are.

And here is the deal:  the world has changed.  We now have thousands of XBRL-based public company digital financial reports that have been filed with the SEC to look at.  That is important information which is extremely helpful in figuring out how the supply change wants digital financial reporting to work.  This empirical evidence will show the financial reporting supply chain how to make digital financial reporting work.

Don't be naive.  The world is going digital.  Financial reports need to go digital.  Stop making the SEC the scapegoat and do what you said you would do XBRL International Members; make XBRL work.  Merrill is pointing the finger at the SEC when only about half of the filings they create meet even basic consistency checks?  This is not a failure yet, but if the AICPA and other XBRL International members who got the SEC into this situation don't contribute to fixing the issues and show some leadership with regard to digital financial reporting, then yes; what the SEC is trying to achieve with XBRL (exactly what XBRL International wanted the SEC to do) will likely fail and the SEC will try some other technology.

Further, digital financial reporting is not about the 8,000 public companies who report to the SEC.  There are another 28 million private companies who need digital financial reporting and it needs to work significantly better than what public companies are experiencing.  Otherwise, why should private companies have any interest in a technology which just adds more work for them? If implemented properly, XBRL-based digital financial reporting can save time and money and increase quality.

I would be the first to say that if XBRL-based digital financial reporting cannot be made to work correctly then some other approach should be used for digital financial reporting.  A financial report is an important document and it needs to work.  As I have said before,

Prudence dictates that using financial information from a digital general purpose financial report should not be a guessing game. It is only through conscious effort that the specific control mechanisms can be put in place to realize this intent.  The system that works safely, reliably, predictably, repeatedly, effectively, and efficiently is the desired goal.

All this said, it still seems that financial reporting is leading the way to the semantic web.  XBRL-based financial reporting and electronic medical records are just part of a much more significant trend: going digital.  Business professionals are going to need to adapt.  Rather than forcing a government bureaucrat to dictate what digital financial reporting will look like, it is better for the financial reporting supply chain to figure this out and help the SEC make it work correctly.  Collaboration and cooperation with the SEC is what is necessary.

Posted on Friday, March 20, 2015 at 06:54AM by Registered CommenterCharlie in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.