Corporate Data Transparency and Accessibility with XBRL

Posted by Gianluca Garbellotto on Feb 21, 2012 in Around the Corner, XBRL | 0 comments

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:

1. Proliferation of spreadsheets to address internal data aggregation requirements from disparate modules of the information system that cannot easily be automated;
2. Duplication of processes, in particular related to data analysis and monitoring, in different applications where data similar in nature is stored or processed;
3. Manual “last mile” of financial reporting;

And here are three ways in which XBRL can help address these issues:

1. 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; 
2. 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; 
3. 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.

EIOPA Aligning Solvency II XBRL Taxonomy with EBA – The Right Way

Posted by Gianluca Garbellotto on Feb 16, 2012 in XBRL | 0 comments

This Solvency II Wire article  had a lot of exposure in XBRL forums and mailing lists over the last few days. I would like to focus on its last paragraph:

The EBA is using a Data Points Model, a more sophisticated XBRL model, in which the link between the taxonomy and the business use is more difficult to establish. According to Mr Hoedjes, “EIOPA is trying to stay closer to the business side so that business users can read the taxonomy without a dictionary by their side. So we will try to develop a mixture between Data Point Modelling and the business use.” [Patrick Hoedjes is Director of Operations and Chairman of the IT and Data Committee at EIOPA]

This remark is very encouraging. The ability of business users to “understand” an XBRL taxonomy is a key enabler of the real benefits that XBRL brings not only to regulators and analysts, but also to businesses and organizations. The tendency to adapt to the XBRL domain commonly adopted IT data modeling techniques, which are perfectly appropriate for other purposes but can result in XBRL taxonomies that are more complex and therefore more difficult to understand and use, is present in many XBRL initiatives. In some cases this tendency is justified with the consideration that a specific XBRL taxonomy is used in a “closed” environment – meaning that the reporting program that the taxonomy supports does not allow users to modify or extend it. Therefore, the argument is that a complex data model is not an issue because

1. Since the data model is completely controlled by the architects of the taxonomy, users can be provided with tools external to the taxonomy, such as spreadsheets and templates, that act as an interface and help them understand the complexity of the data model within the scope of the closed reporting project;
2. Complexity does not create a problem for users because they are not allowed to modify the taxonomy anyway, and therefore they do not have to deal with that complexity.

In reality, users can and should be able to leverage any XBRL taxonomy, even if designed for a closed reporting environment, to support other internal or external reporting processes where it can be beneficial, even if those processes are completely unrelated to the purpose for which the taxonomy was created in the first place. This requires understanding, modifying and extending the taxonomy, and complexity becomes an issue.

Broad reusability of taxonomies is a key part of the value proposition of XBRL. XBRL taxonomies represent a wealth of authoritative, freely available information and resources related to a specific domain – be it the International Financial Reporting Standards, Solvency II, tax returns information in Australia, or anything else for which an XBRL taxonomy is published.

Within every XBRL project that I worked for I have always advocated a balanced approach between the use of generally accepted IT data modeling principles and the need of keeping taxonomy architectures as simple as possible, to facilitate its understanding and re-use both by business and IT users. This is not to say that a complex data model or certain types of XBRL taxonomy architectures are “wrong” – the issue is that frequently taxonomy architects consider only the immediate requirements of each project and lose sight of the broader picture.

XBRL is a business reporting supply chain integration standard. Focusing only on the end of that supply chain, on the moment in which a filing is received by a specific regulator or released to the market for a specific purpose, means considering XBRL as just another IT format in which information can be expressed. It also means giving up on its potential to make business, financial and accounting information transparent and accessible, cheaply and effectively, within or outside the corporate information system, for regulators and investors as well as for global corporations and SMEs.

The position expressed by EIOPA, and in particular the motivations that support that position, are encouragingly consistent with this broader vision of XBRL, and I consider them the most remarkable part of the announcement.

Standard Charts of Accounts in XBRL

Posted by Gianluca Garbellotto on Feb 1, 2012 in XBRL | 0 comments

In my professional engagements with global XBRL programs I am frequently asked the question: what is the best way to represent a chart of accounts (CoA) in XBRL?  And how can we represent the mappings between each account in the CoA and reporting concepts in end reporting XBRL taxonomies – such as the IFRS or US-GAAP taxonomy –in order to communicate how to derive the XBRL financial statements from a trial balance that conforms to the CoA?

There are two approaches in XBRL to represent a CoA and its mapping to one or more XBRL taxonomies for end reporting:

