Posts Tagged "xbrl formula"
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.
Follow Me!
