Posts Tagged "deeply embedded xbrl"
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 FAQ: What Are the Practical Benefits of Considering XBRL as a Supply Chain Integration Standard?
| Q I frequently read that XBRL is a supply chain integration standard, not an eFiling standard. What does that mean in practice? |
| A The benefits of XBRL in terms of making business data transparent and easily accessible have been globally recognized by regulators, who are mandating its use for the submission of financial statements and other regulatory reports. As a consequence, XBRL is widely regarded as an eFiling format, and this is one of the reasons why businesses do not extend its use within their own information systems to achieve the same benefits that prompted adoption by regulators. In reality XBRL is designed to be applied at each step along the whole Business Reporting Supply Chain (BRSC), which includes corporate internal processes as well as external reporting processes:  The Business Reporting Supply Chain and XBRL
Using XBRL to integrate the whole BRSC means using it to
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:
|
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.
Corporate Data Transparency and Accessibility with XBRL
Data transparency and accessibility are two of the key themes of the 24th XBRL International Conference in Abu Dhabi (March 20 to 22, 2012).
These are probably the two most important objectives that regulators around the world are pursuing with the adoption of XBRL, and also the most significant requirements for other consumers of XBRL data, such as analysts and investors. They are also key requirements within any corporate information system, big or small, and something on which organizations spend a lot of money:
- In the time and resources wasted to support the inefficient and mostly manual processes in place to bridge the gap between the real internal data aggregation and reporting needs and what the corporate information system can actually deliver;
- In the consequences of the errors that come with those processes;
- In the continued quest for additional software tools and add-ons that are supposed to fix those problems – but wait a minute, wasn’t that something that the software we bought last year was supposed to fix?
Internal data transparency and accessibility ARE issues for businesses and organizations of any size, and XBRL can help addressing those issues just like it does for regulators and analysts in a cost-effective fashion. Unfortunately for some reason extending the vision on the benefits of XBRL and of data standardization in general within the enterprise does not come natural, not even for companies that are exposed to XBRL because they have to comply with a mandate.
The truth is that any organization, large or small, for-profit or not-for-profit, no matter if it is already subject to an XBRL mandate or not, can significantly benefit from using XBRL internally to support data aggregation and reporting processes. Here are three common consequences of lack of data transparency and accessibility within an organization:
- Proliferation of spreadsheets to address internal data aggregation requirements from disparate modules of the information system that cannot easily be automated;
- Duplication of processes, in particular related to data analysis and monitoring, in different applications where data similar in nature is stored or processed;
- Manual “last mile” of financial reporting;
And here are three ways in which XBRL can help address these issues:
- Base your spreadsheets on a custom XBRL taxonomy that supports the data aggregation requirements. Spreadsheets still act as user interfaces, so users interact with a familiar environment – but they are centrally managed and automatically populated through mappings from source systems to the XBRL taxonomy, reducing time and resources required to create them and increasing the efficiency of the processes that rely on the spreadsheets;
- Map the data stored in the relevant applications to XBRL Global Ledger (XBRL GL), an XBRL taxonomy designed to standardize granular data in accounting software and ERP applications. Then use XBRL Formula to express the necessary analytics and controls on the data converted to XBRL GL. The same analytics can now be applied to the source data no matter in what module or application the data is stored, avoiding duplications and inconsistencies;
- Leverage existing XBRL taxonomies to represent the end reports, or create your own if no suitable taxonomy exists. Then map the data that rolls up to those reports using XBRL GL. The manual activities currently required to generate the end reports can now be automated and applied consistently to any data source within the organization.
These are just generic and high-level ideas, but they come from practical experience in leveraging the benefits of XBRL within the enterprise. In just a few weeks I will be in Abu Dhabi, training and presenting on internal data transparency and accessibility enabled by XBRL and XBRL GL. If you plan to attend the Conference it will be easy to find me if you want to discuss these ideas in more depth. If not, you can always leave a comment to this post, or contact me directly.
Follow Me!
