CoreFiling is often called upon to review new XBRL taxonomies. Here are some of the most common mistakes we find and what can be done to avoid them.
XBRL Formula Errors
XBRL Formula is used to define business rules which are critical to maintaining the value of the data collected. A surprising 16 of the 100 taxonomies tested were released with at least one business rule that could not be run in a specification-compliant XBRL processor. The most likely errors were trying to compare text with numbers and cases where the formula could cause a “divide by zero” error.
Testing for these errors should be as simple as validating the taxonomy prior to release. However, it would be much better to avoid them entirely and for that we need to understand how they come about. The evidence points towards these being primarily human error, where low level tools have failed to provide the developers of the taxonomy with sufficient protection.
CoreFiling have found that process that exposes formula writers to constructs such as variableSetFilterArcs and assertionSets is too low level to efficiently write error-free formula. The answer is to define rules using high level definitions and then generate the XBRL syntax automatically. When automated formula generation is coupled with automated test case generation, even complex checks are made simple and robust enough for non-developers to write and publish free of errors.
Packaging Errors
Proper packaging of a taxonomy means that configuring a piece of XBRL software can be as simple as dropping the package in. While the XII packaging specification is arguably the simplest document in the XBRL suite, only 75% of the taxonomies looked at were correctly packaged with typical errors being typographical errors in entry point addresses, required folders missing or no packaging at all.
In a similar way to formula issues, these usually come down to human error. However, in this case, the issue is not with difficulty, rather it is assumed to be the fiddly nature of dealing with long web addresses and the need to zip up files and folders precisely. Again, scripting or other automation of the packaging process is the solution. In order to assist the community with packaging (and since the specification started at CoreFiling) we have released a package generator for all to use as part of CoreFiling Labs (requires sign-up).
Inconsistent Versioning
When taxonomies are changed, marking them with version identifiers helps filers to make sure that the correct taxonomy is used at the correct time. However, many taxonomies have an ever-shifting versioning scheme that makes this task unnecessarily difficult.
While not an error per se, this makes keeping track of versions a challenge for filers. Double-checking which version to use is historically CoreFiling’s most common support request leading to us publishing a mandate picker that filers can use to answer this question. Much like specification errors, inconsistent versioning causes unnecessary additional costs throughout a filing program’s ecosystem.
Three top tips for making versioning work for users of a taxonomy are:
- Decide on a versioning scheme and stick with it! People can learn a scheme and work with it, they can become lost when the scheme changes.
- Always apply a new version number to every release. Even if it is a hotfix or taxonomies are released in quick succession there should never be any ambiguity about the exact contents of a particular version.
- Prefer sequential numbers over dates. A great default versioning scheme to use is the 3-number scheme [major release].[minor release].[hotfix number]. Unlike date-based schemes, these are flexible, easy to understand and equally valid when dates change or their relevance is forgotten.
Why Does This Matter?
As a taxonomy author or the primary data collector for a filing program, an organisation is usually responsible and answerable for the costs of the filing program across the whole reporting ecosystem. A too-high burden can (and does) lead to downsizing of the filing program and corresponding decrease in the ability of data collectors to carry out their task.
Every time one of these errors occurs, it impacts the overall cost of the filing program with additional inefficiencies and costs appearing throughout the reporting supply chain. Preparers’ projects are disrupted as they wait for clarity and fixes, independent software vendors must fix or work around issues themselves and the taxonomy author invariably needs to start planning a hotfix.
Another Way!
There is another way! The vast majority of the errors in the 100 taxonomies tested were caused by human error and were entirely avoidable. CoreFiling have taken a practical view to solving these issues, automating manual and error prone tasks within a comprehensive Taxonomy Management System.
Come and see for yourselves. CoreFiling are running Build a Taxonomy workshops where organisations can get hands on experience building 100% error free taxonomies using their own data requirements.
For more information and to book a workshop visit: https://www.corefiling.com/taxonomy-workshop/