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

(A downloadable PDF version of these recommendations and the results of the analysis refered to can be obtained here.)

Helping to create XBRL, helping to create multiple XBRL taxonomies including the US GAAP Taxonomy, helping to create the US GAAP Taxonomy Architecture, helping to test the US GAAP Taxonomy, creating XBRL instances with the US GAAP Taxonomy, and being a CPA gives me a unique perspective when I look at XBRL instances and XBRL taxonomies. I used this perspective to have a look at SEC XBRL filings.

This is a set of the top 10 categories of errors found in SEC XBRL filings which you should consider avoiding. This information comes from two sets of analysis of SEC XBRL filings. You can see a summary of the latest analysis here on my blog.

But let's get right to it. These are common mistakes which are seen in SEC XBRL filings and how to avoid them:

Don't use concepts when you should be using contexts to differentiate fact values: Specifically, you don't want to do something like creating the following two concepts: my:CashBeginningBalance and my:CashEndingBalance. Bad, bad, bad. You never see this in the US GAAP Taxonomy. Of 403 filers, about 9 made this mistake.
Don't use concepts to differentiate where a concept is used: Specifically, don't create concepts like this: my:Cash and then my:CashCF (meaning one cash concept for the balance sheet and another concept which represents the same thing for the cash flow statement).
Stick with US GAAP Taxonomy concepts where appropriate: There are some filers defining their own terms for things like "cash" and "net change in cash". See this blog post for more information. Only 4 of 403 filers defined a concept to replace the US GAAP Taxonomy cash flow statement which is supposed to contain the value for the net change to cash. That is a pretty good clue (4 of 403 creating a custom concept) that the US GAAP Taxonomy is most likely the way to go. This may not be true in 100% of situations, but from what I saw from those filings, I cannot see why they had to create a new concept. If you do not follow the pack and you create a new concept, a good idea would be to make it clear in the documentation for that concept why you felt that was necessary.
Check your calculations: When you create your XBRL filing, be sure to run the filing through an XBRL processor which checks the calculations. You can see what the results of these checks looks liike here. This is an example of a clean filing with no calculation inconsistencies. This is an example of a calculation inconsistency which indicates which, if compared to the HTML filing, is really an error.
Prove all your computations: Prove to yourself that all the computations add up correctly. This means not just the XBRL calculations, but also the [Roll Forward]s which cannot be validated by XBRL calculations. Another category of computations which XBRL calculations cannot validate relate to aggregations across dimensions. You need XBRL Formulas in these cases. Use both of these, XBRL calculations and XBRL Formula, to prove that 100% of your computations are correct.
Follow the US GAAP Taxonomy: If you look at the US GAAP Taxonomy you will notice that it is constructed quite consistently and a in very specific ways. You should follow that guidance within your filer extension taxonomy. The SEC or XBRL US do not provide rules to enforce this currently, but they will eventually. An example of what I am talking about here can be seen in this analysis. What this analysis did was to look at one specific area of the US GAAP Taxonomy information model: the [Table]. Per the US GAAP Taxonomy Architecture (see section 4.5 Implementation of Tables on page 38 of that PDF), a [Table] must always have at least one [Axis] and it must have exactly one [Line Items] concept. Further, since the US GAAP Taxonomy uses [Table]s to express every primary financial statement, you would expect that there would be a [Table] for each of those. This is what the test results would look like for a well prepared filing. This is what the test results would look like if you you are not following the US GAAP Taxonomy structure for a [Table]. If you want extra credit, model EVERYTHING within a [Table]. There are about 10 filers who already do this. In my view, that is where the US GAAP Taxonomy will be moving to in the future. I will stop with that recommendation for now, if you want further information on this send me an email or read my blog.
Avoid rounding within the XBRL instance, take care of this when creating the filing: Of 403 filings that I looked at, only one showed a computation error as a result of rounding. It is far better for filings to add up correctly within the filing than to force investors and analysis to deal with these rounding issues.
Don't stand out in the wrong areas: Sure, if you have a great financial statement you obviously do want to stand out to analysts. But you don't want to be a stand out for the wrong reasons. For example, of 403 SEC XBRL filers all but 8 followed the US GAAP Taxonomy computation of net change in cash. These 8 seem to be making a mistake from what information I have accumulated. You can decide if this is, or is not, an error for yourself, see this blog post. Far be it from me to say whether the 8 are correct, or the other 395 are correct. Whether this is truly an error or not is not my point. The point is, if you are not following the pack, you really should be able to explain and justify why. If you are comfortable with that explaination you are OK.
Push for software interoperability: One software vendor, XBRL Cloud, says that 28 filers have filing errors, per the Edgar Filer Manual, in their filings. Yet, the SEC accepted the filings. How is that possible? XBRL Cloud publishes its validation results that they on the web. The SEC publishes a test suite. Other vendors have software and they test their software against the SEC's test suite. Other vendors may disagree with the SEC test suite, I cannot tell for sure because they don't publish results on the web. It will take time for all the software vendors and the SEC to get on the same page in this regard. Eventually, all software vendors and the SEC will all have the same validation results. For now, just go for the least common denominator. Check out the errors which are being reported. If you can make them go away by fixing something, then I would suggest fix them. Talk to your software vendor and ask them if they feel the errors are valid. I predict that these differences in validation results will get resolved over the next six months or so.
Help investors use your information: In general, do things which make it easier for investors, analysts, and others to use your information. Not quite sure what those things are? Well, this list is a good starting point. Asking analysts is another idea, help them automate their analysis models rather than throw things in that make it harder to automate their analysis. Clearly you don't want to change the meaning of what you are reporting, you still need to properly reflect your financial information, don't change that.

For those of you who are not SEC XBRL filers or support those filers, these same errors should be avoided in other uses of XBRL also generally, not just in SEC XBRL filings. The point is that even if you have nothing to do with SEC XBRL filings, the list above is good information to know.

Want more details? See here and here.