BLOG: Digital Financial Reporting
This is a blog for information relating to digital financial reporting. This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting. This is my brain storming platform. This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.
Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.
Entries from January 17, 2021 - January 23, 2021
Autoreview: A Sign of Things to Come
Autoreview is a sign of things to come. Autoreview was created by Chirag Gurbani. This video provides an overview of Autoreview (three and a half minutes). You can fiddle with an online demonstration and try Autoreview yourself.
The interface is well designed, I would say even beautiful.
Autoreview currently seems to work on top of QuickBooks accounting system data.
Imagine an integrated accounting, reporting, auditing, and analysis system with a similarly easy to use interface. That is what is on the way. Once you recognize that accounting is a mathematical model, you understand how to organize the logical artifiacts within that model, you have the software to process the data stored in that model using those logical artifacts, and you have the rules necessary to control the entire process; improving the entire process (i.e. accounting, reporting, auditing, analysis) is trivial. That is the point of my method, to organize all that stuff.
Complex? No doubt. But the complexity can, and will, be hidden behind the scenes. Modern approaches to accounting are on their way; enabled by software applications like Autoreview, Blackline's smart close, Mindbridge's AI Auditor, Botkeeper's bookkeeping automation, Engine B's Common Data Model and Audit Common Data Model, Audapio's audit automation tools, Lodgeit's reporting tools, and other such software.
Most of these software applications currently work in their own individual silos. But software vendors will wake up and recognize that they are not the center of the universe. That will change using standards such as XBRL and as professional accountants understand the possibilities.
Maybe the future of accounting is not here yet; but when you look in your rear view mirror remember that objects may be closer than they seem! Unstructured, unorganized, human dependent and therefore time consuming and error prone processes will be significantly improved.




Controlled Use of XBRL
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!




Hospital Price Transparency Rule
A law was passed last year in the United States that requires every hospital in the US to provide a publically available list of their standard charges for services that they provide in a machine-readable file. There are two sections that elaborate on these requirements:
SUMMARY
This final rule establishes requirements for hospitals operating in the United States to establish, update, and make public a list of their standard charges for the items and services that they provide. These actions are necessary to promote price transparency in health care and public access to hospital standard charges. By disclosing hospital standard charges, we believe the public (including patients, employers, clinicians, and other third parties) will have the information necessary to make more informed decisions about their care. We believe the impact of these final policies will help to increase market competition, and ultimately drive down the cost of health care services, making them more affordable for all patients.
Section E. Requirements for Public Disclosure of All Hospital Standard Charges for All Items and Services in a Comprehensive Machine-Readable File 1. OVERVIEW:
For purposes of displaying all standard charges for all items and services in a comprehensive machine-readable file, we proposed requirements for the file format, the content of the data in the file, and how to ensure the public could easily access and find the file.
Here is a good interpretation and explanation of the regulation. Here is information related to implementing the rule. Here is general information about the CMS.
The regulation does not specify specifically what syntax should be used or the specific semantics of what is actually provided. Currently, from what I have seen each of the approximately 6,000 hospitals in the United States uses whatever syntax they want and makes available whatever information they want using names and labels they make up.
An alternative is to use off-the-shelf XBRL software. I created this working prototype to help examine what XBRL can provide. You can do this using raw XBRL or Inline XBRL. I provided a simple version of both. I used XBRL Dimensions to work with the information in the form of a pivot table.
#################################



