Digital Financial Reporting

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.

Steve Hoberman who is an expert in data modeling created an excellent video, Data Modeler of 2020, which discusses the future of data modeling.  The video points out considerations which is applicable to digital financial reporting.  The primary thing the video shows is that there are new trends in working with data/information which are replacing current techniques and data modelers need to adapt.

Steve's 40 minute video is worth watching.  In the video Steve goes through 5 adaptations which a data modeler should consider.  Those adaptations are summarized here:

• Become a data structure scientist (others seem to use the term knowledge engineer rather than data structure scientist)
• Ride the wave caused by the perfect storm (agile + cloud + big data)
• Learn a graph or document database
• Master a fact-based modeling (FBM) dialect (others use the term object role modeling (ORM); XBRL and OWL are fact-based modeling tools)
• Build and maintain an enterprise logical data model (LDM) (taxonomy, ontology, or some other highly-expressive information modeling approach)

It is slow going, but progress is being made toward achieving an RDF/OWL representation of a financial report. If you are interested in this you may want to follow the Semantic XBRL group on LinkedIn.  Here is information helpful to this process.

1. Financial report in XBRL: This is what I call a reference implementationof a SEC-type XBRL-based financial report.  To convert the XBRL technical syntax to OWL, the first step is to convert the XBRL technical syntax to the semantics of the report.
2. Semantics of financial report (Model Structure and Fact Table):  The XBRL instance and XBRL Taxonomy are converted from a syntactic representation into a semantic representation.  There are two primary parts: the model structure which articulates the relations between the pieces of a report and the fact table which is the information contained in the financial report.  Here are human readable versions of the model structure and fact tables.
3. Initial target, the fact table:  While there is really a lot that needs to be converted to OWL in addition to the model structure and fact tables, such as business rules; but the initial conversion target is just the fact table.  Once that is done, other parts can be built out in OWL.  To help visualize this, I wrote an Excel macro which imported the fact table. So this is the information which should be converted to RDF/OWL expressed in Excel (within a ZIP archive).
4. TopQuadrant "table" model:  If you look at the Excel spreadsheet in #3, you will notice that the fact tables of a financial report fit nicely into an Excel spreadsheet.  TopQuadrant built a little OWL ontology that can be used to represent information that fits into a spreadsheet.  Here is that OWL ontology.
5. Initial attempt at RDF:  This is an initial attempt at getting the fact table information into the proper RDF/OWL format. This is pitiful I know, but it is progress.
6. Semantics of a financial report:  This is the most succinct explanation of the semantics of a financial report that I have at this point: Understanding the Mechanics of an SEC-type XBRL-based Digital Financial Report.  I know it is probably not suscint enough yet, but it is getting where it needs to be.
7. Key semantics and spreadsheet analogy:  So this is my thinking. Just like a Workbook has spreadsheets, spreadsheets have rows, and rows have columns in the TopQuadrant representation; in a financial report a report has components (similar to how workbook has sheets), components have facts (similar to how spreadsheets have rows), and fact has aspects (similar to how rows have columns).

Perhaps it is misguided, but that is my thinking.  Got a better idea?  Post it to the Semantic XBRL group.