Digital Financial Reporting

In prior blog postsI have pointed out that XBRL Formulas have some specific deficiencies. One of those deficiencies involves chaining.  XBRL Formula processors cannot do forward or backward chaining.

Well, there is a way you can achieve a similar result using XBRL Formula.  What you can do with an XBRL Formula processor is "chain" a process together.  Now, you have to put everything in the right order because XBRL Formula processors cannot do forward or backward chaining as I have pointed out.

The objective is to duplicate these fundamental accounting concept relations continuity cross checks. All of these Excel extraction tools similarly use sequential processes as opposed to forward or backward chaining.

Here is how you do that validation using XBRL Formula:

• Step 1.  You have an XBRL instance. That XBRL instance has 12 facts.
• Step 2: You feed that XBRL instance in Step 1 to an XBRL processor as input; you also provide these XBRL Formulas linkbases:
  • formula-Impute-PullFactsForward.xml(this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-EquityAttributableToNoncontrollingInterest.xml(derive the value for Equity Attributable to Noncontrolling Interest from existing information)
  • formula-Impute-NoncurrentAssets.xml(derive the value for Noncurrent Assets from existing information)
• Interim result A: You get this resulting XBRL instance.  (human readable) That XBRL instance now has 16 facts.
• Step 3: You take interim result A and use that as input; you also provide these XBRL Formula linkbases:
  • formula-Impute-PullFactsForward.xml (again, this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-Equity.xml (derive the value for Equity from existing information and previously derived information)
• Interim result B: You get this resulting XBRL instance. (human readable) That XBRL instance now has 18 facts.
• Step 4: You take the interim result B and use that as imput; you also provide these XBRL formula linkbases:
  • formula-Impute-PullFactsForward.xml (again, this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-Liabilities.xml (derives the value for Liabilities from existing information and previously derived information)
• Final result: You get this resulting XBRL instance. (human readable) That XBRL instance now has 20 facts.
• Consistency checks: You take the final result; you also provide these XBRL formula linkbases:
  • fac-formula-BSC.xml (value assertions which check the consistency of reported fact with expectations)
• Consistency checks validation result: This is the ultimate validation result in human readable form.

And there you have it! While it is true that a human has to string the rules together in the correct order and that this process is not that effecient because you have to reload XBRL instances multiple times; this process does work and so it is effective.

What this example also clearly demonstrates is that there is a use case for deriving facts that were not reported so that consistency checks can be executed.  If it is the case that information about unreported facts cannot be determined, the XBRL instance is fundamentally unusable by automated processes.  At the same time, this shows that information can be used by automated processes since you can chain the process together effectively.

I have run this or had this run through the UBmatrix and Fujitsu XBRL Formula Processors.  I am going to try and get this run through two more processors to confirm that this works consistently.

I put together this little self guided tour of XBRL-based financial reports.  If anyone has any feedback that would help make this easier or provide additional helpful information please feel free to send me comments.

Here are some key ideas to think about as you look at the XBRL-based digital financial report:

• Alternative reporting format: An XBRL-based digital financial report is an alternative to paper or "e-paper" financial reports.  In today's digital environment a digital report provide benefits.
• Case for XBRL-based digital financial reports: Benefits of XBRL-based reports include greater transparency, better capital allocation decisions, and better functioning capital markets.
• Quality matters: XBRL-based reports are not that useful if the quality of the information in the report is not high.
• Improved financial report creation processes: Not only are XBRL-based digital reports beneficial for users of information, they are also beneficial to creators of reports.  The digital nature of reports enables different processes to be used to create reports.
• Financial transformation and the modern finance platform: Improved processes will transform accounting, reporting, auditing, and analysis.
• Don't panic: Prepare yourself.
• Paradigm shift: What is occurring is a paradigm shift; not an incremental innovation.  The changes will be distuptive, maybe even foundational.  You cannot use yesterday's paradigm to understand this new paradigm.
• Computer empathy: You don't need to "learn to code".  You don't need to learn about technology.  What you need to understand is how computers really work. That is the best way to understand what is and what is not possible.

Today, Inline XBRL Viewers are pretty rudimentary in terms of functionality.  Over time that will change.

Here are some Inline XBRL files where a viewer is not used: (they basically look like normal HTML documents)

• Lorem Ipsum example
• Public company report submitted to the SEC
• 15 CAFR demonstration financial reports
• USA Facts

Here are some Inline XBRL files where a viewer IS USED:

• Lorem Ipsum example
• State Fact Book Prototype
• Public company report submitted to the SEC using the SEC's viewer
• 15 CAFR demonstration financial reports using a viewer
• GLIEF Annual Accounts (Use Google Chrome, not IE11)

What would be really nice is if someone got inspired or saw the business opportunity and created a really good Inline XBRL Viewer.  That will eventually happen.

The SEC Inline Viewer is open source I believe.  I do know you can get the source code for an Inline Viewer that is provide by the CAFR demonstration project.  Arelle also provides source code for an Inline XBRL Viewer.

You can put these four files into any Inline XBRL document and you get a very basic viewer: (these links will open in Google Chrome, not so much if you use IE)

• https://www.xbrl.org/ixbrl-samples/es6-shim.js
• https://code.jquery.com/jquery-1.12.0.min.js
• https://cdn.jsdelivr.net/interact.js/1.2.6/interact.min.js
• https://www.xbrl.org/ixbrl-samples/ixbrl-inspector.js

Using that information, maybe someone that is motivated can figure out how to create a better Inline XBRL Viewer.  If you want to do that and need some help, please let me know and I can explain some really useful functionality.  There are lots of possibilities.

==================================

People made me aware of this information related to Inline XBRL Viewers:

• XBRL International email about Workiva creating an Inline XBRL Viewer
• More from XBRL International about Workiva Inline XBRL Viewer
• Source code for Workiva Inline XBRL Viewer

Imagine a financial statement viewer that worked like this. 

This is a nicely formated report but not Inline XBRL (i.e. not machine readable).  What if that nice formatting was combined with Inline XBRL.

I put together a prototype that shows the possibilities that are enabled by XBRL-based reporting of financial and non-financial information.  The trail is being blazed by the U.S. SEC and public companies that are required to report to the SEC using the XBRL format.

What I did was run a query of the last 10-K submitted to the SEC by each of the 5,555 public companies in the set I am working with.  I exclude funds, trusts, foreign issuers, etc.  It took about 3 hours to run a query that went from XBRL document to XBRL document, extracted high-level fundamental accounting concepts from the reports, checked the information to make sure the information was right, and then put the resulting information into a database.  Then, I generated that HTML page from the database.

Of the total 5,555 10-K reports, there were 4,604 (85% of the total) reports where the information was checking out. There still seem to be some errors in the information in my HTML document.  Ultimately, the quality level needs to be 99.99966% which is Sigma Level 6.

So, how do we get to that level?  Well, part of what needs to happen is that a method for implementing a standard business report using XBRL needs to be created.  Then, professional accountants need to learn to consciously create such reports.

The case for XBRL-based general purpose financial reports is pretty straight forward.  The $64,000 question is how long will it take to get professional accountants with the program.  People tend to not like change. Accountants in particular are not known for their ability to embrace change.  But change will come.  The same technology that is causing problems like information overload are also the solution to the problem of information overload.

Here are a couple more prototypes that I put together for other purposes: (these are 10-Ks and 10-Qs that I use for evaluating the consistency of reports to high-level fundamental accounting concepts)

• Financial report core information sorted by reporting entity.
• Same information as above, but sorted by assets.
• Same information as above, but sorted by net income (loss).
• Same information as above, but sorted by net cash flow.

If you want to understand how to extract that sort of information from XBRL-based reports, see this set of Excel spreadsheets.  There are different ways to get lists of the XBRL-based reports, one is this set of RSS feeds provided by the SEC. Another is XBRL Cloud's Edgar Dashboard.

You don't have to be a programmer to create something useful.  Start fiddling around and you will become a good enough progammer to perform useful tasks.  I have been fiddling around with Excel VBA for probably 30 years.  One of the more useful things I learned was how to process XML files.  Then, I picked up what I could about XBRL.  This is not really rocket science.  The thing is, programmers don't really understand financial reproting.  Further, it would take way longer for a progammer to learn financial reporting than it would for a professional accountant that does undersand reporting to pick up programming.

If you come up with something useful or interesting please be sure to let me know about it.

You can get information about the field test of the European Single Electronic Format (ESEF) here.  This is a lot of very nice stuff to fiddle with.

More information soon!

This Taxonomy Package specification explains the format of the files the ESMA has provided.  Be aware that not all the ZIP files are in the correct format.