Digital Financial Reporting

I was asked a question on the XBRL-Public discussion group related to exactly how the validation that I have created is detecting accounting and reporting errors in XBRL-based reports of public companies that are submitted to the SEC.  This blog post "weaves" all of this information together as best that I can currently to explain how all this works.

There are a couple of good things to understand before you read this explanation.  To begin with, I am showing some prototypes that are used to detect fundamental accounting concept relations continuity cross check mistakes made in reports.  I am using that because it was the first initial prototype that I created to prove this concept and explain to software vendors how to implement this functionality.  The disclosure mechanics and reporting checklist came later.  HOWEVER, both processes fundamentally work the same way.  In fact, I really don't think this should be two separate processes; what I need to do is combine both of these separate processes into ONE process.  Also, there are other pieces of this that I am not covering such as the "model structure relations" checks and the "type/class relations" checks.  They also work using the same basic approach.

Here is an explanation of the method that I use to create what I am calling my "automated reporting checklist" which is similar to the manual "memory jogger" many professional accountants and pretty much all auditors use today to make sure a financial report is created correctly.  This automated reporting checklist leverages the structured nature of an XBRL-based financial report. 

STEP 1: First you have to understand the “business logic” of the report; basically what is required to be reported.  A financial report is made up of many different specific disclosures.  Each of those disclosures can be identified.  Here is a summary of that for the 65 disclosures I have documented for my campaign to improve disclosure quality.  You can scan that list and see the sort of information the PDF contains.

That entire document can be hard to digest; so here is one fragment of that document for one specific disclosure, future minimum payments due under noncancelable leases of a lessee.

Notice that I gave the disclosure a specific unique name, I described the disclosure, I provided a reference to the Accounting Standards Codification (ASC) for the disclosure, provided an example of the disclosure, the Level 3 Disclosure Text Block and Level 4 Disclosure Detail concepts used in the disclosure, referenced the disclosure to one specific company that has that disclosure, and provided a like to 110 examples of that specific disclosure within the financial reports of public companies.

Essentially what I am doing is understating the logic of the disclosure and accumulating evidence to support that logic.  (Note that this is a skill professional accountants will need in the future.)

STEP 2: Once you have gathered the business logic of a disclosure, you then have to translate those disclosure requirements into machine-readable form.  The machine readable form that I am using is basic global standard XBRL technical syntax.  Note that older prototypes shown do not use that syntax, but I have converted 100% of these machine-readable business rules into the XBRL technical syntax.

Basically, you create metadata in the for of declarative business rules that is used to TEST the information submitted within an XBRL-based financial report.  I am using XBRL definition relations to achieve that for the disclosure mechanics and reporting checklist rules. Here are the XBRL definition relations of the business rules in machine-readable form for the mechanics of the future minimum payments disclosure.

And here is the EXACT same information in human-readable form.  The human-readable representation which is essentially a controled natural language syntax is actually generated using software from the XBRL-based rules.  So, the two are 100% consistent; one format is intended to be used by machines, the other format is intended to be used by humans who are using the machines.

STEP 3: Once you have an XBRL-based structured report and the machine-readable rules; you need software that processes the structured reports and the structured rules and tells you if the report is created correctly based on the rules.  Generally the best approach to creating this software is to create a business rules engine. But, alternative approaches work also.

You create software that uses (a) an XBRL-based financial report (i.e. structured data, therefore the individual pieces of the report can be accurately identified) and (b) the machine-readable business rules (i.e. the metadata) and uses software algorithms to deterimne if the XBRL-based report is consistent with or inconsistent with the machine readable rules.  Here is the “line of reasoning” generated by one such software application that have implemented this functionallity. 

STEP 4: You organize all of this into some sort of software interface and you repeat this process for EVERY disclosure.  Here is the interface generated by one of the software applications that spews out a set of HTML documents that hooks all of this together. (Note item 54with is the future minimum payments due under Noncancelable leases for lessees.) 

Can all this be done using Microsoft Excel?  Sure, no problem.  I created my first initial prototype of this in Microsoft Excel.  If you download and look at the Excel application, which is an updated version of that initial prototype, you will notice that the application actually works on the 1,445 XBRL-based financial reports of public companies who have filed with the SEC which use the most common reporting style. And here is another working prototype that works for a different reporting style which is used by about 454 public companies.

