Digital Financial Reporting

Sometimes when you look at something just slightly differently a whole new world opens up. To help accountants understand the benefits of classification, I built this working prototype, remind accountings of financial reporting's conceptual framework, and explain the benefits of classification below.

Sturdy structures are built on sound foundations.  Financial reporting has a conceptual framework which serves as the foundation.  Accounting students learn about financial reporting's conceptual framework in intermediate accounting.  One part of that conceptual framework, first described by FASB's CON 6and then revised by SFAC 6, defines 10 elements of financial statements. These 10 elements are described as "the building blocks with which financial statements are constructed - the classes of items that financial statements comprise."

Yet there is no notion of classes ever referred to in the US GAAP XBRL Taxonomy. Why is that?

Why do some people refer to everything in the US GAAP XBRL Taxonomy as a "tag"? I pointed out that there are different categories of report elements in the US GAAP XBRL Taxonomy in a prior blog post: network, table, axis, member, line items, concept, abstract.

SFAC 6 points out that financial statements are made up of 10 different elements: assets, liabilities, equity, investments by owners, distributions to owners, comprehensive income, revenues, expenses, gains, losses.

Yet, you cannot go to the US GAAP XBRL Taxonomy and have a computer return all the assets.  (But you can go to iTunes and limit a search by genre.)  Wouldn't such a search capability be helpful in making use of the US GAAP XBRL Taxonomy? Certainly.  And if classification were better leveraged even more benefits would be realized.

A classification scheme is an arrangement of types or sets of things into useful groups. SFAC 6 elements are an example of such groups.  'Assets' is one group.  'Revenues' is another group.  Something cannot be both an asset and revenue.

Groups, or classes, are related to other groups. For example, the accounting equation 'assets = liabilities and equity', is an example of a relation between financial report elements.

Now, the 10 elements defined by SFAC 6 are not sufficient for the US GAAP XBRL Taxonomy, but they are a good starting point.  Assets can be broken down into current and noncurrent assets.  Liabilities can similarly be broken down by current and noncurrent.  Revenues and expenses can be broken down by operating and nonoperating.  SFAC 6 does not really address cash flows which can be broken down into operating, financing, and investing.

My poking and proding of XBRL-based public company filings revealed an initial set of 51 fundamental accounting concepts and 21 relations between those concepts.  That initial set expanded to about 71 fundamental concepts when I started to consider the different ways entities report.

So while the number of classes is certainly higher than 71, consider the 71 as perhaps a starting point.  If you look at the classes you start to notice some things.

• Some classes have lots of members such as current assets; others have only one member such as operating income (loss).
• Some classes are required to be reported such as entity registrant name; others are not required such as total noncurrent assets.
• It makes no sense to allowed certain classes to be redefined or extended; others seem to lend themselves to being redefined or extended.
• Some can perhaps have subclasses of additional detail added such as with current assets; others make no sense to have additional subclasses added such as operating income (loss).

Basically, when you group things into classes; then the patterns of each group begin to emerge.

Another significant flaw in the US GAAP XBRL Taxonomy is that for the most part the type of relation between one report element and another is exactly the same, "parent-child".  While it is true that calculations relations and definition relations do provide more information, few people understand and therefore few respect the relations.

By way of contrast, consider these sorts of rather common potential relations:

• Element-class
• Class-subClassOf
• Class-equivalentClass
• Class-sameAs
• Class-differentFrom
• Class-disjointWith
• Class-complementOf
• Class-inverseOf
• Class-unionOf
• Class-intersectionOf
• Whole-hasPart
• IsPartOf-whole

You may or may not understand the specifics of those sorts of relations. (If you want to understand relations better, this is a great overview.)  Basically it all boils down to this: the richer the information, the more machines can do for humans.

Classification is really a type of relation.  The more useful and diverse the information is about relationships between report elements, the more a machine such as a computer can do to help users of the machine.  It really is that straight forward.

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.)

I created a nifty new prototype analysis summary.  This is looking pretty good already.  Here is a test of this format using the Fortune 100.  This first list is all of the Fortune 100, a total of 38 public companies, which pass 100% of the fundamental accounting concept conformance tests: (Click on the image to go to the web page)

(Click image to go to web page)

So above you can see that all the cells are GREEN.  That means everything is OK.

Below you see cells that are RED and YELLOW.  This list of members of the Fortune 100 who have one or more issues with their digital financial report.  A total of 62 have one or more issues.

The RED cells indicate that there is some sort of issue, but I have not verified the issue manually net. The conformance tests are very good at detecting most issues.  There are a handful that are not tuned properly yet.  The YELLOW cells are issues and you can CLICK on the issue and see an explanation of the issue.  Try it out, it is pretty slick.

(Click image to go to web page)

And here is a list of all the public companies in the Fortune 100. One more thing worth pointing out.  At the top of the pages; you can click on the conformance rule code such as BS1 and navigate to a document that explains the rule and provides an analysis of entities who conform or do not conform to the rule which helps you understand the rule.

(Click image to go to web page)

Digital financial reporting is going to be so much fun!

This video is an excellent discussion of extensibility and what it takes to make extensibility work correctly.  One key takeaway is that all of the following needs to be addressed to make extensibility work:

• syntax
• vocabulary
• validity (validation)
• meaning (semantics)
• behavior

This is somewhat technical.

The primary cause of errors in XBRL-based financial filings boils down to two things:

• US GAAP XBRL Taxonomy inconsistency
• US GAAP XBRL Taxonomy ambiguity or lack of explicitness/intention

Those are the problems from the evidence that I observe.  Everything else is a symptom of those two things. These two fundamental issues causes software to be created incorrectly, causes the SEC to have to write EFM rules to overcome these issues, and unnecessary complexity and confusion for public companies having to create XBRL-based financial filings.

