Digital Financial Reporting

The U.S. Securities and Exchange Commission (SEC) is one of the very, very few organizations which is showing leadership and vision for the institution of accountancy related to the notion of digital financial reporting.

In a speech Accountants and Capital Markets in an Era of Digital Disruption, SEC commissioner Kara M. Stein made the following comments:

Related to the important role of accountants...

Accountants’ expertise in summarizing and presenting information – that is, data – makes them ideally suited to play a crucial role in ensuring the reliability and accessibility of the data that now drives our capital markets.

Use of common taxonomies...

For example, companies should use common taxonomies to provide up-to-date, accessible, and transparent information to investors.  This is where reporting and standards can be reimagined in the new digital world.  Let’s think seriously:  how should the delivery of information change in the digital age?  How should investors access information?  Should it be pushed to them every few months, or should it be available on-demand?

Enhancements offered by technology...

Further, technology can enhance both the delivery and usability of financial reports.  Most companies keep their financial reporting data in structured databases.  However, the data is often presented to investors and financial statement users in an unstructured manner.

Accountants can and should be driving innovation:

A lot has changed since the early 1880s.  But just as the industrial revolution drove and accelerated growth, the digital revolution is driving change.  Accountants have a unique role to play in our capital markets.  With this role comes the responsibility to move forward with strategies to help businesses, investors, and regulators in an increasingly digitally disrupted world.  Accountants can and should be driving innovations to enhance transparency, accessibility, accountability, and to promote further trust in the integrity of our capital markets.

Yet, despite all the change, at the end of the day, some things remain constant.  This Institute represents a special heritage - a commitment to the public trust that you bring to wherever you work, be it in accounting, management, as investors, or in other capacities.

Others should follow the SEC lead.  If the digital financial report is a good thing for public companies, why would it also not be a good thing for financial reporting in general?  My personal vision is that of the digital general purpose financial report.  Have a look at my personal manifesto.  That is where I am going.  If anyone has any ideas that would improve my vision, I would love to hear them.

Reimagine financial reporting.  Join the 31 others who like this idea!  Hard group to sell?  Not really.  Look at all those who are on the quality band wagon.  While digital financial reporting has to earn its right to exist, it is fast proving its worth.  Its not about volume of understanding, it is about quality of understanding.

What have you done lately to help move the world closer to digital financial reporting? Or, are you holding onto the practices of the early 1880s?

Business rules don't belong in code, they should be metadata.  Why do people sometimes put what should be metadata into code?  Well, I did it because I am not that good of a programmer.

But now it is time to separate the code and metadata.

First, let me explain the metadata.  This is a list of what I call "report frame codes".  A report frame is simply a style of reporting.  Here is the list in human readable form. Here is that same list in machine readable form (RSS). And here is another version of the list in machine readable form (RDF).

Those human and machine readable lists point to information about each report frame.  I will use ONE report frame as an example, INTBX-BSU-CF1-ISS-IEMIX-OILN.  For each report frame you get:

• A human readable summary. This lets you look at the stuff in the report frame. This includes.
  • The model structure of the report frame fundamental accounting concepts and relations between the concepts.
  • The mapping information.
  • A list of economic entities that use this style.
• A schema file. This is a machine readable version of the information in the report frame.  The mapping rules are connected to this schema file.
• Mapping rules. These are mappings from fundamental accounting concepts to US GAAP XBRL Taxonomy concepts.
• Impute rules.  These are rules for deriving values of information that was not explicitly reported.  For example, most economic entities do not explicitly report the line item "Noncurrent assets". Some do.  You can use the rules of logical deduction to arrive at the value if certain other values are reported.  For example if "Assets" is reported and "Current assets" is reported and you know that "Assets = Current assets + Noncurrent Assets"; then "Noncurrent assets = Assets - Current assets".  There is ONE ISSUE with these impute rules.  They are NOT represented in the XBRL syntax.  (I will correct that by eventually expressing these impute rules using XBRL Formula.)

So, that is all the metadata.

Now, here is my mistake.  This Excel application does the following:

1. For a list of economic entities that use the report frame INTBX-BSU-CF1-ISS-IEMIX-OILN that is provided in the "List" worksheet;
2. It gets the XBRL-based filing from the SEC web site,
   1. reads the fundamental accounting concept information per the mapping rules,
   2. goes through the impute rules to derive values for fundamental accounting concepts that were not explicitly reported,
   3. tests the relations between the fundamental accounting concepts,
   4. and then puts all that information into the Excel spreadsheet.

