Digital Financial Reporting

While creating the disclosure templates I am putting together I noticed something and a question occurred to me.  How does someone creating an SEC XBRL financial report know which [Table] to use and which [Axis] to use when expressing their financial information and how is this "controlled" by the SEC?

This is what I mean.  Take a look at a rather straight forward disclosure, product warranty accrual. To create the product warranty accrual disclosure template, I started by looking at what other filers did.  I built a nifty application which helps me do this.  That application generates a nice little summary which shows the disclosure template and lets you look at the model structure of other SEC filers who modeled that same disclosure.  You can see this here.

If you go to the section "Similar SEC XBRL Filer Examples" you will see links to about 42 SEC filings which provided this disclosure.

Of those 42, the vast majority of filers modeled this disclosure without using any [Table] and therefore not providing any additional [Axis] beyond the reporting entity, period, and concept which they are required to provide for all facts provided. So here is one example of that approach.

Three of the filers added an additional characteristic, the "Legal Entity [Axis]".  Personally I prefer this approach because I prefer to (a) consistently use [Table]s for everything (as compared to using them for some things but not for others and (b) because it explicitly states that the legal entity characteristic is the consolidated entity (as opposed to having to imply this information).

However, of these three filings; two different [Table]s were used to disclose the product liability accrual roll forward:

• us-gaap:ScheduleOfGuaranteeObligationsTable
• us-gaap:ProductLiabilityContingencyTable
• us-gaap:ProductLiabilityContingencyTable

These two SEC XBRL financial filings used the Range [Axis].  That seems like it could be reasonable; however these two filers did not use any of the [Table]s above, rather they created their own [Table] and used that:

• flir:ScheduleOfAccruedLiabilitiesTable
• twi:ScheduleOfWarrantyTable

This filer used the Business Acquisition [Axis] and created their own [Table]:

• hlit:ScheduleOfProductWarrantyLiabilityTable

This filer used three different [Axis], two of which used the [Domain]:

• us-gaap:ProductLiabilityContingencyTable

This filer created its own [Table] and its own [Axis], whr:ProductWarrantyAndRecallAxis, and this does seem to make sense because they choose to break down the information into product recalls and normal product warranties; plus the do provide the total of these two categories which is comparable to all the other disclosures of this information:

• whr:ProductWarrantyAndRecallRollforwardTable:   

This SEC filer provides no explicit [Table] and packs the product warranty accrual together with a bunch of other disclosures as compared to focusing on that specific disclosure in this specific network.  (Approximately 50 percent of the total focus on one thing and the other 50 percent pack multiple pieces together):

• No table

Clearly this product warranty liability accrual roll forward is a rather basic and straight forward disclosure.  Consider these examples and consider the fact that there are I would guess perhaps approximately between say 1300 and maybe 3000 specific disclosure.

How do SEC XBRL financial report filers know

1. When two things should go into one network or be separated into two different networks,
2. What goes into a [Table] within a network or when separate [Table]s should be used,
3. Whether to use an existing [Table] or create their own explicit [Table],
4. And what [Axis] to put onto a [Table].

Here is another good example, document information.

Clearly it is highly unlikely that 8000 or so different SEC filers are going to figure this out themselves and consistently do the right thing without some sort of guidance.  SEC XBRL financial reports filed with the SEC bear this out.

The point here is that some sort of general guidance would be nice from the FASB, the SEC, and/or XBRL US.

The terms "semantics" and "metadata" are increasingly showing up in initiatives which are attempting to properly position governmental organizations and private companies in our new "digital economy". Two good examples of this are the W3C Government Linked Data Working Group and the Asset Description Metadata Schema initiative in Europe.

The Asset Description Metadata Schema folks have a great document, Towards Open Government Metadata which provides some very nice definitions of semantics and metadata.

Paraphrasing from that document, they explain that semantic interoperability is an essential precondition for open, flexible information exchange. Not the only precondition, but an essential precondition.  This is consistent with what the HL7 folks say, pointing out that technical, semantic, and process interoperability are all important.

That document further describes why their "Semantic Interoperability Assets" (i.e. metadata) are important to achieving semantic interoperability:

"… the meaning of data elements and the relationship between them. It includes developing vocabulary to describe data exchanges, and ensures that data elements are understood in the same way by communicating parties."

This promotional video walks you through why semantic interoperability and appropriate metadata are essential ingredients for effective business to business information exchange.

Another part of that paper which is of particuar value in understanding the term metadata is what they call the five levels of maturity for metadata management:

• Level 1: Metadata Ignorance – Metadata is not documented, mainly because administrators are not aware of its importance.
• Level 2: Scattered or Closed Metadata – Metadata may be partially documented but a) not in a centralised and structured way or b) it is not available and accessible under an open license framework, in other words as "Open Metadata" for developers to share and reuse.
• Level 3: Open Metadata for Humans– Metadata is documented and becomes available as "Open Metadata" for reuse, but are not systematically published in a reusable format, e.g. may only be available in .pdf or .doc documents.
• Level 4: Open Reusable Metadata– Metadata is centrally managed, and published as "Open Metadata", in a machine readable format and/or an API is provided for computers to access, query and reuse the available metadata repositories, catalogues, libraries, etc.
• Level 5: Linked Open Metadata – Semantic Assets are documented using linked data principles and are managed by advanced Metadata Management Systems.

