One Step Towards Deeply Embedded XBRL

Posted by Gianluca Garbellotto on Jan 6, 2012 in Featured, XBRL | Comments Off

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:

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

XBRL and Red Tape Reduction Initiatives in Canada – SBR Webinar June 7, 2010

Posted by Gianluca Garbellotto on Jun 2, 2010 in Featured, Webcasts, XBRL | Comments Off

Following recent announcements by the Canadian Government on the formation of a Red Tape Reduction Commission to consider ways of reducing the cost of compliance for businesses, XBRL Canada will hold a webinar on June 7, 2010 at 4:00pm EDT on how XBRL and the Standard Business Reporting (SBR) model can help.

The webinar includes a presentation by Paul Madden, Director of the SBR Program in Australia. See the press release here and the XBRL Canada website to register for the event. Paul’s presentations are very informative and pragmatic, and the result of a solid and successful implementation experience. If you want to know more about SBR, I suggest not to miss this opportunity.

Why Should I Even Consider Using XBRL For More Than I Am Required To?

Posted by Gianluca Garbellotto on Jan 11, 2010 in Featured, XBRL | 1 comment

In the last few months I wrote three columns in IMA‘s Strategic Finance magazine discussing three different approaches to XBRL implementation for regulatory compliance: the Bolt-on, Built-in and Deeply Embedded approach.  I received a number of questions from readers, and the title of this post reflects the one that was by far the most recurrent.  XBRL is being adopted worldwide for regulatory filings and dissemination of financial reports; isn’t advocating its use for different, much broader and more complex purposes a solution in search of a problem?

The value of XBRL is in the fact that it provides an optimized format to represent relevant categories of financial and accounting information – entries, documents, journals of various types, trial balances, and of course financial reports – in the same way across applications, business units, industries and jurisdictions. In turn, the value of this consistent format is that it enables the use of software procedures that can be created and shared relying on that single, consistent format as opposed to be software and application specific. The advantages are evident: not only data is decoupled from the application in which it was created or resides in and can be freely exchanged, but also and more importantly the same controls, business rules, analytics, visualization templates etc. can be applied to it consistently – again, across applications, business units, industries and jurisdictions. These benefits are obviously very relevant in the internal reporting and auditing space, for business intelligence purposes, and for other key internal processes.

If we look at SEC or other XBRL based regulatory compliance in isolation, the bolt-on approach – the conversion of financial reports and regulatory filings to XBRL once they have been created under whatever process is currently in place – may seem more appealing, but only if we choose to ignore the obvious connection with other processes and concerns that are critical and currently very cost and resource intensive. There are significant benefits and cost reductions that can be achieved by leveraging this existing and proven standardized format while planning its implementation for regulatory compliance.