Digital Financial Reporting

Many people tend to offer up the explanation "there are too many extensions" as the reason why SEC XBRL financial filing information provided by public companies is not usable as envisioned.

The true reason the information is not as usable as it could be is more nuanced than that simplistic and unsubstantiated statement. When it comes to extensions, when extensions are done correctly those extension are generally a very good thing.

Did you know that per the XBRL Cloud EDGAR Dashboard that 99.9% of all SEC XBRL financial filings had the proper XBRL technical syntax? Do you realize that the XBRL US Consistency Suite found a total of 140 XBRL technical syntax errors in the approximately 100,000 XBRL financial filings submitted to the SEC? That is .14%.

Do you know that testing of a set of 7160 SEC XBRL financial filings showed that 98% of such filings pass a set of tests for 50 fundamental accounting concepts which one would expect to find and 21 relations between those fundamental concepts?

Why is it that 99.9% of all SEC XBRL financial filings have such a high rate of compliance to the XBRL technical syntax?  There is a very, very simple and straight forward answer to that question: the XBRL conformance suite.  Tests!

Back in 2001, XBRL 2.0 had a serious software interoperability problem.  Business users could create XBRL in one software application, send it to someone else using a different application, and the receiving application many times could not load the XBRL.  Clearly this was not a good situation.

The current version of XBRL, XBRL 2.1, does not suffer from that interoperability problem.  Why?  XBRL technical syntax issues were solved back in 2005 when XBRL created and started using a conformance suite to test software interoperability.  Every version of every XBRL technical specification has had a conformance suite since that time.  You can find those conformance suites along with the technical specifications.  Here is where you find the XBRL 2.1 conformance suite.

A conformance suite is simply a set of tests where the results are known and software applications are expected to act in certain specific ways when they encounter situations found in the tests.

So a good question to ask yourself is this: Why are there 140 XBRL technical syntax errors found in submitted SEC XBRL financial filings if there is an XBRL technical syntax conformance suite???  Why wouldn't XBRL Cloud and the XBRL US Consistency Checks and the SEC inbound validation get exactly the same results?  Why shouldn't the number of errors in SEC XBRL financial filings be zero?

The answer to that question is that while the XBRL conformance suite helps interoperability, it is not perfect.  The conformance suite is only as good as the tests it contains and the compliance to software vendors to those tests.  The software which the SEC uses for the inbound validation of SEC XBRL financial filings seems to give different results than XBRL Cloud's Edgar Dashboard and the XBRL US Consistency Suite.  Humans make mistakes.  Conformance suites or consistency suites and other such tests help humans make less mistakes.

It works like this as shown in the diagram:

(Click for a larger image)

The only way a meaningful exchange of information can occur is the prior existence of agreed upon syntax, semantics, and workflow/process rules.  To the extent that these rules exist, information exchanged will have the "quality" of meaning for the information to be reusable by automated analysis processes.  By automated analysis processes I mean something as simple as comparing the basic financial information of reporting entities.

So now back to the 98% of fundamental accounting concepts being in the filings and the relations between those concepts being correct.  US GAAP has agreed upon rules.  For example, "assets = liabilities and equity".  Every accountant knows that rule and other such rules.  Well, actually, seems that a handful don't know that.  Or, somehow they created a balance sheet that did not balance.  About 15 SEC filers, of a total 7160 which were tested, had a balance sheet which did not balance.

What would happen if the SEC put a rule in its inbound validation which tested to see if the balance sheet balanced for every period provided within the financial report?  Well, then those 15 reporting entities would need to correct their financial reports in order to submit them and have the SEC accept them. And, then that quality issue would not exist.

How hard is that?  Well, not hard at all.  In fact, here is that exact test along with a handful of other test in this XBRL Formuila file. You many not understand that file, but an XBRL processor which supports XBRL Formula would.  You can see those rules being enforced by the XBRL Cloud EDGAR Dashboard, see the "US GAAP Domain Level Rules" column:

Here are tests to be sure the structure of the representation is correct, I don't have a rate for that but based on looking at the XBRL Cloud EDGAR Dashboard, it looks pretty good:

So why does XBRL Cloud or XBRL US get to determine what constitutes a good or bad SEC XBRL financial filing? Why wouldn't the SEC do that?  Well, good question.  But the SEC does not.  You really cannot argue with XBRL Cloud or XBRL US or my tests of fundamental accounting concepts other than to point out where those tests are wrong.

Tests are how you articulate to computers what "good" and "bad" look like. Test are how you agree on right and wrong.  Tests is what helps a filer, the SEC, the FASB, software vendors, and those using the information understand that they are all on the same page. Tests is what enables a meaningful exchange of information.

The 99.9% interoperability at the XBRL technical syntax level and the 98% interoperability of 50 fundamental accounting concepts and 21 relations is not to say the quality of SEC XBRL financial filings is where it needs to be.  It is more a statement to show that there are some very high quality areas but that this is only the tip of the iceberg.  It also shows a path to quality: more tests.

