Digital Financial Reporting

In prior blog postsI have pointed out that XBRL Formulas have some specific deficiencies. One of those deficiencies involves chaining.  XBRL Formula processors cannot do forward or backward chaining.

Well, there is a way you can achieve a similar result using XBRL Formula.  What you can do with an XBRL Formula processor is "chain" a process together.  Now, you have to put everything in the right order because XBRL Formula processors cannot do forward or backward chaining as I have pointed out.

The objective is to duplicate these fundamental accounting concept relations continuity cross checks. All of these Excel extraction tools similarly use sequential processes as opposed to forward or backward chaining.

Here is how you do that validation using XBRL Formula:

• Step 1.  You have an XBRL instance. That XBRL instance has 12 facts.
• Step 2: You feed that XBRL instance in Step 1 to an XBRL processor as input; you also provide these XBRL Formulas linkbases:
  • formula-Impute-PullFactsForward.xml(this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-EquityAttributableToNoncontrollingInterest.xml(derive the value for Equity Attributable to Noncontrolling Interest from existing information)
  • formula-Impute-NoncurrentAssets.xml(derive the value for Noncurrent Assets from existing information)
• Interim result A: You get this resulting XBRL instance.  (human readable) That XBRL instance now has 16 facts.
• Step 3: You take interim result A and use that as input; you also provide these XBRL Formula linkbases:
  • formula-Impute-PullFactsForward.xml (again, this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-Equity.xml (derive the value for Equity from existing information and previously derived information)
• Interim result B: You get this resulting XBRL instance. (human readable) That XBRL instance now has 18 facts.
• Step 4: You take the interim result B and use that as imput; you also provide these XBRL formula linkbases:
  • formula-Impute-PullFactsForward.xml (again, this pulls all the existing facts forward into the new XBRL instance which will be generated)
  • formula-Impute-Liabilities.xml (derives the value for Liabilities from existing information and previously derived information)
• Final result: You get this resulting XBRL instance. (human readable) That XBRL instance now has 20 facts.
• Consistency checks: You take the final result; you also provide these XBRL formula linkbases:
  • fac-formula-BSC.xml (value assertions which check the consistency of reported fact with expectations)
• Consistency checks validation result: This is the ultimate validation result in human readable form.

And there you have it! While it is true that a human has to string the rules together in the correct order and that this process is not that effecient because you have to reload XBRL instances multiple times; this process does work and so it is effective.

What this example also clearly demonstrates is that there is a use case for deriving facts that were not reported so that consistency checks can be executed.  If it is the case that information about unreported facts cannot be determined, the XBRL instance is fundamentally unusable by automated processes.  At the same time, this shows that information can be used by automated processes since you can chain the process together effectively.

I have run this or had this run through the UBmatrix and Fujitsu XBRL Formula Processors.  I am going to try and get this run through two more processors to confirm that this works consistently.