Digital Financial Reporting

1. Error in filing: The public company SEC XBRL-based financial report which reports some fact or facts does so incorrectly; a fact is wrong or a relation between facts is wrong or is interpreted differently than was anticipated for some reason
2. Error in base taxonomy: The US GAAP XBRL Taxonomy expresses a concept which is used to report a fact does so incorrectly which is an error or does so ambiguously so that there are different interpretations by those using the taxonomy or some important or common concept is missing altogether
3. Error in mapping or impute metadata: The metadata used by the software algorithm to compute or otherwise interpret the fundamental accounting concepts or the relations between those concepts is in error or are interpreted differently by different software creators

If there is any issue detected by software applications in the high-level fundamental accounting concept relations, it becomes impossible to then safely use that information without a human getting involved to determine the reason why the anomaly has occurred. And this does not mean using the fundamental accounting concepts; this means using any information in the entire report becomes risky.

As such, it is these high-level fundamental accounting concept relations which serve as a solid base upon which other relations are then built.  For example, if the accounting equation is known to be true which is "Assets = Liabilities and Equity", then next obvious question is does assets foot and does liabilities and equity foot.

Further, prudence dictates that using financial information in SEC XBRL financial filings should not be a guessing game.  Software vendors must write algorithms and create metadata which enables them to make use of machine readable financial information.  If untangling and otherwise deciphering this information is too complicated for them, then it increases the probability that different software vendors will create different metadata and software algorithms, and therefore different software applications will give different answers to exactly the same question.

Therefore, the safe, reliable, predictable, repeatable use of the facts reported within a machine readable digital financial report demands that the high-level fundamental accounting concept relations to be 100% satisfied.  Or said another way, deriving some set of high-level concepts so that facts reported within a machine readable digital financial report can then be safely, reliably, predictably, and repeatedly be sent to automated downstream processes is essential to using any information in that machine readable report.

In order to communicate with someone else about this information it is critical to use consistent terminology so that both parties understand what is being communicated in the same way.  If parties communicating have different understandings of specific words, communication does not really take place.  The following are specific terms which are used and the definitions of these terms.

There is a difference between a fact, the interpretation of a fact, knowledge, and an opinion.

• Fact: a thing that is indisputably the case or situation
• Interpretation: the action of explaining the meaning of some fact or set of facts
• Knowledge: believe in some fact or facts which can be justified using evidence, justified true belief
• Opinion: a view or judgment formed about something, not necessarily based on fact or knowledge

When attorneys argue a case one of the first things they do is try and agree on the facts, the items about the case which are not in dispute. When an interpretation is agreed to by both attorneys, that interpretation becomes a fact.  If both parties in a case agree on some set of facts it can be said that both attorneys have knowledge of the facts, generally both parties agree when there is evidence which can be used to justify that knowledge.  Everything else which cannot be agreed to becomes an opinion which is then argued in the case.

Evidence is provided but the parties don't agree on the evidence or they can dispute evidence with different interpretations of facts.

Sometimes it is a useful thing to create a shared reality to achieve a specific purpose: To arrive at a shared common enough view such that most of our working purposes, so that reality does appear to be objective and stable.

• Explicit: stated clearly and in detail, leaving no room for confusion or doubt; very clear and complete : leaving no doubt about the meaning
• Implicit: implied though not plainly expressed; understood though not clearly or directly stated
• Ambiguous: open to more than one interpretation; having a double meaning; able to be understood in more than one way;  having more than one possible meaning; not expressed or understood clearly
• Impute: assign (a value) to something by inference from the value of the products or processes to which it contributes;

Sometimes things are required, other times things are a choice.  Yet in other times setting some policy eliminates certain options which could have been considered.

Agreed upon standard interpretations are critical to making a system work safely, reliably, predictably, and in a manner which can be repeated over and over without error.  Philosophical or theoretical debates, trying to satisfy all arbitrary options, trying to meet every unimportant negligible situation, confusing what is objective and what is subjective, confusing policies with requirements and with choices only make something which could be sophisticated but simple into something which is complex, confusing, and can never be made to work.

Some people might believe that there is one absolute reality and that reality is their reality and that everything about their reality is important and they can compromise on nothing.   Some people insist that everything involves judgment and that nothing is in any way subjective.  But this is to miss the point. The point being:

