Digital Financial Reporting

The folks working on the FINREP (FINancial REPorting for financial institutions) have provided a prototype XBRL taxonomy and related documentation which provides insight into how to model information using XBRL. Serious students of XBRL should consider taking a look at that they have done which you can find here:

• FINREP taxonomy main page
• Proof of concept taxonomy files
• Proof of concept taxonomy architecture documentation
• Bank of Italy "Matrix Schema" documentation (see page 25 onward), referenced

There is one very unique aspect of this taxonomy worth pointing out because it helps to answer a big question that I, and others, have. The FINREP taxonomy has only one hypercube which it uses over, and over, and over to express information. This was done intentionally to force the business semantics of the dimensions and primary items pulled together by the hypercube onto the network containing the hypercube.

This is not to say that I like that approach (i.e. using one hypercube for everything as compared to making each hypercube unique and the hypercube contains the semantics of what the hypercube defines).

What this basically points out is the two extremes of creating hypercubes:

• make each one unique (and each has meaning)
• create only one (and the hypercbue has ZERO semantics, the network contains the semantics which describes what the network/hypercube means)

What is not good is mixing those two approaches.  It makes no sense if one hypercube has multiple meanings (i.e. hypercubes should not be polymorphic).

In discussing the characteristics of the FINREP taxonomy on the Eurofiling news list someone made the following statement about XBRL:

The flexibility and extensibility of XBRL provides numerous solutions which is a double-edged sword.

I could not agree with this statement more. Particularly today because the dust has not settled from the experimentation of trying to figure out the best approaches to use XBRL and the best approaches are not coded into software applications to help guide those making use of XBRL; a cautious "buyer beware" type attitude is quite appropriate.

I have been a proponent of using a logical model to hide the XBRL technical syntax for quite some time. It can be hard to communicate the value of such a logical model.  But, I believe that I have two things which clearly show the value of a logical model.

First, I build two prototypes using this logical model: the the reorganized US GAAP taxonomy and exemplars and the evaluation utility.  You can see the info sets I worked with here(i.e. I was not working at the XBRL syntax level). This is a more general example.

Second, a much more specific example, is the business rules I created associated with the model/reference implementation of an SEC XBRL financial filing. When I first created the business rules for this model/reference SEC XBRL filings, this is what I was editing. That is an XBRL Formulas file which I created to validate that filing. (You can see the valiation results here and here which will give you an idea of why these XBRL Formulas are needed.) It was a painful process to create those XBRL Formulas to say the least.

But after I had all the XBRL Formulas created, I realize that there were patterns within those XBRL Formulas or categories that the formulas fit into.  These are the categories:

• Roll forward (beginning balance + set of changes = ending balance where only the period axis changes)
• Dimensional aggregation (flat set of members)
• Exists of a fact
• Equality of two facts
• Adjustment (originally stated balance + set of adjustments = restated balance where the report period axis changes)
• Roll up (similar to an XBRL calculation)
• Fact greater than another fact
• Fact greater than zero
• Dimensional aggregation (nested set of members)
• Variance between two reporting scenarios

So that is about 10 categories.  I probably don't have all of them yet, but for all the XBRL Formulas I created, they fit into one of those categories.

Next, I distilled down the relevant things from the XBRL Formulas, basically the parameters of each category of XBRL Formula.  Then, I expressed those moving pieces in the form of, you guessed it, an info set.  Here is that info set. So, which of those files is easier to read, the info set or the raw XBRL Formulas? Hands down, it is the info set.

Finally, I wrote a little VBA application which read the info set and generated the XBRL Formulas from the information in the info set.  Took me about 4 hours to do that.

And so now if I want to create any XBRL Formulas, all I have to do is provide the information in the info set format and then run that info set through my VBA code (I could have used XSLT, but my VBA skills are better so that was easier for me)  (Here is the generated version and the HTML.

Want to estimate the value of a logical model? Go look at the complexity of the XBRL Formula file.  Then go look at the complexity of the business rules info set file.  Calculate in your head how much effort it would take to teach someone to create that XBRL Formulas file.  Then, think about how long it might take to explain how to create that business rules info set file.  Bingo.  Apply that to the fact tables, the relations, the report elements, etc.

Take a good, hard look at those info set files.  That will show you the value of a logical model.

Now, imagine having to use a software application to create those XBRL Formulas which is intended to be used by business users.  Which interface is likely easier to use:

• One that lets you edit the XBRL Formulas technical syntax
• One that lets you edit the business rules info set information

Basically, you can look at the business rules info set categories as a category of functions.  Provide the information required by that category, then generate the XBRL Formulas.

As part of a discussion thread on XBRL-Public, I learned something which I sort of knew but never really heard this articulation or explanation of semantic models before. It seems to make things clearer for me.

Wikipedia defines semantic models as:

Terms such as "semantic network" and "semantic data model" are used to describe particular types of data models characterized by the use of directed graphs in which the vertices denote concepts or entities in the world, and the arcs denote relationships between them.

That describes what XBRL does.

If you work with XBRL and you don't understand graph theory, you need to study up if you REALLY want to understand XBRL.

In an effort to help accountants understand what a quality SEC XBRL financial filing looks like and how to differentiate quality filing from a marginal or even poor quality filing, I have put together a number of resources.

Documentation of characteristics

First, this document provides a summary of characteristics and some details which helps one see how to evaluate quality.  These characteristics seem hard to dispute.  The list may not yet be comprehensive, but I believe that it is a step in the right direction.  Here is a list of the high level characteristics:

• HTML and XBRL convey the same message
• Financial integrity
• Clear business meaning
• Consistency with peer groups
• Consistency between periods
• Justifiable extension concepts
• Appropriate rendering
• Usable by analysts

Prototype battery of validation reports

Second, in support of those characteristics and to help better understand the characteristics, I created a battery of validation reports.  You can get to this prototype here.  Look closely at this prototype, there is really a lot to see. Notice that the reports are relevant to proving the characteristics listed above.

Model/Reference implementation

Third, I have been nurturing along a model or reference implementation of an SEC XBRL financial filing. This is the latest instantiation of that model. While the model is not a large SEC XBRL financial filing, it does cover all the bases.  It is this filing which is being validated using the battery of validation reports above.

Education

Finally, if you don't understand what you are looking at, you really can't possibly judge good from bad.  This web page contains the document Understanding SEC XBRL Financial Filings.  It provides a solid framework for and details needed to grasp XBRL.  It does not provide everything you need, but it certainly provides a solid foundation upon which to build.

I have updated the SEC XBRL financial filing reference implementation I have been maintaining. Enhancements include:

• It now passes 2 separate EFM validations (i.e. two different validators).
• Many more business rules were added, including rules which enforce core financial integrity and consistency checks. (You will REALLY want to look at these)
• Modified the cash flow statement to disclose continuing cash flows.

More to come.