The original version of the Inline XBRL specification was released over ten years ago with a wide range of features to enable filers to embed XBRL tags within an HTML file, creating a document which is both human readable and computer readable. In my role as editor of the transformation registry, I look after one of these features – the ability to have a fact value which is presented in a human readable format for human readers and a canonical computer readable format for computers to use.

Another of these features has a great deal of potential for streamlining reporting by making a single document suitable for submission to multiple regulators or to meet multiple goals. This feature is known as the target document. Each fact in an Inline XBRL document can be associated with a target document so that a report can contain data for multiple purposes and different audiences. The same report can even be submitted to different regulators. The specification describes the process by which relevant facts can be picked out and assigned as required.

Processing an Inline XBRL document will always create at least one target document, which is usually an unnamed default target. This target document is then processed for semantic validation, such as calculation checks. However, it is also possible for an Inline XBRL document to define additional target documents for multiple audiences.

For example, suppose a firm needs to produce a report to describe financial and sustainability data. This firm would, using target documents, be able to create a single report that describes both sets of data.

If there are any items of information which only need to be reported by one regulator, a single tag can be created for that data set. For example:

<ix:nonNumeric contextRef=”context” name=”fin:address” target=”financial”>20 Northmoor Road</ix:nonNumeric>

However, if there are items which are included in both data sets, that can be done by nesting tags:

<ix:nonNumeric contextRef=”finContext” name=”fin:nameOfChairman” target=”financial”><ix:nonNumeric contextRef=”susContext” name=”sus:nameOfChairman”>JRR Tolkien</ix:nonNumeric></ix:nonNumeric>

This will create a fact in each of the data sets, each with the value of ‘JRR Tolkien’ and each associated with the appropriate concept in the relevant taxonomy.

In this particular pair of examples, there will be two target documents created. The first target document will be the default target document, which will contain all the information required for the sustainability data set. The second one will be named ‘financial’ and will be associated with the financial data set. Of course, there is no requirement in the specification that a target document has a name with any semantic meaning whatsoever, though there are syntactic limits on what it can be. A document could theoretically represent any number of target documents, as long as there is at least one, and none of them have to be the default target document.

Around the world, this feature is not in much use, but one place where it has been used to great effect is Denmark. The Danish Business Authority (Erhversstyrelsen) permits filers to create an Inline XBRL document which contains tags for the ESEF taxonomy using the default target and the ÅRL (Annual Accounts) taxonomy using a target document named ‘DKGAAP’. This means that Danish filers are about to create their reports which are suitable for submission to multiple regulators within a single Inline XBRL file.

It would be wonderful to see this feature used more widely around the world. The Danish solution is very elegant and straight-forward. By defining a name for a target document, the Erhvervsstyrelsen has made it very simple for filers to create a single report that covers both mandates and for anyone reading the report to understand which mandate is associated with which target document. ESMA also envisage this scenario, though they insist that the default target document is the only one that can be used for their filings. For any regulator or taxonomy author, suggesting a name for a target document would make it significantly easier for filers to create a single report that can be submitted to multiple regulators.

CoreFiling provide a range of products and solutions for processing Inline XBRL reports, and more bespoke innovations are planned for the near future. If you are looking for assistance on this Inline XBRL front, please contact our team.