Digital Financial Reporting

Critical to understanding XBRL is the ability to differentiate between an "open taxonomy" and a "closed taxonomy" information exchange.  This blog post sheds light on these important differences. Now, I am not certain that I have the graphics that I provide below 100% correct.  But that is the path down which I am headed: to get these visualizations which explain the important differences as precise as possible.  Any ideas or other feedback would be greatly appreciated.

Why is the distinction between an open and closed taxonomy so important? Because it helps one understand what it takes to make a business system which exchanges information work reliably, predictably, correctly, effectively, be easy to use, and so forth.

Goal: Meaningful information exchange between business users

First off I want to be clear on the goal which is the meaningful exchange of business information by business professionals.  What does it take have a meaningful exchange of information? 

The only way a meaningful exchange of information can occur is the prior existence of agreed upon semantics and syntax rules. (Workflow rules are also important.)

Another term used by others to describe meaningful information is "actionable information". Actionable information is information:

• from a trusted source,
• about something that’s important to you, and
• that, once known to you, will impel you to take action.

Another piece of the puzzle is that we want a business user to be able to exchange information and we want to do this using automated processes as opposed to humans having to get involved in the process. And so, the system needs to be:

• cost effective
• easy to use by business users
• robust
• reliable
• repeatable
• predictable
• scalable
• secure
• auditable (in many cases)

And so the goal is to enable business information exchange across business systems by a business user.

Business users and business systems have been exchanging information using automated processes for years and years.  However now two things are different.  First, rather than technical people needing to get involved to automate these processes (which they can do with one arm tied behind their back), business people need to do this without the IT department.  Why?  Ask yourself why business people like the personal computer and the electronic spreadsheet. Reduced costs, control over their processes.

(Note: you can see the entire graphic by clicking on the images below.)

Open taxonomy

An open taxonomy is a taxonomy where the creator of information can change the taxonomy. For example, the SEC XBRL financial reporting system uses an open taxonomy. Achieving meaningful information exchange is significantly harder using an open taxonomy than a closed taxonomy. This blog post explains why.

Basically, because additional information can be added to the system, the creator of that additional information and the consumer of that information need to make sure they are on the same page.  

Open taxonomy

Exchanging information with an open taxonomy has never really been achieved as I understand it.  Most information exchanges use closed taxonomies.

This is one of the reasons that the US SEC's use of XBRL for public company financial filings is so interesting, and so hard.  If the SEC pulls this off, this will be a new approach to exchanging information.  Rather than using closed taxonomies which I will explain next and are basically forms; information exchanges can be as rock-solid as closed taxonomy information exchanges but also richer in nature.

Is business information exchange using an open taxonomy an enlightened view or a disillusion? Well, I guess time will tell for sure.  But, it is my personal observation that information exchange via an open taxonomy can work.  Clearly you cannot have those expressing information randomly spewing out whatever they might desire.  Information creation must be controlled.  How much control?  That is a balance.  Too formal and the system might not be usable by business users and therefore such a system will fail.  Too little control and the information will be garbage and unusable.  Striking the appropriate, practical balance is necessary.

Closed taxonomy

When the system is closed, meaning the creators of information cannot add anything to the taxonomy, information exchange is much easier because it is much easier to control the quality of the information. But on the down side, closed systems are more like "forms".  You lose information richness because information needs to be packed into some predefined form.

For example, the FDIC system is a closed taxonomy. Call reports are forms. 

Closed taxonomy

Trusted exchange

Worth mentioning is what I call a "trusted exchange".  With a trusted exchange, the user of the information assumes that the information which they are using is correct and therefore takes no steps to verify the correctness of the information before they use it.

I am not sure about this but I think a trusted exchange can work with both an open taxonomy or a closed taxonomy. The graphic shows a closed taxonomy only.  Although, I am not sure if open taxonomies and trusting the information go together.  More work is needed to figure out if trusting information where you have an open taxonomy will work. 

Bottom line

I quess the bottom line is that whether XBRL is an enlightened view or a disillusion will be determined by the success or failure of a system such as the SEC XBRL financial filings. Creators of business information "spewing out whatever they want" will clearly not work.  Some amount of control is necessary. It seems to me that if information exchange using an open taxonomy is achieved, the XBRL community will have provided something which is incredibly useful.  Not just useful for financial reporting, but something generally useful.

28msec took there existing information processing platform, loaded the business information from XBRL instances and XBRL taxonomies (rather than the XBRL technical syntax), extended their existing query platform specifically for the business information (BizQL), and the result is XBRL.io. Their stated goal is as follows:

We want to radically simplify the way people build and deploy business reporting applications using XBRL.

As I understand it they are testing their platform by loading the entire set of SEC XBRL financial filings into their database platform. That should provide very good information about how scalable their database is and the power of their query language.

The jury is still out.  I will be checking this out as I got invited to join their private beta. You can sign up for yourself. There is certainly more to come. I am cautiously optimistic.

For more information about XBRL and databases please see this blog post.

Beware: RoboCop is on patrol. And the number 1 item on the list for staying off the SEC radar and avoiding additional scrutiny is "Check your work".

“Check your work.” When asked how companies can minimize the risk that their company is flagged, Mr. Lewis responded succinctly: “I would say check your work.”  Because RoboCop is an automated system looking for oddities, it is unable to account for mistakes made.  This is particularly important because the AQM relies on the newly-mandated XBRL data which is prone to mistakes by the inexperienced. Sloppy entries could land your company’s filing at the top of the list for close examination.

Too often I hear the generalizations such as "financial reporting is subjective" as the justification for what amount to obvious errors to those who understand how XBRL truly works. Is financial reporting subjective? Well, there are some subjective aspects to financial reporting.  But everything about financial reporting is not subjective. By "subjective" I mean that your opinion counts; professional judgment must be considered.  This is as contrast to "objective" where there is no room for your opinion, professional or otherwise.

Every aspect of financial reporting is not subjective.  Yes, financial reporting does have some, or even many, aspects which are subjective.  But not everything about financial reporting is subjective.

Understanding what is an error in an SEC XBRL financial filing starts with understanding what is "science" and objective and what is "art" and is truly subjective, where you can have a preference or an opinion.  If you think about it, if you create a global standard and then make everything about that global standard a matter of opinion and then let 8,000 public companies use that global standard, what exactly is the point of having a "standard".

How XBRL works is not subjective at all.  It is called the "XBRL Technical Specification" for a reason.  It is objective, it is not subject to the whim of those who use the standard. Specifications specify.

Now, specifications are written by humans and humans make mistakes. And that is why XBRL has a conformance suite.  A conformance suite is a set of tests which show both positive examples and negative or "contra-examples" to help people agree on how something like the XBRL technical specification actually works. There is no art involved here.

And don't confuse "art" with ambiguity.   Specifications try to state explicitly and in detail how things work.  Sometimes a specification can be ambiguous meaning that two different people can reach two different conclusions as to what is "right" and therefore both conclusions reached are right.  This is not "art", this is not "subjective", this is an error in the specification.  Specifications take great strides to eliminate ambiguities.  But specifications are created by humans and humans make mistakes.  So, writing specifications such as the XBRL technical specification is a process.  But an ambiguity in a specification is not an opening for subjectivity; it is an error in the specification.

While 99.9% of all SEC XBRL financial filings comply with the XBRL technical specification, only 97.9% comply with the representation structure or "model structure".  That is still a very high number, but there is about 2% of filings which deviate from the proper model structure rules.  Does this mean that how models can be structured is more subjective?  No.  What it means is that about 98% of SEC XBRL financial filers follow those rules and 2% do not.  By model structure I mean the relations between the major pieces which make up an XBRL taxonomy: Networks, [Table]s, [Axis], [Member]s, [Line Items], [Abstract]s, and Concepts.  How these report element categories relate to one another is not subjective at all.  It is not "art".  Those relations are science and not open to interpretation.

These model structure relations are somewhat documented in the US GAAP Taxonomy Architecture and even by the XBRL International Abstract Model 2.0. But the real proof that they exist is that 97.9% of SEC XBRL financial filers follow these rules.  All one needs to do is go look at the other 2.1%, see specifically why they are not following the rules and you can determine if they made a mistake.

The same with relations such as "Assets = Liabilities and Equity", the accounting equation.  So what, accountants can exercise judgement at to whether the accounting equation is true?  No, they cannot.  By definition that business rule is true.  Additional proof is that 99.4% of SEC XBRL financial filings follow that business rule.

In fact, 98% of SEC XBRL financial filings follow that and 20 other fundamental business rules and report 51 fundamental accounting concepts in their financial reports. What accountant would argue that financial statements have balance sheets when 99% of financial statements can be shown to have balance sheets, or that balance sheets have "assets", they have "liabilities and equty" when 99% of balance sheets can be shown to have such concepts, or that balance sheets balance?  This is not subjective, this is not art; this is science.

Assets foot.  Any accountant care to make an argument aganist that statement?  Well, 92.8% of all SEC XBRL financial filings have balance sheets which have assets which foot. What about the 7.2% who don't.  Subjective? Art?  Nope.  Errors.  This becomes interesting when you can show a correlation between the software product used to create an SEC XBRL financial filing and whether assets on the balance sheet foots.