When you build your XBRL based metadata to achieve the semantic interoperability described above in order to achieve business system to business system information exchange keep these ideas in the back of your mind.

One thing that is becoming increasingly unclear how XBRL best fits into the linked data initiatives such as the two above.  These seem to be the spectrum of options:

1. Everyone should ditch their technical syntax and use the XBRL technical syntax. XBRL zealots push for this.  Yeah, do you really think that is going to happen?  I doubt it, nor does it need to.
2. XBRL ditches its technical syntax and moves to RDF like the two groups above and others. That is what the Government Linked Data folks are calling for, see their list of the ingredients of high quality linked data; they say everything needs to be in RDF.
3. All these groups agree on the business semantics and all the metadata is made available which is necessary to convert from one technical syntax such as XBRL to any other technical syntax such as RDF/OWL.

Technical syntax is important, but less important than agreement on semantics.  Or, maybe I am saying this incorrectly.  Perhaps that it is not about which is more important, technical syntax or semantics; it seems to be that there are multiple "layers" which are necessary to achieve effective interoperability.  If you have all the meaning, nothing prevents conversion from one technical syntax to another.

It seems as though some people are even questioning the XML syntax as the base for all other technical syntaxes.  For example, JSON seems to be a more compact syntax than XML with some distinct advantages.  Seems to me that the important thing is whether the technical syntax works correctly over HTTP and whether the syntax can be used globally.  XML is global.

I ran across something which is incredibly helpful in understandings the power of patterns. Watch the video on this web page of Duarte Diagrammer.  Notice how he mentioned that after 22 years of working with diagrams they realized that diagrams generally fell into one of five different categories.

Years ago when working to build the first XBRL taxonomy, one for US GAAP created in 2000; I noticed that the information we were putting into XBRL taxonomies for US GAAP had patterns.  I jumped over to work on the IFRS taxonomy for a number of years, same deal: patterns.  Back to the US GAAP taxonomy again: tuned the patterns. You can see information about all these different iterations and a summary of this evolution here.

I realized that these patterns even had patterns and condensed/distilled the patterns down into a set of metapatterns which are found in IFRS and US GAAP financial reports.

Believe it or not, everything in the US GAAP taxonomy fits into one of these metapatterns.

Computers love patterns.  Patterns mean that software developers can hide complexity from users. Patterns are a way to hide the complexity of SEC XBRL financial filings.

This is my first draft of an articulation of all the properties of the financial report semantic objects.  (I think I am saying this correctly).  I used an approach which was used when I was working on the XBRL International Taxonomy Architecture working group; I did this using VUE (Visual Understanding Environment).  It is not UML, but it is UML-ish.  I am no expert at this but I think this is getting pretty close to where it needs to be.

