Digital Financial Reporting

(This is the final installment in a 3 part discussion related to digitizing disclosures.  In Part 1 I explained how a digital financial report is lots of little pieces which fit together.  In Part 2 I explained the bigger picture, why digitize financial reports.  In this final part I look at the details of what it takes to "digitize a disclosure". Specifically, I show exactly how disclosures are digitized, how business rules help quality, and how to create an automated digital version of a disclosure checklist.)

There are a few things which are important to have in your mind for this discussion.  First, you need to understand that:

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.

Second, as can be seen from this graphic and as discussed in Part 2,

The stronger the semantics, the higher the reasoning capacity which a machine can achieve; the more reasoning capacity which can be achieved the more a machine such as a computer can do for its user.

Third,

Humans are expensive and make mistakes (i.e. humans are not machines), computers are cheaper and don't make mistakes, computers are machines. Enabling a computer to automate tasks, to be used as a tool, has advantages.

This has nothing to do with magic and this is not about computers taking over the world and doing everything.  That cannot happen.  This is about recognizing that there are some things that computers can do better than humans, there are some things that computers can never do, and recognizing the difference between the two and figuring out how to use the computer as a tool correctly and appropriately.

Don't judge how people are employing XBRL today as how to leverage XBRL.  Pretty much software vendor who implemented XBRL in software has done so considering only the short term needs to get something to the SEC.  Software vendors have made two fundamental mistakes.  First, they simply "bolted on" the creation of XBRL to the end of some existing process.  That serves the immediate need to comply with the SEC mandate to supply XBRL.  The quality of the XBRL is nowhere close to where it needs to be, but the software vendors enabled public companies to comply with the SEC mandate to supply XBRL.

The second mistake software vendors made is to provide what amounts to XBRL technical syntax editors, not digital financial reporting tools.

Eventually, digital financial reporting will change the work practices of accountants significantly. Accountants will harness the power of computers, when they get the right software.  Lots of people complain about how labor intensive the "last mile" of financial reporting is. Lots of people are pushing disclosure management. These are signs of change.

This is what I mean.  Consider this digital disclosure checklist framework which I put together. That framework outlines 23 sets of rules which are pretty hard to dispute.  Basically, for a digital financial report such as an SEC XBRL financial filing to be correct, all these rules must be satisfied.  Are there more?  Probably.  But no one satisfies even these business rules currently.

In the paper, Understanding Minimum Processing Steps for Effective Use of SEC XBRL Financial Filing Information, my co-author and I point out what I have converted to the first eight GREEN diamonds in the left hand column of that framework.  The diamonds are GREEN because I have actually implemented those tests to check SEC XBRL financial filings.  Those results are summarized here, Summary Information from Evaluating SEC XBRL Financial Filings Against Minimum Criteria.

Now, the GRAY diamonds on the right hand side are things that can only be checked manually.  No way that I can see to automate those.  Now, you can use the automation results to help in the process of doing those manual checks, but only a human can tell you if a financial report is a "true and fair representation of financial information."

That leaves the stuff in the middle, the YELLOW diamonds.

What I want to show is that these validation rules are not the nuisance that they seem to be.  They are a nuisance if you don't have software at your disposal which understands the rules; software which can help you to not make mistakes.  You see, the business rules are two sides of the same coin.  They can be used to validate that digital financial reports are created correctly, but they can also help you create them correctly and even guide you through the financial report creation process.

This may sound odd, but let me walk you through this using the first two YELLOW diamonds which are steps in the digital disclosure checklist framework.  These are the two:

• Required disclosures are discovered
• Each Level 3 (text block) and Level 4 (detail) disclosure match

This first step is easy, "Required disclosures are discovered".  All you need to do is somehow express in machine readable form that a disclosure is required.  I did that using XBRL as follows.  First, I define an arcrole which is documented on this wiki

Financial report-requires disclosure: Indicates that a financial report (full) is always required to contain a specific disclosure (hasPart). This disclosure MUST always be present. For example, a financial report for a commercial and industrial company requires a balance sheet.

