Posts Tagged "xbrl gl"

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.

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.

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.