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