Digital Financial Reporting

If you follow this blog you know that I post quite a bit of information. I have taken information relating to working with SEC XBRL financial filings and consolidated it into a single resource: Understanding SEC XBRL Financial Filings which you can get to here.

This resource is useful for more than creating SEC XBRL filings. As this HL7 video points out (see slide 4) you need three things to make interoperability work: technical interoperability, semantic interoperability, and process interoperability. XBRL provides the technical interoperability, the XBRL technical syntax. If used correctly XBRL can provide the semantic interoperability also it seems. Process interoperability I don't really grasp well yet. I don't think XBRL provides that.

So check out this resource whether you work on SEC XBRL filings or not. This resource is not for the XBRL novice. But, it can help beginners or those with intermediate or advanced skills add to their skill set. I know that over the three years that it has taken me to accumulate and grasp this information I have learned quite a lot. Hopefully this will help you.

In my popular video How XBRL Works (pushing 12,000 views) I did my best to explain three important notions needed to properly understand XBRL.  This is a better articulation of that information. Watching the video can also be helpful in gaining a better understanding of these important key terms. If you don't have a proper understanding of these terms, it is doubtful that you have a proper understanding of XBRL.

Unstructured versus structured information

Digital information comes in two forms:

• Unstructured which means the information contains no identifiable structure and therefore it is unrecognizable and therefore not usable by computer software. Further, no controlled navigation within the pieces of the unstructured information is possible due it its lack of structure.
• Structured which means the information has identifiable structure which can be recognized and utilized by computer software. Further, because of the structure navigation within the pieces of structured information is possible because of the structure.

Truth be known, everything that a computer works with has to be structured at some level and the level of structure determines what a computer can do with that digital information.

Structured for presentation versus structured for meaning

There are two approaches to structuring information digitally:

• Structure for presentation. An example of that is a Word processor document which is structured using headings, sub headings, paragraphs, tables and lists. An Excel spreadsheet is also an example of structuring for presentation, it uses worksheets, columns, rows, and cells.
• Structure for meaning.  An example of that is database or a taxonomy or other type of classification system. A database structures the presentation into rows and columns, but the rows and columns are associated with defined names which have specific meaning.

Syntax versus semantics

More often confused are the two parts of structured information.  Both parts are important, but for different reasons:

• Syntax describes the form of the information and is generally not relevant to a business person. This is syntax: <Name>John Doe</Name>. Syntax is important to technical people.
• Semantics communicates the meaning of the information. For example, "the balance sheet balances" is semantics. Business meaning is key to the digital world.

Interoperability = Business benefits

What does all this mean to you?  More than you might think. Properly weaving business systems together provides significant business benefits. For example, SAP says in this article that its customers have sharply cut costs of creating regulatory reports by 75 percent. If you are not experiencing that magnitude of benefit you may be confusing some of these terms.

As his video about HL7 points out (see slide 4) you need three things to create useable business system interoperability:

• Technical interoperability is concerned with the conveyance of payload. This is syntax, what physically gets transferred.
• Semantic interoperability communicates meaning unambiguously. Semantics are domain specific. The business systems on both sides of the transfer need to have the same understanding of the meaning for the transfer to work effectively.
• Process interoperability enables shared human understanding that is needed to coordinate work processes and enable business systems to interoperate. Basically, the work flow needs to be understood.

Think "Semantic Spreadsheet"

This short 6 minute video helps you see the world differently (the first video, "Basics of Quantrix Modeler"). In the video the narrator makes up the terms used in his matrix, "Net Income", "Revenue", "Expenses". For financial reporting use of that semantic spreadsheet or what the narrator calls a "matrix", you would generally not create the concepts used yourself; you would generally pick most of them from the US GAAP or IFRS taxonomy.

Evolution

We are not there yet.  Business software is not what it needs to be. For example business intelligence software is too focused on OLAP, it does not handle text well preferring to work with numbers, and it is "read only", you cannot write information back to the database generally.  The US GAAP Taxonomy is modeled like a the documents accountants are used to, not like the data model that it should be. Each implementation of the XBRL standard is unique to that implementation, for example the SEC and FDIC implementations of XBRL don't interoperate.

All these issues will be worked out over time. Don't make the mistake of confusing the moving pieces to this puzzle.  The better you understand the moving pieces, the fewer mistakes you will make in working with new technologies such as XBRL.

I have been trying to articulate the benefits of unique, explicit [Table]s in the US GAAP Taxonomy for quite sometime. In trying to figure something else out I stumbled across a paperwhich helps communicate why unique, explicitly [Table]s are superior to [Table]s which are not unique and [Table]s which are implicit.

First off, let me explain what I mean by unique [Table]s and by explicit [Table]s.

A good example of a non-unique [Table] is the "Statement [Table]" which appears in the US GAAP taxonomy.  What does the "Statement [Table]" represent?  Well, it represents many things and that is the underlying problem. It could represent a balance sheet, an income statement, a cash flow statement or actually anything because some vendors are using "Statement [Table]" to express every [Table]. So, what I mean by unique [Table]s is exactly the opposite and exactly as it sounds.  Just like concepts or other things in the US GAAP Taxonomy each [Table] has ONE meaning, one name.  Rather than using "Statement [Table]" to identify multiple things, each [Table] is specific: Balance Sheet [Table], Income Statement [Table], Cash Flow Statement [Table], and so forth.

By explicit [Table]s I mean that there are no implicit [Table]s.  What I mean by that is that today, everything exists in a "[Table]" in the US GAAP taxonomy.  And of course you will say, "No, that is clearly not correct, one can cleary see that is not the case." But, this is exactly my point.  True, you can't "see" the [Table], but it is there.  What I mean is that after you address all the explicit tables identified by the XBRL hypercubes marked with a "... [Table]" in the label and name, you have one more table which implicitly exits.  Basically, it is the "everything else [Table]" which has no name.  It has two [Axis], the "Reporting Entity [Axis]" which is instantiated using the XBRL syntax "entity identifier" portion of a context and the "Period [Axis]" which is articulated using the XBRL syntax "period" portion of a context.

Don't make the mistake of confusing syntax and semantics. Just because it is called part of the XBRL context does not mean that from a business perspective that it is not an [Axis].  First off, be aware that ALL [Axis], be they XBRL Dimensions defined or XBRL 2.1 defined, are expressed using part of an XBRL context element.

So, what I am saying here is rather than modeling things to show up under the "unnamed [Table]" implicitly, it is better to be explicit and define the [Table].  Further, having multiple "unamed [Table]"s violates the first notion of making every [Table] unique.

"Why?", you ask.  Here is why. Navigation and use of the taxonomy and the SEC XBRL filings is superior if [Table]s are unique and explicitly defined because navigation within the pieces of the taxonomy and/or SEC XBRL filings because of the unique "handles" of the [Table]s.

If [Table]s are unique, you dont also have to use the network to uniquely identify WHICH of the non-unique [Table]s you mean should you be trying to tell a computer software application which of the non-unique [Table]s you desire to use.  Further, there is no need to ask what defines the [Table], the hypercube which defines the table with the "... [Table]" label/name on the end or the set of [Line Items] which make up the [Table].  You will not have that question because every [Table] is unique and you will never run across that situation.

Computers need these unique handles to understand exactly what you desire. Unique, explicit [Table]s provide the handles needed to control navigation between pieces of a taxonomy or SEC XBRL financial filing.  Without unique [Table]s, there is no way you can get around using network information to create unique handles.

If you need more details please read the paper. It is quite technical, but it lays all of this out quite nicely.