A taxonomy style guide isn’t about creating a memorable “style”. The style guide is about building clear, transparent, understandable standards that result in predictable communication every time. XBRL relies on a taxonomy of concepts to identify facts, contexts and other relationships. Any ambiguity in the language used within that taxonomy to communicate data, could produce inconsistent results.
A well thought out taxonomy should aid in creating, relaying and storing well-formed data. Like a house built on a weak foundation, a poorly designed taxonomy will look fine on the surface but will contain dangerous inconsistencies hidden within the structure. Some issues may only surface after move in.
The idea of using a style guide to produce quality work is not new. Every serious publisher of printed or electronic documents will create a style guide for look, feel and content. For XBRL, we are concerned about the frame on which data hangs.
The style guide is also about ensuring developers make it as easy as possible for data creators through the use of understandable (non-technical) language.
Ensuring that the standards within the style guide are clear and useable is also critical to producing good-quality, consistent data. Readers are encouraged to review the style guide and make use of the public comment period, which we’ll discuss again below.
Making Data Consistent from One Taxonomy to the Next
We often refer to a taxonomy as a “digital dictionary” of concepts or data fields. The style of the taxonomy refers to the punctuation and grammar used in the labels and documentation within the taxonomy. In some respects, it doesn’t really matter what punctuation or grammar is used, as long as it’s the same every time. The style guide provides guidelines so that developers can use the same punctuation and grammar for every taxonomy being created.
Taxonomies can reference, and be referenced, by other taxonomies. That’s part of the power of XBRL. For example, the US GAAP Taxonomy contains approximately 15,000 elements. Many of those elements are re-purposed and used in other taxonomies like those being developed today for solar financing, or contractor’s financials. There’s no need to reinvent the wheel when we already have it. For example, to create a taxonomy that represents solar financing requires US GAAP data fields like amount of the lease payment, plus solar-specific data fields like term of the power purchase agreement. The diagram below shows how data fields from US GAAP can be combined with solar-specific fields to create a new Solar Taxonomy.
The ability to leverage elements from multiple taxonomies saves time and labor for the developer; even more importantly, it allows preparers to use the same elements for multiple reporting situations. For example, a publicly traded power company can use the same taxonomy elements when sending Power Purchase Agreement (PPA) data to a bank as part of a solar installation project that they do when filing quarterly financial statements to the Securities and Exchange Commission (SEC).
But in order to seamlessly combine data fields from two different taxonomies, both taxonomies need to use the same language. It would be pretty confusing for the reporting manager at a power company if they were preparing reports that used different methods to express numbers for solar-specific concepts versus those that are strictly US GAAP.
For example, “Operations and Maintenance” is a common phrase used in solar projects. What if the solar-specific data fields used concept name “OAndM” and the US GAAP data fields used the concept name “OperationsAndMaintenance”? It wouldn’t make sense to have multiple labels within the same taxonomy following different naming conventions. The XBRL US Style Guide explains that in this situation, the term “OperationsAndMaintenance” should be used – brevity is important but clarity is more important.
Making Taxonomies Easy and Understandable
The style guide is designed to give taxonomy developers clear and unambiguous guidance on how to create element names, references, and labels including presentation labels and documentation labels. The style guide includes guidance on when to use pronouns, adverbs, nouns and adjectives, and gives examples of proper use. It covers areas such as units, scaling and how to properly express numbers. For example, don’t use unit descriptions in concept names or labels. Instead of using “Contract Payment, Dollars”, use “Contract Payment, Amount” because currencies are handled in XBRL by metadata for units.
Guidance like this will help developers create a clear, concise and easy-to-understand taxonomy. And consumers will have simpler paths to find the data points they need.
Feedback on the XBRL US Style Guide
The XBRL US Domain Steering Committee (DSC) recently finalized the XBRL US Style Guide to meet the needs of taxonomy developers, data creators and data users. They designed the Guide to be used in conjunction with a Taxonomy Guide which is currently still under development by the DSC. The Taxonomy Guide will cover topics such as creating a data model, the development steps in building a taxonomy; and it will provide examples of business cases, instance documents and taxonomy guides, as well as other resources a developer can review.
These two documents together will give developers, and the business analysts and project managers that are also involved, important tools to build good-quality taxonomies and implement them successfully.
The DSC is looking for input on the Style Guide to make sure it meets all needs. A public review and comment period is set to close July 17, 2017 and the DSC encourages all developers, business analysts and project managers to review and comment: https://xbrl.us/xbrl-reference/style-guide/
Creating good-quality taxonomies leads to successful standards implementation. The Style Guide (and eventually the Taxonomy Guide) are critical building blocks to get us there.