So, what is the problem?  If you look at the Excel code, it DOES NOT use that metadata.  The mapping rules and the impute rules are HARD CODED into the Excel application.  This Excel spreadsheet uses the style of getting the fundamental accounting concept relations of the very first version of the tool used to obtain this information.  I modified the rules to match as much as possible the current rules of the INTBX-BSU-CF1-ISS-IEMIX-OILN report frame.  So, it works; but it ONLY WORKS FOR ONE REPORT FRAME!

And THAT is the problem.

What if I wanted to do the same thing for a DIFFERENT report frame?  Simple, create another Excel application that is hard coded for THAT report frame.  Repeat this same process for all 143 report frames!  Not a good idea.

Alternatively, the Excel application could be modified to use the metadata above rather than hard coding the mapping rules and impute rules with massive numbers of IF...THEN statements that are hard to change, hard to maintain, and therefore not very flexible.

A better way is to point the Excel application to a report frame, read the metadata for that report frame, and then point to the list of filings with that report frame.

If someone who understands how to program reads the code, they will immediately see the problems of the IF...THEN statements in the code.

(PLEASE NOTE!!! The metadata available now is not the most current version of this metadata.  The reason is that I am constantly updating this metadata for new mappings, new impute rules, fixing bugs, adding new report frames and so on as I try and get the fundamental accounting concepts dialed in.  If you need the most current version of the metadata please contact me.  I will update this information publically at the end of the year.)

(PLEASE NOTE!!!!  All of this metadata is represented in XBRL, except the impute rules.  Not representing the impute rules in XBRL was a mistake.  Future versions of this will also provide the impute rules in XBRL Formula.)

Per SFAS 8 issued by the FASB, page 19, QC23:

"Comparability is not uniformity.  For information to be comparable, like things must look alike and different things must look different. Comparability of financial information is not enhanced by making unlike things look alike any more than it is enhanced by making like things look different." 

A form is uniformity.  Financial statements are not forms.  And while financial statements are not forms, they are likewise not random either.

I put together a little presentation about the comparability of financial reports for something and figured that I would share it.  If you don't want to read through that entire presentation, I provide the cliff notes here in this blog post but the entire presentation is worth watching.

First, it is important to understand what the FASB means by "comparability (including consistency)".  That is explained in SFAS 8 which is referenced above.  Here is the pertinent section of that document: (from page 19).  This is well stated, very clear, and every word is worth reading:

Comparability:

• QC20. Users' decisions involve choosing between alternatives, for example, selling or holding an investment, or investing in one reporting entity or another. Consequently, information about a reporting entity is more useful if it can be compared with similar information about other entities and with similar information about the same entity for another period or another date.
• QC21. Comparability is the qualitative characteristic that enables users to identify and understand similarities in, and differences among, items. Unlike the other qualitative characteristics, comparability does not relate to a single item. A comparison requires at least two items.
• QC22. Consistency, although related to comparability, is not the same. Consistency refers to the use of the same methods for the same items, either from period to period within a reporting entity or in a single period across entities. Comparability is the goal; consistency helps to achieve that goal.
• QC23. Comparability is not uniformity. For information to be comparable, like things must look alike and different things must look different. Comparability of financial information is not enhanced by making unlike things look alike any more than it is enhanced by making like things look different.
• QC24. Some degree of comparability is likely to be attained by satisfying the fundamental qualitative characteristics. A faithful representation of a relevant economic phenomenon should naturally possess some degree of comparability with a faithful representation of a similar relevant economic phenomenon by another reporting entity.
• QC25. Although a single economic phenomenon can be faithfully represented in multiple ways, permitting alternative accounting methods for the same economic phenomenon diminishes comparability.

US GAAP is an excellent financial reporting scheme because it strikes a good balance between the ability to compare and the ability accurately report the financial condition and financial position of an economic entity. When trying to implement "comparisons" in software, it is very important to understand the goal of comparability the financial reporting scheme enables.

The first key idea one needs to understand is the difference between a "concept" and a "preferred label for a concept".  For example, if you see "Revenue" in a financial report, the reporting entity might mean "Operating revenue" or they might mean "Operating and nonoperating revenue" or perhaps even something else.  So while the label might say "Revenue", the concept they are reporting could be "Operating revenue" or maybe "Nonoperating revenue".  And the first step needed to understand the differences between concepts is to get a list of those concepts.

