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 had mentioned Quantrix before (see the last link in the blog post).  Here is another demo of how they approach articulating business information.

Now, I don't know if they support XBRL.  But imagine editing an XBRL taxonomy using that interface.  The interface hides XBRL, abstracting it out leaving the user to focus on business semantics rather than having to struggle with the XBRL syntax.

Watch that demo.  Then have a look at the business use cases here. Look at the "Rendering" for each of the business use cases, seeing how it might fit into the demo you saw.  What I call a "slicor" on the renderings, they call a "filter".  What I call "Measures", they call "categories".

More later on this...stay tuned!

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.

I mentioned that I was updating the business use cases or patterns that I had been nurturing along over the years in another blog post.

I am making more progress and am up to 20 business use cases and have added a bunch of new features.  In particular check out:

• The additional use cases added.
• A landing page for each pattern, here is one example.
• Something to help you find the business use case you are looking for.
• An index page which puts everything together.
• A JPEG image for each business use case (see the landing page).
• Creative Commons licences in key areas to make it clear all this is there for others to make use of as they see fit.

Thanks to all those who have sent ideas and have made me aware of errors so that I can correct them.

I have created an updated set of metapatterns, business use cases (i.e. patterns), comprehensive example, and basic example of using XBRL. I have nurtured these examples over the years and have not adjusted them to comply with the Business Reporting Logical Model created by the XBRL International's Taxonomy Architecture (TA) working group, of which I am a member.  These examples are constructed to help come up with that Business Reporting Logical Model and to prove that model.

You can find this information here in various stages of completion. If anyone has ideas on things they might like to see, please contact me directly and I will see what I can do to add what you feel you might need if it makes sense.

Creating these ultra-high quality (my opinion, I can back it up) examples has been a long process. Over the years I have had a lot of help from a lot of people. While I created these examples and take full responsibility for any errors (although I have validated each of these using three different XBRL processors), I would like to thank those who have helped in the past, these could not exist without their help. At this stage, I would particularly like to thank Herman Fisher and Frederic Chapus, both of UBmatrix, for their help with XBRL Formulas. I would also like to thank Cliff Binstock of XBRL Cloud for his help in generating his fact tables and getting those converted to the Business Reporting Logical Model. I would also like to thank those who are members of the XBRL International Taxonomy Architecture working group for their efforts to create and drum up support for this work. (We still need more members.)

• Metapatterns: Basic building blocks from which the Business Use Cases were built. All of the business use cases can be distilled down to these metapatterns. (Complete.)
• Business Use Cases: Follow the metapatterns. Contributed to figuring out what the metapatterns were. (At this point I have 11 of about 30 business use cases completed.)
• Basic Example: Takes the metapatterns and puts them all into one basic XBRL taxonomy which is quite simple, but shows how the metapatterns relate to one another. Tests the relations between the metapatterns. (Complete except for detailed documentation.)
• Comprehensive Example: Puts each of the business use cases into one XBRL taxonomy and XBRL instance, testing the interrelation of the business use cases.  Also, intended to look like a financial report; but not as complex as a real financial report. (Still have a ways to go on this, I want to finish the business use cases first.)

Keep checking back if you are interested in this sort of thing.  XBRL is not going away any time soon. While this information is quite detailed, I contend that it is worth diving in. Investing in understanding these details pays dividends in many different ways. Also, again, feedback is welcomed. Good ideas to make it even easier to use in particular.

If you are familiar with XBRLS, this new set of examples is intended to replace XBRLS.  Use this stuff instead.