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.

Are the numbers right?  Well, actually, many times no.  In an AccountingToday article, Are the numbers right?, Ranica Arrowsmith points out:

• Finance execs blame human error for inaccuracies
• Lack of automation contributes to human error
• Clunky spreadsheets and outdated processes contribute to an inability to automate

Accounting and reporting processes tend to be outdated.  Manufacturing processes benefited from applying Lean Six Sigma philosophies and techniques. Further, the use of robotics in the manufacturing process improved processes.  The typical accounting department tends to not understand Lean Six Sigma philosophies and techniques and uses little to no real automation.

Don't think you can automate tasks and processesf?  Think again.  Read what Deloitte believes can be automated. Now, Deloitte does not tell you HOW to automate processes.  Also, I personally believe that Deloitte is over stating the opportunity.  Some tasks and processes can be automated.  Here are the basics as to how:

1. Put information into structured and therefore machine-readable form.  Computers cannot reliably process unstructured information or information structured for presentation, such as spreadsheets. (Don't understand?  Watch How XBRL Works.)
2. Create machine-readable rules.
3. Use software to compare the machine-readable structured information with the machine-readable rules to make sure the information is mathematically consistent, logically consistent, etc.

Automated processes are already being used.  Unfortunately, not by the creators of financial reports and not remotely as extensively as is possible. But, software vendors such as XBRLogic, XBRL Cloud, and heck, I can even verify information using my processes.

Ultimately, intelligent software agents are going to be doing a lot more checking of the easy mundane and repetitive review tasks.  That will cause two things to happen.  First, the mundane and repetitive tasks will automated thus free up accountants.  Then, accountants will have more time to focus on the tasks that cannot be automated.

With the volume of information seemingly increasing at increasing rates and the complexity of information increasing as well; reviewing work is not just a matter of throwing even more bodies at the problem.

You can download a study undertaken by Blackline, Mistrust in the Numbers. Here are two nice infographics provided by Blackline:

• Financial Reporting Errors Eroding Trust and Wasting Valuable Time
• Is There a Reality Riff?

Interesting stuff.