Digital Financial Reporting

Blackline properly makes an important distinction between the “discovery of fire” and the “controlled use of fire” in this article The Case for Continuous Accounting.

"The discovery of fire (more accurately, the controlled use of fire) enabled early humans to cook food, repel carnivorous beasts, and survive past the ripe old age of 22; thus radically altering the course of homo sapiens' future."

In 1903, Orville and Wilbur Wright achieved the first powered, sustained and controlled airplane flight.  They were not the first to fly; they were the first to be able to control flight making flight predictable and repeatable.  (This story is incredibly interesting, I recommend the book by David McCullough: The Wright Brothers). Everything else achieved between 1903 and now is an incremental improvement to the fundamental ability to control powered sustained flight.

It is relatively easy to control the use of XBRL if the information represented using XBRL is effectively a “form”. That is how most if the 180 or so implementations of XBRL leverage the XBRL technical syntax, to exchange what amounts to a form.  Creators of reports cannot change the form.  This form-based approach is used by the data point model approach.  There is nothing wrong with using this approach if that is your use case. XBRL can be effectively used for this type of business use case.

Financial statements created using financial reporting schemes such as US GAAP, IFRS, UK GAAP, and many other financial reporting schemes are not forms.   In these cases the report model can be "altered" or "reshaped" or "modified" within permitted boundaries. This is explained in the Essence of Accounting which both accountants and I hear software engineers are finding quite useful. 

And so, financial reports are not “forms”; but likewise they are not “random” by any means either.  Financial reports fall between "forms" and "random".  So how do you control adjustments to the report model; distinguishing model adjustments that are permitted from those adjustments that are not permitted?  The answer is rules.  Rules are used to control model adjustments; distinguishing what is permitted and what is not permitted.  Without rules you get anarchy and the quality issues that are being experienced in XBRL-based financial reports submitted to the SEC. (Quality issues 1 | Quality Issues 2 | Quality Issues 3 | Quality Issues 4 | Quality Issues 5)

Faulty XBRL is not a fringe phenomenon. Faulty XBRL is what you get when you are not proactively controlling your processes.  You get the quality you want by (a) proactively establishing rules and (b) effectively measuring your XBRL-based reports against those rules.

When the report model can be altered or reshaped by report creators; it is necessary to control those modifications.

Faulty XBRL-based financial reports submitted to the SEC are well understood.  I predict, and others predict, that XBRL-based financial reports that will be submitted to the ESMA will suffer similar quality issues.

So how exactly do you “control” XBRL-based financial reports where these alterations or modifications or other reshaping can occur?   What rules do you need to provide?  The answer is to use rules and a rules engine to process the rules to keep the alterations/modifications within specific and permitted boundaries.

That is what I am trying to communicate within the proven best practices method that I have created and the document Essentials of XBRL-based Digital Financial Reporting. Those two document provide the specifics that you need to create fundamentally correct and proper functioning XBRL-based financial reports.

Because of the high level models of accounting like the double entry accounting model and the accounting equation; accounting, reporting, auditing, and analysis has a lot “control points”.  These control points are a very good thing; they make automation easier.

General business reporting typically has fewer such control points; but they do exist.

The more control points, the more control. The more control, the better the quantity. The better the quality, the more effectively information can effectively be exchanged (i.e. no garbage in, garbage out problems).

I predict that accountants are going to get continuous accounting working before Elon Musk gets his self-driving cars to Level 5 (fully autonomous). In fact, I already have a working prototype of XBRL-based “record to report”.

I am certain that programmers and accountants who are smarter and cleverer than I am will improve upon what I have created or come up with something completely different and better that works. Heck, others might even already have something better and are just keeping their cards close to their chest. If you want to be one of those clever accountants or programmers; have a look at what I have provided and perhaps it can jumpstart your efforts. Things like “always on audit” and “continuous accounting” and such will be part of “modern accounting”.

XBRL is proving to be quite useful if you understand the specific techniques necessary to use it effectively.  And this really is not about XBRL per se.  Any problem-solving paradigm will do the trick.  Over time, it is inevitable that more and more best practices will be identified and things that don’t work will be dropped. This is part of anatural evolution process.

Heck, XBRL might not even survive long-term.  But something like XBRL, probably even better than XBRL, will persist.  Me, I think there is a place for XBRL.  It is powerful enough, it is easy enough to use, and XBRL is used by 180 implementations in 60 or so different countries.

Maybe XBRL will not have an impact as profound as the controlled use of fire or controlled flight; but the impact will be will be significant.  Be sure to be ready!