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.