Basically, what I did was leverage the business reporting logical model created and change it, expressing it in terms of the Financial Report Semantics and Dynamics Theory and my implementation of the SEC XBRL financial filing logical model.  You can get more information of both of those here on my blog.

More to come...comments welcomed.

Precise terminology can be important.  Using terms incorrectly inhibits communication. 

The XBRL technical syntax includes not only XBRL terms defined by the XBRL Specification; but also terminology defined by XBRL Dimensions and XBRL Formula.  Not only that, but because XBRL builds upon other technical specifications such as XML, XML Schema, XLink; you have that that technical terminology to contend with.  How do you keep this all straight?

Well, most of this terminology will be hidden from users by software applications. Eventually.

I have put together a reconciliation of this terminology.  This reconciliation maps XBRL and other technical terminology on the far right to financial reporting terminology on the far left.  In between I have provided an example, Business Reporting Logical Model (BRLM) terminology which I have used in the past, and US GAAP/SEC financial filing terminology.

If implemented correctly, generating XBRL output from a software application does not have to be complicated by terminology which business users do not need to understand.

If you hear people using terms such as "tag" or "element" or "dimensionally qualified", they are making things harder than they really need to be.

A commonly misused term is "concept".  Concept is a good term, if used in the right way.  The terms "tag" and "element" could mean any of the building blocks used in an SEC XBRL financial filing: network, table, axis, member, line items, or concept.

The XBRL specification (section 1.4, terminology) does define the term "concept".  A concept, per that definition is:

Concepts are defined in two equivalent ways. In a syntactic sense, a concept is an XML Schema element definition, defining the element to be in the item element substitution group or in the tuple element substitution group. At a semantic level, a concept is a definition of a kind of fact that can be reported about the activities or nature of a business activity.

Pretty hairy.  But this gets even better.  Tuples are not relevant because the US GAAP Taxonomy does not allow them, so basically, per this definition an XBRL concept is an XML Schema element which has a substitutionGroup attribute value of "xbrli:item".  But there is a problem here.

The XBRL Dimensions specification (section 1.3, terminology) defines the terms hypercube (called a [Table] in the US GAAP Taxonomy) and dimension (called an [Axis] in the US GAAP Taxonomy). A hypercube is defined as an XBRL concept which has the substitutionGroup xbrldt:hypercubeItem and a dimension is defined as an XBRL concept which has the substitutionGroup xbrldt:dimensionItem.  So, hypercubes and dimensions (or [Table]s and [Axis] using US GAAP Taxonomy/SEC terminology) are XBRL concepts; per the definition above they are "...kind of fact that can be reported...".  Right?

No.  XBRL Dimensions redefines the XBRL concept to mean Primary Item. So in essence, with XBRL Dimensions you get the major primitive building blocks of:

• Hypercube (or [Table] using US GAAP taxonomy/SEC terms)
• Dimension (or [Axis] using US GAAP taxonomy/SEC terms)
• Primary Item (or [Line Items] using US GAAP taxonomy/SEC terms)
• Domain Member (or [Member] using US GAAP taxonomy/SEC terms)

So, when most people use the term "concept" they are referring to a "kind of fact that can be reported about the activities or nature of a business activity", not a hypercube, dimension, or domain member.

Three primary take aways here:

1. These different cagetories of rudimentary or primitive building blocks do exist, terms like "element" and "tag" are not appropriate.
2. Use the proper term.
3. While there is no "global standard" set of terms; you can use the terms I propose create your own set of terms; or help push for one standard global standard set of terms.

Personally, I have pushed for that global standard set of terms for quite some time.  That logical model will be very useful to both business users and software vendors who are trying to create quality software.

Do you have a better terminology scheme?  If you do I would like to hear about it both to improve mine and pass this information on to XBRL International.  Let me know.