Digital Financial Reporting

This web page summarizes the conformance/nonconformance of the digital financial reports of Fortune 100 companies to a battery of tests.  The tests, or business rules, check to see if the reporting entity's XBRL-based SEC financial filing:

• Are fundamentally readable by machine-based processes.
• Conforms with fundamental relations within US GAAP.
• Conforms to Edgar Filer Manual (EFM) rules related to disclosure of Level 3 text block information and Level 4 detailed information for a set of disclosures.

The battery of tests is not a 100% complete set of all business rules necessary to prove that 100% of reported information is is issue free per the provided tests.  Rather, the battery of tests is a subset of the complete set and a good way of understanding why these business rules are necessary.

(Click image to go to web page)

This summary and information linked to the summary is an excellent resource for anyone trying to understand digital financial reporting.  It is somewhat like a dashboard of the system (partially complete).  I want to point out the following helpful features of this resource.

• Excel spreadsheet version: Click on the link or go to the upper left hand corner to download a ZIP file which contains an Excel spreadsheet which provides the same information as the web page.  The primary value of the Excel spreadsheet version is that you can filter the list of reporting entities.
• Video walk through: Click on the link to go to a YouTube video which walks you through some of the features the summary offers.
• Compare/contrast reporting entities: Every issue is backed up with detail which compares a reporting entity with every other entity in the Fortune 100 so enable you to compare/contrast how entities report the exact same information.  There is a wealth of understanding which comes from comparing/contrasting how information is reported across a set of entities.
• Details for each conforming or nonconforming item: Each cell provides precise details as to why a reporting entity conforms or does not conform to each conformance test.  In most cases commentary is provided which helps you understand the issue.  For example, click here to see how BOEING reports PPE (which is CORRECT); and here to see how BEST BUY reports PPE (ERROR, notice how the text block shows estimated useful lives of PPE, not the components of PPE like most other filers; basically BEST BUY put the wrong information into the text block)

Here is what I have learned as a result of creating this prototype:

• There are precisely identifiable reasons for each and every issue related to XBRL-based digital financial filings and errors are attributable to a specific party:
  • Concept missing from or ambiguity in US GAAP XBRL Taxonomy (i.e. FASB error)
  • Ambiguity in SEC EFM rules (i.e. SEC error)
  • Misinterpretation by filer caused by ambiguity in US GAAP XBRL Taxonomy or EFM rules  (i.e. FASB/SEC error)
  • Quality control issues on part of reporting entity creating XBRL-based digital financial report (i.e. filer error)
  • Misinterpretation of US GAAP XBRL Taxonomy and/or SEC EFM rules by my software (i.e. FASB/SEC error)
  • Errors in my mappings and impute rules used by software when reading and then using digital financial report information (i.e. my error)
• Software can be incredibly helpful in working with the structured information contained within the digital financial reports.  Note how I can take information from separate filing, put that information together using automated processes, and then use that information.  For example, take a look at this comparison of PPE component Level 3 text blocks. That comparison is trivial to create by leveraging the structured information.  That sort of comparison would need to be created manualy in the past or by using complex parsing code.
• I am starting to get a sense for the overall quality level of filings which is amazing good given the lack of machine readable business rules.  While not one of the Fortune 100 reporting entities passes 100% of my basic conformance tests,
  • 3 of the Fortune 100 pass all but 1 test
  • 41 of the Fortune 100 pass all but 2 tests
  • 90.5% of the information reported is correct, 9.5% is incorrect.  This is calculated as follows: 3200 possible issues exist (32 conformance tests X 100 entities); There are a total of 303 issues (YELLOW cells).  303 divided by 3200 = .0095 or 9.5% have issues; 3200-303=2897; 2897 divided by 3200 = .9053 or 90.5% have GREEN cells.
• There is a communications problem between public companies, the FASB, the SEC, software vendors who provide software, and business users making use of that software.  That communication problem needs to be solved for digital financial reporting to work correctly.
• Business rules shared between the public companies (who create the reports using the US GAAP XBRL Taxonomy), the FASB (who creates and maintains the US GAAP XBRL Taxonomy), the SEC (who owns the system), and software vendors (who have to build software to make all this work) will solve this problem.
• Human readable business rules are better than no business rules.  Machine readable business rules are better than human readable business rules.  However, business professionals must be able to understand the machine readable rules so they can tell you if the rules are correct.
• For digital financial reporting to "work", 100% of the reporting entities must pass 100% of business rules and business rules must be provide for 100% of reported information.
• Conformance summaries such as provided by that summary are essential to making digital financial reporting work effectively; basically the summary is a dashboard of every communications issue within the system which must be resolved.
• If the public companies, the FASB, the SEC, software vendors, and business professionals using this information do not share the same business rules the probability of the system working is reduced.

Said another way (for those who follow my blog and who remember my mantra):

The only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax rules, domain semantics rules, and workflow/process rules.

(There, that will do it...I put this in bold now people will find this easier to understand.)