Digital Financial Reporting

Here is more information related to implementing robotic finance and an updated version of my document Guide to Implementing Robotic Finance.

I think that Inline XBRL will help enable a transition from current accounting and financial report creation processes and robotic finance. In addition, there is a boatload to be learned form the Inline XBRL financial reports of public companies that have been submitted to the SEC. While it can be a challenge today to "separate the wheat from the chaff", here is why I think what I think.

First, you have to "look around" the quality issues, the information representation issues, the issues with the US GAAP XBRL Taxonomy, and other factors related to the XBRL-based financial reports that public companies submit to the SEC.  Don't let those things distract you.

If you look at the reports of public companies that don't have errors and if you look at disclosures that do not have errors there is a lot that can be learned.  There are many, many reasons why the XBRL-based reports of public companies have issues.  But there are just as many of good examples that provide excellent learning opportunities.

Second, you have to "look around" the software issues of the software vendors and filing agents that have created software to support the creation of XBRL-based financial reports.  Most have not taken a long-term view of the opportunity.  Most have built "bolt on" solutions that add to existing processes that make XBRL seem like more work rather than expose the true opportunity.  Don't let that distract you.

Third, you have to "look around" the fact that XBRL-based reports of public companies are not leveraging metadata appropriatly and the general lack of metadata.

If you don't understand what I am talking about, I would encourage you to read the document Closing the Skills Gap.  That will help you get better dialed into what is really going on.

Now, I did some experimenting with Inline XBRL (see points 1 through 6).  I am continuing that experimentation here on public company financial reports submitted to the SEC.  The prior examples where testing smaller test documents that I had created to examine specific things.  So here I am looking at the same idea of contrasting raw XBRL to Inline XBRL; but I am doing this experiment with a 10-K filed with the SEC by a public company. Here is the filing I am looking at.

1. Raw XBRL: I start here with the raw XBRL. Now, this raw XBRL was not created by the filer, it was auto-generated by the SEC.  This company submitted their report in the Inline XBRL format.
2. Inline XBRL (in Inline XBRL Viewer): This is the Inline XBRL as viewed using the SEC provided Inline XBRL viewer.
3. Inline XBRL (not in viewer):  This is the same Inline XBRL document but not viewed using the SEC Inline XBRL viewer; this is the document you would work with to extract information from the Inline XBRL using a computer based process.
4. Inline XBRL auto-generated from Raw XBRL: This is Inline XBRL that was auto-generated by XBRL Cloud from the raw XBRL auto-generated by the SEC from the Inline XBRL submitted by the filer.  This rendering is pretty readable but does have some readability issues.
5. Extraction of Facts: This is a ZIP archive that contains an Excel spreadsheet with macros that extract facts from raw XBRL or inline XBRL. The tool will extract facts from #1, #3, and #4 above. (Note that there appears to be a bug in the XBRL Could auto-generated inline XBRL.  The first two documents report 2,182 facts but the third has 1,860 facts returned.  I am looking into why this is happening.)

So the point here is that extracting information from Inline XBRL is just as easy as extracting information from Raw XBRL.  You should get the exact same results when information is queried in either syntax; which syntax you use does not impact the meaning of the information represented.

A public company financial reoprt filed as part of a 10-K is about as complex document that I can imagine.  What might be more complex is the management discussion and analysis document which is also part of an SEC 10-K but does not need to be represented using XBRL currently.

In this prior analysis I was using smaller documents than a 10-K financial report.  I did that to make creating all the business rules to verify the facts reported in the document easier.  The only difference between the documents used in the prior analysis and the 10-K financial report is the volume of disclosures.  The fact is that the smaller test documents that I used are more complex than the 10-K financial report.  Why?  Because I included some additional information patterns that are not used in the typical 10-K financial report.