Digital Financial Reporting

The U.S. Chamber of Commerse has created excellent introductions to HTML, HTML5, CSS, and XML.  You can find those here: 

• HTML (Should use HTML 5)
• HTML 5
• CSS
• XML

I am trying to get them to add an introduction to XBRL.  Also, an introduction to artificial intelligence and digital distributed ledgers would be nice.

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.

#################################

Price Transparency and Variability in U.S. Health Services

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.

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?

This interview of Alan Morrison of PriceWaterhouseCoopers is one of the best articles I have read in quite a while: The Data-Centric Future Is Here, It Is Just Not Evenly Distributed: A Dialogue with Alan Morrison, by Teodora Petkova.

Here are some interesting excerpts: (the entire article is worth reading, takes about 15 minutes)

Standards:

“There’s no machine understanding without shared semantics, and no shared semantics without standards.”

Drunk looking for his keys:

That problem, in other words, is the “drunk looking for his keys under the lamppost” problem. “Why are you looking under the lamppost, if you think your keys are over there in the dark?” he’s asked. “Because under the lamppost is where the light is,” the drunk answers.

Bits and bytes in buckets:

In reality, “knowledge”, “content” and “data” are all the same thing to a machine–bits and bytes in buckets that represent people, places, things and ideas. These representations are often poorly described.

Semantic Web:

We were quite bullish on the semantic web back then. In retrospect, there were four things we didn’t account for enough in our forecast:

 

• How alien the semantic web methods would be to enterprise IT and data management shops; 
• How often enterprises couldn’t see the forest for the trees because of their preoccupation with applications, rather than interacting with data/information/knowledge more directly. 
• How much tribalism and just pure ignorance or unwillingness of one tribe to learn from other tribes inhibits how technology evolves, and 
• How much compute, networking and storage would have to improve to operationalize compute-intensive semantic graphs at scale. Eleven years later, enterprises are still struggling with these problems.

 

Knowledge Graphs:

A commitment to knowledge graphs gives these three groups the opportunity to share one method and one toolchain to contextualize and better describe data, content and knowledge as commonly modeled representations. The right leader can understand this bigger picture and break down the barriers between the teams and departments.

Utility of a method:

The key challenge is how to update and broaden the mentality of the organization with whatever methods you’re using. The compulsion for most is to see every problem as a nail and use RDBMSes as a hammer, along with the associated one database per application development habit, are just plain wasteful. The impulse for most is to look first to an RDBMS, because that’s what’s been comfortable for most.

Waste:

Companies are spending 10 to 100 times more on development than they need to, he says.

Need for a "guerilla team":

Thus the need for a guerilla team inside each organization, people who do have the passion and knowledge, a team that has leadership backing. That passionate core needs to exist in every company serious about data/information/knowledge-centric transformation.

Software Wasteland (book)

"This is the book your Systems Integrator and your Application Software vendor don't want you to read. Enterprise IT (Information Technology) is a $3.8 trillion per year industry worldwide. Most of it is waste."