Posts Tagged "fsa"
XBRL Global Filing Manual
The Interoperable Taxonomy Architecture project, a joint initiative between the US Securities and Exchange Commission (SEC), the Japan Financial Supervision Agency (FSA) and the International Financial Reporting Standards (IFRS) Foundation XBRL team, recently published the Global Filing Manual (GFM), a set of best practice rules for the preparation, validation and filing of XBRL documents. More information can be found here, and the actual manual is here.
This document is a very useful resource made available by a globally significant project, and it contains information that anybody working with or interested in XBRL and its implementation will greatly benefit from.
From my perspective, I was happy to read in it a very clear statement about the scope of the Manual (page 4):
“The rules in this document have been created for financial reporting; some of the rules may be inappropriate or inapplicable for other types of business reporting.”
I have always been very vocal in stating that financial reporting is only a part of business reporting, and that XBRL is about the latter – as the words behind the acronym spell out - and not (only) about the former. The statement quoted above is very clear in pointing out that best practices or rules that are suitable for the use of XBRL to represent financial statements are not necessarily applicable for other kinds of XBRL reporting. In my professional activity I frequently (and painfully) deal with the damages caused by applying the “financial reporting” mindset and best practices to initiatives that are broader in scope and different in nature – the Standard Business Reporting (SBR) environment is a typical example of XBRL taxonomies where filing financial statements is only a portion of the business requirements, but there are many others. Architectural principles that are best practice for financial reporting taxonomies are simply not appropriate for other types of business reporting, for example tax or payroll information, and in general form-based information, due to the nature of the data being represented and to different underlying requirements . Seeing this concept so clearly expressed in the GFM really made my day.
Then, I went on reading:
“In this document, ‘financial reporting’ encompasses authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance and related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction‐ or journal‐level reporting, primarily narrative reports (for example, internal controls assessments) and non‐financial quantitative reports (for example, air pollution measurements).”
These words rang a bell, and then I remembered why. The very same words were used in the Abstract of the Financial Reporting Taxonomies Architecture (FRTA) 1.0 document released in April 2005 by XBRL International Inc. FRTA, even if obsolete – it was released before the XBRL Dimensions 1.0 Specification, and many of FRTA’s provisions are not suitable for dimensional taxonomies – is still considered by many the ultimate source of best practices for XBRL taxonomies architectures… and in spite of that statement in its Abstract, this tends to happen no matter if the taxonomy is about financial statements or not.
With this I do not mean that those statements in the FRTA and GFM are insufficient or inappropriate. Quite the opposite, they clearly state a basic principle that many seem to ignore or forget. The problem obviously lies in the way in which best practices are applied, even by XBRL “experts”, without enough insight on what those best practices are about in the first place. If you only have a hammer…
Having a clear understanding of the differences between financial statements – usually a flat list of reporting concepts with little or no hierarchy – and other types of business reporting is key to make the right choices in terms of taxonomy architecture principles. Being aware that comparability across different instances, a clear requirement for published financial statements, is not a requirement at all in other contexts, and that the architectural choices necessary to meet that requirement come at a price that you may not want to pay if you can avoid it, is also key. These are only the most evident examples, there are many more, and more subtle ones.
It is not a matter of right or wrong – it is a matter of understanding the actual requirements and making choices that are consistent with them.
Follow Me!
