Posts Tagged "XBRL"

Software applications that “understand” the XBRL specification and the key semantics embedded into XBRL taxonomies can work consistently with XBRL data, no matter what the data represents. They can be developed and deployed without any knowledge of the specific type of data that they will process, or the specific kind of reports that they will produce. They can be used to support any process where data that can be represented with XBRL participates – and this, as discussed above, means that they have a very broad applicability.

This is a very different model for developing software applications than the traditional one, which is based on developing an application-specific, proprietary data model first, and then create software code that works with that data model, and with that data model only. Applications that truly leverage the XBRL standardized data model (as opposed to just being able to convert an Excel or Word report to XBRL) are highly flexible and re-usable and therefore their ROI is significant.

The benefits are very practical. In a traditional, proprietary software model, if you need to add a report, or a control, or some other data processing capability to your software package your choices are:

1. Add the functionality to a software package you are using by purchasing it from its vendor, if available
2. Pay for its development, either in-house or externally
3. Retype or transfer the necessary data in some other software or spreadsheet that serves the purpose

Obviously these solutions are (or may be) effective for the immediate purpose, but are not re-usable – the next report, control or data-processing capability will pose the same issues and require a similar solution.

In a standardized, data driven model – the kind of model that XBRL enables –and limiting the example to the creation of an additional internal report, the report is represented with a XBRL taxonomy, either leveraging a taxonomy that already exists or developing one for the purpose. The data required to populate the report is mapped to the taxonomy from any existing accounting software or data repository – and again, the mappings may be already available in whole or in part if the taxonomy is publicly available, or if not they can easily be developed internally. The mappings are also standardized and represented with XBRL using XBRL Global Ledger (XBRL GL). The software necessary to create the report and process the mappings is either open source/free or very inexpensive, because it is not specialized for a specific purpose and it does not conform to the logic of a proprietary application. The know-how and the tools used for the first internal XBRL implementation are broadly re-usable and will provide significant value over time. In fact, the organization that chooses to move along this path is not looking at purchasing a new software package or replacing an existing one – rather, it is acquiring the knowledge and the tools necessary to make the various components of the existing information system meet the requirements better.

With the necessary software in place and sufficient know-how on how to design XBRL taxonomies and how to use XBRL GL, businesses and organizations acquire flexibility and the capability to adapt their information system to their actual requirements in an efficient and cost-effective way, which is re-usable over and over again for very different data-related processes and activities. Best practices and lessons learned in other similar deployments are also highly re-usable. Needless to say, if the organization is subject to a XBRL mandate it may already possess relevant know-how and software tools that can be leveraged internally for benefits that go way beyond regulatory compliance.

I will close with a note of self-promotion – if you would like to read more about the possibilities offered by this approach, have a look at IPHIX’s Three Easy Steps.

1. Because the filing program supported by the base taxonomy is an open program – which means that it allows, or even requires, filings based on a filer-specific extension to the base taxonomy. We will refer to this kind of extension as a “public” taxonomy extension;
2. Because the owner of the extension intends to leverage a publicly available taxonomy internally, for purposes that are not directly or necessarily related to a filing program or to the purposes for which the base taxonomy is created and maintained. We will identify this kind of extension as a “private” taxonomy extension.

If the taxonomy extension is created for the purpose of filing XBRL reports within an open XBRL filing program, the regulator receives and accepts the extension together with the filings. The rules for the creation of a valid public taxonomy extension are set by the regulator and designed to make extensions consistent with the processes of reception/consumption of the filings. It is also important to remember that the XBRL Specification supports the creation of extensions in a way that makes it possible to easily separate the base taxonomy from its extension – see the previous XBRL FAQ on the topic. A taxonomy extension never changes or deletes anything in the base taxonomy; it only adds something new to what is in the base taxonomy, or prohibits something that is already there. This mechanism makes it easy for the regulator to either ignore or consume selectively the extension or parts of it.

If the extension is created by an organization that intends to leverage the base taxonomy internally and customize it for a specific internal process or purpose, the owner of the base taxonomy is not even aware that the taxonomy has been extended. It is totally possible that the organization that creates the private extension is not even subject to a regulatory mandate that requires the use of the base taxonomy being extended – the taxonomy just happens to be a valuable, authoritative and free knowledge base of reporting concepts, documentation and related resources that are useful to the organization internal processes. Even if the organization is required to use the base taxonomy for regulatory compliance it is easy to create instances with only the subset of data that is valid against the base taxonomy for the purpose of eFiling, and create instances that include extension data for other internal purposes.

The release of a new version of the base taxonomy requires the release of a new extension. The content of the extension can remain the same, or change because of increased scope or to leverage the new resources added to the base taxonomy. Designing the architecture of the extension and the guidelines for its maintenance in a way that make it easy to adapt to the evolution of the base taxonomy is key for a sustainable life cycle of the taxonomy extension and for the efficiency of the processes that it supports.

The fact that private extensions to XBRL taxonomies are created even when a regulatory program does not allow extensions is a reality and a key part of the value proposition of XBRL for the regulated community. Regulators should keep this fact in mind when designing their taxonomy architectures, keeping them as simple as possible to make extension easier and providing information and guidelines for an effective extension to facilitate the process.

From a technical standpoint, there is no difference between XBRL GL and other XBRL taxonomies, such as the IFRS taxonomy, the US-GAAP taxonomy, or the Standard Business Reporting (SBR) taxonomies. Each XBRL taxonomy has a different architecture – basically, a set of rules that defines the way in which the various technical tools and features defined in the XBRL Specifications must be used within the taxonomy itself. The reason why a taxonomy architecture is necessary is that not all the technical features defined in the XBRL Specifications are always all relevant in all situations, and different types of information being represented by a taxonomy require different subsets of features that are more suitable to represent them. The taxonomy architecture identifies the subset of XBRL technical features that must be used to create and maintain a specific taxonomy, and provides guidance on how to use them. XBRL GL, like any other XBRL taxonomy, has its own architecture, consistent with the type of information that it represents and the requirements that it needs to meet in order to support its business purpose.

From a business standpoint, each XBRL taxonomy is designed to achieve a certain purpose. The business purpose of many XBRL taxonomies is to support the creation of specific reports, such as “financial statements according to the International Financial Reporting Standards (IFRS)” or “financial statements according to the US GAAP.” Others have a broader business purpose. For example, the purpose of the Standard Business Reporting (SBR) taxonomy is “supporting all the reports that businesses must submit to the participating agencies in the Australian Government.”

The XBRL GL taxonomy is provides a standardized representation of the business information found in any accounting and operational software application, and of the rules used to populate end reports (typically represented by other XBRL taxonomies) with that information. In practice, this means that the business purpose of the XBRL GL taxonomy is to enable the creation of standardized, application-independent and purpose-independent processes to access, monitor, analyze, and report on business data.