Digital Financial Reporting

I have reached a big milestone in updating the business reporting use cases which I am putting together. You can get to those from this index page which contains the use cases plus some other things relating to the use cases. This is a direct link to 31 business use cases.

Several points about these business use cases.

• You can download the complete set, see the download link on the page.
• Each use case has been validated by 4 different XBRL validators and all of those validators report no errors.  (The XBRL Formula stuff used is only validated by one validator.)
• I would consider these use cases "very safe" areas of XBRL.  This is because of the consistency in the validation across 4 different validators, each provides the results expected, XBRL extension works as expected, and all approaches used come from years of fiddling around with different approaches to articulating these use cases in XBRL. (Considers techniques use in the most current US GAAP taxonomy, IFRS taxonomy, COREP, etc.
• All the visual stuff in the taxonomy such as the "[Fact Group]", "[Member]", "[Measure-Concepts]", "[Roll Forward]", "[Roll up]" (and so forth) is only visual eye candy and is unnecessary.  Those things appended to the concepts and labels only helps one visualize the taxonomy given the lack of assistance provided by software these days.
• While I did provide a presentation linkbase, the presentation linkbase is not necessary.  Basically, the presentation linkbase can be autogenerated from the definition linkbase.
• The presentation, calculation, and definition linkbases are consistent.
• While I did use the substitutionGroups of the business reporting logical model schemaand doing so is very helpful in creating a consistent XBRL taxonomy, doing so is not necessary.
• While I did use the measures of the financial reporting logical model schema, I really did not have to because these taxonomies are only demos.  However, the technique of using those measures does enhance comparability across XBRL taxonomies if that is desired.
• These XBRL instances and XBRL taxonomies do follow the useful practices of the Financial Reporting Instance Standards (FRIS) and Financial Reporting Taxonomy Architecture (FRTA), they do not necessarily follow the useless syntactic constraints imposed by FRIS and FRTA.  On the other hand, the XBRL instances and XBRL taxonomies do follow a number of best practices which would be a good idea for something like FRIS or FRTA (or whatever replaces them) should make use of. So, don't expect that these comply with FRIS or FRTA validation.

I do intend to provide additional documentation which explains the subtle characteristics of these use cases which one can miss if they are not pointed out.  Not sure when. My next goal is to create a comprehensive example which tests these use cases by seeing how they interrelate with one another within one larger business report.

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 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.