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.