Digital Financial Reporting

In his book Saving Capitalism, Robert Reich describes three categories that all modern work/jobs fit into: (page 204)

• Routine production services which entails repetitive tasks
• In-person services where you physically have to be there because human touch was essential to the tasks
• Symbolic-analytic services which includes problem solving, problem identification, and strategic thinking that go into the manipulation of symbols (data, words, oral and visual representations).

In describing the third category, symbolic-analytic services, Mr. Reich elaborates:

In essence this work is to rearrange abstract symbols using a variety of analytic and creative tools - mathematical algorithms, legal arguments, financial gimmicks, scientific principles, powerful words and phrases, visual patterns, psychological insights, and other techniques for solving conceptual puzzles.  Such manipulations improve efficiency-accomplishing tasks more accurately and quickly-or they better entertain, amuse, inform, or fascinate the human mind.

And of course you as, "What the heck does this have to do with XBRL or financial reporting?"

Why this is interesting to me is the third category of work/jobs: symbolic-analytic services. Financial reporting, or at least many tasks related to financial reporting, fall into the symbolic-analytic service category.

How many professional accountants think of their job as "rearranging abstract symbols using a variety of analytic and creative tools".  Not many.  Most professional accountants just do the work.  Besides, what the heck is an "abstract symbol"?

Consider the ledger:

From http://digitalroam.typepad.com/photos/uncategorized/2008/04/19/ledger.jpg

There is nothing natural about the ledger.  A ledger was an invention of man. Those columns are abstractions.  The numbers and other information that go into the columns are symbols.  The ledger is a useful idea.

A table is likewise a useful idea, an abstraction.  A table has rows.  A table has columns.  A table has cells which are the intersection of a row and a column.  So actually, do you realize that a table can have way, way more than rows, columns, and cells?  What about groups of rows.  And groups of columns.  What about a row that spans more than one column.  You might not have known that there is actually a specification which describes tables, the CALS Table Model.

Why would someone create a written specification for a table?  Well, that is how you make it so machines can read a table and that tables created on one machine can also be read on another different machine.  A specification explains how to create tables consistently.

An electronic spreadsheet is really nothing more than a fancy table that is machine-readable but also readable by humans.  At first Excel was a proprietary Microsoft specification but eventually a standard spreadsheet model was created, OpenOffice.

The point of mentioning this is that spreadsheets are creative tools for rearranging abstract symbols.  This tool, similar to a table in that it has rows, columns, and cells; but also adds the idea of a sheet and a workbook.

You can think of a digital financial report as a spreadsheet on steroids.  First of all, a digital financial report is more like a dynamic pivot table than a static table.  You can see this by checking out any XBRL-based public company financial report submitted to the SEC here using the XBRL Cloud Viewer. Just click one of the "View" buttons in the "Interactive Reviewer" column. (Try pivoting the [Axis] within a report.)

So back to the notion of symbols.  An alphabet is a set of symbols. Morse Code is a set of symbols. While you can write Morse code or the letters of an alphabet, you can also make it so machines can understand the symbols.  An ASCII, American Standard Code for Information Interchange, is a set of machine readable codes for representing an alphabet in machine-readable form. UNICODE is the most current set of machine readable codes.

XBRL is a global standard for representing the information that is contained in a financial report in machine-readable form.  Consider this one small part of a financial report:

Click for larger image.

You can represent the rows, the columns, and the cells of the disclosure above.  You can represent the relations between the total with the information that makes up the total (i.e. you can articulate the the information foots).  You can articulate that the PARTS of some WHOLE add up to that WHOLE, i.e. the WHOLE is the sum of the PARTS. These are only examples of some of the possibilities.

Creating an XBRL-based financial report involves rearranging abstract symbols using creative tools. What is different is that the rules related to how the information can/should be arranged is in machine-readable form and therefore a computer can have that knowledge and provide this knowledge to a user of the computer.  Before digital financial reporting knowledge was only in the minds of the professional accountants.  This is because no one took the time to represent the knowledge in machine readable form.  All that changes with XBRL-based digital financial reporting.

Today, only minor pieces of knowledge are represented in machine-readable form.  For example the fundamental accounting concept relationsof US GAAP primary financial statements, some basic disclosure information, and some other stuff. These are only the tip of a much larger iceberg.

What if a disclosure checklist was represented in machine-readable form and could be used to automate 50% of what you do manually today?  Now, 50% might not be the right number; it is likely on the conservative side.  I know the automation percentage is not 100% because I understand disclosure checklists and I understand what computers are capable of.  I will stick with 50% for now, could be as high as 80%. But undoubtedly, digital financial reporting will change the work practices of professional accountants.

The benefits of digital financial reportingare hard to argue against.  It is only a matter of time before the transformation occurs.  Resistance is futile, you will be assimilated!  Digital financial reporting is not only inevitable, it could perhaps even be imminent.  Time will tell.

If you want to understand the abstract symbols of a financial report, read the Financial Report Semantics and Dynamics Theory. If you want to dig even deeper, read the Digital Financial Reporting Manifesto. Or, check out the series of videos I created, Introduction to Digital Financial Reporting Terminology.

Why would you do that?  Here is another thing Mr. Reich mentioned in his book,

We are faced no just with labor-replacing technologies but with knowledge-replacing technologies.

When a transformation occurs there are winners and losers.  Be sure to end up on the right side of that equation.

I have updated the publicly available fundamental accounting concept relations metadata. This metadata is not as straight forward as I would like it to be; but it does work.  This metadata is want drives the public company quality measurements that I make available each month.  Anyone who has the intellectual curiously to dig deeper into how all that works can do so by analyzing this metadata.  All the information you need to know is available.