To understand what I am saying and how I reached this conclusion; take a look at a very simple analysis of four required disclosures: nature of business, basis of reporting, significant accounting policies, and revenue recognition policy.

You can go walk through the details of the analysis yourself.  But allow me to walk you through the big picture.  Keep in the back of your mind that a taxonomy such is supposed to be a formal, well-thought-out representation of information.

First, consider this matrix: (click on the image for a larger view)

(Click image for larger view)

In the matrix you see four required disclosures and one very, very common disclosure in the column headings: nature of business, basis of reporting, significant accounting policies, consolidation, and revenue recognition policy.

In the rows of the matrix; rows 1 to 5 provide concepts from the US GAAP XBRL Taxonomy which reporting entities can use to represent that information in their XBRL-based financial filing.  Rows 6 to 11 provide various combinations of those concepts which likewise can be used to represent that information. Rows 12 to 14 show extension concepts created by filers to represent information.

My analysis looks at how Fortune 100 companies represent this information: nature of business, basis of reporting, significant accounting policies and revenue recognition policy. Of the 100 public companies, 53 of them conform to all of what I would have expected.  That leaves 47 who do not for one reason or another.  If a reporting entity misses one detail, it is considered nonconforming.  All other reporting entities are considered conforming.  So, 53% of reporting entities get everything correct.

Consider the following terminology reconciliation:

Go back and look at the matrix.  Look at the inconsistency in the terminology the US GAAP XBRL Taxonomy uses.  There is zero reason for this sort of inconsistency.  For example, while reporting entities might refer to something as "nature of business" or "nature of operations" or "business description" or "organization" or perhaps a handful of other terms; the US GAAP XBRL Taxonomy really should be using exactly ONE term.  I happened to pick "Nature of business".  The US GAAP XBRL Taxonomy could pick some other term.  Does not matter what term.  But they should pick it and stick with that term consistently.  This may seem like a very simple thing, and it is pretty basic.  But you would be surprised of how much of this sort of inconsistency exists in the US GAAP XBRL Taxonomy and the problems that the inconsistency causes in terms of concept duplication, difficulty in using the taxonomy, general confusion, complexity, and so forth.

Secondly, the fact that a concept such as "Organization, Consolidation and Presentation of Financial Statements Disclosure and Significant Accounting Policies [Text Block]" even exists shows a fundamental flaw in the orientation of those building and maintaining the taxonomy.  That one US GAAP XBRL Taxonomy concept represents four distinct disclosures.  It may not seem like it because of the inconsistency issue.  But read the definition/documentation of that concept:

The entire disclosure for the organization, consolidation and basis of presentation of financial statements disclosure, and significant accounting policies of the reporting entity.

That is a presentation oriented view of the information reported.  This is the disclosure oriented view:

• Nature of Operations [Text Block]: The entire disclosure for the nature of an entity's business, major products or services, principal markets including location, and the relative importance of its operations in each business and the basis for the determination, including but not limited to, assets, revenues, or earnings.
• Consolidation, Policy [Policy Text Block]: Disclosure of accounting policy regarding (1) the principles it follows in consolidating or combining the separate financial statements, including the principles followed in determining the inclusion or exclusion of subsidiaries or other entities in the consolidated or combined financial statements and (2) its treatment of interests in other entities.
• Basis of Accounting [Text Block]: The entire disclosure for the basis of accounting, or basis of presentation, used to prepare the financial statements.
• Significant Accounting Policies [Text Block]: The entire disclosure for all significant accounting policies of the reporting entity.

There is zero probability that the US GAAP XBRL Taxonomy could ever provide every permutation of the combinations of possible concepts a every reporting entity could come up with.  Attempting to do so makes the taxonomy significantly more complicated and complex to make use of.  But heck, if the folks at the FASB do want to take this approach, then they should at least use consistent terminology.

It could very well be the case that it was a conscious choice to in the short term take the approach of leading public companies to believe that all possible presentational combinations would be included in the US GAAP XBRL Taxonomy.  The reality is that it is harder to describe how to use the US GAAP XBRL Taxonomy if you have to explain all these convoluted options which are available.

For example, consider this analysis of PACCAR. I am not picking on PACCAR, I just happened to pick that example.  Here is there filing so you can go to the SEC EDGAR system and look at this yourself.

PACCAR clearly provides a nature of business disclosure.  They call it "Description of Operations".  You can see it in the significant accounting policies disclosure, which PACCAR provides.  But they created an extension concept, pcar:NatureOfOperationsPolicyTextBlock, to report what should have been reported using the concept us-gaap:NatureOfOperations based on that concepts definition/documentation.  Now, a lot of filers put the nature of business information within the consolidation policy concept, us-gaap:ConsolidationPolicyTextBlock, so my algorithm to find these disclosures considers that concept. This need for a mapping causes complexity in making use of the information, and in my case here an error interpreting the reported information.  Everything else for PACCAR is fine.

Go look through the conforming and nonconforming Fortune 100 reporting entities.  You can project what you see onto the other 6900 reporting entities and the 1000 or so other disclosures.  This is a fairly straight forward disclosure requirement, their really is nothing particularly hard here.  Yet, you try to sort this out in your own mind or try to explain this to someone or otherwise determine what is correct and what is incorrect can be maddening. Simple is hard to create.  I am not saying it is easy.  But, it is necessary.

Fixing US GAAP XBRL Taxonomy issues such as these will reduce errors. Many filer errors are symptoms of the problem of inconsistency.  Other are a symptom of not being explicit, such as not providing explicity business rules preferably in a machine readable format.

Both consistency and explicit intention are things software vendors can leverage to make XBRL-based digital financial reporting easier for SEC filers.