Second, I express that arcrole using the XBRL technical syntax rules.  You can find the arcrole here. You may or may not be able to read that XML, but a computer can.  That is why the wiki documentation exists, for humans.

Third, you express the rules for every required disclosure in machine readable form also.  This blog post shows how that is done using XBRL definition relations.  Go back and look at that wiki, read through the other defined rules.  Am I missing any?  Most likely I am missing some.  Fine, I will add them as I realize they are missing.

The second item, "Each Level 3 (text block) and Level 4 (detail) disclosure match" provides even more insight.  If you read this blog post, Mind Boggling Diversity of SEC XBRL Financial Filings, and specifically look at the diversity of the long-lived assets by geographic area disclosure analysis, you start to see how business rules can guide a use toward making the right choices, even proactively helping the business user (if you understand how computer work).

Consider this pseudo code:

• Long-lived assets by geographic area disclosure - REQUIRES TABLE- us-gaap:ScheduleOfSegmentReportingInformationBySegmentTable
• Long-lived assets by geographic area disclosure - REQUIRES AXIS- us-gaap:StatementGeographicalAxis
• Long-lived assets by geographic area disclosure - REQUIRES CONCEPT - us-gaap:NoncurrentAssets
• Concept us-gaap:NoncurrentAssets - ALLOWS ALTERNATIVE CONCEPT - us-gaap:PropertyPlantAndEquipmentNet
• Long-lived assets by geographic area disclosure (i.e. a Level 4 detail disclosure) - HAS EQUIVALENT LEVEL 3 TEXT BLOCK - us-gaap:LongLivedAssetsByGeographicAreasTableTextBlock

Now, consider having those sorts of rule for EVERY DISCLOSURE!  First you have to give a name to every disclsoure so you can refer to it.  Here is that list (prototype).  That list has 221 examples which I am testing with software right now.  This list has more disclosures, but these are less built out. And here is the complete list organized by topic.

You may want to go back and read Part 1 and Part 2 of this series again.

Now, if you had rules for every one of those categories in that digital disclosure checklist, that is a lot of rules.  Well, considering that a manual "disclosure checklist" alone commonly has several hundred pages, the number of rules will be huge.

Managing all these business rules is a topic of discussion for another day.  But I will tell you that you don't want to do what most people do and hire technical people to hard code these rules into software.  Business users need to control these rules. Be sure to stay tuned for that discussion.

Looking at individual SEC XBRL financial filings is helpful. Looking across many, many SEC XBRL financial filings with a focus on one specific aspect is likewise beneficial.  Carefully and consciously comparing and contrasting many SEC XBRL financial filings helps one build a mosaic, increasing ones understanding even more. This helps one see and understand important and insightful patterns within those financial filings.

As part of something else that I am doing I have created a handful of analysis of SEC XBRL financial filings to see how different economic entities report specific disclosures.

As part of this analysis, I am seeing some interesting and pretty clear patterns.  One of the patterns that I see is three specific reasons for let us just say "mind boggling diversity" within SEC XBRL financial filings.  Here are the three reasons I see for this mind boggling diversity:

1. Properly functioning US GAAP XBRL taxonomy: If you look at the property, plant and equipment by type roll up, you will notice a very high level of consistency between the Level 3 [Text Block] and the Level 4 detailed concept used to express that disclosure.  SEC filers are able to find the correct concepts and they are applying the concepts consistently for the most part.  One very interesting thing that you see is that of the 37 financial reports analyzed, 35 of the are reporting "PPE, NET" and 2 are reporting "PPE, GROSS" for the exact same disclosure.  What is expected from the [Text Block], the same concept to be used for the detail disclosure?  Or, might there be a missing [Text Block] if a filer discloses GROSS rather than NET?
2. Filers having issues in some specific areas of US GAAP XBRL Taxonomy: If you have a look at the accounts receivable roll up, you start to see some issues reporting entities have with finding the correct concepts.  Another interesting thing that you see is that some [Text Block]s don't differentiate between "current" and "noncurrent".  Does that mean that there is a missing [Text Block]?  Or, does that mean that [Text Block]s can sometimes be used to report "current" information and sometimes to report "noncurrent" information?
3. Missing text blocks from the US GAAP XBRL Taxonomy: If you look at the capitalized computer software roll forward you can see the consistency in the Level 4 detailed representation of this disclosure, and a wild inconsistency in the Level 3 [Text Block] used by filers.  This is a clear sign of a missing [Text Block] concept.
4. Duplication of text blocks making it harder for filers to find the correct text block:If you look at the long-lived assets by geographic area disclosure, you will see 3 different and logical/rational choices for how to represent the Level 3 [Text Block] for that discloser.  Is this diversity a feature or a bug?  On the one hand, providing diversity (i.e. many choices) may be helpful.  On the other hand, providing 3 choices where 1 would do causes complexity as contrast to simplicity.  If a filer has 3 things to pick from, they have to go through the effort of choosing.  Also, what is the value of providing a combined "revenues and long-lived assets by geographic area" as opposed to one for "revenues by geographic area" and another for "long-lived assets by geographic area"?