After that, you can look at how different reporting entities use those concepts.  Theoretically, if you are working with one specific industry group and the economic entities in that industry group all use the same reporting style, then you CAN think of that specific set of financial reports as a "form".  One of the most consistent reporting styles of public companies is that which is used by those that report using the "interest-based revenues" approach.  i.e. banks.

If you go to this web page and grab the Excel spreadsheet with the link "Compare All Excel Code (ZIP)" and then run the algorithm (click the button), the algorithm goes and grabs the fundamental financial information from the balance sheet, income statement, cash flow statement, and statement of comprehensive income for 535 financial institutions that use an interest-based revenues style of reporting. (Takes about 15 minutes to get all that information).

The information is very consistent.  For the 535 entities there are about 50 concepts.  535 times 50 equals a total of 26,750 facts that the Excel macro looks for.  There are about 120 inconsistencies.  120 inconsistencies divided by 26,750 facts equals an inconsistency rate of .44% (less than 1%), or an accuracy rate of 99.55%.  Not bad quality.

But what if you wanted to use that same Excel algorithm to analyze a regulated public utility.  How good would that algorithm be?  Not as good because the reporting styles of banks and regulated public utilities is different.

What if you created a different algorithm for regulated public utilities and ran that against companies that were regulated public utilities.  The success rate would likely be better.

But then, what if you wanted to COMPARE a bank and a regulated public utility for some reason. How would that work?  Well, you would have to map the reporting style of a regulated public utility to the reporting style of a bank that used interest-based revenues style of reporting.  That requires judgement.

So what is the point?  Here you go:

• Financial reports are not "uniform" or forms.  But when you compare economic entities that use the same reporting style, you can treat the information more like a form.
• When you cross reporting styles, comparisons are possible but require judgement.
• If you want to see how to compare, all the moving pieces, go look at the code of that Excel spreadsheet I referenced above.
• Automating comparisons using machines such as computers takes metadata, you have to document the patterns and then explain those patterns to the software.

More and more important pieces are falling together.  Remember, my background is accounting and not information technology or knowledge engineering.  What I am realizing is that many technical people either don't know or cannot properly explain extremely important ideas which business professionals need to understand in order to make important decisions related to implementing a technology which they will then use.

For example, consider the notion of "decidability" which I have talked about before.  That idea is linked to the notion of a Turing Machine.  And that is linked to the notion of a Finite-State Machine.  And that is linked to the Chomsky's Hierarchy of languages. (Here is a tutorial that explains this stuff.)

Make your head spin?  Yeah, mine too.  But my question is this: Why in the 16 years that I have been working to figure out and create XBRL and make it work for financial reporting with a bunch of world-class technical people did this stuff never come up? The closest to these sorts of important discussions what I remember getting is when we discussed the "closed world assumption" as contrast to the "open world assumption".

This is incredibly important stuff.  Understanding these things is critical to making a system work correctly.

Why is this important?  Here is an example.  A financial report at any particular time has a "state".  You can prove this by looking at a lot of financial reports, say 7000 financial reports given to the SEC, examine them, and you can see that, again as an example, they all are consistent with a set of fundamental accounting concept relations. Now, the 22 some relations that I am looking at is only for testing purposes.  There are WAY, WAY more relations than that which exist in a financial report.

There are events that occur to an economic entity that creates a financial report: transactions, actions, circumstances, phenomenon, and other such events.  And so that state changes.  Kind of line an event driven finite state machine.  Accounting systems track those changes in state.

Heretofore, accounting systems worked with data.  But what if accounting systems worked with information?  What if there were a Chomsky Type-3 language that could be used to provide information to an accounting system (not data that goes into a database) and finite-state automation could be achieved?  What if the events are all perfectly tracked with that event driven finite state machine and then you wanted to report the next financial report for the economic entity?

Maybe your imagination will allow you to understand what I just said, maybe not.  If you do understand, then it will now make a lot more sense why I have been reverse-engineering the financial disclosures, reporting styles, fundamental accounting concept relations, and other metadata related to financial reports.

Can a digital general purpose financial report be useful to the creators of the report, not just the users of the information?  Well, first off; because there are so many details involved in creating a correct XBRL-based digital financial report for those that are required to create such reports and provide those reports to regulators, that is the only real practical way to create the XBRL-based reports that must be created today.   So, that tool will exist.  But the question is, can that application be compelling enough to use even when you don't need to press that "Save as XBRL..." button.

We shall see, because I am going to build that tool. Stay tuned.