Digital Financial Reporting

I got my copy of The XBRL Book: Simple, Precise, Technical:

How about you?

I have always been bothered by the way most programmers programmed.  I did not know why I felt that way, but I did.  I finally received an explanation.

According to Ilya Suzdalnitski per his article Object-Oriented Programming is The Biggest Mistake of Computer Science; object oriented programming (OOP) was a very big and a terribly expensive mistake.

Why? Because it can be very hard to maintain and can be very unreliable.  Read the article whether you are a programmer or not.  Give that the importance of computer algorithms will increase significantly over the next 50 years, this is a big deal.

XBRL-based financial reports should be deterministic.

For about 15 years I have been poking and proding XBRL-based financial reports and the XBRL taxonomies used to create them.  The 85 pages in the documentation and this suscinct set of examples is what I have come up with for proving that reports and their models are functioning properly.

Essentials of XBRL-based Digital Financial Reporting helps professional accountants understand the dynamics of an XBRL-based financial report when creators of reports can "alter" or "reshape" or otherwise modify the report model.  US GAAP, IFRS, and UK GAAP are financial reporting schemes that allow for such model modifications.

Any feedback that contributes to improving this documentation will gladly be accepted.

Every XBRL-based financial report fits into the model documented.  Here is a simple knowledge graph of the Microsoft 2017 10-K.  Here is detailed analysis of that Microsoft report.  Same deal for Amazon, Apple, Google, Facebook, and Salesforce. Same deal for all other US GAAP reports and IFRS reports.

Really pretty straight forward once you understand the Essence of Accounting and Computational Professional Services. It just took a while to put the pieces toghether because this is so novel and complex. This is an example of what the information in a financial report looks like.  The information forms a graph.  The more nodes and edges; the easier it is to control report quality.

Dave McComb's article The Data-Centric Revolution: Data-Centric vs. Application-Centric points out problem that causes software to be 10 times and even 100 times more complicated than it really needs to be.

When XBRL International first got going, there were discussions about making sure people's thinking was "data centric" instead of "document centric".  What Dave McComb is pointing out is the same sort of issue except being "application centric" instead of "data centric".

All of this is explained in more detail here by Alan Morrison.

What if you completely removed all applications, focused on the information, and then rebuilt systems to interact with the information from the information's perspective rather than the application perspective?  That is what I do here with this effective automation of the record to report process.

What if you used this approach as "modern accounting" is built out? Billions of dollars could be saved.

Google seems to get this perhaps.  Google appears to be trying to be the "operating system for personal finance".  They could give Intuit a run for their money.  Personal and micro organization accounting could be the first to be reorganized to be data centric as opposed to application centric.

Today, XBRL International reports that there are 180 XBRL projects around the world. (Here is an Excel spreadsheet with the projects.)

Those 180 XBRL projects are in 60 different countries, The Netherlands has the most projects with 15.

There are a total of 195 countries, 60 different countries have projects; so about 30% of all countries currently have XBRL projects.

That is pretty satisfying.  If you want to read how all this began, I would recommend reading this blog post and this article, XBRL: The Story of Our New Language, by Karen Kernan of the AICPA.

All of this started in a CPA firm in Tacoma, Washington!

The world is well on its way to a more modern approach to accounting, reporting, auditing, and analysis.  If you want to get on this train and don't quite know where to start; I would recommend starting here: Essence of Accounting.

XBRL-based financial reporting is not about meeting a regulatory mandate.  Every company will ultimately choose to use XBRL-based digital financial reporting.  I know this is hard to believe.  But once you see the right software applications, then it will be very easy to understand why this is the case.  US public companies are missing an excellent opportunity to understand XBRL-based financial reporting.  Most are not taking advantage of that opportunity.  A former SEC Chief Accountant suggests that companies take XBRL more seriously.  Few likely will.  The few will have an advantage over the others.

If you contrast self-driving cars and XBRL-based financial reporting, both of which work using artificial intelligence and machine-readable rules, you can learn about the ramifications of not thinking through XBRL-based financial reporting rigorously.

Consider this article by Forbes, Self-Driving Cars and The Chicken that Crossed the Road. As the author points out, "Chickens can be quite serious business."

What should a self driving car do when the car sees a chicken crossing the road?  Should the self-driving car algorithm (a) allow a chicken to be killed to reduce risk that the car's drive be killed or (b) make every attempt to save the chicken?  What about a dog?  A cat?  A rat?

Can artificial intelligence even distinguish between a chicken, dog, cat, rat, or a human that spontaneously jumps in front of a self-driving car.  How well will that algorithm work?  How well does it need to work?

Many similar issues exist for XBRL-based financial reporting.  You have to understand how dumb computers really are.  Computers are driven by rules.  Who do you want creating those rules?  Programmers???

(If you are interested in these sorts of issues, I would recommend reading Computational Professional Services.)

Self-driving cars are classified by level.  For example: 

• Level 0: No Automation. (This describes your everyday car.)
• Level 1: Driver Assistance. (Here we can find your adaptive cruise control and lane keep assist to help with driving fatigue.)
• Level 2: Partial Automation.
• Level 3: Conditional Automation.
• Level 4: High Automation.
• Level 5: Full Automation.

When you discuss "automation" it is important to understand the definition of the term you are using; this is true for self-driving cars and XBRL-based financial reports.

How many accountants are discussing this?  How many even understand that this is something that needs to be discussed and figured out? What else needs to be figured out?

Not all XBRL projects are the same.  Of the 180 projects there is a critically important distinction that most people don't think about.  When XBRL is used to represent information contained in a fixed form that cannot be changed, XBRL is easy to implement and make work.

But, if an economic entity is allowed to "adjust" or "reshape" or "modify" or otherwise modify the report model; how do you control those adjustments/modifications/alterations?  Sophistocated financial reporting schemes such as US GAAP, IFRS, UK GAAP and others allow for many sorts of adjustments or modifications or alterations, whetever you might want to call them.

XBRL-based financial reports submitted to the SEC allow for alterations and they have significant quality problems.  See my measurements here.  Others have faulty reports.  See here and here.

ESMA will have the same mistakes; maybe a few less because of a few lessons learned.

Professional accountants need to be ahead of the curve on this, not behind the curve.  ESMA requires that XBRL-based reports need to be true and fair representations whether they are human-readable or machine-readable and the reports will be subject to audit.  We will see how that goes.

As a professional accountant how much of this do you understand?  How much should you understand?  How exactly did you reach your conclusion?