XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

I have been creating XBRL taxonomies for quite a few years. I was on the team that created the very first US GAAP Taxonomy which was released in 2000 (I even created my own taxonomy creation tool using Microsoft Access), I spent about three years creating several different iterations of the IFRS-GP taxonomy, I participated in the meeting to determine the architecture for the COREP taxonomy, I was on the team which created the 2008 edition of the US GAAP Taxonomy which the SEC paid for, and there were lots of other taxonomy projects in between where I participated either directly or indirectly (i.e. comparing notes with others in order to learn as much as I could about creating taxonomies).

In creating taxonomies, I have probably made every mistake there is to make. Some of the things we did not even realize were mistakes when we were building taxonomies, eventually revealed themselves as mistakes. Very good information about this journey can be found here. Information about some of the conclusions reached can be found here.

During this process I have accumulated a list of the ten most common mistakes in creating taxonomies. I have been guilty of many of these mistakes myself in the past. I try and avoid these today when I build an XBRL taxonomy.

Mixing dimensional (using XBRL Dimensions) and nondimensional (not using XBRL Dimensions) in the same taxonomy. The clearest evidence that this is a really bad thing (not bad, really bad) is that XBRL Formulas partitians it's world as "dimensional" (i.e. with XBRL Dimensions) and "nondimensional" (i.e. without XBRL Dimensions). Mixing these two will cause lots of problems.
Looking at pieces of an XBRL taxonomy in isolation. Taxonomies are not used in isolation, they are used in XBRL instances along with other parts of the taxonomy. The next two items also relate to this point.
Not creating ways to be sure that the same things are expressed in the same ways in different areas of the taxonomy. This is both about inconsistency and being clear to the users of the taxonomy. If you are not doing things to help you be consistent, there is 100% probability that you are being inconsistent. If you are inconsistent, try and write documentation and explain to someone how to use the taxonomy. Further, inconsistencies will be confusing to users of the taxonomy.
Not verifying that an XBRL taxonomy works by creating XBRL instances. It makes sense to be sure you are getting what you expect from your taxonomy. The only way to do this is to create XBRL instances to be sure you are getting what you expect.
Modeling a taxonomy based only presentation. So this problem typically results from a number of things. The first is a lack of a data modeler on the team (see the next point). Another is business people making decisions which technical people should be making.
Having no one on the taxonomy creation team which has data modeling expertise. Taxonomies are data models. Not having a data modeler involved would be like having a business person create the database schema for an applicaiton you are building.
Using tuples if you need extensibility. I have see-sawed on tuples, and to some degree still cannot figure out if they are evil or helpful. One thing is very clear. If you need extensibility and you use tuples, you will run into problems.
Not controlling how users of the taxonomy can extend the taxonomy. If you don't control how a user of the taxonomy extends the taxonomy, you are pretty much guaranteed to have a free-for-all when users do extend the taxonomy.
Not using a style guide. The style guide created for the US GAAP Taxonomy was one of the most painful things I have ever participated in creating, but also one of the most helpful.
Not documenting the taxonomy architecture. There are two problems with not documenting a taxonomy's architecture. First, the team creating the taxonomy does not understand the architecture. Second, users of the taxonomy don't understand the architecture. What both of these mean is that "anything goes". You are generally bounded by what XBRL allows, but then again I see people proposing to add attributes which are not in the XBRL specification and otherwise do things which move away from the standard. Documenting a taxonomy's architecture eliminates this problem.