Posts Tagged "xbrl for internal use"
XBRL FAQ: What are the practical benefits of the re-usability of XBRL?
| Q I hear a lot about the benefits of XBRL re-usability. What does this mean in practice? |
| A XBRL is a technical specification optimized to represent business and accounting data. This means that the same syntax and the same semantic model can be used to represent very different types of information – such as financial statements, tax returns, invoices, inventory, fixed assets, trial balances, payroll information, Key Performance Indicators (KPI), sustainability data, just to make a few examples. These different types of information are used in very different processes, by businesses and organizations as well as regulators, Governments and the market in general (analysts and investors). Being able to use the same format to represent and share such a diverse range of data for equally diverse purposes surely suggests that re-usability is a key feature of XBRL, both within a single organization and when information is shared across different organizations.But what are the practical benefits of the re-usability of a standardized data model?
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:
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. |
XBRL FAQ: Does a Taxonomy Extension Create Additional Burdens for the Base Taxonomy Owner or the Extender?
| Q Does the fact that a user creates an extension to a regulatory taxonomy create confusion and additional burdens for the owner of the base taxonomy (the regulator), for the filing process in general, and for the extender, for example when a new version of the base taxonomy is released? |
A No, it does not. An extension to a taxonomy can be created for one of the following reasons:
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. |
Introducing DEXT – the Deeply Embedded XBRL Toolkit for data integration, internal and external reporting, data monitoring and auditing
While the benefits of XBRL in terms of data transparency, cost savings and greater efficiencies in handling data are widely recognized by data consumers (regulators, analysts and investors), businesses and not-for-profit organizations are not typically looking at XBRL to achieve the same benefits internally.
IPHIX is releasing DEXT, a set of software tools, free knowledge bases and other resources that help organizations do just that – leverage the benefits of “deeply embedded XBRL” internally, whether they are subject to an XBRL mandate or not. DEXT is not an alternative to the software applications in use within a corporate information system; rather, it is an enabler for the use of data standardization to get better results from those applications, and yield an immediate, positive return on your existing IT investment.
Here are a few examples of how DEXT is used:
- To bring together accounting and/or operational data from disparate applications for a specific internal reporting purpose, such as providing a consistent view on information related to a specific category of costs across different units of a company that use different systems
- To apply the same business rules to data stored in different systems for data monitoring and auditing
- To create automated processes to feed KPI systems and executive dashboards from accounting systems and operational modules
- To create and reconcile summarized reports for internal and external use, such as tax returns, reports for external auditors and CPAs, management reports
- If the organization is actually subject to an XBRL mandate, to generate the relevant XBRL filings in a simplified and more efficient way
There are many more examples. Indeed, whenever there is the need to aggregate, analyze or report data across different applications, or to complement the reporting or analytical capabilities of one application, without a significant investment, deeply embedded XBRL is the solution, and DEXT can help.
Because XBRL can be applied to a very broad range of diverse internal data-related processes, it can be difficult for an organization to decide where to start using it, and how to best leverage DEXT. This is why IPHIX conceived Three Easy Steps – a simple, proven methodology and a package of products and services that enables businesses and organizations of any size to complete their first deeply embedded XBRL project using DEXT and leveraging our expertise. At the same time, executing each segment of the Three Easy Steps process will give users the knowledge and the experience necessary to continue on their own after the first successful implementation.
Three Easy Steps has been developed distilling the experience accumulated over many years of thought leadership and unmatched experience on the internal use of XBRL, and applying the lessons learned in our leading role in helping Governments and regulators in various countries implement XBRL-based projects.
Another factor that can complicate the decision of undertaking a deeply embedded XBRL project is that it can be hard to estimate the time that will be necessary to complete the project and the resources that will be needed. The costs of the necessary consulting services can become significant and, more important, they are hard to predict — initial estimates can easily be exceeded once the project is kicked off. That’s why we decided to offer Three Easy Steps for a flat, all-inclusive fee. It will make the investment decision easier; on our side, we are totally confident that a Three Easy Steps implementation will deliver immediate value, and that we can leverage our experience to complete it quickly and efficiently.
Also, our new XBRL Inside training is the first and only training course designed to provide the specific knowledge and the hands-on experience necessary to use XBRL within an organization. It is a great way to prepare for your first “deeply embedded XBRL” project, whether you plan to use our Three Easy Steps methodology or to do it on your own.
All of us at IPHIX are very excited about the release of DEXT and Three Easy Steps. We deeply believe in the potential of XBRL to bring significant benefits to businesses and organizations, large and small, in terms of total internal data transparency and accessibility. We also believe that these benefits will not be realized until XBRL is used as more than just an e-Filing format, which is the reality today. We think that DEXT and Three Easy Steps will help change that.
Check the Three Easy Steps and DEXT websites, and let us know what you think.
XBRL FAQ: Do I need to replace my software applications in order to leverage XBRL for internal purposes?
| Q Do I need to replace the accounting and operational software applications that I am using now in order to use XBRL to streamline my internal data access, aggregation, auditing/monitoring, and reporting processes? |
| A No. The key benefit of adopting XBRL for day-to-day use (“deeply embedded XBRL”) within a corporate information system is that it does not replace anything, nor it requires significant investment in new software. Quite the opposite: it preserves the IT investment in place by enabling the elimination of the inefficiencies that come from corporate data residing in different systems that are not easily interoperable, and by bridging the “information gaps” between them that usually translate into the manual creation of spreadsheets to fulfill specific internal and external reporting requirements.
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. |
XBRL GL Is An Adaptor
I find myself answering the question “What is XBRL Global Ledger?” quite frequently – either because people ask me or because I come across some kind of misconception about its nature.
By now I am very aware that answering this question by getting into the detail of what XBRL GL can do really does not work, because of its very broad nature and of the large number of use cases that it supports. Over time I have condensed all those use cases in a short list of “meta use cases”, best served with an appetizer of the most common misconceptions about XBRL GL. Enjoy!
What XBRL GL Is Not
An alternative to accounting software and/or ERP applications.
XBRL GL can’t replace those – but it makes them deliver better results by unlocking the data that is stored in them and making it interoperable, accessible and reportable. See “What XBRL GL Is” below.
An alternative to XBRL taxonomies for financial/end reporting – such as the IFRS, US-GAAP, SBR or Solvency II taxonomies.
XBRL GL is designed and used to represent granular information, not end reports. It is also used to represent mappings from granular information to end reports. It is NEVER used to represent end reports. XBRL GL and XBRL taxonomies for financial reporting are complementary, not alternative. Granular data and end reports have very different features, and this is why very different taxonomy architectures are required to represent them.
As a side note, this misconception is so common that I have seen taxonomy architects who design XBRL taxonomies for financial/end reporting, and who have the need to also represent granular data within the same project, stretch their taxonomy architectures to include both types of data rather than integrating XBRL GL in their reporting environment. This generally happens out of ignorance of what XBRL GL is – even though I imagine that in some cases the real driver is that reinventing the wheel pays more consulting fees than just using something that already exists. Whatever the reason, the result is a clumsy taxonomy architecture, more difficult to understand and implement and ultimately damaging for the very objectives of the XBRL project that it is designed to support.
What XBRL GL Is
XBRL GL is an adaptor:
1. Between accounting software, operational software, ERP applications – any internal data repository within an organization’s information system.
It makes all those systems interoperable even when they are not. Whether it is about moving data from one system to the other or visualize, analyze and report on data residing in each of those systems, XBRL GL achieves the goal at a fraction of the cost of comparable proprietary solutions – including home made ones such as spreadsheets or custom interfaces, which are perceived to be free apart the time of development but have significant implicit cost in terms of process inefficiencies and errors.
2. Between the internal data repositories described in point 1 and end reports supported by XBRL taxonomies.
XBRL GL standardizes granular data, which is the underlying detail that rolls up to those XBRL end reports. It also standardizes the way in which granular data rolls up to those XBRL end reports – in other words, the mappings between the underlying detail and XBRL end reports. A software that “understands” XBRL GL supports an application-independent and flexible reporting environment that the owner of the data, not the vendor of a reporting application, controls.
3. Between the internal data repositories described in point 1 and internal reporting needs.
This is really a variation of point 2, and only adds the consideration that you can easily (yes, easily) create end reporting XBRL taxonomies to support internal reporting needs – and whether you work for a global company, a small business, a not-for-profit organization or a Government agency, you can put this to fruition fairly quickly. Invest a little time in understanding how to create an XBRL taxonomy, how to map from your internal data repositories to XBRL GL, and how to map XBRL GL data to your custom XBRL taxonomies. The investment will soon pay off: no more need to consider investing in that new reporting tool, no more waiting for that brilliant person in the accounting department to do her magic with Excel (“Man, what will I do the day she quits?”), no more fighting with the IT department on where in their list of priorities your much needed new report sits.
Follow me in this blog or in Twitter (@iphixbrl) for frequent tips on how to make the XBRL GL adaptor work for your organization. If you have specific questions you can post a comment or contact me directly.
Follow Me!
