Posts Tagged "standard chart of accounts"
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.
Follow Me!
