Digital Financial Reporting

I explained generally what the fundamental accounting concepts and relations between concepts are in another blog post.

In this blog post I will walk you through the specifics of how they work.

I will use this Microsoft Filing submitted last Friday in the walk through. Microsoft uses the most common reporting style which I gave the report frame code COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6. There are about 2,174 other public companies that use that reporting style. Microsoft is # 1,238 on that list.  Their reporting style is one of about 180 different reporting styles. (Here is a web service which tells you which report frame code companies use.)

Step #1 is to read the XBRL instance document using some software application.  I created an Excel spreadsheet that reads this information. This publicly available Excel application reads information for a different reporting style, interest-based reporting, but by looking at the code you can see specifically how the process works.

Step #2 is to use the mapping information to find the reported facts that you are looking for. What I mean is that not every public company uses the same concept to report the same information.  For example, the line item "Revenues" can be reported using many different concepts.  Here is the mapping information for each of the 2,174 public companies, including Microsoft, that use the COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6 reporting style.

If you look through the mapping file you might ask yourself the question, "Are all these concepts necessary?"  That is for the financial reporting supply chain to determine.  Based on the existing rules imposed by the SEC and the way the US GAAP Financial Reporting XBRL Taxonomy works, this is what is necessary today.

This file shows what XBRL Cloud calls a "trace file".  If you look at the top of this trace file you can see the processor look through the XBRL instance trying to find the concepts the fundamental accounting concept relations validation process is looking for.

Step #3 then starts after you read all the concepts you are looking for and you get an explicit list of concepts that were reported.  But not every public company reports every specific line item.  For example, not every reporting entity report concepts such as "Noncurrent assets" or "Noncurrent liabilities" or "Operating income (loss)" explicitly.  Why?  The accounting rules do not require each of the fundamental accounting concepts to be explicitly reported.  And therefore, you use the rules of formal logic and deductive reasoning to deduct or impute information from other information that has been reported.

For example, while the fact for the concept "Noncurrent assets" might not be explicitly reported, facts for "Assets" and "Current Assets" are generally reported.  We also know that "Assets = Current Assets + Noncurrent Assets".  Using the properties of mathematics, you know that you can change that equation to the equivalent true equation, "Noncurrent Assets = Assets - Current Assets".  So, we look for "Current Assets" and "Assets" and try and figure out what the fact value of "Noncurrent Assets" is.  Pure deductive reasoning which a computer can do quite nicely.

These reasoning rules are articulated in machine readable form here for the specific reporting style of Microsoft and others that use that style.  (Remember, that is the old format, the new rule format is better.)

And so you then impute all the information that you can impute.

Step #4 starts after you have all the explicitly reported information and imputed information that you deduced based on other information.  You use all of this information to see if the pieces of information make sense relative to one another. Here is a list of these consistency check rules to make sure the set of information makes sense.

Now think about something.  How could you possibly go grab a piece of information from an XBRL-based digital financial report without knowing one of two things: (a) if information you grab is the correct piece of information relative to other information and (b) if the value of the information is correct.  How do you know this without checking to be sure it is true?  This is particularly true now with all the information quality issues in public company XBRL-based financial filings.

Here is the consistency check information for the Microsoft filing, all the information checks out correctly:

(Click image for larger view)

And so, because of the consistency checks, we know that we can safely work with these basic, fundamental financial report line items.  Could you work with OTHER information in a report if this basic, fundamental information was not consistent?  No, the information would not be trustworthy.

STEP #5 ties everything together in a tidy little package.  Below you see the Microsoft information that was explicitly grabbed from the financial report and information derived from other explicitly reported information so that our set of information is complete and all the information we are using is consistent with what we expect relative to other information.

(Click image for larger view)

Note that in the graphic above, the GREEN color information was explicitly reported and the ORANGE color information was imputed. About half of the information was imputed from other information.

One might ask the question, "Isn't it safer to simply report all of the information rather than try and imply certain line items?"  While that might be true, that is not how US GAAP based reporting works today.  There is no specific requirement that every important line item is reported.  While most public company do report all of these line items, others do not.  This is a topic which I will dig into in another blog post.

So that is specifically how the fundamental accounting concept relations work.  The vast, vast majority of XBRL-based public company financial reports are consistent with all the mappings, impute rules, and consistency check rules; 98.73% to be precise.  There are about 1,800 specific facts that are not consistent with my set of fundamental accounting concept relations, the vast majority of those have specific filer errors which have been manually observed.  I predict that within 6 months, the number of inconsistencies will drop to less than 1,000.