Digital Financial Reporting

This post is somewhat of a summary of information made available in a number of other blog posts over the past 18 months or so.  Over the past 18 months I have tried to figure out the best way to get XBRL to meet the needs that I have which are most probably similar to many other CPAs.  The use case is fairly broad: general business user to business user information exchange.  I think back on the 15 or so years that I worked within the accounting and financial reporting function of small to medium sized businesses or as a consultant to others responsible for that function.  What would be useful to this process?

Based on what I have learned about XBRL from, what, 10 years helping to create it, years of building XBRL taxonomies for both US GAAP and IFRS, years of involvement with others creating taxonomies such as COREP and FINREP, discussions with others who have worked on other taxonomy projects such as the Netherlands and Australian Standard Business Reporting (SBR) projects; this is what I see.

First off, there are a lot of clues about how to use XBRL from regulators who implement XBRL and make information available to others.  Three sources in particular are very good: COREP, US GAAP Taxonomy, and the FDIC. The fact is that there are more and more implementations and it is getting increasingly challenging keeping up with all of them.  Further, I have not seen a lot of new ideas lately.

Pulling all the information that I have together, this is the approach that I have come up with for taming the XBRL beast and putting it to use to meet business objectives:

• Avoid proprietary approaches: A mistake that I see a lot of projects making is adding little proprietary things which muck up their otherwise standard XBRL solution.  Avoid that temptation. Stay within the XBRL standard.  It can be done.
• Settle on a minimal architecture: XBRL is a general solution to a large set of business information exchange problems, you don't need all of it. Identify the pieces that you need, articulate them in the form of an architecture, make sure you have a good conformance suite to help automate the testing process of staying within the bounds of the architecture you decided on, and then build your solution.
• Articulate and stick with an information model: I have not figured out yet if an information model is part of an architecture or something that sits on top of an architecture.  It seems to me that they are to separate things, basically making them more modular.  Particularly if you use extension and allow business users to modify the information model, you really need a documented and controlled information model.  This allows for the creation of an internally consistent XBRL taxonomy and extensions which are likewise consistent.
• Keep it simple: In all likelihood you will be working with multiple different implementations of XBRL, meaning different regulators and business partners which you have to deal with who have chosen different XBRL architectures, different information models, and maybe even have gone down the proprietary route slightly within their solution.  How are you going to deal with each of these different XBRL implementations?  Are you  going to let parties external to your organization dictate how you need to use XBRL internally?  Maybe, maybe not.  If you need control over all of this, an abstraction layer between your internal implementation and other implementations is necessary.

Seems like a lot to build all of the above, and it is.  Architecture, information model, abstraction layer.  There are two approaches to getting there: (1) "roll your own", (2) borrow from someone else.  Building your own gets you more of what you want potentially, but you have to have a lot more knowledge about XBRL to do this and it will cost you quite a bit more money figuring it out.  Borrowing from someone else you give up some control but what you get are better functioning and less expensive systems, if you do this the right way.

I call the borrow from someone else option an appliation profile.  An appliation profile rolls an architecture and an information model and all the testing infrastucture necessary to ensure you are following that architecture and information model correctly into one tidy package.

There is one negative thing that I still see which needs to be made to somehow go away.  It would be rather easy to build a tidy application profile package using one software vendor's tool.  The fact is that if a project implements XBRL correctly, this is exactly what they have done for their project.  All this is necessary to make XBRL work.  The problem is that every project is repeating this process.

This creates two things: lots of different and non-interopreable application profiles and lots of different vendor software which will not interoperate.

Or, another way to say this is that what is really needed are a few application profiles which a lot of people are using (thus broad support exists) and cross vendor support for these broadly used application profiles (thus cross vendor interoperability).

How to get to this is the 64 thousand dollar question.

Here is more information which points back to the steps to reaching the conclusions which I have reached:

• Application profiles are good (and why there will be more than one)
• Taxonomy creation best practices (or common mistakes and how to avoid them)
• High level model of XBRL (difference between logical model and physical model of XBRL)
• Problems of taxonomy interoperability (why XBRL taxonomies are not interoperable)
• Advantages of an easy to use logical model (XBRL's missing logical model)
• Possibilities of how all this could work if done correctly (business user to business user information exchange)
• You cannot do this with  XML alone (What XBRL brings to the party)
• The proliferation of XBRL "dialects" (why XBRL taxonomies are not interoperable)
• Reducing business information to three meta patterns (improving XBRLS)
• Adding additional meta data to your taxonomy(improving XBRLS)
• An XBRL application profile which solves these problems (XBRLS is attempting to solve these issues)
• A proper logical model: interactive information hypercube, shape, and flow (power of meta patterns)

Now all I need to do is condense all this information into one paper which puts all the pieces together in a more logical and understandable way!  Maybe I will call it "Practical XBRL: Taming the XBRL Beast".