XBRL CL or Dare to Share (5)

Reading Gary Thompson’s very interesting post from last year (?) on Cloud Dimensions: Who, What, When & Where got me thinking about XBRL GL again in terms of my upcoming ‘Dare to Share’ presentation in Brussels. Perhaps the inventors of XBRL GL were not ambitious enough in their thinking of the role that something like XBRL Global Ledger could play. Especially if it were just re-positioned slightly and renamed (to avoid that general ledger connotation) to something like XBRL CL (Corporate Lens).

If you mashup transparency, with sharing, with points of view (POVs) and XBRL GL, it starts to make you think that maybe something like XBRL CL could have an important role to play going forward.

xbrl-cl

xbrl-cl

Many people have proposed that we should not be sending files to regulators but that regulators should simply retrieve it, web service-wise from our corporate servers. Our friends at RRD are not going to like this suggestion much but really, sending all these files to all these places is a pain. In much the same way, in the spirit of ‘intentional transparency’, other stakeholders could also access corporate data the same way  as a regulator but simply via a different lens.

Of course there are many issues with this kind of open data access: authentication, permission to access the data, ability to drilldown, what the data can be used for etc. But technically nothing essentially different from what every Facebook, Twitter or Flickr like application programming interface (API) deals with already. Regulators, auditors, business partners and other stakeholders could potentially benefit from a ‘standard reporting’ data lens like this that provides a point of entry in a well-defined, taxonomized way.

Naturally, you accessing ‘your’ data on Facebook via an API is different from an ‘outsider’ accessing your data – you are in reality the owner of your data on Facebook. But in effect Facebook functions as little more than a front-end to your data and makes it visible in various ways to various ‘permissioned’ stakeholder groups (at least it does now on the back of various privacy concerns). XBRL CL simply bolts on a web service layer and provides a set of POV ‘lenses’ through which externals can access your internal data.

XBRL GL as it stands today was not designed for this purpose but there’s no reason why it – or something like it – couldn’t be adapted to this kind of use. Clearly there is a ‘Dare to Share’ aspect to this proposition but as people like David McCandless and others like him are proving, when you get the data out there you discover interesting things. As McCandless puts it: Data is the new soil.


Tags:



  • Eric E Cohen

    Thanks for this! I will take the hit for ambition, and welcome ideas on rebranding and repositioning. But I may be slightly more ambitious than we get credit for.

    Since you asked – we have thought of renaming XBRL GL numerous times since its earliest days when GL actually meant “General Ledger”. It was renamed “XBRL GL, the Journal Taxonomy” (to represent sub-ledgers, like AR, AP, inventory and the like, although it can do much more than generically represent journalized information) and has morphed to the present XBRL Global Ledger Framework (any ledger, anywhere). We have struggled for years on a better name, and will continue to consider it, but we have also gotten regular feedback that it would be more confusing to get rid of the “GL” nomenclature. Attempting to be like the human genome project, except for ERP systems, is a big area to cover, and hard to get one's arms around:

    - XBRL GL goes beyond general ledgers, beyond traditional accounting systems, to information – qualitative and quantitative – any detail for internal or external use.

    - Some people try to stratify XBRL GL for Internal reporting (and XBRL “FR” for External reporting) and that doesn't work. Internal data is shared externally to close parties, and – as you note – many regulators are talking about just asking for the underlying detail and then filling out the forms for management, either optionally or thinking something more. Today's internal is tomorrow's external.

    - Some people limit the role of XBRL GL to transactions – and again, it is much more: setup files, master files, transaction files, history files, mapping/configuration files and more.

    Way back in early 2002, we ran a “Rename XBRL GL Contest”. Entries, serious and otherwise, included:

    XBRL/BE – Business Events

    XBRL/TD – Transaction Detail

    XBRL/ATOMS – Accounting Transaction Open Messaging Specification

    XBRL/ERIC – Extensible Representation for Internal Consolidations

    ADAPT – Accounting Data Access & Processing Taxonomy

    BUGLIST – Bridging Utility for General Ledger Interchange with Software Taxonomy

    CARPET – Chart of Accounts, Receivables and Payables Exchange Taxonomy

    GLAD – General Ledger and Accounting Data

    GLITCH – General Ledger International Taxonomy for Computers and Humans

    JESTER – Journal Entry and Statement Trail Export Representation

    RIDDLE – Reporting Interchange for Drill Down Ledger Export

    SADDLE – Statement and Audit Drill Down Ledger Export

    and we can't forget the original ADFST (add fast!) that preceded XBRL – Accounting Data and Financial Statement Transfer/Transport; that was my original baby, which I brought in to the consortium as the basis for XBRL GL.

    Regarding the Corporate Lens concept, that is also very much in line with XBRL GL's development.

    We introduced back in 2005 the concept of being able to express any data (ntive file formats, export formats such as CSV or fixed-length ASCII) using the XBRL GL semantic – sometimes called Eric's XBRL GL Colored Glasses – where, without ever turning anything IN to XML/XBRL, the semantic is used to describe the data within systems or files. In line with that, XBRL GL was almost renamed XBRL DX (Data Exchange) or DDX (detailed data eXchange) but that wasn't well enough received. We never gave any thought to actually calling it XBRL CG (rose-colored glasses), although the lens metaphor is very apt.

    For example, imagine if any CSV or fixed length ASCII file could be described using XBRL GL (without actually being turned into an XBRL GL compliant file). Whether it is the physical position in a fixed length ASCII file (starting position, length) or the relative position of fields in a CSV file (the third value in the record), you could with a very small file provide a globally understood definition of the content of very large files without needing to change the file or introduce the additional verbosity of XML.

    A very simplistic snippet of what we called the XBRL GL Data Definition File format (driven by XBRL-GL_DDF.xsd) describing two fields in a fixed length ASCII file where the first two characters represent the source journal ID and the next three characters represent the entry number:

    - <entrymaps>

    – <entrymap><xbrlnamespace>

    <xbrlelement>sourceJournalID</xbrlelement>
    <filename>
    - <fixedinfo>

    <startingpos>1</startingpos>

    <len>2</len>

    </fixedinfo></filename></xbrlnamespace></entrymap>

    – <entrymap><xbrlnamespace>

    <xbrlelement>entryNumber</xbrlelement>

    <filename>

    – <fixedinfo>

    <startingpos>3</startingpos>

    <len>3</len>
    </fixedinfo>
    </filename></xbrlnamespace></entrymap>

    This small file, which could accompany or be embedded in an existing file, can introduce much of the power of XBRL GL to external file formats.

    Another example of the “lens” was demonstrated by the fine folks who oversee Crystal Reports a number of years ago – they were showing XBRL GL as a generic vocabulary for looking at any off-the-shelf ERP system that they support – when you brought up the potential data files and fields with which you build a report, you had your choice between the proprietary naming/organization and the XBRL GL naming for data fields.

    Within XBRL's Specification group, the folks developing “Generic Links” almost kidnapped the name XBRL GL, making things even more fun.

    Regarding XBRL GL and Web services, we have been describing the benefit of using XBRL GL's schema formats as the standard, generic and holistic way to represent data from first transaction to end reports in WSDL/Web service environments; just as one type of blood is visible if you stick a pin in your toe or your ear, one type of XBRL GL harmonized data flow could be used for data anywhere throughout the internal audit supply chain.

    We hope that XBRL GL is ready to share when companies and other organizations are.
    </entrymaps>

    • Stewart Mckie

      Eric – I was rather hoping you would take my facetious 'not ambitious' remark on the chin and use it as an opportunity to illustrate just how much thinking has gone into XBRL GL over the years. You've done that very nicely. Thank you.