Ten Common Mistakes Made When Creating XBRL Taxonomies
I see the following 10 common mistakes made when people get together to create XBRL taxonomies:
- Don't have clear, useful requirements: The first mistake that is usually made is that clear, useful requirements or principles are not created that drive decisions.
- Confusing business domain tasks and technical tasks: Business professionals should make domain decisions; technical professionals should make technical decisions. Mixing these two tasks wastes time and leads to bad choices.
- Don't treat project as an engineering task: Taxonomies need to thought about using engineering processes and techniques. The engineering design process works to create things that work.
- Little or no consideration given to existing taxonomies: Existing taxonomies have strengths and weaknesses. If you understand those strengths and weaknesses, that information can be used to make the taxonomy you are creating better. If you don't understand those strengths or weaknesses, then you probably should not be building taxonomies.
- Don't use XBRL instances to judge if taxonomy works correctly: Ultimately, an XBRL taxonomy is used to build XBRL instances. If XBRL instances don't work correctly, then the taxonomy is not constructed correctly.
- Don't test nearly enough: Related to #3, testing is important. Most taxonomy projects test about 1% or less of what they should be testing. Testing results should drive decisions, not personal opinions. (See #3, engineering design process; prototype, test, iternate, communicate)
- Don't involve software vendors appropriately: Not involving software vendors, which create the software people using the taxonomy will interact with the taxonomy, appropriately is a big missed opportunity. That said, most software vendors don't really understand how to engage properly in a taxonomy creation project.
- Taxonomy pieces too big: Taxonomy pieces tend to be too large in taxonomies. More smaller pieces that are well organized is better. Remember, computers will be interacting with the taxonomy.
- Don't understand the "model as dimension or primary item" quesion: Endless debates occur around the topic of whether something should be modeled as a dimension or modeled as a primary item in a taxonomy. Taxonomy requirements and testing drives this decision, not personal choice.
- Not understanding and mixing dimensional and nondimensional models: The multidimensional model is well understood. The multidimensional model works well in XBRL that functionality is not open for debate. Taxonomy creators need to first understand and then work within that model not fight with it.
If the engineering design process was followed, resulting taxonomies would be superior in terms of functionality. Managing a project where a lot of different people from different domains are involved is challenging. If done right, good thing result. If not, then this is what happens:
Reader Comments