Digital Financial Reporting

This blog post provides information related to the analysis of the Microsoft 2017 10-K.  This has to do with controlling the process of creating the report and analyzing information the report contains.  This is information about the report: 

• Video walking you through the analysis
• SEC filing page
• XBRL instance
• XBRL Cloud Evidence Package
• Pacioli Power Tool Analysis Package
• Rendering of Report (Autogenerated)
• Disclosure Mechanics Validation Results, XBRL Cloud (about 68 disclosures, about 50% of report)
• Disclosure Mechanics Validation Results, Pesseract (about 124 disclosures, 94.8% of report)
• Disclosure Mechanics Rules (Human Readable | Machine Readable)
• Blocks
• Flat list of statements from the report
• Extracting report information
• Knowledge Graph of Information Models

Most current prototype:

• XBRL instance with rules attached directly to the report
• Pacioli validation results for above report
• XBRL Cloud validation results for above report
• Visual image of what I mean by "pieces" (note how verification linkbases and schemas are tied to the report)
• Pacioli list of disclosures
• Pesseract list of disclosures
• More information

This XBRL-based report contains 194 sets of facts which I used to call "blocks" and now I think I call "fact sets".  For this report, I can identify 94.8% of those 194 sets of facts. This is important because (a) the rules can be used to make sure the report is created correctly and (b) the rules can be used to effectively and reliably extract information from the report.

I am comparing the Microsoft 10-K to the 10-Ks of Amazon, Apple, Facebook, Google, and Salesforce.  The primary thing I am noticing is the propencity of accountants to focus on the presentation of information which is arbitrary/subjective and the representation of information which tends to be objective.

Also, I have completely recast the Microsoft 10-K in order to be able to control some things and perform some additional testing.  You might find that helpful.

A Wired article asks the question, How Many Spreadsheets Does It Take to Run a Fortune 500 Company? The article points out that companies rely on spreadsheets to fill gaps in company systems.  The article asks the question, "Does it work?"

I say a better question is, "Is there a better way?"  Personally, I think there is a better way.  Here is a collection of blog posts related to spreadsheets:

• Great Video about the Issues with Spreadsheets
• Need for a Global Standard Spreadsheet Alternative
• Time for a New Take on the Electronic Spreadsheet
• Semantic Spreadsheet
• Updated Vision of the System
• Radically Tailorable Tool
• End-user Computing: Business Users Building Software

This is the key point in that Wired article:

The problem is that we always build enterprise software by starting with a static data model or an object model, and then we're surprised when the resulting systems are inflexible. What if we took different approach? What if we turned the problem upside down? Instead of a static data model, we build services around a Modeling Engine that is purpose built to change dynamically.

What I am calling a semantic spreadsheet is not totally flexible like an electronic spreadsheet.  It is flexible exactly where you need flexibility, but no where else. For example, if you tried to express a balance sheet in an Excel spreadsheet you can absolutely create a balance sheet because you have 100% control, to the extent that Microsoft Excel has features, therefore you have that same level of flexibility. 

But that is not what a business user needs to create a balance sheet.  Business uses don't need infinite flexibility to mask the reality that the electronic spreadsheet does not understand balance sheets, what business users need is for the application to understand balance sheets!  The spreadsheet needs to understand that a balance sheet has "assets", it has "liabilities", it has "equity", that "assets = liabilities + equity", that assets can be current and noncurrent, and that property, plant and equipment is a noncurrent asset.

The business user interacts with the balance sheet model, not the raw electronic spreadsheet model.  The raw electronic spreadsheet model knows nothing about balance sheets, that causes the following: (a) the user of the electronic spreadsheet needs to know more about balance sheets and (b) the electronic spreadsheet has to be overly flexible because it does not understand what you can and cannot do when you create a balance sheet.

How the heck do you get an application to understand a balance sheet?  Machine readable metadata.  You define "things" such as assets, liabilities, equity, current assets, noncurrent assets, etc.  You define "relations between things" such as "assets = liabilities + equity".  You do this for every disclosure.

