Digital Financial Reporting

Still churning away at the business use casesI am trying to express using XBRL. Creating these is a lot like solving a sudoku puzzle. There really is only one right answer (which should be the case for XBRL, but it is not quite there) and the answer needs to follow the rules (in XBRL's case the business rules which helps you make sure things foot, cross cast, and otherwise tick and tie.)

The restatement use case is vexing. I have been shown a number of different approaches to expressing what amounts to accounting related prior period adjustments (corrections of an accounting error or a change in accounting principle). Most of the solutions are not particularly elegant which is a clue they are wrong. Each time I think I have the answer correct, one more moving part needs to be dealt with which makes everything fall apart.

From an accounting perspective, this explains the situation.  If you look at the PDF. You will see three financial statement fragments: the balance sheet, the income statement, and the statement of changes in equity. The three different pieces interrelate with each other, that is what makes this challenging.  The balance sheet contains retained earnings which is also shown in the statement of changes in equity. Net Income (Loss) is on the statement of income and the statement of changes in equity.  The prior period adjustment flows through the income statement and is shown in the prior period adjustment portion of the statement of change in equity.  The retained earnings balance connects the prior period adjustment and the changes in equity portions of the statement of changes in equity.  Accountants get all these pieces.  Technical people might not.

From a technical perspective, these are the moving pieces.  Within this one use case you have several roll ups (balance sheet, income statement, total prior period adjustments, total changes in equity), a roll forward (changes in equity), an adjustment (prior period adjustment). The challenging thing to piece together is the XBRL instance.  The XBRL taxonomy is a less of a challenge, as long as the architecture is correct. You can view the XBRL taxonomy here.  That will give you a sense for the strategy I have used to create the XBRL taxonomy.  This Fact Group visualization allows you to get a sense of the information being expressed.

The tricky part is this:

1. Getting all the calculations to work.
2. Getting the XBRL Formulas to work, the business rules of the information.
3. No duplication of concepts or contextual information.  Doing this is basically a hack, it is not elegant and you will run into data integrity issues.  Basically, the different sections (balance sheet, income statement, statement of changes in equity) all need to properly relate with one another properly.
4. Everything needs to be logical and easy to explain.

Today, doing this is a lot like building a proper database schema unfortunately.  Longer term, this will not be the case because (a) an elegant solution will exist and will be well articulated and (b) software will implement that solution in the background and will not let you make any mistakes.

Regretfully, software does not work like that today.  Software is still dealing with the XBRL syntax level, not hiding XBRL and properly implemented solutions behind the software solution.  So, users have to figure all this stuff out, user by user.

Don't worry, that problem will go away.  These business use cases will contribute to that, that is part of the reason for creating things like these business use cases, the metapatterns upon which the business use cases are built, etc. (These are basically patterns or design patterns.)

Currently, I cannot get all the pieces to fit together correctly.  Right now only one piece of the puzzle is out of sync.  That could be an easy fix of an error I am making, or it could mean a fundamental flaw in the architecture of how I am trying to solve the problem.  I cannot tell which right now.

The primary piece of architecture being used here to solve the problem is the notion of a "Report Date [Measure]" (or report date dimension).  This is implemented as an XBRL Dimensions explicit dimension.  Others have suggested that this Report Date [Measure] should be implemented as an XBRL Dimensions typed member (an implicit dimension, see this example).  Whether this is an explicit dimension or an implicit dimension will not solve the problem I am having; they are both dimensions and work the same way.

Do you have ideas on how to articulate the XBRL instance information and the resulting XBRL taxonomy to make this work elegantly (i.e. I don't need a hack, I have plenty of those)? Send me an email.

I am continuing my work to document business use cases and how one can express them in XBRL taxonomies and XBRL instances and I have, I belive, determined that there are two new metapatterns.

To summarize, the Roll Forward metapattern is overloaded, in my view, and really should be broken out into three metapatterns:

• Roll Forward: This is what exists now. The Roll Forward reconciles a balance at one point in time to a balance at a different point in time.  This is a simple thing that most people learned in their auditing class most likely: BASE.  Beginning + Additions - Subtractions = Ending. In the XBRL world you have one concept which is an instant (the balance) and one concept which summarizes the changes (the additions and subtractions).  The only dimension which changes is the period (Calendar Time [Measure] in the business reporting logical model.  Here is a very basic example.
• Adjustment: This is new.  I had always tried to model this as a Roll Forward, but it is really something different than a Roll Forward. For an Adjustment, the period (Calendar Time [Measure]) does not change, it stays the same.  What changes is some other dimension.  Here is a basic example. In the example, the balance of retained earnings is restated for prior period adjustments.  The equation is: Originally Stated Balance + Adjustments for Prior Period Errors = Restated Balance. In the example (look in the XBRL instance at the contexts), what changes is the Report Date [Measure]. Frankly, I believe that the definition of an adjustment is a change in the report date. If one looks at the details, you can see the differences between a Roll Forward and an Adjustment.
• Variance: This is new. I had always modeled this as a Roll Forward also. Here is a basic example to help you visualize what is going on. In that example, we have Actual - Budget = Variance. The variance seems to be the difference between two Members of the same dimension or called Measure in the Business Reporting Logical Model. While the Roll Forward appears to specifically relate to changes in the period and the Adjustment appears to relate to changes in the report date; the Variance appears to be generally applicable to any dimension (Measure). The Domain of the dimension (Measure) is what expresses the actual variance value.

So while I do want to check with the super smart XBRL people that I know to be sure that breaking the Roll Forward out like this is the thing to do, I would contend these are in fact metapatterns.

Alternatively, one could perhaps argue that the Adjustment and Variance are specializations of the Roll Forward.  But, if one were to look at the details in the XBRL instance and the XBRL taxonomy, I really do think someone knowledgeable about XBRL and business reporting would break these out into separate metapatterns.

Have a look at the details, let me know your vote. I will get back to you with what others think at some point in the future.

A number of years ago after a meeting at the XBRL International Conference in Tokyo where I was showing some things I was working on to Geoff Shuetrim and Rene van Egmond, Geoff made the statement, "Charlie, you are like a guy who is trying to escape from prison using a teaspoon."

I am not sure if that was meant as a complement, but that is the way I took it. I have been trying to achieve something for, I don't know, three or four years and I have finally reached my goal!

The goal was to render the information contained within an XBRL instance in a human readable format given any XBRL taxonomy.

The journey included rendering a complete IFRS financial report of a Singapore company, the Deloitte model IFRS financial report, modeling the some 28 business reporting patterns I had pulled from those and other such financial statements, modeling the 29 USFRTF patterns document patternsused to understand how to create the US GAAP Taxonomy, re-modeling the USFRTF patterns into XBRLS business use casesin order to overcome issues discovered with the USFRTF patterns. Each of these contains a rendering, and each of the renderings was generally created by hand coding an XSLT style sheet.

I have one final iteration of these business use cases to create. I want to model the business use cases I have been collecting (really financial reporting use cases) using the Business Reporting Logical Model. I have created one use case already, the "Simple Hierarchy" which you can see below.  The others will follow.

The difference is that I will not code these renderings by hand, they will be 100% automated. I already have the process in place, it works, as can be seen from the renderings below.

How do you do this?

The following things are needed to automate renderings and generate something useable by humans:

1. You have to have a good information model, i.e. a good XBRL taxonomy. It has to be consistent. That is the starting point.  If the model is inconsistent or fundamentally broken, you will never achieve your result.
2. Your XBRL processor has to ouput two consistent info sets.  In the Business Reporting Logical Model the two sets are the Fact Groups and the Measure Relations.  (See the link above to understand this.
3. The semantics of the XBRL taxonomies need to be aligned.

Note that the first two have huge benefits, even if your semantics are not aligned. As long as the XBRL taxonomy is internally consistent, any XBRL instance can be reduced down to these two fundamental pieces: fact group and measure relations as they are called in the Business Reporting Logical Model.  You can call them anything you want, but you will need them.  XBRL Cloud, who helped by generating these in its format call them fact tables (here is a human readable version) and a logical model.

Again, let me repeat. 1 and 2 above is all you need for one taxonomy to work. To have interoperable taxonomies you need number 3.  That is provided by the Business Reporting Logical Model: aligned semantics.

Two Messages

There are two messages here.

First, XBRL already HAS a logical model, but most people cannot see it. This is shown by the fact table created by XBRL Cloud, or at least you can get a glimpse of that model.  Into that model will fit items, tuples, XBRL dimensions, typed dimensions, custom created segment and scenario metadata, etc.  This is an epiphany for me, I never really realized this. This is good because at a technical level, this provides very substantial leverage.

The second message is that there has to be some mapping between the XBRL syntax used and the semantics expressed. If this is achieved you get leverage across taxonomies and business users can make use of the functionality of these very technical tools without the need for help from the IT department.

The bottom line is this: I had always thought that XBRL's flexibility was the real problem. That is not the problem. The problem is the inconsistent use of semantics within and across XBRL taxonomies.  This is generally unconscious by most of those who create XBRL taxonomies because they tend to not understand how XBRL works.

My Automated Renderings

Here are the automated renderings I was able to generate. I will have more information later, there is a lot of stuff going through my mind as a result of going through this exercise.

The really good news is that teaspoon enabled my escape from the XBRL prison I have found myself in for the past 10 years, literally.  I am really seeing some things in a very new light.  More to come, stay tuned. I see some very significant positive implications.

Here are my renderings. Notice that this is a number of different XBRL taxonomies, each complying with the Business Reporting Logical Model:

Business Reporting Metapatterns (basic components of the business use cases):

• Sales Analysis, Summary:
• Sales Analysis, by Business Segment:
• Sales Analysis, by Geographic Area:
• Accounting Policies:
• Property, Plant and Equipment; by Component:
• Roll Forward of Land: (This rendering is not really acceptable, but it is readable. A better rendering algorythm and format is needed for this type of information model. I know what it should look like, just have not done the programming yet.)
• Director's Compensation:

State Fact Book:

• Population Trends:
• General Information for Period:
• General Information at Point in Time:
• Financial Information, by State:
• Financial Information, by State, Alternative Aggregation of Expenses:

Business Reporting Use Cases: (This is only the first of 28 business use cases which I will eventually create)

• Simple Hierarchy:

Transaction Use Cases: (This is a prototype I built for someone else which uses their dimensions but builds upon the Business Reporting Logical Model.)

• Demo Transaction: (Note that this had two typed measures)

This post begins a series of posts where I point out the benefits of the Business Reporting Logical Model.  If you are unfamiliar with the Business Reporting Logical Model, be sure to check out my straw man implementation of this model.

In my straw man implementation of the Business Reporting Logical Model, I created a prototype application in Excel called the "Hypercube Viewer" which allows you to extract and render XBRL instance information. The prototype application does not actually read XBRL, rather it reads an info set generated by an XBRL processor which supports the Business Reporting Logical Model.  The prototype starts by reading an RSS feed which contains links to XBRL instances.  My straw man implementation uses this RSS which points to two XBRL instances: ACME Company and Sample Company.  Here are the info sets for those two companies:

• ACME Company: Fact Groups, Measure Relations, XBRL instance
• Sample Company: Fact Groups, Measure Relations, XBRL instance

If you follow my blog, you may have heard about the State Fact Book prototype which I had created to test some things. I created this prior to the Business Reporting Logical Model being available. I did use XBRLS in creating the State Fact Book which has many characteristics of the Business Reporting Logical Model.

What I wanted to do is refactor my State Fact Book XBRL example to use the Business Reporting Logical Model. To do that, I made two changes to my State Fact Book XBRL implementation.  First, I corrected the data I was using to fix the error in the US Census Data which I had discovered and the Census Bureau subsequently adjusted. Second, I modified the State Fact Book taxonomy to use the Business Reporting Logical Model. I then generated the info sets for the three XBRL instances I was using which you can see here:

• Population Trends: Fact Groups, Measure Relations, XBRL instance
• General Information: Fact Groups, Measure Relations, XBRL instance
• Financial Information: Fact Groups, Measure Relations, XBRL instance

Next, I organized those three XBRL instances with the XBRL instances above into a new RSS feed which you can see here. This RSS contains all 5 XBRL instances, all created using the same Business Reporting Logical Model. I then pointed a new version of the Hypercube Viewer to that new RSS feed to see if the Excel application would read those new info set files generated by the XBRL processor.

After fixing a few bugs in the State Fact Book XBRL taxonomy and the application, my Excel application would read all five sets of information and render the sets consistently in the way I would have expected the information to be rendered.  You should consider trying this for yourself.

For the intellectually curious who understand a little about Excel, you may want to consider reverse engineering the Excel application to create something which reads those info sets.  In doing so you will realize the benefits of the consistency enabled by the Business Reporting Logical Model.

Even if the Business Reporting Logical Model never becomes an XBRL International standard, everyone creating an XBRL taxonomy will have to use something to ensure consistency in the XBRL taxonomies created. This is less important if you do not use taxonomy extensions, it is vital if you do allow extensions. Those creating extensions have to be guided to create extensions which are consistent with the taxonomy they are extending.

What I learned from this exercise is that some of the things I thought were important are not really important at all. I have always tried to keep taxonomies consistent by using the presentation linkbase.  It is clear to me now that that is the wrong approach.  I also thought that you would never get consistency unless you ditched a number of the pieces of XBRL such as typed members and tuples.  That really is not necessary. You do need to control those pieces and others, but you don't necessarily need to ditch them all together.

Consistency is key.  The Business Reporting Logical Model does allow for creating consistency.  There are certainly other alternatives. While smart software engineers can figure out all the ins and outs of XBRL and generate an info set with information similar to the ones generated for my straw man implementation of the Business Reporting Logical Model, the "channeling" of XBRL syntax which the model does makes it significantly easer to process the XBRL syntax to generate that info set. Once you have the right info set, you can convert that into whatever syntax you might like. The syntax is really unimportant.  It is the consistency of the business semantics which is important. The Business Reporting Logical Model is one way to achieve that consistently.  There are others.

In order to both test the Business Reporting and Financial Reportin Logical Models and demonstrate how to implement SEC XBRL filings using those models, I created a mapping from the logical models to the SEC XBRL implementation.  You can get that mapping here. If you wanted to contrast that to the mapping of my straw man implementation, that mapping can be found here.

What is easy to see from the mapping I created is that it is very possible to use these logical models in creating SEC XBRL filings and their related XBRL taxonomies.  What is harder to see is why that is beneficial.  To see the benefits, one would need to use a software application which leverages the logical models, making it so you don't have to struggle with XBRL at the syntax level.