What about those extensions? How about tests which explain where extensions are allowed and where they are not allowed?  That would provide clarity to filers.

While automated tests cannot be created to detect every quality issue, more tests will certainly help improve SEC XBRL financial filing quality.

This Understanding Concept Computing helps one understand where digital financial reporting is headed in my view. This is not as much about the specific term "concept computing"; it is more about the ideas that I see in that slide deck.

In particular take a look at slide 32 which talks about "self-declaring" and "self-defining" components.

"Knowledge models" which are the concepts and relations between concepts are not hard coded into software applications, rather software applications read these knowledge models and dynamically adjust themselves.

This is another presentation, Concept Computing in Twelve Tweets. 

Model = Design = Documentation = User Interface

Concept computing enables everyone to model.

BeInformed videos.

I held a class for CPAs in Seattle last week and during the class one of the participants made the following statement:

"ERP systems don't have all of the information in them that you need to create a financial report."

The comment led to me creating the diagram below which shows the problem and the solution to the problem:

System overview (click for larger image)

The Problem:

Today information is stored in  ERP systems, accounting systems, other relational database based systems, Excel spreadsheets, Word documents, and other structured, semi-structured, and unstructured formats.  To create something like an external financial report; humans go to all these different information storage devices, gather what they need, and piece the information together into the report they desire and in the form of a PDF, HTML, Word document or Excel spreadsheet.

Then, they hand that document or spreadsheet over to someone else and the process starts over again with those documents being the inputs for some other system.  For example, a financial report created by a public company is an output from the reporting entity's perspective; but that report is an imput from the perspective of the SEC or an analyst.

Some of the information is obtained using efficient database queries.  Other information is entered using "copy/paste".  Other information is simply rekeyed.

Managing and controlling this process is a monumental task. Sarbanes-Oxley requires companies to have a very good handle on this process if the process relates to external financial reporting.  Other rules impose a level of rigor and dicipline for other reporting schemes in other domains.  Internal processes have unspecified levels of rigor/dicipline.

Research papers by both Ventana and Gartner describe this process for external financial reporting.  Gartner estimated that the average Fortune 1000 company used more than 800 spreadsheets to prepare its financial statements for regulatory reporting.

What tools do business users such as accountants have for keeping tabs on this process and making it efficient? They use things like the linking mechanisms provided in Excel. The tools are presentation oriented and know nothing about the information contained in the application other than how to present the information in a document or spreadsheet.

Weaving these things together is like trying to build something and trying to hold it together with bailing wire and band-aids.  If bridges, buildings, or airplanes were engineered in this manner; lots of bridges and buildings would be falling down and air travel would not be very safe.

The Solution:

In the future the problem will be the same and likely get even more complicated and complex because things always seem to get more complicated and complex.  However, the solution will be different.

Think of an accounting system.  That system is made up of modules: general ledger, accounts receivable, accounts payable, payroll, fixed assets, and so forth.

But there are no "modules" for things like subsequent events, commitments and contingencies, line of credit facilities, and hundreds of other disclosures.  But what if there were?

What if business users could create their own modules.  Those modules could be integrated with other modules.  The modules were "smart" and had accounting and financial reporting knowledge built in which controlled the module.

That is what a semantic spreadsheet is: a module.  A disclosure management application is a module manager or a semantic spreadsheet manager.  A reporting template is basically a module for a specific type of disclosure.  I call all the spreadsheets which I used to create a financial statement my closing book.  That closing book had all the supporting information for the financial statement.

In the future semantic spreadsheets will be used to capture and manage all this information which comes from all sorts of different systems which hold the information which ends up being reported in an external financial report or other business report.

Rather than linking information together based on its physical location, information will be held together using business rules which make sure the information is correct, complete, accurate, and consistent.  Disclosure checklists will not be used by accountants to manually check a financial report after it is created; a disclosure checklist will serve as a guide to software which will make sure that you don't ever create a report incorrectly.  These guides will be used during the creation process, not after the fact.

Validation and verification that information follows specified business rules will be done using both automated processes and manual processes where a process cannot be automated. When a rule is violated or something in the process breaks, the exception will be obvious.

Making the system work

What does it take to make something like what I am describing above actually work? What does "work" really mean?

