Digital Financial Reporting

Ten years ago the problem was that there was not enough validation of XBRL-based financial reports.  Today, it is fast becoming a problem that there is too much.  This is what I mean.  If everyone used the SAME validation rules to build their software and test their XBRL-based reports, that would be wonderful.  But what is happening, everyone and their brother is validating XBRL-based reports using different sets of validation rules which leads to many different answers as to whether an XBRL-based report is RIGHT or WRONG.

Now we have a semantic level validation mess.

What is RIGHT is that there are single sources for XBRL technical syntax validation provided by XBRL International.  This is excellent and contributes to interoperability.  You have:

• XBRL Base Specification Conformance Suite
• XBRL Dimensions Conformance Suite
• XBRL Formula Conformance Suite
• Inline XBRL Conformance Suite
• XBRL Taxonomy Package Conformance Suite
• Other Supporting Specifications Conformance Suites

That is all well and good, in fact it is fantastic to have the consistency and interoperability that is the result of these high-quality tools to test to make sure everything is working as expected at the XBRL technical syntax level.

However, that is not enough. The semantic level needs the same sort of things. As explained in the document, Method of Implementing a Standard Digital Financial Report Using the XBRL Syntax, move validation is necessary to control the variability that is allowed by financial reports.  How do you control that variability that is inherent with extensibility? For example,

• If a reporting entity is allowed to reconfigure the relations in a base taxonomy; what is software doing to make sure things where reconfigured correctly?
• If a report is created; what is being done to be sure there are no inconsistencies or contradictions in the reported information?
• If you were to compare information across reporting entities; what is being done to make sure you will get the compatibility that you expect (and in fact was promised by the people promoting XBRL for analysis?

Today there are multiple XBRL-based financial report validation options:

• XBRL Cloud
• SureFile
• XBRL US Data Quality Rules and Consistency Suite (marketed by AICPA)
• XBRLogic (AsReported)
• My quality measurements
• Each software vendor does their own validation

So, what is right?  What is the appropriate level of validation if you are automating internal processes ah la The Finance Factory?  How powerful is the logic being used by each of these validation approaches?  What are the problems caused by different levels of expressive power and logic?

What I am personally doing is creating a high-quality conformance suite for XBRL-based digital financial reporting.

Ask yourself a question.  Why would XBRL International go through the effort of creating conformance suites?  The reason is, that is what is necessary to have high-quality machine-readable information.  You need this not only at the technical syntax level.  You also need it at the business semantics level (as pointed out by this HL7 video, in particular SLIDE 4)

If you want to understand more about this, read Computer Empathy.