Liabilities and equity, net income (loss), and net cash flow likewise each foot.  Any accountant care to disagree with that statement?  Science, not art.

When 99.2% of SEC XBRL financial filers can make their root reporting entity clearly identifiable and .8% cannot, is that caused by accountants judgement?  Sorry, that would be an error.  Again, all one needs to do is go look at each of the 58 SEC XBRL financial filings where you could not identify the root reporting entity, determine why, and then understand the rational behind not clearly identifying that root reporting entity.

Now, most of the examples above relate to the primary financial statements.  However, the line of thinking relates to the disclosures as well.  For example, consider the disclosure of long-term debt instruments.  You can refer to this reporting template for that disclosure. How much sense would it make if each long-term debt instrument did not provide an amount of that debt instrument?  How about not providing a way to identify the debt instrument and distinguish one debt instrument from another debt instrument.  That part is science.

But now we get to the art of financial reporting. While it is true that there is no judgment necessary to recognize that you must provide an amount of each debt instrument and some way to differentiate one debt instrument from another; it is subjective as to which of the many, many other important pieces of information needs to be disclosed to make the financial information truly meaningful.  If you go to this link and look at lines 353 to 458 which shows numerous other possible pieces of information which might be disclosed; you see where judgement, you see where the "art" of financial reporting starts to fit into the equation.

So yes, it is subjective, there is art in understanding which of those many other facts need to be provide with the amount of each long-term debt instrument and with the information used to differentiate one debt instrument from another.

Which disclosure to provide is also very subjective in many cases, but not all cases.  For example, whether a balance sheet is necessary is rarely open for discussion; but sometimes because you could provide a statement of net assets.  Whether long-term debt maturities must be disclosures is not subjective really. But whether to include or not include other disclosures can be highly subjective.

Qualitative disclosures (as compared to quantitative disclosures) are generally very subjective.  (Here is information to understand the difference.) And so, there are a lot of things about qualitative disclosures which can be very subjective, where professional judgment comes into play.  But there are still items which are purely objective, which provide somewhat of a "framework" for all of the qualitative information to fit into.

This is not to say that all quantitative disclosures are objective; they are not.

And so, the bottom line here is that trying to lump all anomalies into the "art" of financial reporting, the area where accountants can apply their professional judgment is not appropriate.  Being able to differentiate between where science is applied and where art is applied is crucial to creating an SEC XBRL financial filing correctly.  Not understanding what is art and what is science is inviting errors to creep into your SEC XBRL financial filing.  This can be dangerous because RoboCop is on patrol.

I have mentioned the notion of the "semantic spreadsheet".  This blog postsays that it is time for a new take on spreadsheets. The author of the blog also points out that Microsoft Excel is by far the leader in the world of electronic spreadsheets, but the needs of the tablet PC and moble devices could open an opportunity to dethrone Excel.

Don't get me wrong, I love the Excel.  There is really a lot to like. If anyone is going to dethrone Excel as the king of the electronic spreadsheet hill, they better have some really good ideas because business users are quite attached to their Excel spreadsheets.

But I don't see this as an either-or situation.

People point out the flaws of the electronic spreadsheet. For example, this web page points out the following 10 disadvantages of spreadsheets as being:

1. Vulnerable to fraud
2. Susceptible to trivial human errors
3. Difficult to troubleshoot or test
4. Obstructive to regulatory compliance
5. Unfit for agile business practices
6. Not designed for collaborative work
7. Hard to consolidate
8. Incapable of supporting quick decision making
9. Unsuited for business continuity
10. Scales poorly

The blog post about the new take on spreadsheets provides this wish list of features which I have paraphrased:

• Don't intermingle "Grids, values, formula and style" (i.e. separate the "model" and the "view" of the information)
• Terser, more readable source forms (better file format)
• Backing with Source Control (better versioning or collaborative use)
• Live data
• In-Browser editing of content, via plugins (i.e. lighter weight client)

This is my take on what is wrong with current electronic spreadsheets is this list of 5 fundamental problems that I see:

1. Information is presentation oriented rather than meaning oriented: Today's electronic spreadsheets, all of them, are made up of sheets which contain rows and columns which intersect to form cells. Information is entered into cells. All these rows, columns, and cells are presentation oriented.  What if the information were meaning oriented instead? (If you don't understand what I am talking about, watch this Quantrix tutorial)
2. Business rules combined with spreadsheet information: Spreadsheets today have the data within the spreadsheet combined with the business rules such as formulas for how information adds up, tests to make sure there are no errors, and other information mixed within the data of the spreadsheet.  This can make it very hard to check a spreadsheet for errors or missing business rules.  To look at this another way, imagine a spreadsheet which is verified using an external set of business rules.  Sometimes the business rules could be publically available, other times the business rules would be securely available to a select group of users of the spreadsheet.  The basic premise is that you can separate the business rules used to check the spreadsheet from the actual information which provides more control over both the business rules and the information. Plus, this means that the same set of business rules can be used across multiple spreadsheets to verify that the spreadsheets do not contain errors. Considering #1 above, the information, the business rules, and how the information is presented all really need to be separated to make the spreadsheet more flexible.
3. Multiple copies of the same spreadsheet: A big problem is multiple versions of the same spreadsheet and you lose track of which version is the correct version to be using. Many people refer to this issue as spreadsheet hell. More and more people are addressing this by storing spreadsheet information in a database and exposing the information view Excel, but saving the information into a database.  The problem with this is see #1 above, the information stored is still presentation oriented and not meaning oriented.
4. Comparing information between spreadsheets can be a challenge: If you have ever given a spreadsheet to two or more different people, had each person put information into the spreadsheet, and then tried to compare spreadsheet information you understand this situation. Reusing information contained in spreadsheets effectively can be a big challenge.
5. Proprietary format, forced to use one software application: Excel is a great software application for working with spreadsheets. But if you don’t have Excel or someone you want to share information with does not have Excel and you want to exchange information, this can be problematic.  The interoperability between Excel, Google Spreadsheets, and Apple Numbers spreadsheets is OK some times, but other times problematic.  Standard formats such as Open Documents helps, but the standards focus on formatting of information, not the semantics of the information.  Also, business rules are still embedded within the application.  Further, Excel is a very "heavy" client.  With tablet PCs and mobile devices growing in popularity, that becomes more and more of a problem.

So what is the solution?

In my view the solution is an XBRL-based global standard semantic spreadsheet. The truth be known, the global standard semantic spreadsheet already exists.  "Say what?", you ask.  If you go to any SEC XBRL financial filing and look at it, say by going here to the XBRL Cloud Edgar Dashboard, and look at any financial filing you can see a semantic-oriented spreadsheet.  That semantic spreadsheet is dynamic in that you can pivot the information.

What you don't have is three things: (1) good representations of the information (i.e. the models are poorly created), (2) all the business rules to prove that the information is correct, and (3) good software which allows you to see that this is really a bunch of little semantic spreadsheets all connected to form a financial statement.

Now, the XBRL Cloud Viewer is close in my view.  But, it is only a viewer. But I believe that people will ultimately realize that business information in general is more similar to the information contained in financial statements and that the Financial Report Semantics and Dynamics Theory can be applied more broadly to business reports.

Concepts such as "report component", "fact", "characteristic", "property" are very general. I have mapped these terms to the XBRL International Abstract Model 2.0. If you compare these terms to the terms used in the Quantrix tutorial above, they have the same things, they just call them different names.  For example, they use "Matrix" where the XBRL International Abstract Model 2.0 uses "Cube", and Financial Report Semantics and Dynamics Theory uses "Report Component".

What is the bottom line here? Digital semantic spreadsheets already exist. What is missing is good software which allows business users to:

• Separate information reported, representation (or model) information, business rules, and presentation information: represent information in that form correctly,
• Rules prove information is correct: verify that the information represented is represented correctly via business rules (syntax and semantics)
• Neutral human readable view: view the information in a manner which is understandable by humans driven by business rule driven rendering algorithms of the domain
• Global standard syntax: do all of these things using a global standard syntax such as XBRL
• Proven to work: effectively exchange the meaning of the information with other software applications (business user to business user)
• Numbers, text, and rich text: the software works with both number, text and rich text information formats, not just numbers
• Useable by business users: do all of this using an open taxonomy which business users manage

Some software applications do some things on the list above, other software does other things. But there is not one software application which does ALL of these things on that list.  That is what will help business users realize that alternatives to exchanging information using something like Excel or CSV (comma separated values) do exist.

The best solution for business users would be for this functionality to exist within Excel (because that is where a lot of information is created) and outside Excel in other software applications business users make use of. A true global standard digital semantic spreadsheet format owned by no specific software vendor but supported by all business applications used to create or consume business information.  That would be ideal.  Having islands of information in some new software application or only having one software vendor supporting a digital semantic spreadsheet such as this helps nothing really.

The digital semantic spreadsheet will help accountants in this new world of big data.