Posts Tagged "xbrl implementation"

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.

Using XBRL Global Ledger (XBRL GL) as a standardized, application-independent representation of business data enables re-engineering the internal processes based on that data. No matter in what application or format the data is stored, it is possible to create consistent, automated processes to access and analyze it. Also, internal and external reporting needs can be fulfilled by leveraging existing (and free) XBRL taxonomies for end reporting, and/or by creating custom corporate taxonomies for internal use. XBRL GL seamlessly interacts with other XBRL taxonomies to populate end reports from source systems, and this enables a great degree of flexibility in their creation and maintenance. It also eliminates the need for costly manual activities and systems customizations.

Existing applications do not need to change at all. Most of the software required to map source data to XBRL GL is either free or is well established off-the-shelf software with a limited cost. On the processing side, a lot can be achieved using freely available tools such as the Deeply Embedded XBRL Toolkit (DEXT) or broadly available, non XBRL-specific applications like Microsoft Excel.

There are various resources and training courses available that provide guidance on how to deploy XBRL for internal benefit. It is possible, and actually recommended, to start small, from one prototype that is meaningful enough to show a benefit but also well delimited in scope, so that it can be completed quickly to evaluate the results and achieve the internal expertise necessary to apply the same approach more broadly over time. This gradual approach is not possible when internal inefficiencies in data-related processes are addressed by acquiring a new system.

Bottom line, the investment is limited, the effort required can be managed and optimized over time based on what processes are more critical and provide the greater internal benefits if successfully addressed, and the return is significant – with no need for a drastic intervention on the existing information system.

The Business Reporting Supply Chain and XBRL

Using XBRL to integrate the whole BRSC means using it to

1. Access corporate data as an integrated whole, as opposed to accessing it within silos corresponding to different software applications that do not talk with each other;
2. Report on corporate data, both for internal and external purposes, using automated, sustainable processes as opposed to the highly manual and inefficient spreadsheet-based processes that are currently the norm.

Evidence shows that companies that apply a “built-in” approach to the implementation of XBRL – which means leveraging XBRL to streamline the internal processes of creation of end reports and corresponds to point 2 above – experience a 20/25% reduction in costs related to those processes. See for example this article by John Stantial on the United Technologies experience.

In comparison, companies that just convert to XBRL reports already created using pre-XBRL processes (the “bolt-on” approach) not only do not see any internal cost reduction or greater efficiency, but have to support one additional step – the conversion to XBRL – without any compensating benefit. In this situation XBRL is obviously an overhead that increases the cost of reporting for businesses.

The full benefits of the BRSC integration are realized when businesses and organizations leverage XBRL to standardize and “take ownership” of their data within the software applications they use, as described in point 1 above – the “deeply embedded” approach to XBRL adoption. This approach enables re-designing costly and inefficient internal data-related processes such as data aggregation and consolidation, data monitoring and auditing, and of course internal and external reporting without a significant IT investment, basically leveraging the existing software applications in a much more efficient fashion. In other words, it means achieving the same benefits that prompt regulators to require the use of XBRL within the corporate firewall. The benefits of this approach are pervasive and not limited to a better performance in external reporting processes, and therefore they are harder to quantify. Their significance is evident in the available use cases: from large global corporations such as Wacoal and Fujitsu to small not-for-profit organizations such as the Maryland Association of CPAs.

Bottom line: for businesses and other organizations, considering XBRL for its true nature of supply chain integration standard as opposed to an eFiling format means going from:

• Experiencing no benefit, and actually some overhead, when it is regarded as a pure eFiling format
• Experiencing 20/25% cost reductions, when it is used to streamline the processes of creation of end reports in XBRL, where XBRL reporting is required
• Experiencing a true “paradigm shift” in the efficiency of data-related internal processes similar to what is normally pursued, and not often achieved, through significant IT investments, when it is “deeply embedded” within the organization, be it subject to an XBRL mandate or not.