• Meaningful exchange of information: First off, there needs to be a meaningful exchange of information between these different business systems. If that cannot occur, this system simply will not work correctly.  It is pretty simple: garbage in, garbage out.
• Controlled by business users: Business users need to be at the controls.  Business users cannot be running to the IT department at every step.  This is sophisticated stuff, but it is what IT people do.  IT people builds systems like this all the time.  Really think about what happens when you book an airline ticket online. For what I am describing, business people need to weave things together.  IT people help by burying the complexity and sophistication deeply within software.
• Queries of structured, semi-structured, unstructured information:  If we could rip out all legacy systems, throw them away, and start over all this would be easier.  But we can't.  The reality is that there are a lot of different systems out there.  They will be there for a long time.  Software needs to make working with these different systems appear seamless. Systems need to be polyglot, but business users should be able to use their language of choice.
• No artificial boundaries between internal and external systems: The system is a collaboration of business users internal and external to an organization.  There is a workflow/process which business users follow. That workflow/process must be followed, what software application you use should not be a barrier, were your physical location should not be a barrier.
• System has to work: In order for all this to be used, it has to be useful. The system needs to be easy to use by a business user, cost effective, predictable, repeatable, and reliable. There needs to an appropriate audit trail when necessary.  Clearly security needs to be managed appropriately.

I have called this a "radically taylorable tool". Another term for that is controlled flexibility. Other software has aspects of what I am talking about for working with other things.  GoAnimate is one example. Scratch is another example.  Think "Legos".

One day you won't need to use your imagination to understand what computer software can do to help business reporting and financial reporting.  One day you may believe what I am saying because you will see the software in action.

Am I nuts or will this grand vision be realized?  Time will provide the answer.

A comprehensive analysis of 7,160 SEC XBRL financial filings has resulted in a set of common sense insights, or Digital Financial Reporting Principles, which are helpful to creators and consumers of such digital financial reports.

Looking at details across the 7,160 public company 10-K filings helps one see and understand the combined digital financial reporting "forest" which is comprised of individual digital financial report "trees". This perspective helps one understand the utility of something like the Financial Report Semantics and Dynamics Theory for relating to digital financial reports.

Although still a work in progress, this draft helps both accountants and software companies who build software for accountants get their heads around digital financial reporting, including SEC XBRL financial filings.

Here is a summary of the common sense principles:

• Recognize that the goal is the meaningful exchange of information.
• Meaningful exchange requires prior existence of agreed upon syntax, semantics, and workflow/process rules.
• Recognize that even if SEC filing rules and the US GAAP XBRL Taxonomy may allow for ambiguity; approaches do exist where SEC filings rules can be followed and information is unambiguous.
• Recognize that being explicit contributes to the unambiguous interpretation of reported information.
• Recognize the difference between presentation and representation.
• Recognize that a financial report should be a true and fair representation.
• Recognize that financial reports contain a discrete set of report elements which have specific properties and relations.
• Recognize that report elements can be categorized into common groups which have common relevant properties.
• Recognize that financial reports contain a discrete set of financial report component which can be categorized.
• Recognize the existence of and properly represent intersections between report components.
• Always strive for consistency
• Recognize and respect fundamental accounting concepts and unchangeable relations between those accounting concepts
• Recognize and respect common report component arrangement patterns.
• Recognize and respect common concept (or [Line Items]) arrangement patterns.
• Recognize and respect common member arrangement patterns.
• Avoid mixing or run-together concept arrangement patterns.
• Avoid mixing distinct characteristics and concepts.
• Recognize need for both automated and manual verification processes.
• Recognize that concepts cannot be moved between fundamental accounting concept categories.
• Avoid unknowingly changing information representation approach midstream.
• Avoid inconsistencies in network identification.
• Recognize that characteristics apply to all reported facts within a report component.
• Recognize that rendering engines render presentation differently but the meaning is the same across all rendering engines.
• Number of members reported does not change the characteristics of a reported fact.
• Label networks with meaningful information.

You can break down the information contained within a digital financial report such as an SEC XBRL financial filing in many helpful ways. Here are some helpful breakdowns of the report elements and report components which make up SEC XBRL financial filings.

For my set of 7160 SEC XBRL financial filings (all 10-K filings), the following summarizes the report elements of those filings, averages per filing, average per report component, and extension rate percentages for each report element category:

(Click on the image for a larger view)

Some items of interest.

• Categories of report elements: The first thing to note is that the pieces of a digital financial report are identifiable and fit into categories.  It is not really appropriate call any piece of a report by the term "tag" or "element" because no one knows if you mean report element, concept, axis, member, table, line items, abstracts or reported facts.  Using the more specific term conveys more meaning.
• Lots of small pieces: The average report component has 6.7 concepts.

The following breakdown is even more insightful in my opinion. Here is information about concepts and extension concepts grouped by report component category:

(Click to view larger image)

Understand is that a third of all report components are text blocks. So we should look at text blocks and detail components separately.  We should also look at statements and disclosures separately.

And so in tuning this you can see that the average report component which is a statement has 20 concepts and the average disclosure has 7.

You can break this down even further, by disclosure.  Here is a summary of concept usage for a select number of report components:

(Click to view larger image)

What will really be interesting is when you can analyze the information communicated within the disclosures themselves!  I am working on that.  Computational linguistics seems to be useful for that.  More to come.