Sound like a lot of work?  It is a lot of work.  The US GAAP XBRL Taxonomy is a huge step in this direction.  But what is even better is all the balance sheets and other disclosures submitted to the SEC by public companies in the form of digital financial reports.  I don't want to go into details here, just know that it is not as much work as it might seem.

First, it is create once, use many times.  Second, it is way more effective and efficient for a computer to manage as much of this complex process as possible rather than rely on humans who make mistakes, who change jobs, and who are expensive.  Humans will certainly be necessary, but machines will be able to assist humans.

So you will not only be working with a modeling engine, you will be working with a financial report modeling engine.  Don't understand all this?  Go read the Financial Report Semantics and Dynamics Theory. That proves that SEC XBRL financial filings fit into a model.

There will be other types of modeling engines: not-for-profit financial report modeling engine, state and local governmental financial report modeling engine, pension plan financial report modeling engine, expense report modeling engine, purchase order modeling engine, and so forth.  Purpose built and specific driven by machine readable metadata, not infinitely flexible electronic spreadsheets.

Think of this as radically tailorable software, business users configuring software using metadata.

Prudence dictates that using financial information in SEC XBRL financial filings should not be a guessing game. Safe, reliable, predictable, automated reuse of reported financial information seems preferable.

So, how is safe, reliable, predictable, automated reuse of reported financial information achieved?

SEC EDGAR Filer Manual (EFM) rules are only the beginning of what is necessary for investors, analysts, and others to use this information.  EFM rules are necessary, but they are not sufficient.

For a number of years I have been poking and prodding SEC XBRL financial filings to understand how to construct XBRL taxonomies within systems that allow extensibility. A byproduct of that poking and prodding is an understanding of what causes information contained in SEC XBRL financial filings to be ambiguous, to not be decipherable by automated computer processes, to yield "red flags" which indicate the information may not be trustworthy to automated computer processes; basically what causes reported information to be unusable by automated processes.

Or stating this another way: there is a set of minimum criteria which are necessary for making use of information contained in SEC XBRL financial filings.  This is that set of seven criteria.  These criteria state the goal or desired/necessary state, a process which can be used to test that goal, and the current state of SEC XBRL financial filings toward satisfying that goal or desired state:

Click image to view larger version

To be clear, meeting these seven criteria does not mean that all information in an SEC XBRL financial filing would be usable. These seven criteria are necessaryfor safe, reliable, predictable automated reuse of any information at all. But meeting these seven criteria is not sufficient for making use of all information reported in an SEC XBRL financial filing.

An interesting thing about these criteria is the current state of SEC XBRL financial filings in meeting the criteria.  Today, SEC XBRL financial filings satisfy between the low of 85.9% for criteria #7 to a high of 99.9% for criteria #1.

And so, this is my set of minimum criteria which I will be using to evaluate the set of 10-K financial filings submitted to the SEC for 2013.  My analysis of 7,160 SEC XBRL financial filings for last year helped me arrive at these seven criteria.

Are these criteria fair?  I believe they are fair.  What do you think?  None of these criteria are subjective, all are objective.  All are automatable.  There has not been one accountant that I have talked to who has articulated specific objection to the criteria.

The proof is in the pudding as is said.  No one that I am aware of has shown successful use of basic financial information within SEC XBRL financial filings.  And I mean 100% automated reuse without the need for manually adjusting information or writing special algorithms to handle special situations.  I mean 100% automated reuse.

And I am not even saying that all my rules are 100% correct.  You can see the results that I get, note the current state percentages.  Don't think my rules/criteria are correct?  I will take any suggestions which result in improved success rates.  Again, this is not subjective and this should not be a guessing game.  There are exactly three moving pieces here:

1. The SEC XBRL financial filings.
2. The rules or criteria.
3. The software algorithm for making use of information.

The goal is simple: 100% success for each criteria.  Change the filing, change the rules, or change the software algorithm.  Pretty straight forward.  The goal is system equilibrium.

