Super PROOF

This version of the PROOF which I am referring to as the Super Proof helps technical people understand how the Seattle Method works to control the quality of an XBRL-based financial report. The first step to understanding this is to watch this video related to the verification of an XBRL-based financial report. (video is 6 minutes and 40 seconds)

The next thing to understand is that you can load any of these XBRL files into software that supports XBRL and view the files. Pesseract is an excellent tool, but you need to download and install it. Contact me if you want a license.

This Super PROOF compares and contrasts three different report configurations.  This is the human readable HTML version of the report.

REPORT #1: Start with this XBRL instance.  To verify that XBRL instance using a tool such as Auditchain Pacioli's Power User Tool, you have to add this extra information to the discoverable taxonomy set. The resulting verification result will look like what you see in this link.

REPORT #2: The above XBRL instance and this XBRL instance that has the Seattle Method rules directly attached are logically equivalent. You can simply send the above XBRL instance (with the extra information linked directly within the XBRL instance) to Auditchain Pacioli's Power User Tool and you will get this set of verification results returned.

So again, the two reports above, REPORT #1 and REPORT #2 are logically equivalent.

REPORT #3: This XBRL instance is EXACTLY the same XBRL instance as REPORT #1 above. But no extra rules are attached to that report.  The resulting Auditchain Pacioli Power User Tool verification result for REPORT #3 with NO ADDITIONAL RULES ATTACHED is this. Basically, THIS REPORT IS INCOMPLETE. It is missing verification rules that let errors slip into the report. Ignorance of rules is not "bliss"; the ignorance of the rules lets mistakes slip into a report.

What exactly is the difference between REPORTS #1 and REPORT #2 which give the same complete result and REPORT #3 which gives incomplete verification results (note the GRAY in the REPORT #3 result; it means that category of rules were not executed because the rules were not provided).

  1. XBRL technical syntax verification is the SAME for both sets.  Nothing needs to be added to make the XBRL technical syntax of the XBRL instance and connected XBRL taxonomy schema and linkbases.
  2. Report Mathematical Computations Verification (XBRL Calculations) is the SAME for both sets. Same set of XBRL calculations rules are used in both sets. (This, report-cal.xml)
  3. Report Mathematical Computations Verification (XBRL Formulas) is the SAME for both sets. Same set of XBRL formulas rules are used in both sets. (This, report-for.xml)
  4. Report Model Structure Verification is DIFFERENT for each set. REPORTS #1 and #2 know about these rules that verify the model structure of the XBRL presentation relations.  REPORT #3 does NOT.  This is the verification result provided when the rules are run. Those rules make sure the relation between the "FROM" and "TO" report elements conform to the permitted logical patterns. (To understand model structure, watch this video.)
  5. Fundamental Accounting Concept Consistency Crosschecks Verification is DIFFERENT for each set.  REPORTS #1 and #2 know about these fundamental accounting concept relationship rules (all the files attached to that XBRL taxonomy schema). This is the verification result provided with those FAC rules are attached. Additionally, all these XBRL formula results with FAC in the rule ID are leveraged.  Additionally, all of these derivation rules are executed that map the PROOF facts to the FAC facts. (The mapping files is attached to the FAC XBRL taxonomy schema.  To understand the fundamental accounting concepts, watch this video.)
  6. Type-subtype (wider-narrower) Associations Verification is DIFFERENT for each set.  REPORT #1 and #2 know about these type-subtype relations rules.  This is the verification result provided with those type-subtype rules attached. (Note, the graph rendering can be hard to see but it is there.  Also see this table which provides the same information. To understand type-subtype associations, watch this video.)
  7. Disclosure Mechanics Verification is DIFFERENT for each set.  REPORT #1 and #2 know about these these disclosure mechanics rules.  This is the verification result provided from using those disclosure mechanics rules. (Note, the disclosure mechanics rules references another XBRL taxonomy schema, disclosures.xsd, that has the list of disclosure names.  Also note the arcroles that are used to represent the disclosure mechanics rules.)
  8. Report Disclosure Checklist Verification is DIFFERENT for each set.  REPORT #1 and #2 know about these reporting checklist rules.  This is the verification result provided from using those reporting checklist rules.  (Note, the reporting checklist rules also drive the "agenda" of the expert system for creating financial reports. To understand the agenda, watch this video and watch this video.)
I will continue to try and improve this, incorporating feedback that I receive from others.

Additional Information:
Super PROOF (2024-08-27)








Comments

Popular posts from this blog

Getting Started with Auditchain Luca (now called Luca Suite)

Relational Knowledge Graph System (RKGS)

Professional System for Creating Financial Reports Leveraging Knowledge Graphs