One Step Towards Deeply Embedded XBRL

Posted by 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.