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

There are a number of ambiguities which you will need to overcome in your SEC XBRL filings. Overcoming these ambiguities can help your renderings look better in the SEC XBRL viewer, enhance comparability of your reported information, help you improve the integrity of the information you report.

Further, if software vendors take advantage of these ideas they can implement easier to use software because the business users don't have to deal with these issues because the applications deal with the ambiguities for you behind the scenes.

Here is a list of the biggest issues which cause ambiguity and how to overcome the issue:

Lack of clarity of extended link and hypercube semantics. What is the business semantics of an XBRL extended link? How about the business semantics of an XBRL Dimensions hypercube? What is the relationship between an extended link and XBRL Dimensions hypercube? There are no real rules articulated in the US GAAP Taxonomy as to exactly when you need to use an extended link and where, when you need to use a hypercube and where. How to overcome. The safest way to overcome this issue is to create one hypercube per extended link and to always use hypercubes. Basically, you will end up with a lot of small consistent pieces. Name and label the extended links and hypercubes so that they are the same or very similar. Another reason this is good is that you can get the most predicable representation of your information in the SEC XBRL viewer.
Inconsistent information models. The concepts of an XBRL taxonomy are articulated in what amounts to a tree view in most software applications. For example, the US GAAP Taxonomy has [Table]s, [Roll Forward]s, [Axis], [Line Items], and other pieces of the XBRL taxonomy organized in a specific manner. There are other things in the taxonomy which are organized but not explicitly identified such as roll ups (calculations) and general hierarchies. There are two things which provide information about this organization which I refer to as the information model: the US GAAP Taxonomy Architecture document and the US GAAP Taxonomy itself. For example, section 4.5 of the document discusses how to build [Table]s. Or, looking at the US GAAP Taxonomy can provide clues. The US GAAP Taxonomy itself and the SEC don't require that the information models be followed. How to overcome. The best way to overcome this issue is to simply follow the information models consistently within your extension taxonomy.
Inconsistency between presentation, calculation, and definition linkbases. There are three different hierarchies of concepts (information models) that you can create. What does it mean if you have inconsistencies between your presentation, calculation, and definition linkbases? If they are inconsistent, which one is correct? For example, if you have a concept in your presentation relations but that does not exist but SHOULD exist in the calculation relations; how should determine which one is correct? How to overcome. The best way to overcome this issue is to make sure your presentation, calculation, and definition linkbases are consistent. Clearly this does not mean that they will look the same, rather it means that if you build your presentation information model in a certain way then you can predict what the calculations and definition relations look like.
Extension points. What areas of the US GAAP Taxonomy are you allowed to extend and what areas are best not extended? For example, certain higher level areas of the US GAAP Taxonomy probably should not be changed. Lower levels of hierarchies are more likely to be appropriately modified. How do you know the difference? How to overcome. When you are making changes to higher levels in the US GAAP Taxonomy be able to explain why you are making the change. If you can rationalize the change to yourself, you can probably rationalize it to others. If you cannot, you probably have not thought through the modification throughly enough.
Extending as an concept or a dimension of a concept. There are two ways that new information can be articulated within the US GAAP Taxonomy: create a new concept or create a new [Member]. The US GAAP Taxonomy does both, in fact they do both for exactly the same information. Go to the US GAAP Taxonomy and look up the subclasses of Property, Plant and Equipment (Land, Buildings, Furniture, etc.). You will find the exact same information articulated as concepts and as [Members] within an [Axis] of those concepts. Why would you need both? How to overcome. First off, if you don't understand what I am talking about here, you need to learn. Being unconscious of this issue is a good recipe for making a mistake. After you understand the issue, pick one approach and stick with it consistently.
Information integrity of numeric values. Your numbers need to add up correctly. All of them, whether the US GAAP Taxonomy contains the relations or not. XBRL calculations cannot achieve this result. Roll forwards, dimensional aggregations, and other such computations cannot be verified using XBRL calculations. Not checking the numeric relations will lead to errors. How to overcome. Every numeric value which has a relation with another numeric value should be checked in some manner. One way to do this is using XBRL Formulas. But the SEC does not allow you to submit XBRL Formulas with your SEC XBRL filing. No problem, create the XBRL Formulas to verify you XBRL instance and don't submit it to the SEC. You will need these XBRL Formulas to also be sure your current period numbers tie to your prior period filing. Using a calculator and a human to do this is both too costly and insufficient and will lead to errors. If your information model is consistent, most of the XBRL Formulas can be auto-generated by software.

Following these recommendations can lead to better renderings of filed information and better comparability both between filing periods and with other public companies. Further, if software vendors implement ways to hide these issues from users, it can make the software and dealing with XBRL significantly easier.