Digital Financial Reporting

One form of knowledge is know how. Know how is practical knowledge about how to accomplish something.

It has taken roughly 10 years, but I can now say that the implementation framework for XBRL-base financial reporting is complete, tested, and proven to work.  All of this framework has been implemented in a working proof of concept by one software engineer and a very signification portion of the framework has been implemented in at least one commercial software product, XBRL Cloud.

This open source framework is useful for creating financial reports, verifying that the reports were created correctly, analyzing or otherwise using information from reports, and processes that feed information into a process that provides information that will end up within a report.

Why is this important?  It is important because while others can talk about things like "financial transformation" and the "modern finance platform" and visions such as "The Finance Factory" and "accounting process automation" and all the other ways that technologies like artificial intelligence are going to impact accounting, reporting, auditing, and analysis; I don't have to just talk.  I can show.  I can make this tangible.  I have helped a handful of people develop the know how. We know that all this can work and we know how to make this work effectively.

Others have been focused on helping companies meet regulator mandates; regulators that are not too concerned with quality or efficiency or effectiveness. Others have been developing know how in the wrong areas in my view. Software vendors that do not have the capability to deliver high-quality can never creating something that will work.  Reliability and high-quality is a fundamental capabilities, they are requirements.

Here is the stuff that will be automated:

(Click image for larger view)

Here is an open source implementation of an XBRL processor, XBRL formula processor, and other XBRL related stuff using PHP.

Something occurred to me.  I wonder if it is possible to convert PHP to ASP.Net.  Well, it seems like it is possible.

One thing that is unique about this project is that the software engineer has taken the time to document things for other software engineers that help them better understand things that I tried to explain but seem to be coming up short.

This is worth checking out.

I put together this little self guided tour of XBRL-based financial reports.  If anyone has any feedback that would help make this easier or provide additional helpful information please feel free to send me comments.

Here are some key ideas to think about as you look at the XBRL-based digital financial report:

• Alternative reporting format: An XBRL-based digital financial report is an alternative to paper or "e-paper" financial reports.  In today's digital environment a digital report provide benefits.
• Case for XBRL-based digital financial reports: Benefits of XBRL-based reports include greater transparency, better capital allocation decisions, and better functioning capital markets.
• Quality matters: XBRL-based reports are not that useful if the quality of the information in the report is not high.
• Improved financial report creation processes: Not only are XBRL-based digital reports beneficial for users of information, they are also beneficial to creators of reports.  The digital nature of reports enables different processes to be used to create reports.
• Financial transformation and the modern finance platform: Improved processes will transform accounting, reporting, auditing, and analysis.
• Don't panic: Prepare yourself.
• Paradigm shift: What is occurring is a paradigm shift; not an incremental innovation.  The changes will be distuptive, maybe even foundational.  You cannot use yesterday's paradigm to understand this new paradigm.
• Computer empathy: You don't need to "learn to code".  You don't need to learn about technology.  What you need to understand is how computers really work. That is the best way to understand what is and what is not possible.

One of the many benefits of the FFIEC's XBRL-based call report information reporting system was the reduction of mathematical errors in the bank call reports.  In the last reporting period of the old system there were 18,000 mathematical errors.  In the first reporting period of the new XBRL-based system there were 0 mathematical errors.

How did the FFIEC achieve this result?  If you go to the PDF referenced above and compare the old data collection and management process on page 9 to the new data collection and management process on page 10 you can see exactly what the FFIEC did.  Basically, the FFIEC moved the validation of information from a manual, after call reports receipt validation process, to a process where the inbound reports were AUTOMATICALLY validated prior to a report being accepted by the FFIEC.

This graphic shows where inbound call report validation exists in the FFIEC's new system which went live in the third quarter of 2005:

That is right, the FFIEC does not accept call reports from banks if the mathematical relations are not what they are expected to be.

So, why is it that the FFIEC can validate the mathematical relations within reports but the SEC cannot verify the high-level relations of reported financial information (i.e. there are mathematical errors in the high-level fundamental accounting concept relations)?

One would thinkthat the answer to this question would be, "Because the FFIEC call reports are basically forms with known relations and validation rules but the financial reports submitted to the SEC are not forms, the information is more variable."

But, that is NOT THE REASON.  Yes, it is true that bank call reports are forms and that it is an order of magnitude easier for the FFIEC to verify their reports because they are forms.  And yes, it is true that financial reports have significantly more variability.

And so, basically what the SEC needs to do is take that variability into consideration and apply different inbound validation rules to different reports; but fundamentally, the SEC can achieve the same result as the FFIEC.  This blog post explains a technique for achieving exactly that result.

Basically, rather than have ONE set of business rules like the FFIEC can because call report information is a form; the SEC needs to have separate sets of validation rules for each reporting style used by public companies.  As I have shown for both US GAAP and IFRS, about 80% of reports fit into less than 20 different reproting styles.

What if someone like the SEC and/or FASB and/or IFRS Foundation made these reporting rules, the fundamental accounting concept relations of high-level information available in machine-readable form?  What if a public company submitting a report had to "declare" their reporting style or "configure" the high-level relations to indicate what relations they were using in their report?

Or, what if the FASB/IASB published these rules in machine-readable form in addition to the information that they make available in books for humans to read. What if software vendors could allow the accountants creating reports to configure these rules to help the creator of the report verify that the report is being created correctly?

Basically, the variability of reports needs to be managed in some manner.  The variability is not random.  The term generally accepted accounting principles(GAAP) is used for a reason. There are standards for reporting financial information.  Again, yes, variability is allowed. I would point out that financial institutions that report to the SEC consistently use the same interest based revenues reporting style.

There are many technical approaches that could be used to manage this variability such as the Zachman framework. I am sure there are plenty of other approaches.

Bottom line: So here is the bottom line.  There are a lot of different ways that this could be done, but the financial reports submitted to the SEC can be verified for consistency with expected high-level financial accounting relationships in reported information.  It is an order of magnitute harder than what the FFIEC's situation, but it is very achievable.  The question is what is the best approach for achieving this objective and improving information quality.