Here are my analysis documents:

• Accounts receivable roll up: Shows relation between Level 1 "footnote" text block, Level 3 "disclosure" level text block, and Level 4 "detailed" representation. (See more AR roll ups here)
• Property, plant and equipment by type: Shows a high level of consistency and specific reasons for the inconsistency. (See more PPE by type disclosures here)
• Long-lived assets by geographic area: Shows the possibility of a duplicate level 3 text block and combining of multiple disclosures into one text block. (See more long-lived assets by geographic area disclosures here)
• Capitalized computer software roll forward: Shows a clear sign of missing level 3 text block.
• Long-lived assets by geographic area: Shows consistencies and inconsistencies in the use of [Table]s, [Axis], the root [Member], and concepts used in the same disclosure.
• Property, plant and equipment estimated useful lives: Shows a relationship between disclosures and that common disclosure patterns exist (see next disclosure).
• Finite-lived intangible assets: Shows a similar "disclosure pattern" as property, plant, and equipment by type and property, plant, and equipment estimated useful lives (above) and that there is consistency, or should be consistency, between similar disclosures.

If you look at those documents, don't make the mistake to think that the analysis relates only to the specific disclosure being analyzed.  These sorts of patterns exist for every discloser.  Here are two prototypes you can use to look at different disclosures.  This first prototype has more disclosures (420) but the volume of information is not as high. This second prototype is a bit easier to use, the quality of information is higher, but there are fewer disclosures.

How much diversity is warranted? Is this diversity planned?  Or, is this diversity caused by sloppiness and lack of attention to detail? 

How can this diversity be controlled?  The answer to that question is easy: business rules. The reason for a lot of the unwarranted diversity is lack of business rules to control the diversity.

So consider the long-lived assets by geographic area disclosure.  The following is pseudo code for business rules which would, if used by every reporting entity (i.e. if this information was provided by the US GAAP XBRL Taxonomy) would control where diversity is allowed and how diverse filers can be:

• Long-lived assets by geographic area disclosure - REQUIRES TABLE- us-gaap:ScheduleOfSegmentReportingInformationBySegmentTable
• Long-lived assets by geographic area disclosure - REQUIRES AXIS- us-gaap:StatementGeographicalAxis
• Long-lived assets by geographic area disclosure - REQUIRES CONCEPT - us-gaap:NoncurrentAssets
• us-gaap:NoncurrentAssets - ALLOWS ALTERNATIVE CONCEPT - us-gaap:PropertyPlantAndEquipmentNet

Look at those rules, then look at this matrix of what filers are doing.  Don't quite like my rules? Fine, create whatever you want to allow filers to do.  Rather simple.  All this information can be expressed using XBRL definition relations.  All these rule are, are allowed and disallowed relations between the report elements contained in the US GAAP XBRL Taxonomy. Having no rules means that anything is allowed.

Is there some sort of statement the SEC or FASB is making where their strategy for the diversity offered by the US GAAP XBRL Taxonomy is explained?  If you see one, please point me to it.  A clear sign that the US GAAP XBRL Taxonomy is out of control is a lack of that information....and no strategy.