Digital Financial Reporting

I created another updated to my Financial Disclosure Research Tool prototype.  This one gets a little closer to how I think a disclosure research tool would work.

Click image to go to prototype

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

An analysis provided by Calcbench shows three types of common errors in SEC XBRL financial filings:

• Sign switches (about 50% of filings), which is reporting the incorrect polarity of a number such as reporting a negative number which should have been positive
• Scale errors (about 8% to 12% of filings), which is reporting 5 when the number 5000 should have been reported
• DEI errors (about 3% of filings), such as incorrect infomation for the fiscal period, fiscal year, or document balance sheet date

For more information on errors, you can see my analysis of a basic set of minimum criteria here necessary to make safe, reliable, repeatable, predicatable use of SEC XBRL financial filings.  Details which explain each of those minimum criteria can be found here.

This blog post builds upon the post Digitizing Disclosures (Part 1).  In Part 1 I shows that a disclosure can be broken down into pieces.  Some people call this "structured", I call it "digitizing" the information.  In this part I try and paint the big picture and point out the advantages of digital financial reporting and point out where we fall short today. Part 3 will show exactly how disclosures are digitized, how business rules help quality, and how to create an automated digital version of a disclosure checklist.

This is a summary of the pieces which you want to keep straight in your mind.

First, external financial reporting managers and other such accountants create reports such as financial reports.  I am focusing on financial reports as an example because I am an accountant.  But these ideas also follow for other types of reports.

Second, these reports are can be very complex.  There is lots of information which must be correct, complete, consistent, and accurate.  To make a mistake is to risk noncompliance with laws/regulations.  How do the accountants who create and publish this information get the job done?

• Vast amounts of knowledge and skill they have crammed into their brain
• Resources which the accountants use to find the things that don't know off the top of their head, for example a disclosure checklist which they use as a memory jogger
• Lots and lots of manual effort
• Software publishing tools which has zero knowledge of financial reporting; these tools may have some information extraction capabilities and/or content management capabilities, but they truly know nothing about financial reporting

Why is this process used?  Well, because up until now there has been no other alternative.  How might this alternative work:

• Take as much knowledge of financial reporting as possible (necessary) and put that information in not only human readable form, but also into machine readable form
• Take other resources which accountants use and put that into human readable and machine readable form also
• Manual effort, but replace as much manual effort as possible with automated processes
• Use software which leverages the machine readable information which has been expressed about how to correctly, completely, consistently and accurately create a financial report and therefore can appear to understand financial reporting and actively assist and even guide an accountant through that process of creating a financial report

Note that I am NOT saying that this process will be 100% automated, NOT saying that computer will exercise judgment because they cannot, NOT saying professionals will be eliminated from the process; what I am saying is that what can and should be automated will be automated and what cannot be automated or should be manual will be manually performed by humans.

How is this possible?  Magic?  There is zero magic involved.  Artificial intelligence?  No artificial intelligence at work.  Hard work and attention to detail?  Lots of that.  Beating down complexity by simplifying as much as possible? Yes. And I don't mean make things simplistic.   Simplicity and elegance are the ultimate sophistication.  Simplifying is extremely hard work. 

This graphic explains visually how this will be achieved:

(Click image for larger view)

Here is the narrative with walks you through the graphic. 

First, there are a lot of different ways to express information in a machine readable format: CSV, Excel, JSON, XML, XML plus an XML Schema, RDF, RDF with a schema, RDF with a schema and ontology, or XBRL.  The XBRL syntax is a global standard format for doing this.

Next, you take all the things which make up a financial report and you express them in a machine readable form, such as the way the US GAAP XBRL Taxonomy does this for US GAAP and the IFRS XBRL Taxonomy does this for IFRS.  Eventually other taxonomies will do this same thing for State and Local Governmental financial reporting.  The specific format matters less, what matters more is how much meaning or "semantics" which you can pack into machine readable form.  You need all the "things" and the "relations between the things" which make up a financial report.  Not everything related to accounting and reporting, just the stuff that ends up in a report.

If you notice the graphic, you can see that there is a correlation between the level of semantics (weak or strong) and the reasoning capacity of a machine such as a computer (low or high).

Part of the necessary semantics are the relations between the things in a financial report.  One of the things which plagues SEC XBRL financial filings to day are errors in the relationships. The following succinct statement summarizes the reason why data quality problems exist in SEC XBRL financial filings:

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.

Digitizing disclosures has little to do with XBRL mandates. 

An external financial reporting manager needs to create external financial reports in an efficient and effective manner and insure compliance with legal requirements to minimize the risk of lawsuit, regulatory non-compliance, other reporting error, or other risk factor.  Software companies began creating disclosure management software long before the SEC mandated reporting by public companies in the XBRL format. Clarity (now IBM FRS), Hyperion (now owned by Oracle), cundus (now owned by SAP), WebFilings, Trintech and others all were creating disclosure management systems before they retrofitted their software to support XBRL.

But each of these software solutions, while they can output XBRL formatted financial reports; none of these systems actually understands financial reporting semantics.  This software does not fit the digital financial reporting bill because it does not provide the necessary functionality. For example, none of these software products, to the best of my knowledge, offers a digitized disclosure checklist which replaces the manual "memory jogger" approach.

I would argue that the market for disclosure management software, if it provided the correct functionality, is not the 10,000 public companies which file with the SEC.  I personally see the market as being approximately the following in the United States alone:

• Those 10,000 public companies
• Private companies who provide audited or reviewed financial statements in support of commercial loans, I hear that there are between 14,000,000 and 24,000,000
• Not for profits who provide audits in support of grants, about 360,000 as I understand it
• State and local governmental entities required to create financial reports, about 90,000

But none of these reporting entities would ever purchase software that works the way software works today for creating SEC XBRL financial filings.  That software provides no real benefit when working with structured information, only additional work. And besides, there is another problem: quality.

The XBRL syntax is fine, 99.9% of SEC XBRL financial filings have the proper XBRLtechnical syntax.  Domain semantic rules are not even remotely sufficient, however, so the SEC XBRL financial filings have a boatload of quality problems.  See the quote above, pretty straight forward.  You can tell by the patterns in the errors that not one software application has the processes in place to systematically detect errors.  Software has systemic process problems. 

So, that is why quality issues exist in SEC XBRL financial filings, missing domain semantics rules or "business rules" they are commonly called. Plus, even if they magically existed, the software does not leverage those rules.  The best that software today could do is run the rules after the digital financial report is created.  That is helpful in creating proper XBRLformatted financial reports, but it is of no help in actually creating the report in the first place. The XBRL formatting is simply bolting on additional work to the end of an already complex process. What needs to change are the fundamental work practices.

Seem impossible?  It is not impossible.  Two things are necessary to make digital financial reporting work: (a) the metadata which assures a meaningful information exchange and (b) software which understands and leverages the metadata to guide the accountant in the process of creating a financial report. The software will be simple to use but will provide sophisticated functionality because the complexity of dealing with the thousands and thousands of individual pieces of a structured report and the relations between the structures are managed, behind the scenes, by the software.

While validation software such as XBRL Cloud's Edgar Dashboard or the SECXBRL.info validation of basic financial information is helpful, that validation needs to be imbedded in software so the software will not let business users make these mistakes.  Further, this validation must be comprehensive.  Rather than covering, for example, a set of minimum criteria; all aspects of every disclosure must be verified by creation software.

As I will show in Part 3 of this series, there is not that much of a difference between verifying the minimum criteria and verifying disclosures.  Stay tuned.

To start thinking about this "digitation" process, first take a look at this HTML and this XML (here is a rendered version of the XML if you don't understand how to read the XML).