The Journal of Accountancy, a trade publication of the public accounting profession, has published an article titled Avoiding Common Errors of XBRL Implementation. This describes the article:
This article describes common errors appearing in Voluntary Filing Program (VFP) Forms 10-K that continue to occur under the SEC’s mandatory Form 10-Q submissions and discusses how they can be prevented. CPAs can use this information to develop expectations about the challenges of XBRL document preparation and of performing agreed-upon procedures engagements. It is especially important for companies to be aware of these potential errors, because the errors occur not only in filings prepared in-house, but also in filings prepared by third-party financial printers. Regardless of who prepares the filings, the company is ultimately responsible for the documents’ accuracy.
(Be sure to check out my blog post which summarizes the top 10 errors which I see in SEC XBRL filings.)
The article does a pretty good job of summarizing many of the common errors, providing examples, and solutions to the errors; but what it does not do is ask why many of the occur and the analysis could have good "deeper". I speculate that CPAs will get to this level with more experience, the good news is that there is a realization that there are some things which need to be dealt with.
Here is a list of the "Steps Where Errors Occur" in the article and I have added things which can be done to help make these types of errors not occur in the first place. Here is the list from the article using their categories, adding my commentary:
- Mapping: Selecting inappropriate elements from the US GAAP Taxonomy (Users need better search and filtering capabilities in taxonomy creation software so they can FIND the right concepts. The use of synonyms to help identify concepts would be very helpful to users.)
- Mapping: Creating unnecessary new elements (If you can find the existing elements, there is less probability of adding a new element unnecessarily. Again, search and filtering capabilities helps this. Better guidance on when it is appropriate to add a new concept seems necessary also based on what is appearing in SEC XBRL filings.)
- Extensions: Presenting elements in the wrong location in the rendered financial statement(Well, in my view this is a misguided suggestion indicative of most CPAs obsession with presentation. I am not saying that presentation is important, what I am saying is that presentation and extension are two different things. Most XBRL software force users to work at the XBRL syntax level. If software allowed business users to work at the financial reporting semantics level, this would not be a problem. When business users realize this, they will push software in the right direction. What would help is better taxonomy modeling which is information driven, not presentation driven.)
- Extensions: Failing to establish mathematical relationships among elements(Again, why is it that a software application cannot automatically adjust the computation when say a new line item is added to a balance sheet? Software can do this. Again, the problem here is software working at the XBRL syntax level, not the financial reporting semantics level. Another example is that every roll forward has a computation. Why should a business user have to physically establish the computation if they just told you something is a roll forward?)
- Tagging: Assigning incorrect signs to the value of the element (This is a function of not having validation rules for all the computations. If you have the proper validation rules, you will never be able to inadvertently put the sign in incorrectly. And if software is working at the financial reporting semantics level and it automatically builds the computation relations for you, you will get those rules.)
- Tagging: Making data-entry errors (Data entry errors is a function of having to enter information. If you don't have to enter information, there will be no data entry errors. This is why the "bolt on" approach is not a sustainable approach, inherently it is an approach where data entry is required. These types of errors will go away when integrated approaches are used.)
- Creating and Validating: Failure to validate adequately documents both manually and with validation software(Why does software have to wait until the end of a process to tell you, "Hey dude, you made a lof of mistakes that you have to now go back and fix." It seems to me that a better way to build software is to not allow the user to make the error in the first place! Software needs to be more proactive and less reactive.
If one takes a step back and looks at all these errors from a bigger picture perspective and asks questions such as:
"Is it possible that the US GAAP Taxonomy could be created in ways to make errors less likely?"
and
"Can XBRL International do things to make it so software vendors can perform more of this validation automatically so business users don't have to manually check these things?"
and
"Can the SEC be more clear on what is an error and what is not an error to help software vendors help business users?"
...then the real problems will be solved and less of the symptoms of the problems (i.e. errors and difficulty complying with the SEC submission requirements).
The difficulty and errors will become more of an issues as the SEC XBRL filings move into the next phase of detailed tagging. This will put more pressure and stress on the problem, perhaps resulting in a solution.
More good news is that there has been a significant improvement in SEC XBRL filings because of incremental improvements in XBRL creation tools, the US GAAP Taxonomy, software valdiation tools, software interoperability, and so forth. Incremental improvements will only get one so far though, and it does less to solve the problem of the fundamental complexity of creating SEC XBRL filings.