A shared view of reality which is clearly interpretable and understood to achieve the purpose of meaningfully exchanging information so that time is reduced, costs are reduced, and information quality improves provides a benefit.

The goal is to arrive at some equilibrium, to balance the duality, to recognize that there is no singular objective reality but in spite of that, if we create a common enough shared reality to achieve some specific and agreed upon working purpose and considers important nuances and subtleties machines can be made to do useful work.

To make reality of the financial reporting domain appear to be objective and stable in certain specific and agreed upon ways in order to fulfill some higher purpose.  The purpose is to enable a machine to read and interpret certain basic information such that manual human work can be effectively eliminated and that higher-level interpretations are then possible.

So basically, public companies should want their financial reports to be fundamentally decipherable and consistently interpreted at some fundamental level.  If reported information is not fundamentally interpretable, there is no foundation upon which to build.

Why information cannot be interpreted by automated processes is excellent evidence in determining what is necessary to make information interpretable by automated processes.  Even better, comparing two or more interpretations against each other is really the only way to assure that interpretations can be consistent.

What can be interpreted can grow.  But it can only grow as fast as the business rules, the tests, which prove consistent interpretation.  If business rules are not provided, what is there to test how information was interpreted?  The fundamental accounting concepts are both a base level of interpretation and a very good clue as to what is needed to correctly interpret more aspects of a digital financial report.  The fundamental accounting concepts are an important building block.

And so these other things are just steps in the interpretation process.  The "minimum criteria" is for making base use of reported facts. The base expands based on expanding buiness rules. To the extent business rules assure that information is correct, is to the extent that interpretation of information can occur.

So, the issues pointed out by fundamental accounting concept tests are interpretation issues.  If a process stumbles in an attempt to interpret information, that is a strong clue that something is wrong.  It could be filer error, taxonomy error, or metadata/algorithm error.  The processes is to agree which category caused the process to stumble, fix that error, and try again.  When interpretation software does not stumble, then the system is in equilibrium.

Filings are publically available, the US GAAP XBRL Taxonomy is publically available, and the metadata used by software algorithms created by software vendors should be publicly available.   Any arguments people have need to be directed at one of those three things: the filing, the taxonomy, or the other metadata.

Examining each also provides clues where things can be made less complex.  Why are so many mappings necessary, can some be eliminated?  Why are impute rules so complicated, can't they be simplified?

Ted Potma, Product Manager at IBM Canada Ltd, created a demonstration of IBM technologies SEC XBRL on IBM Bluemix.  There is a LinkedIn discussion related to this demo.  Basically, you enter an entity name, enter a concept, and you click a button and get a graph of the concept over time.

This is worth checking out and the LinkedIn discussion is worth reading.

One thing I learned from the discussion is that there is API level access also.  Seems like the API level access flexible.  So for example, HERE I used a CIK number and a concept. And here is another.  That is rather nice.

Although, this is a little troubling. If you go to the "About" page you will see the following:

No Extension Elements

Any facts that use an extension element as their concept are ignored. Likewise any fact that is dimensionalized using extension elements as axes or members is ignored.

 This can be explained with one word: comparability. If what we want to do is graph one organization's assets against another, we need to ensure that they define "assets" the same way. The SEC allows me to file ted:Assets instead of us-gaap:Assets if I so choose (assume the "ted" prefix doesn't resolve to a us-gaap standard namespace). This allows filers a great deal of freedom, but drastically reduces the usefulness of the data.

 There's also the hope, however distant, that this may sway the SEC into restricting or even eliminating extension elements/taxonomies all together. At the last IBM Vision during the XBRL workshops IBM's clients expressed that they don't see any real value to creating extension elements, and only do it because they have to.

That is telling. Totally misguided, but none-the-less telling. Clearly whoever wrote that does not understand US GAAP, financial reporting in general, or the power of appropriately used extensions to enable a reporting entity to articulate the nuances and subtleties of their reporting entity. Understanding these nuances is critical to understanding the financial position and financial condition of an economic entity.

Now, I am not saying that the way the FASB and the SEC are using XBRL's extensibility is correct. It is not correct and therefore it may appear that extensibility should be ditched.  But that would be like throwing the baby out with the bath water. Perhaps another alternative is to employ XBRL's extensibility appropriately.

