Posts Tagged "altova"
Not Your Usual XBRL Case Study
The Maryland Association of CPAs (MACPA) and Altova recently published a remarkable case study focused on exploring the actual internal process benefits available for small businesses with the use of XBRL, and to showcase those benefits to MACPA members and to other non-profit organizations.
Basically, MACPA used Altova’s Mapforce (part of the Altova Missionkit suite) to convert its internal accounting data to the XBRL Global Ledger (XBRL GL) format. The data was then used to automatically populate their Key Performance Indicator (KPI) system. They also used Altova XMLSpy to extend the US GAAP XBRL Taxonomy (UGT) and adapt to meet the reporting needs of a non-profit organization. Finally, they mapped their XBRL GL data to the extended UGT, again using Altova Mapforce for the purpose, and created the final XBRL reports. You can find the full document here.
This case study is remarkable for a number of reasons.
Scope. The case study shows that XBRL is not only about the Securities and Exchange Commission (SEC) mandate in the United States or other similar global compliance initiatives – it is very much about achieving internal process efficiencies and cost savings for businesses. Financial reporting is one very important output of those processes, but not certainly their essence. Check out the comments from Tom Hood IV, the college intern that MACPA engaged to perform most of the technical activities described in the case study, in the YouTube video that illustrates the project. You will hear him describe the process benefits achieved and their practical consequences – the elimination of several manual activities and of the spreadsheets used to support them.
Tooling.The case study demonstrates that XBRL does not necessarily need to be embedded in accounting software, ERP applications and consolidation/reporting packages. It would be great if this was the case, and when it is the case it would be great if that support was not conceived as a “print to XBRL” function at the end of very application specific reporting processes, as opposed to providing richer deeply embedded XBRL capabilities. But the existence of tools like Altova MissionKit enables the creation of a “standardization layer” sitting on top of any application and data repository within a corporate information system. This translates into complete control over the characteristics of your XBRL implementation, its clear separation from the process constraints imposed by proprietary applications and its consistency across different components of the corporate information system. In other words, it sets the stage for the achievement of the real internal benefits enabled by XBRL for global companies, small businesses and non-profit organizations alike.
XBRL implementations “can” be easy.Here is a quote from the case study by Tom Hood, MACPA’s CEO and Executive Director: “If we can implement XBRL as a state-based non-profit association working with a college intern, you can do it too – implementing XBRL in-house is easy with the right tools.” XBRL GL is the seamless bridge between source accountinginformation and end reporting supported by XBRL taxonomies, the UGT in this case. Altova Missionkit was already used to implement XBRL GL long before XBRL support was added to its capabilities - and things got a lot easier after this happened of course. It does look like the MACPA made all the right moves, and those moves paid off.
This is the real promise of XBRL. Small businesses and non-profit organizations can achieve advanced internal and external reporting and business intelligence capabilities quickly and for a fraction of the cost. Larger companies can make their existing IT infrastructures more efficient and eliminate manual and resource intensive data-related processes.
A Blueprint For “Deeply Embedded” XBRL Implementations
One of the most frequently questions that I am asked – and also the most welcome closing remark of any meeting where the use of XBRL to enhance internal processes as opposed to just responding to a regulatory mandate is discussed – is: “All this sounds really great – how do I do it?”
Here is a high-level set of steps that I consider relevant, and some of the resources and considerations related to each of them. These steps are the foundation for a sort of template or blueprint that can be used when defining the architecture of a prototype, or an actual implementation, that leverages XBRL for internal data aggregation and automated monitoring/reporting on business information.
1 – Source Data Repositories
Description: Identification of the applications where data relevant for the prototype/implementation resides – accounting packages, ERP systems, spreadsheets, etc.
Artifacts: Documentation on the data model of each repository and related access/support.
IT Resources: None.
Issues to consider: If multiple sources are involved, how will the data aggregation/consolidation work?
2 – XBRL GL Profiles
Description: Identification of the XBRL Global Ledger (XBRL GL) Profile(s) relevant for the specific use case. XBRL GL Profiles are subsets of the XBRL GL Taxonomy Framework specialized to represent a specific type of entry or document, such as the Trial Balance XBRL GL Profile, the Journal Entry Profile, the Invoice Profile etc. The creation and publication of such Profiles is currently under consideration within the XBRL GL Working Group (WG) of XBRL International Inc. (XII) – see a webcast on this topic here. Meanwhile, the XBRL GL Best Practice Instance Documents published by the XBRL GL WG are acceptable substitutes for Profiles.
Artifacts: Technical instantiation of each relevant XBRL GL Profile – taxonomy files, rules, etc. Or, the relevant XBRL GL Best Practice instance document and the guidance contained in it.
IT Resources: None.
Issues to consider: If multiple Profiles are needed for the specific use case, how they relate to each other?
3 – Mapping(s)
Description: Creation of mappings between each source data repository (step 1) and each relevant XBRL GL Profile (step 2).
Artifacts: Mapping file(s) in the chosen mapping format.
IT Resources: User interface (UI) to create the mappings and processor to execute them, These will normally be part of any mapping tool that can work with multiple data sources (the Source Data Repositories) and XBRL GL. It is not necessary to use an XBRL compliant mapping tool; XBRL GL is more XML Schema “friendly” than your typical XBRL Taxonomy – it has been designed like that to be the “bridge” between source data and the XBRL world. The use of a popular (and relatively inexpensive) XML mapping tool like Altova MapForce with XBRL GL has been publicly demonstrated multiple times. See for all this webcast.
Issues to consider: None.
4 – Controls
Description: Identification and creation of controls/validations/business rules useful or required for the specific use case.
Artifacts: Documentation related to each control and its technical instantiation in the chosen format. There are multiple possible formats to express business rules that work with XBRL/XBRL GL data, such as Schematron or RuleML. XBRL Formula is, in my opinion, the logical choice since this format is optimized for the XBRL data model.
IT Resources: UI to create the controls and processor to execute them. Depending on the format chosen for expressing the business rules there are open source and off-the-shelf solutions available.
Issues to consider: If other prototypes or implementations of the same or similar use case already exist, there will be the opportunity to re-use existing controls based on the same XBRL GL Profiles as opposed to creating them from scratch.
The next two steps will only be included if an “end reporting” layer is part of the specific use case. This typically happens when the use case includes the generation of XBRL instance documents supported by an end reporting XBRL taxonomy – AKA XBRL for Financial Reporting (XBRL FR) taxonomy, even though end reporting is not only financial – or the reconciliation between different end reporting formats based on the same underlying data, or the drill down from an end reporting representation to its underlying detail.
5 – End Reporting XBRL Taxonomies
Description: Identification of the XBRL taxonomies supporting the external or internal end reporting format(s) relevant for the specific use case. Examples include the US GAAP (or other local GAAP) Taxonomy, the IFRS Taxonomy, a Standard Business Reporting taxonomy, but also taxonomies for internal management reporting or sustainability reporting.
Artifacts: XBRL taxonomies, already existing or created for the purpose.
IT Resources: Depending on how the end reporting layer fits in the specific use case: a processor to create instance documents from the source data supported by each relevant taxonomy, and/or a reconciliation/drill down/drill around UI and processor. Various prototypes where these functionalities have been implemented are publicly available, so it is not difficult to find appropriate support for these capabilities.
Issues to consider: None.
6 – SRCD Mapping(s)
Description: Creation of mappings between the XBRL data (step 2) and relevant end reporting XBRL taxonomies (step 5), based on the Summary Reporting Contextual Data (SRCD) module of the XBRL GL Taxonomy.
Artifacts: XBRL GL instance document(s) representing the mappings.
IT Resources: UI to create the mappings and manage/store/expose them to the user. As for step 5, there are publicly available prototypes that implement these functionalities.
Issues to consider: Similarly to step 4, there may be the opportunity to re-use existing mappings created for other implementations.
These steps can be assembled in a template for a generic “deeply embedded” XBRL implementation architecture. The template can then be “instantiated” for a specific use case. For example, an implementation based on “last mile” reporting processes:
- Use of XBRL GL to aggregate trial balance data from multiple sources plus the necessary consolidation entries and other relevant journal entries, perform validations and run controls on the results;
- The resulting information is then rolled up to multiple end reporting XBRL taxonomies, such as the US GAAP and the IFRS taxonomy plus a third one developed by the entity for, say, management reporting or sustainability reporting purposes.
I will contribute a document based on these steps to the XBRL GL WG. Since the XBRL GL Taxonomy Framework is one of the key enablers of the “Deeply Embedded” approach, that WG is the most appropriate place for this kind of discussion. So if you are or plan to become a member of XII and you are interested in this discussion please join us there and make your voice heard. If you do not have access to the XII internal resources but are nevertheless interested and willing to contribute please feel free to contact me directly.
Hope To See You In Paris
If you are in Paris – or around there – during the week of June 22, and since you are reading this blog, chances are that you are already aware of the 19th XBRL International Conference. What you may not be aware of are the excellent opportunities for training that the Conference offers in such topics as taxonomy design, conversion of financial reports to XBRL and how to leverage XBRL internally for the benefit of your company with an XBRL Global Ledger (XBRL GL) introductory and intermediate courses.
I will be teaching the XBRL GL courses together with Eric E. Cohen, the inventor of XBRL GL. If you want to find out how to make XBRL work for you rather than it being just an additional compliance cost, and how to achieve the same benefits and significant cost reductions that drive the adoption of XBRL by governments and regulators around the world for your own company, you should take advantage of this opportunity. You will leave with practical, actionable knowledge on how to make XBRL work for you and how to achieve significant process enhancements and cost reductions in key internal reporting, auditing and data integration processes.
Altova and XBRL
February 5, 2009 turned out to be an exciting date for the XBRL world. It is the day when the leading suite of tools for all things XML became also a suite of tools for all things XBRL. I am sure that some in the XBRL community have mixed feelings about this. As for me, I could not be happier.
I care about XBRL adoption, and the support of XBRL in the Altova suite will open the world of XBRL to XML professionals in ways that would not have been possible before. And there are way more XML professionals than XBRL professionals around.
Also, I have a specific interest in the use of XBRL for internal purposes. The enabler for this is the XBRL’s Global Ledger Taxonomy (XBRL GL), and I have been working with it using the Altova suite of tools form more than 3 years now… right, more than 3 years. XBRL GL is designed to be the bridge between accounting and business software applications and XBRL, and it looks much more like an XML Schema than an XBRL taxonomy, even though it can handle all the variations of the XBRL 2.1 Specification and other related Specs, such as XBRL Dimensions. So, Altova worked just fine with it even before becoming XBRL savvy.
But now, I am very excited by the possibilities opened by working with XBRL GL and other XBRL taxonomies not only in XMLSpy, Altova’s XML editor, but also in other applications in the suite, like MapForce, the mapping tool that I use to convert any kind of data to and from XBRL GL, and that can now map XBRL GL data to any XBRL taxonomy, like the US GAAP or the IFRS taxonomy. I have always been a strong proponent of the joint use of XBRL GL and other XBRL taxonomies as a more powerful and yet simplified way to implement XBRL and to achieve benefits that go way beyond regulatory compliance, which is the better known and most visible application of XBRL, but in no way the only, or the most beneficial, one. It looks like Santa Claus arrived early for me in 2009.
Follow Me!
