Posts Tagged "sec"
New IPHIX Corporate Blog
With the release of the new IPHIX website we are also starting a corporate blog. I will keep writing on the GLG Repository and my posts will show up in the IPHIX blog as well, or at least the XBRL related ones. In addition, the IPHIX blog will from time to time have posts from guest bloggers – and by the way, if you are interested in posting something you can contact us.
If you are a reader of the GLG Repository for professional reasons you may want to subscribe to the IPHIX blog instead. The current skin of the GLG Repository may have already suggested that the tone of the blog will slightly change, to become a little more personal. At least this is one of my New Year resolutions, we’ll see if time allows.
So I hope to see you there… and here, if you care to stick around.
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
Not Your Usual XBRL Case Study
The Maryland Association of CPAs (MACPA) and Altova recently published a remarkable case study focused on exploring the actual internal process benefits available for small businesses with the use of XBRL, and to showcase those benefits to MACPA members and to other non-profit organizations.
Basically, MACPA used Altova’s Mapforce (part of the Altova Missionkit suite) to convert its internal accounting data to the XBRL Global Ledger (XBRL GL) format. The data was then used to automatically populate their Key Performance Indicator (KPI) system. They also used Altova XMLSpy to extend the US GAAP XBRL Taxonomy (UGT) and adapt to meet the reporting needs of a non-profit organization. Finally, they mapped their XBRL GL data to the extended UGT, again using Altova Mapforce for the purpose, and created the final XBRL reports. You can find the full document here.
This case study is remarkable for a number of reasons.
Scope. The case study shows that XBRL is not only about the Securities and Exchange Commission (SEC) mandate in the United States or other similar global compliance initiatives – it is very much about achieving internal process efficiencies and cost savings for businesses. Financial reporting is one very important output of those processes, but not certainly their essence. Check out the comments from Tom Hood IV, the college intern that MACPA engaged to perform most of the technical activities described in the case study, in the YouTube video that illustrates the project. You will hear him describe the process benefits achieved and their practical consequences – the elimination of several manual activities and of the spreadsheets used to support them.
Tooling.The case study demonstrates that XBRL does not necessarily need to be embedded in accounting software, ERP applications and consolidation/reporting packages. It would be great if this was the case, and when it is the case it would be great if that support was not conceived as a “print to XBRL” function at the end of very application specific reporting processes, as opposed to providing richer deeply embedded XBRL capabilities. But the existence of tools like Altova MissionKit enables the creation of a “standardization layer” sitting on top of any application and data repository within a corporate information system. This translates into complete control over the characteristics of your XBRL implementation, its clear separation from the process constraints imposed by proprietary applications and its consistency across different components of the corporate information system. In other words, it sets the stage for the achievement of the real internal benefits enabled by XBRL for global companies, small businesses and non-profit organizations alike.
XBRL implementations “can” be easy.Here is a quote from the case study by Tom Hood, MACPA’s CEO and Executive Director: “If we can implement XBRL as a state-based non-profit association working with a college intern, you can do it too – implementing XBRL in-house is easy with the right tools.” XBRL GL is the seamless bridge between source accountinginformation and end reporting supported by XBRL taxonomies, the UGT in this case. Altova Missionkit was already used to implement XBRL GL long before XBRL support was added to its capabilities - and things got a lot easier after this happened of course. It does look like the MACPA made all the right moves, and those moves paid off.
This is the real promise of XBRL. Small businesses and non-profit organizations can achieve advanced internal and external reporting and business intelligence capabilities quickly and for a fraction of the cost. Larger companies can make their existing IT infrastructures more efficient and eliminate manual and resource intensive data-related processes.
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.
XBRL Implementation Strategies: The Bolt-on Approach, Strategic Finance, May 2009
My XBRL column in the May 2009 issue of IMA’s Strategic Finance discusses in more detail one of the three XBRL implementation strategies outlined in the March 2009 column: the bolt-on approach. In brief:
- With the bolt-on approach filings and reports are created following the existing process and converted to XBRL once finalized, either in-house or by a third party;
- This approach is a fast and relatively inexpensive way to react to the SEC - or any other – XBRL mandate, and it is also the only approach promoted and supported by the vast majority of XBRL consultants and vendors;
- On the other end, it has limitations that have to be taken into account in its evaluation:
- It turns XBRL into just an additional format to print the report once it is created, and it does nothing to make the advantages that XBRL offers in terms of greater efficiencies and lower costs in the process of creating the reports available to the company;
- It poses change management issues: if a change in a particular report occurs, it will typically have to be implemented twice, once in the generation of the report, and once in the conversion to XBRL;
- Evolving reporting requirements, either new – such as the convergence of US GAAP with IFRS - or already embedded in the SEC rule – the “year 2″ additional tagging requirements – will soon challenge its efficiency and even its viability.
Check the complete article at the IMA website (members only). Alternative approaches – Built-in and Deeply Embedded - which enable to achieve the primary goal of compliance but also offer significant benefits for the filer, will be discussed in two upcoming columns.
Follow Me!
