Back in the 1980′s I remember going to an IBM seminar evangelizing something called EDI (Electronic Data Interchange) a document messaging format designed for system-to-system operation over a VAN (value added network). I must say I always wondered what was the purpose of a network that didn’t add any value but today, despite the Internet and web services, EDI is still going strong: Particularly among e-commerce partners and in certain vertical industries e.g. automotive. So does XBRL have the potential to become a kind of EDI 2.0?
The XBRL Global Ledger (GL) is the initiative that is closest to EDI 2.0 - not so much for document transmission between supply chain partners but as a way to move accounting transactions between disparate systems that is both vendor independent and extensible: An open format for transaction level import and export, into/from ERP systems.
Back in the 1980′s I used to sell multicurrency accounting software to multinationals on the basis of using a standard ledger package everywhere. Believe me, that was a cool idea then. Companies like Unilever, Pepsi, BP and others who saw the light (reflecting off my shiny double-breasted suit) bought dozens and even hundreds of them. One reason was that they were desperately trying to get away from a mismash of financial applications that required lots of manual and error-prone effort to move data between them using lots of arcane proprietary file formats. In those days, corporations were filled with people whose job was to export data from here, massage it in a spreadsheet, and import it into there. What’s that? They still are? No. Surely not. Isn’t there an app for that?
XBRL GL is a way to reduce this burden and release distraught, exploited white-collar ‘data masseurs’ from their hellish servitude. But like any ‘open’ format it needs software vendors to adopt it for any value to be realized by business users. At the bottom end of the accounting software market, Quicken’s QFX (formerly QIF) format, is a common data interchange standard as is OFX in the banking industry. Yet in the mid-tier and top-tier of the ERP world, vendors still seem to be happy to build their own proprietary import/export functions rather than leverage something like XBRL GL. I say it’s time for the exploitation to stop.
So XBRL GL may not be quite the right thing for EDI 2.0 but it certainly has the potential to become ETI (ERP transaction exchange) 1.0 to help connect heterogenous ERP systems together and ERP systems to reporting systems like our Crossfire. Or does it? What’s your take? Please don’t tell me ASCII rules. And no. I don’t know any good ‘data masseurs’.
Tags: EDI