So far there are approximately 1,000 SEC XBRL financial filings, or about 20% of total filings which pass all seven criteria.  Most SEC XBRL filers pass the vast majority but they don't pass all.  For all those that do not pass, the exact reason they do not pass can be seen in their SEC XBRL financial filing. Whether the filing should be changed, whether the rule/criteria should be changed, or whether the software algorithm should be changed can be somewhat subjective.  Let me remind you:

Prudence dictates that using financial information in SEC XBRL financial filings should not be a guessing game. Safe, reliable, predictable, automated reuse of reported financial information seems preferable.

I am going to update all my information shortly after February 28th, the end of the 10-K season for most filers for fiscal year 2013.

If you have objective information which proves or disproves these criteria or if you have a better way of evaluating SEC XBRL financial filings or a more successful way of reusing reported financial information it would be great to hear your comments.

In my last blog post I pointed out a set of fundamental accounting relations which exists for all financial statements.  These relations focused on the primary financial statements.  This blog post expands on that idea.

So, I created a form in an analysis application which I had and put all these high-level concepts on that form.  You can see a screen shot of that below (click on the image below to get a larger image):

Fundamental accounting relations

Within the analysis tool which I created using Microsoft Access, I both hooked all these concepts together and I also put in check values to be sure the relations were correct.

Now, granted, not one SEC filer reports every one of the totals or line items that I provide for.  For example, if a reporting entity does not have an equity method investment, it is not going to have "Income from equity method investments" and it will not report the concept "Income before equity method investments".  So the line items which they do show depends on the line items which they have and therefore report.

However, that does not change where "Income from equity method investments" WOULD go.  I just provide all these placeholders.  Accountants creating a financial statement cannot move this stuff around.  For example, an accountant simply cannot include "Income from equity method investments" within Gross Profit, Nonoperating income (loss); there is exactly one appropriate spot for that line item.

There are only two areas of this set of concepts that I am having slight problems fitting the puzzle pieces together.  The first is the line items which make up "Operating income (loss)". There is such a wide variety of line items and subtotals provided that this is a bit of a challenge.  There is also one significant error that about 50 SEC filers make.  What the filers do is take the concept "Interest and Debt Expense" which is basically a category of expenses and "repurposing it" (in my view misusing it) as a line item within a different category, "Nonoperating income (expense)".  That is like using the concept "Assets" within the liabilities section of a balance sheet.  And so this area is a bit challenging.

Another area where this model does not quite work correctly is the cash flow statement and the placement of "Exchange gains (losses)" in that statement.  There are two different approaches SEC filers take. The first approach includes the exchange gains (losses) within the computation of "Net cash flow", contributing to that total.  Well over 98% of SEC filers use this approach.  A small minority of SEC filers include "Exchange gains (losses)" within the roll forward of the cash and cash equivalents beginning and ending balance.  I have pointed out this issue previously.  Some accountants I talk to consider this an error on the part of the filers in creating their financial reports.  Others acknowledge an ambiguity within US GAAP which could lead to this second interpretation used by the minority of SEC filers.  There is no real business reason for having two approaches to where this line item should show up.  OK, so that means there are two possible representations for that particular line item.  Fine.  That does not break the idea of the existence of these fundamental accounting relations.

And so there really is not just one representation.  If a reporting entity provides an unclassified balance sheet, they won't report current assets or liabilities.  No big deal, just a slightly different representation.  Same thing for whether a filer provides a single-step or multi-step income statement.  That does not change every fundamental relation, it only changes a small handful.  Likewise if a filer reports using net assets instead of equity, like a small number of SEC filers do.  These are all just minor adjustments to this underlying representation, it does not break the representation.

Another thing that I did was provide a wiki page which captures the concepts and relations which I am using.  You can get to these fundamental accounting relations here.  If you have any other relations which you want to add, go for it.  If there are any that you disagree with, post a comment to the discussion page.

Thus far, no one has made a sensible argument against any of these relations.  Also, the SEC filings that I have support the existence of these relations.  Again, not every SEC filer has all of these relations; but there is not one SEC filing that I have seen which leads me to believe that I have any of these relations incorrect.

I mentioned the WebFilings Taxonomy Analyzer before, but it is worth mentioning again because now you no longer need to log in to use it.

Very useful!