Posts Tagged "wikiaccounts"
Standard Charts of Accounts in XBRL
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:
- 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;
- 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.
IPHIX Turns Page
The IPHIX web site is down today… no, not because of SOPA, even though indeed we don’t agree with its current formulation. Oh and by the way talking about SOPA this article called my attention as a very objective and balanced comment on the “Wikipedia Blackout” that occurred yesterday. Yes, it was a great thing. No, I hope it will never happen again, not even for a worthy cause like in this case. Because there is a tangible risk that people enthusiastically buy into any form of ”crowdsourced protest” just because it is the new cool thing, and that only a small percentage of them really takes the time to look into the reasons, understand the issues and form their own opinion. Anyway, I digress.
The IPHIX web site is down today because a brand new website will take its place. An exciting brand new image, a lot of new content, and a renewed focus on what we think matters the most in the XBRL world: enabling businesses large and small to leverage data standardization internally, and to achieve costs savings and internal process efficiencies that would otherwise require a significant investment in new software and in the time and resources necessary to deploy it.
All the thinking done and the experience gained in many years of leadership in the internal use of XBRL within businesses and NFP organizations is now coming together under new offerings of tools and services designed to support deeply embedded XBRL. implementations, which will complement (and leverage) our extensive experience in helping governments and regulators worldwide design and deploy their XBRL based programs.
It is an exciting moment for us, and we can’t wait to share the news with our clients and those who follow us and support our vision of total data transparency and accessibility within the enterprise through standardization. So please stay tuned, and follow us on Twitter and LinkedIn for the latest updates – the Hello World moment will happen sometimes between now and the end of the upcoming weekend.
One Step Towards Deeply Embedded XBRL
I came across this post in the SAP Community Network Blogs. It is about a proof of concept on using SAP software – ERP Central Component (ECC) – to generate XBRL reports, and in particular SEC filings in the example, by mapping journal entries to the SEC US-GAAP taxonomy, as opposed to mapping the financial statements to the SEC US-GAAP taxonomy after they have been finalized.
I want to point out in particular the conclusions from the post:
“We have gone from a GL journal entry to the published financial statements using the minimum steps required and leveraging the existing SAP production installations. This virtual financial reporting value chain takes a lot of manpower and even more hours to accomplish today, but this example shows a clear opportunity to streamline and make it a more efficient process thus creating added value for all.”
Of course, this proof of concept is not really about using deeply embedded XBRL, since it is based on a proprietary software and XBRL is only the final output. It is, though, about applying the idea behind deeply embedded XBRL – standardize and optimize the process of creation/assembly of end reports from the underlying detailed data rather than just standardizing the resulting end reports, because it is the process and the inefficiencies related to it that cost money to businesses, not the report in itself.
Once the concept outlined in the conclusions quoted above is understood and accepted, moving towards a real deeply embedded XBRL implementation, and more broadly towards leveraging the real value of XBRL internally to the enterprise, is easy:
- Use XBRL Global Ledger (XBRL GL) to standardize the underlying detailed data (journal entries or trial balance in this case, but you can go deeper down to even more granular data as needed) and the mappings to end reporting XBRL taxonomies (such as the US-GAAP taxonomy, or the IFRS taxonomy) as opposed to using the proprietary format of SAP or any other accounting software/ERP application. This makes it possible to integrate data from any data repository in use within he corporate information system and to avoid being bound to one specific application. It also makes it easy to broaden the scope of the internal use of XBRL to other processes that relate to data aggregation, reporting, auditing and monitoring.
- The step described in point 1 already goes a long, long way towards achieving the benefits of XBRL within a business. It is however possible to go one step further, by interposing a standard chart of accounts (SCOA) between the corporate chart of accounts and the end XBRL reporting layer. If the mappings to the XBRL taxonomy of interest are created with a SCOA as the starting point, they become reusable by any business just by mapping the corporate COA to the SCOA – an account-to-account mapping that is way easier than an account-to-XBRL-reporting-concept mapping. This means that a community of users can create and share these mappings in a standardized, reusable format, minimizing - actually I believe that the current buzzword is “crowdsourcing” – the cost and the effort related to deploying XBRL internally.
That community already exists, it is called WikiAccounts – check it out here.
Tweet
Follow Me!
