So it’s good to see that the momentum for XBRL support in ERP systems is increasing, albeit slowly, as evidenced by this summary page – Leading ERP vendors Making Strategic Moves to Support XBRL and Meet Mandates – provided by the 22nd XBRL International Conference website.

James Fisher, SAP vice president of marketing for enterprise performance management and finance solutions, says companies would do well to look beyond simply checking off another compliance box when it comes to XBRL. Once in place, Fisher says XBRL will provide a foundation for a new generation of collaborative financial management applications that will have a profound effect on business.

Well. Better late than never – as I commented on the blog:

It’s good to see that SAP is waking up to the potential of XBRL. They are only a decade or so behind the curve. But then most ERP vendors are.

When FRx produced one of the first executions of XBRL for financial reporting back in 1999 and I and others were all writing breathlessly about the potential of XBRL, we had no idea it would take the rest of the industry 10 years to see the same potential we did back then.

Unlike Steve Levine (see his comment on the blog) I see the problem in the reverse. To date XBRL has been all about developers, IT and ‘tekkies’ generally. Many end users just don’t get it because the applications that are actually delivering the benefits are thin on the ground and many benefits will not be realized until, for example, ERP vendors embrace XBRL tagging at the transaction/account level so that XBRL tagged data ‘flows through’ to financial reporting.

Of course it’s good to see that the slumbering giant is awake. Let’s hope that’s a positive thing for XBRL generally. But more importantly, let’s hope others follow and XBRL can help more end users improve their financial information communication.

Those of you who remember your Gulliver’s Travels, will also remember that one of actions that Lemuel Gulliver famously takes once awakened is to pee on the miniature Lilliputian town to put out a fire. Here at Rivet Software we hope that SAP will respond to the opportunity of XBRL rather differently.

First, you will be aware that there are two financial ‘closes’ for many businesses: internal and external. The internal close is primarily concerned with the consolidation of subsidiary/business unit data to create internal management reporting. The external close is primarily concerned with massaging financial data into whatever formats are required to service external regulatory reporting requirements (e.g. an S.E.C. 10Q/K).

Globally, more and more external closes are being required in XBRL format. The problem is that external closes are a messy, time consuming business – perhaps even messier than internal closes. They would be much less of a messy/time consuming business if a lot of the ‘after-the-fact’ processing of data (e.g. XBRL tagging) was removed.

The obvious way to remove a lot of this effort is to prepare (i.e. tag) the data at source so that it ‘flows through’ and is all ready to be incorporated into various forms of external reporting. This is not difficult to do, it’s just that ERP vendors have not got around to doing it. Like the canny vendors they are, hey have waited for XBRL to reach what they consider to be a ‘tipping point’ as a global standard mandated by key local regulators (e.g. the S.E.C. in USA or HMRC in UK).

I say not difficult to do but to tag at source (e.g. post a transaction to an account that is pre-tagged to GAAP/IFRS reporting element) requires some extra fields sprinkled about the ERP system entities and the ability to manage taxonomies (import, update, navigate, extend etc.) from within an ERP system. It’s not trivial, but it’s not rocket science either. And when you own the ERP stack from transaction entry to business intelligence (as SAP does) you should be able to do a pretty good job with flow-through to help your customers integrate and streamline both closes.

But it’s not just the financial ‘tagged’ numbers that can flow through. So can notes and comments. The type of data that is also often captured at time of entry or as part of a transaction system. This textual data can inform the pre-filing review process by providing content for the evidential disclosures that many regulators require. Note flow-through is an often forgotten element of end-to-end closing that is simply missing today.

SAP’s investment in Cundus and investments by IBM and others before them, indicate that leading players recognize the importance of XBRL processing capabilities being embedded into transactional systems. The momentum to embed XBRL in ERP systems can only accelerate from here, which is another important brick in the XBRL wall. And it’s good for people like us. The more XBRL data there is in transaction systems the more there is for tools like Crossfire Controller/CFO to embrace and leverage for delivering new kinds of analytics to improve organizational performance.

So just in case you are wondering, I’m not suggesting that XBRL is a ‘turkey’ in the US sense of the word – it just makes a great headline. And while you wait for Sage and other ERP vendors to fully embrace XBRL you might like to consider what Rivet’s Crossfire can do to help you to manage your XBRL reporting in the meantime.

Drilldown is a commonplace feature of all accounting/ERP/financial reporting software. The aim is to enable you to get from summary to source i.e. to navigate from information to data or from report summary line to transaction posting line. The problem is that every transaction management software package is different so it’s not easy for any reporting package that sits above these to easily understand how to navigate down to the transaction data source without maintaining multiple ‘mapping layers’ into various ERP systems.

XBRL does a great job of standardizing ‘top-level’ report formats to provide an ideal start-point for a drilldown. But without similar taxonomy based tagging at ledger account and perhaps even transaction level line level, it’s hard to create a ‘universal’ drilldown capability that can facilitate a seamless audit trail. And it’s even harder when the source data systems are not part of an integrated ERP suite but spread all over the place as stand alone modules on an organization’s LAN or WAN.

That’s why it’s a shame that ERP vendors have not embraced XML-based web services as well as they might have. Every module in an ERP system essentially functions as both a data receiver and provider  - that’s why traditional data import and export functions are important core functionality in any ERP system. And enabling data consumption and provision programmatically across the Internet is basically the point of web services.

So one way of providing a seamless audit trail, top-down from an XBRL formatted report, is to be able to call a standardized GL/AR/AP etc. web service (or data interface) and pass XBRL tags as a means of navigating the drilldown hierarchy . Of course this also requires XBRL tagging to move down and become embedded at least at sub-ledger account level. Which is one reason why the first stage of XBRL-enabling ERP systems for seamless drilldown, XBRL-GL, is an important step towards this goal.

ERP vendors seem to be genetically pre-disposed to avoiding any kind of standardization that may reduce their competitive differentiation. But here we are just talking about a very simple, but standardized, ‘GET’ interface available for each ledger that would also facilitate ERP-to-ERP interoperability generally. Unfortunately without this kind of joined-up thinking it’s not just the seamless audit trail that remains pie-in-the-sky, it’s also the promise that XBRL holds for improving the control of internal accounting data and re-architecting the way consolidation reporting software functions.