Basically, that statement about how this system is handling extensions basically says "RDF is of no value". Do they REALLY mean that???  Seems like semantic realities of the system are being cast away for the sake of expediency.  Probably does not handle amended filings correctly.  Might not handle currency/units correctly. Certainly will not be able to deal with restated financial information.  Probably cannot deal with reclassified financial information.

I have been fiddling around with what I call report frames.  A report frame is a more flexible and expanded approach to making use of fundamental accounting concepts. In my initial approach, I had only one set of fundamental accounting concepts and I tried to fit every reporting entity into that one set.  Now I have 126 sets! Why so many now?  Because public companies report in different ways, using different "report frames".  This blog post explains the permutations/combinations which I have notices.

What this achieves is make the impute rules easier to understand and allows more flexibility.  Basically, there is not really one hierarchy, there are a number of different hierarchies.

You can get to the report frame index here. From there just click on the "count" to see the reporting entities which report a specific way.  Read the Description. For example, this is the most popular report frame:

CI, balance sheet CLASSIFIED, redeemable noncontrolling interest NOT REPORTED, cash flow statement NORMAL, income statement MULTI-STEP, income (loss) from equity method investments NOT REPORTED, operating income (loss) REPORTED

You don't need to understand the codes such as "COMID-BSC-RNIXX-CF1-ISM-IEMIX-OILY".  The code and the description say the same thing.

Stay tuned...more to come!

There is some phenomenon which I am observing.  It seems to me that this is not something unique to financial reporting but rather it is likely common to many different domains.  I first articulated this observation in this blog post.  The observation relates to why automated processes cannot make use of information reported in SEC XBRL financial filings.  I repeat the four reasons which I observed as part of my testing:

• Missing totals/subtotals: Missing fundamental accounting concept totals/subtotals. For example, most filers do report key totals such as "Assets", "Equity", "Revenues", Net Income (Loss)" and so forth.  If filers don't report such totals/subtotals, it can cause problems with reading the information.
• Crossing categories: Filers moving a fundamental accounting concept to be part of some other fundamental accounting concept.  A common situation is where a filer moves the concept "Interest and Debt Expense" to be included as part of "Nonoperating Income (Expenses)".
• Extension category unknowable: No machine readable information which relates an extension concept to some existing US GAAP XBRL Taxonomy concept or concept category. For example, if a filer reports the concept "my:SomeTypeOfOperatingExpense" and they intended that to be an operating expense, while a human can figure out that the concept is an operating expense, a computer cannot.
• Missing US GAAP XBRL Taxonomy concept: If a high-level concept is missing from the US GAAP XBRL Taxonomy, it can cause the filing to not be decipherable by automated processes.

I mentioned this observation to someone that I know who has an information technology background. He summarized his observation about this in the following statement: "...there is a boundaries problem...".  That term "boundaries" seemed to totally fit.  Mapping that term to my observations, I get the following:

• Missing totals/subtotals = Missing boundaries
• Crossing categories = Crossing boundaries
• Extension category unknowable = Not explicitly indicating what category or boundary an extension goes into
• Missing US GAAP XBRL Taxonomy concept = US GAAP XBRL Taxonomy not properly defining all concepts, articulating all boundaries, or providing an explicit means for indicating the concept or category a filer is extending

Like I mentioned above, this seems like a general or common sort of problem.  It seems to me that there should be some sort of observation about this sort of situation in something like network theory or graph theory.

It seems to me that what is missing is a global standard way to define or establish a "class" such as the way RDF can define a class.  Also missing is the ability to articulate that something is a subclass or equivalent class and so on.  Probably one of the biggest clues that this is true is that RDF has the notion of a class and RDF is pretty much doing the same sort of thing XBRL is trying to do.

So, to summarize these issues again using the notion of "class", I would do it like this:

• Not defining classes (Missing totals/subtotals = Missing boundaries)
• Not associating concepts with classes (Neither the US GAAP nor IFRS XBRL taxonomies do this)
• Defining something implicitly as one class, but using it as if it were another class (Crossing categories = Crossing boundaries)
• Extensions not associated with a class (Extension category unknowable = Not explicitly indicating what category or boundary an extension goes into)
• Missing concepts (US GAAP XBRL Taxonomy not properly defining all concepts, articulating all boundaries, or providing an explicit means for indicating the concept or category a filer is extending)