Now, this is important.  While this information is very good, the technical organization of the information is not.  My current organization is too hard to maintain and I know of better ways to organize this now that I understand what I am working with.  I explained this here and here.  Besides, I don't want two approaches to doing the same thing; and so I am going to refactor the fundamental accounting concept relations metadata.  The goal is to make it pure XBRL, easier to maintain, and one approach that works for both the primary financial statements and the disclosures.

Here is a summary of the mistakes that I made:

• I represented the impute rules in fairly easy to use proprietary format; but they can be represented in global standard XBRL Formula and then can be better organized to make maintenance 80% easier.
• The notion of a "report frame code" is not necessary.  For example, consider the code "COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6".  If only one of the pieces changes, I have to create an entirely new code and therefore you get far too many permutations/combinations to manage.  Which reporting style a filing uses can be dynamically determined using software and therefore the codes are not necessary.  But to do that, a more sophisticated process must be used which is beyond my programming skill level.
• The mapping rules are expressed in XBRL using XBRL definition relations which is good; but the rules are grouped by report frame code and they should be grouped by network.
• As I mentioned in this blog post, I have only moved 91.4% of all filers (that is 6,158 of public companies) to more specific reporting styles as opposed to general reporting styles.  I still need to move the remaining 8.6% (that is 577 public companies).  Being more specific is better because it makes the impute rules easier to create.
• Finally, I need to organize the information along the lines of how disclosures are organized because the primary financial statements and disclosures are really the same thing: pieces of a financial report.

And so, if you are going to use any of these ideas (which I would encourage); don't repeat the same mistakes that I made!  Learn from my mistakes.

More and more people are complaining about the quality of XBRL-based public company financial reports to the SEC. It is only a matter of time before public companies feel more pressure to get their XBRL formated information correctly dialed in.

This graphic shows public company XBRL-based digital financial report submitted to the SEC quality as measured by a set of basic, common sense fundamental accounting concept relations. These measurements were taken March 1, 2014; December 27, 2014; and December 31, 2015:

(Click image for larger view)

There are three possible reasons for an inconsistency with one of the basic, common sense fundamental accounting concept relations:

1. Filer error
2. US GAAP XBRL Taxonomy error
3. Test metadata error

During that period of time I have learned a great deal and made some adjustments which improved the process of using automated machine-based processes to check the consistency of public company XBRL-based digital financial reports.

• I started with one single set of these basic fundamental accounting concept relations. But this set was too general.  For example, different relations apply to banks which use interest-based reporting and commercial industrial companies.
• I took the single set, added the notion of what I called "report frames", and came up with a more flexible approach to articulate and manage these basic, common sense fundamental accounting concept relations.  But I made these report frames to general in many cases.
• I fiddled around with reporting frames more and realized that a better term than "reporting frame" or "reporting palette" was simply "reporting style".
• I embraced the notion of reporting style. I was able to document all of these reporting styles and learned more and more about the different reporting styles used.
• I realized that looking at the reporting style of each report was not the way to look at this, rather it was better to look at the specific parts of the report: style of the balance sheet, style of the income statement, style of the statement of comprehensive income, cash flow statement.
• Finally, I realized that I don't want to create a few general reporting styles. Rather, what I need is precise and specific reporting styles because of the ways public companies report. More precise reporting styles make everything work better plus maintenance of the machine-readable rules is easier.

And so, during the month of December I converted literally hundreds of public companies from less precise general report frames to more precise specific report styles.  One of the side benefits of the more precise report styles is that extracting information is also safe and reliable.  Currently,

• 91.4% of all filers (that is 6,158 of public companies) fit into one of these more precise report styles
• 8.6% of all filers (that is 577 public companies) have unique reporting styles or fit into a reporting style which I have not yet created.

What is even more interesting is that 88% of public companies fit into one of only 25 different reporting styles which are summarized below:

The remaining public companies fit into one of 58 reporting styles.  There are a total of 109 reporting styles.  This metadata is not updated yet, but I will update it.  All this is implemented, tested, and working.  XBRL Cloud uses this metadata in their fundamental accounting concept relation validation processes.  Not sure when all this will be available publically.

There is one final issue that I think I have resolved, but I am not completely sure because I have not tested it comprehensibly enough. I have another similar but slightly different approach to representing machine-readable business rules for disclosures. The fundamental accounting concept relations do not use this approach completely.  The impute rules for the fundamental accounting concepts are not expressed using the XBRL technical syntax.  They are expressed using a proprietary approach because I did not think I could express this information using XBRL Formula and I though that an XBRL Formula processor was not capable of processing the impute rules. Well, both of those assumptions were incorrect.  There is a way to represent those impute rules using XBRL Formula, I am 100% sure of that.  And although the processing of the rules is not "standard" (because XBRL Formula does not have a global standard chaining specification); you can process one rule at a time (which is standard) and then you can chain the entire process together however you see fit (which is not standard, but it will work).

And so, that is the direction I am going along with a handful of other software vendors who get all this stuff already.  The reason this is important is because there are thousands and thousands of business rules related to disclosures.  Not implementing these correctly will cause scalability issues, maintenance issues, and will cause software vendors to have to reinvent things that have already been invented and are proven to work.

* * *

Previous fundamental accounting concept relations consistency results reported: November 30, 2015; October 31, 2015; September 30, 2015; August 31, 2015; July 31, 2015; June 30, 2015; May 29, 2015; April 1, 2015; November 29, 2014.