1. Use the XBRL Global Ledger taxonomy (XBRL GL). Each account in the CoA is a fact in an XBRL GL instance. The mappings between each account and concepts in the end reporting XBRL taxonomies to which the CoA is mapped to are also represented as facts in the same instance;
2. Create a custom XBRL taxonomy. Each account in the CoA is a concept in the custom taxonomy. The mappings between each account and concepts in the end reporting XBRL taxonomies to which the CoA is mapped to are represented with an XBRL Formula linkbase.

From a technical standpoint there is no absolute best choice – it really depends on the specific requirements of the implementation where the chart of accounts will be used.  There are, however, significant process benefits in using the XBRL GL approach, especially when we are talking about a Standard Chart of Accounts (SCoA) released by a regulator to make it easier for businesses to comply with some kind of reporting concern.

Benefits of the XBRL GL approach

• There is no need to create and maintain a custom taxonomy. XBRL GL exists and does not require any extension to represent both SCoA and mapping information;
• Representing the mappings between a SCoA and concepts in end reporting XBRL taxonomies in a way that allows users (businesses, organizations and accounting software developers) to automatically create the target XBRL instance documents is fairly complex, especially when the target XBRL taxonomies are dimensional. XBRL GL provides a straightforward way to do that. Processing software is fairly easy to create, and open source software is available;
• Once the mappings are created, they need to be deployed by users in their own environments. XBRL Formula is a complex technology, and requires specialized software and expertise. XBRL GL is very similar to a normal XML Schema – much easier to deal with both in terms of tooling and of availability of skilled resources. For the same reasons, extending the SCoA and the mappings to leverage them internally in different reporting processes will be much easier;
• The use of XBRL GL provides a greater value to the users community. In general, the XBRL GL model is re-usable in disparate internal data-related processes for companies and businesses as well as accounting software developers – the benefits of the “deeply embedded” approach to XBRL implementation that we have long discussed and that builds up the value proposition of using XBRL in the first place.  The SCoA/Trial Balance level is the entry point for that, and using XBRL GL to represent the SCoA will provide a starting point for businesses and accounting software developers to more easily extend the use of XBRL GL deeper down – general ledger, sub-ledgers, invoices, inventory etc.

Exactly because of the greater value that an XBRL GL based approach provides to businesses and organizations using XBRL, there are additional benefits coming from the free availability of resources that help deploy XBRL GL CoAs:

• A free and community-supported web application called WikiAccounts enables the creation of mappings from a CoA/SCoA represented with XBRL GL and XBRL taxonomies for end reporting – see http://wikiaccounts.org for more information;
• Users of WikiAccounts can voluntarily choose to make the mappings that they create available to the community. As a result, WikiAccounts already contains a free library of mappings between a common SCoA and widely used XBRL taxonomies, such as the IFRS taxonomy, the US GAAP taxonomy, the Canadian GAAP taxonomy, and the SBR AU taxonomy. When creating a new CoA/SCoA, the user can opt to map it to the common WikiAccounts SCoA, which means that he will be able to leverage all the mappings already present in the WikiAccounts free library, enabling free conversion and reconciliation between all the taxonomies supported.

Features of a custom XBRL taxonomy that are not available under the XBRL GL approach

It is also important to consider the flip side of the coin – what features of a custom XBRL taxonomy are not available when using the XBRL GL approach:

• XML/XBRL validation of the data in the instance is limited to its conformance to the XBRL GL taxonomy. In other words, it is not possible to validate the content of the CoA, only its structure;
• It is not possible to use multiple labels, definitions and references for the accounts in the CoA.

In my experience the first feature can be useful, even though only for certain specific requirements. When that is true, its absence under the XBRL GL approach can be mitigated with the creation of external validation rules, using XBRL Formula or other XML-based rules language. The second feature is rarely relevant at CoA/SCoA level, since labels and references are normally more useful at end reporting level, and are still be available in the XBRL taxonomies to which the CoA/SCoA is mapped.

If you know of other key advantages of the “custom XBRL taxonomy” approach that I missed, please leave a comment below, I will be happy to include them.

Conclusions

In my experience there are clearly documented advantages in the use of XBRL GL to represent charts of accounts, as opposed to developing a custom XBRL taxonomy for the purpose. There are benefits for the regulators who are faced with the choice, and even more for their regulated communities – and the latter is usually a key factor in any XBRL initiative.

It is the typical situation where there are multiple technical solutions to a problem that are all viable – but not because something is technically possible it is also necessarily the best solution.  In the same way, you CAN use spreadsheets to create, say, an accounting system, but after a while you would probably wish you had used a relational database instead.