The results are pre-loaded in the Excel spreadsheets.  If you press the one button on the “Compare” spreadsheet, the existing results will be deleted and the spreadsheet will repopulate.  (i.e. this WORKS)  For both of these two prototypes, I have DELETED all financial reports that DO NOT PASS.  I am going to resynchronize the rules in the Excel spreadsheet with the rules implemented by XBRL Cloud and the Pesseract proof of concept.

STEP 4(a): Key to understanding exactly how all of this work are the following all of which can be examined within the VBA code of the Excel prototypes:

• Mapping rules: Because multiple concepts might be used to represent a financial report fact, you have to create metadata (i.e. mapping rules) or as I did in the Excel application hard code the mapping rules in the code.
• Impute rules: Because not all line items are explicitly reported, you need to be able to logically derive the line items that are missing.  For example, many companies don't explicitly report the line item "Noncurrent assets" on their balance sheet.  Some do, but some don't.  Business rules help you derive these missing line items.
• Consistency rules: Once all the facts are discovered and all the missing line items that you want or need are derived using the impute rules, you use the consistency rules to check to make sure all the information is consistent.  This checks helps make sure there are no contradictions, no conflicts, and all the information you are working with is consistent with your expectation.

All of this works using the rules of logic.  As you are probably aware, when a company creates an income statement, there are a number of different concepts that might logically be used to represent the notion of “Revenues”.  Look at the mappings.  The concept “us-gaap:Revenues” is a rational concept; or the concept "us-gaap:SalesRevenueNet" might be used or "us-gaap:HealthCareOrganizationRevenue".   All of these are logical choicesfor reporting the notion of “Revenues”.  What is NOT logical is to use the concept “us-gaap:Assets” to report revenues.   And, there is other logic at play here; but the bottom line is that what is represented MUST be logical.  It is the metadata that defines the logic.  No metadata, software simply could not figure out what facts to grab. 

Likewise as you are probably aware, public companies are NOT REQUIRED to report every line item.  Certain line items, yes they are required to report.  But other line items are NOT required.  But what IS required, again, is for the information reported to be LOGICAL. 

Look on the "Compare" spreadsheet and look for the columns that have all the GREEN cells that look like this.  Notice how everything is GREEN with the exception of a few “rounding errors” that one company has because they were lazy and did not fix the rounding errors in their report.  This explanation mechanism helps you understand that the reported information is consistent with the expectations represented by the machine-readable rules that explain the logic or the report.

STEP 5: This is where you have to use your imagination a bit because I don't have an Excel application to show you.  While the Excel spreadsheet is used to validate the “fundamental accounting concept relations continuity cross checks”, the EXACT SAME IDEAS AND TECHNIQUES are used for the disclosure mechanics rules (structure, logic, mechanical, mathematical relations of EACH DISCLOSURE) and the reporting checklist rules (required disclosures, disclosures that are required if a specific line item is reported, etc.)

This video (a DRAFT, I am trying to piece together a nice storyboard) that I created walks you through how all this works.  You can “experience” all of this yourself.  That video basically walks you through this “explanation mechanism”.  Or, you could download and install the Pesseract software applicationwhich has essentially the exact same functionality.

IMAGINE THE POSSIBILITIES: Now, imagine that you had a process for verifying 100% of a financial report using automated processes like this.  In the demo that I am showing, I am only validating about 70 disclosures of the Microsoft report.  But Microsoft has a total of about 199 disclosures.  To make this work, I would have to create business rules for 100% of the disclosures Microsoft reports.  I call this the "bottom up" approach.  Think about this the other way around, what if you thought of this "top down" and created all disclosures based on machine-readable business rules.  Read this comparison between the bottom up and top down approach for more information.

Finally, think of that "top down" approach and how the business rules are being used after-the-fact, after a report is created for validating or querying that report.  What if the business rules led you through the logic of creating the actual report?  They call such systems expert systems.  Here is a proof of concept of such an expert system which is used to test the feasibility of such an expert system.

Here are some videos that help you think about the feasibility of such a system.

* * * * * * * * * 

I hope people find this helpful.  What is unclear?  Let me know.  I will try and improve this explanation until everything is crystal clear.