Further, classes and subclasses have additional utility beyond basic needs of ensuring data quality and consistenty.  Several months ago in this blog post I pointed out that different concepts in the US GAAP XBRL Taxonomy act differently.  That is what classes and subclasses do, they differentiate things for machines.  This is an improved version of that categorization to help you understand how classes and subclasses can be used:

• Concept required: it would make no sense to extend concept. For example, there are obvious examples of such concepts like dei:EntityRegistrantName and dei:DocumentFiscalYearFocus. It absolutely, 100% makes zero sense to allow extension of such concepts.
• Optional concept: it would make no sense to extend concept. This is similar to the category above, but the concept is NOT required to be reported, such as dei:TradingSymbol, or the concept would only be reported if the filer actually had the concept, such as us-gaap:InventoryNet.
• Allowed to add subclasses of concept, but not extend concept: For some concepts, it makes a lot of sense to allow a filer to add a subclass for that concept or as some people think about it, to add a "child".  But, it makes no sense to extend the concept. So again take the concept us-gaap:InventoryNet. It is hard to imagine the need to provide for some other concept "my:InventoryNet".
• Allowed to create extension concept: Suppose that some SEC filer wanted to disclose carbon credit information in their financial report but the US GAAP XBRL Taxonomy contained no such concepts.  Pretty clear than an extension concept could be created.  Likewise pretty clear that if a filer needs subclasses, children, or other stuff those should be allowed for also.  Basically, if something clearly does not exist and a filer needs it, creating an extension should be allowed in such cases.

So what I am pointing out, I believe, is that there are specific classes of things in something like the US GAAP XBRL Taxonomy that act in specific and important ways.

Now, XBRL has no problem articulating this sort of information.  XBRL definition relations can be used to define this information.  What is missing though is a global standard XBRL arcrole for describing these classes and subclasses and/or the US GAAP XBRL Taxonomy making use of those global standard arcroles if they existed, or defining the arcroles themselves if the do not exist.

XBRL definition relations does have the arcrole http://www.xbrl.org/2003/arcrole/general-special which is explained as follows in the XBRL technical specification:

A generalisation item is an occurrence of a generalisation concept in an XBRL instance. A specialisation item is an occurrence of a specialisation concept in an XBRL Instance.

So, the XBRL "general-special" arcrole provides some functionallity, but I don't know if it provides enough functionallity.  RDF schema defines two things: rdfs:Class, rdfs:subClassOf.  The definition of the "general-special" arcrole also refers to "in an XBRL instance". That does not sound right because referenced concepts might never appear in the XBRL instance.  Not sure what an XBRL processor, particularly considering the requirement of the relations to be "C-equal" and "U-equal".  Also, the defintion never refers to the terms "class" and "subclass" which are more commonly used.

Bottom line: XBRL is missing the ability to define a "class" and the notion of a "subclass" and/or taxonomy creators are not making use of what does exist to express such relations.  Easy enough to fix, simply add the needed arcroles in the XBRL Link Role Registry.  The fact that RDF defines the notion of a "class" and "subclass" is ample evidence that this is a problem.  Data quality issues of SEC XBRL financial filings only confirms this fact.

Oh the wonderful things XBRL-structured information enables.  This is not earth shattering information by any means, but what is earth shattering is that it is almost becoming trivial to do queries which return information like the following:

• Of all SEC filers, 77% report using a classified balance sheet, 23% use an unclassified balance sheet. There are 6 which report on a liquidity basis.
• Of all SEC filers, 69% use a single-step income statement, 31% use a multi-step income statement.
• Of all SEC filers, 6,092 do not report "Income (Loss) from Equity Method Investments".  Of those filers that do, 314 report the line item before tax, 101 report it after tax, 16 report it as part of revenues, and 151 report it as part of nonoperating income (expenses)

Below is a screen shot of some quick and dirty queries that I created to try and understand the way public companies report.  This may not make total sense or it may not be interesting for your analysis purposes, but it is useful for what I am working on. Click on the image to check it out.  Or, grab this ZIP file which has an Excel spreadsheet with the information. I even created a handy pivot table you can play with.

(Click image for larger view)

Enough said. I will let the demo speak for itself.