Relational Tagging

Harvard Business School has just published what must be considered the ‘bible’ of so-called Integrated Reporting (i.e. reports that combine financial and non-financial data) entitled The Landscape of Integrated Reporting: Reflections and Next Steps. Among over 300 pages of cracking content (US translation: awesome content), the ebook has a section on leveraging technology and a couple of articles that discuss the role of XBRL in facilitating the journey towards integrated reporting. So here I’d like to discuss the concept of “relational tagging” for a moment.

In The Role of XBRL and IFRS in Integrated Reporting, the authors highlight the importance of globally aligned frameworks as a key enabler of comparability between reports produced in different jurisdictions. In Bringing Order to the Chaos: Integrating Sustainability Reporting Frameworks and Financial Reporting into One Report with XBRL, the authors highlight a different issue:

As the markets become more knowledgeable about the myriad of environmental, social and governance (ESG) practices and data sets around the world that are used to assess an organization‘s overall sustainability, the linking of  “vocabularies” governing those practices and data sets becomes more critical. This need for linkage—a common thread to tie them together—causes us to search for a unifying standard that systematically brings order to all of the ESG and sustainability vocabularies that exist around the world today.

Unfortunately they then abandon detailed discussion of ‘linkage’ – which is a shame as it’s key to what I call Holistic corporate reporting. Linkage is really about something very familiar to financial reporting people i.e. mapping. All financial accounting/reporting systems depend on mapping: You map transactions to accounts, you map sub-accounts to rollup accounts, you map entities into consolidation hierarchies etc.

[Aside: So if you are reporting manager and think you are undervalued in your organization, asks your boss to change your title to 'Financial Information Cartographer' - that'll get them talking round the water cooler. But I digress.]

The kind of mapping we are concerned with here is mapping across taxonomies and instance documents. For example how do you map taxonomies like the GRI (broadly non-financial/evidential data) to GAAP (financials)? How do you map GRI to another ESG/CSR taxonomy that you or your stakeholders care about? How do you map data in one instance document to another (to enable drillaround for rich context navigation)? Stuff you need to do in order to truly connect or integrate at the data level in order to create the relationships between data that help information consumers make the important connections in a web of data.

Not being that smart, I went to XBRL for Dummies for guidance. I assumed Linkbases, Xlinks and extended links would have something to do with it and then ‘discovered’  Discoverable Taxomony Sets which define a set of taxonomies governed by rules. A sort of taxonomy universe meta-layer. But as these important concepts (to Integrated Reporting at least) only merit a couple of pages in the book, I started looking for more insight only to find that linkbases and DTS are all rather complex for what I am looking to do i.e. integrate/connect financial performance and sustainability behaviour data.

As a dummy, what I was expecting was something like this.

If I have two taxonomies, let’s call them GAAP and GRI and within those taxonomies are two elements, let’s call them <EnergyCosts> and <Scope1Emissions>, what I want to do is connect them together so that I can drill between them if they are reported in separate report instances (as they often are). So if I’m in a financial statement that reports a ‘Cost of Energy Line’ I can drill to a sustainability report that discloses ‘Scope 1 Energy Emissions’ and vice versa. I don’t want to manually add all these links at the report content level, I want them to be already in place at the data level.

To do this, what I would imagine is that the financial statement and sustainability reports (in this case both represented by XBRL instance documents) simply declare their respective taxonomy scope (i.e. paths to the GAAP and GRI taxonomies), declare the document scope (i.e. paths to the respective instance document instances) and use a new “relational tag’ to relate the specific data to be linked. This relational tag refers to the linked taxonomy, instance document and its element e.g. <taxonomy.instance.element> by combining all three into a single tag declaration that then is used to ‘surround’ the actual element tag (within the current taxonomy context).

So if we have a taxonomy named GAAP and an income statement instance report called is2010, and a taxonomy named GRI and impact statement instance report called impact2010 then the number for energy costs refers to the GRI tag for scope 1 emissions in 2010 (and vice versa) using relational tags like this:

Income Statement report – <GRI.impact2010.Scope1Emissions>1000</GRI.impact2010.Scope1Emissions>

Impact Statement report – <GAAP.is2010.EnergyCosts>500</GAAP.is2010.EnergyCosts>

(Obviously the taxonomy, instance document and element references must relate exactly to the scopes declared in the current instance document and valid elements in the related taxonomy)

So when these XBRL instance reports are rendered, relational links automatically show up as clickable hyperlinks creating a web of connections that represents an integrated whole. You only tag using these “relational links” where you need to and there is no need for linkbases and other complexity to support this specific kind of use case. As a dummy I assume that the XBRL Community braintrust have already thought of this and so I expect some flaming comments, Arthur Brown-style, to educate me about an even simpler way to do relational tagging or if it does not exist why this suggestion is not practical.




  • Pingback: Tweets that mention Relational Tagging | Rivet Software -- Topsy.com

  • XBRLer

    I see your point of using a tag like “<gaap.is2010.energycosts>” – could be a good way to find and link concepts. However, it can't replace what xpath and xlink can offer: being relational, flexible, atomic. A tag like “<gaap.is2010.energycosts>” is fixed in path and “EnergyCosts” can't be associated (in formula or extensions) to other concepts. It is also hard for computer to process such a tag. </gaap.is2010.energycosts></gaap.is2010.energycosts>

    • Stewart Mckie

      Thanks for commenting. I guess my proposition is that if all you want to do is link a tag in one report e.g. income statement to a tag in another e.g. emissions report it seems much easier to do this via processing the tag itself within a named scope rather than having to rely on xpath/xlink etc. Clearly they are more powerful and can solve a wider range of problems but if you just want to drill around a set of reports via – as you say – a known 'fixed path' then it seems like a level of complexity that's unnecessary. But maybe I'm just being lazy. Also it probably is quite hard for a computer to process two end tags without start tags :)