Are These Reporting Frameworks Poor Design
or the Ultimate Flexible Framework?

Introduction

The idea for this article began when the UK Financial Conduct Authority (FCA) introduced the UKSEF XBRL reporting framework, which uses a rare approach to XBRL data collection. It uses a single inline XBRL document to collect data against multiple XBRL independent taxonomies. The UK Financial Reporting Council (FRC) designed the UKSEF framework and has also since led a consultation on the future of UK company reporting taxonomies titled ‘the Opportunities for future UK digital reporting.’

My initial reaction was that I could not understand why any reporting framework would use such an approach. It seemed to me that rather than addressing the issues caused by combining data models described in several XBRL Taxonomies, the Multi Target Document (MTD) approach appears to push these issues down the information supply chain to be resolved by the report issuers and data analysts. In addition, UKSEF raises awkward decisions for software vendors of do they invest to support a unique MTD framework or not.

This MTD approach was also covered in a draft article by the XII Taxonomy Design Working Group (WG), part of XBRL International (XII) called ‘How to use a single Inline XBRL document for multiple reports.’ The WG paper is technically correct, as one would expect, however, my concern was broader than the technical details. The WG paper appeared to normalise the MTD approach, as it presents it as one of several equal approaches that a data collection authority could use when designing an XBRL taxonomy as opposed to addressing a rare and specific use case.

So, I wanted to understand more about why taxonomy designers would use this approach, what the real benefits to a reporting framework were, where the MTD approach should be used and where it shouldn’t. As I am not a taxonomy designer, I talked to a range of practitioners to get their views on the potential real-world use of the MTD approach.

The UKSEF experiment

Very few authorities have used MTDs. As far as I know, only the Danish Business Authority has used it previously. In both UK and Danish jurisdictions, it is common practice for listed companies to include details of the Consolidated and local individual company accounts in company annual reports. So, the reasoning goes that these reports must be tagged using both the European Single Electronic Format (ESEF) or a similar IFRS equivalent for the consolidated accounts and a local GAAP or IFRS taxonomy for the individual company reports.

The UK was an early adopter of XBRL for regulatory reporting and the first country to adopt inline XBRL. However, the adoption of an MTD approach for the UK reporting framework for listed company’s annual returns, UKSEF, was eyebrow raising. The question it raises for me is if the MTD approach is a long-term solution or is the UK just at a specific moment in digital reporting? From the FRC UKSEF 2025 developer guide:

The FRC develops and maintains the UK company reporting taxonomies that is the basis for reports collected by the UK FCA, UK Companies House and the tax office, UK HMRC. In UKSEF, the FRC is combining ESEF and the FRC UK Taxonomies (specifically FRS102 and IFRS entry-points) so that a single inline XBRL (iXBRL) report can be submitted to the FCA and Companies House. The FCA is interested in the ESEF part for market supervision and Companies House will register both documents.

The MTD approach appears to have appealed to the UK FRC as a simple solution to managing both taxonomies without the need to generate a new single entry-point Taxonomy. The latter would have referenced each of the existing Taxonomies, combining the concept definitions and relationships into a single model, but would require the resolution of any conflicting design issues between them. In fact, UKSEF has been through several iterations initially attempting to create a single UKSEF entry-point. Rather than create a new taxonomy that was totally owned by the FRC, it tried to extend ESEF with UK taxonomy definitions but fell foul of the ESEF filing rules (more on this later). The 2025 developer guide claims support for MTD was properly introduced in 2023.

For issuers, the tagging against two separate taxonomies does not increase or decrease the effort, they are still generating the same digital report with the same tags. However, I see two areas where the FRC are just deferring work for others to do:

• I believe the first issue comes with the MTD approach when analysts, issuers, auditors, or investors need to combine the data into a single dataset for tagging and analysis, then you have multiple independent data models that need to be applied. However, as supporters claim, if the data is totally independent then there is no need to do this. I am no accountant, but I thought that consolidated accounts are generated from individual companies, so they are related even if treated differently from an accounting viewpoint.
• I also believe there to be a second, indirect cost. Many XBRL software vendors that support ESEF may decide not to support UKSEF because of the additional software development for MTD, hence potentially putting up software costs and reducing innovation.

The key benefit here is flexibility. If you are unsure what the regulatory framework is going to look like in the near future, then using a MTD approach is a short-term, low-cost solution. Many would use this characterisation for the UK company reporting frameworks after Brexit. In addition, the Economic Crime and Corporate Transparency Act means that UK Companies House is undergoing an all-encompassing legislative and operational transformation, which the UK Government describes as “the biggest change in the role of the Registrar since it was created in 1844”. Plus, new sustainability Taxonomies are close to being implemented in Europe and by the International Sustainability Standards Board (ISSB), part of the IASB. So, one would expect further changes to be required in UK regulatory reporting resulting from these initiatives. In this kind of environment, I can see that it is difficult for the UK FRC to determine a clear pathway on how to move forward.

As far as I understand, the feedback on UKSEF from listed companies has been ‘lukewarm’ with very few companies using it. Instead, listed companies have continued to submit just ESEF reports for which they already had solutions. However, that does not answer the question of the value of MTDs, as there is a lot of change going on in the UK and the companies may just be sitting on the sidelines until they have more certainty and stable instructions.

Multiple XBRL Target Documents

Multiple XBRL Target (MTD) documents is a standard part of the Inline XBRL (iXBRL) specifications. An iXBRL document is formatted in xHTML with embedded XBRL tags. The document can be read, and the tags can be reviewed using a special iXBRL viewer or the tagged data can be extracted into an XBRL document, which can then be loaded into a database for further analysis. The target XBRL document can be validated as normal against each referenced Taxonomy. In MTDs the only difference is that there are more than one XBRL target document produced from the single inline XBRL document. Each resulting target XBRL document is completely standalone and self-contained. So, in use cases where the two sets of data in the report are totally independent then MTDs should work perfectly.

If you are reading this and unfamiliar with XBRL then think of each Taxonomy as a data model linking concepts (fact values) via semantic relationships. Using multiple taxonomies on a single report means either combining multiple data models resolving any conflicts to generate an ‘uber’ model from the combination or in the MTD approach just treating the models as independent.

XBRL makes combining models with a single unified entry-point easy. Extending a model (extensions) is one of XBRL’s key strengths for reporting frameworks. In fact, the ‘X’ in XBRL stands for eXtensible. You should note that there are two levels of extensions, first the data collection authority may bring together several taxonomies into a single unified entrypoint for its published taxonomy. The other is when reporting entities extend the above with their own specific company extensions when reporting against an ‘Open’ reporting framework. This paper focuses on the former.

In a typical data collection system, you would define two data pipelines to feed the two different data collection models. It seems that data collection authorities understand this point, hence the rarity of reporting frameworks using MTDs, as mentioned above.

If a data authority wanted to generate a single, combined Taxonomy, it would need to resolve the differences that exist between taxonomies. So, in UKSEF for example, ESEF and the UK FRC Taxonomies use different context container to use for dimensional qualifications.

The data authority would need the skills and resources to make these changes. This is why data collection authorities may see the MTD approach as the simpler route.

However, even in MTD frameworks these differences can cause issues, for example the different context containers used by different Taxonomies need to be accounted for by XBRL tagging software, else they will produce errors in at least one of the target XBRL documents. Most ESEF software has been primarily developed without knowledge or experience of MTD’s and these issues. Hence, the additional development and cost in supporting UKSEF.

In addition, there are rules and guidelines that cannot or are not expressed in XBRL Taxonomies. These are commonly referred to as Filing Rules and are often presented in a Reporting Guide. In MTD frameworks where conflicts have not been resolved, the Reporting Guide can be more troublesome to define. The UKSEF developer guide has in fact also gone through several iterations as the ideas have developed. (Can be found here.)

Understanding these Filing Rules is critical for developers to ensure that they are producing the correct XBRL report and for validating it. So, XBRL software systems MUST understand that they are processing a MTD report and understand the specific set of Filing Rules to apply, e.g. the default target document in UKSEF is set as ESEF. This extra ‘application’ level, over and above the standard XBRL processing, increases development effort and hence costs for software vendors. This is the second part of my view that the data collection authority is simply deferring the cost.

XBRL Taxonomy Design Guidelines

The XBRL International (XII) best practices group provides a wide range of materials for users to learn from the past 20 years of implementing XBRL. It is a rich knowledge trove of how to implement XBRL systems.

However, the taxonomy design working group article on MTDs makes a number of claims that raised issues for the practitioners that I spoke to, and I believe are worth highlighting. (Note: the people I spoke to are not a scientific random sample that represents the XBRL community).

The article can be found here. It is a draft article for review and comment on, and I am told it will be updated soon.

The first two claims in the WG article concern differing consumers of the data:

• The article claims that the lack of multiple target documents may prove ‘burdensome’ for data collectors with several consumer groups interested only in certain parts of the report. Whereas the practitioners, that I spoke to, feel that having two XBRL target documents (instances) to process is additional work, i.e., you require two independent validation processes, and you cannot run XBRL Formulas across instances generated by different taxonomies today, so you cannot ensure consistency between the two data sets. The only reason that you would not need to run these checks is if the two datasets were totally independent. In which case why not have two separate reports.
• The second is that it may be difficult to distinguish relevant content and ignore data which is not relevant to a given consumer in a single combined entry-point taxonomy. In my own experience this is not true as most such taxonomies deploy the common practice of using different namespace prefixes like “ifrs-all” and “esrs” for concepts from the different taxonomies, so a User can distinguish and filter the facts they are interested at this level if they want.

If the models are not truly independent then my assumption is that users would probably want to look at the combined dataset, e.g., say a User wanted to compare different IFRS accounting facts from multiple company reports to generate a benchmark and maybe wanted to use the UK company and sector identifier and not the ESEF equivalents, then they each user would have to combine the data and models from the two target XBRL documents themselves.

So, if the above is correct, then the key claim for adopting an MTD approach is that it enables firms to use the same report for different authorities. Is that true?

• In the UK FRC Reporting guide, it suggests that a UKSEF document will contain the data that would have resulted from a pure ESEF submission. Hence, “If a consuming system (e.g. an EU regulator) is not interested in the UK-specific information then the “UKFRS” target document can be ignored and discarded,” i.e. the assumption is that the target XBRL documents are independent.
• In XBRL this is true, but ESEF is an ‘Open Reporting’ framework where companies can include their own extensions, and ESEF applications may be confused by the “UKFRS” tags and documents will fall foul of the ESEF Filing Rules, which requires tags to be anchored to an ESEF concept.
• So, any XBRL application software would need to know that it is processing UKSEF document and adjust the filing rules appropriately, i.e., they cannot be Reporting Framework agnostic.
• The practical implication is that a “UKSEF” report will probably be invalid when submitted in non-UK jurisdictions and the recommendation in the UK SEF Reporting Guide is that “companies should seek advice on this from the relevant National Competent Authorities (NCAs) for those jurisdictions” is very wise.

Dual reporting is a big issue for multinational companies, e.g., reporting annual accounts in IFRS to the US SEC (20-F) and in Europe for ESMA’s ESEF. Today these are vastly different reporting frameworks from both an XBRL taxonomy architecture point of view and in terms of Filing Rules. It is not easy to see how companies can be helped, per the UKSEF example above, other than at a minimum tag level. However, I do not see how MTDs would help this situation at all. I believe this will only come from harmonisation and standardisation of digital reporting across regulators, which unfortunately still appears to be very far off.

Modern reporting frameworks that cover multiple topic areas, such as the Dutch SBR, publish a single taxonomy set and use multiple entrypoints to manage the different reporting requirements — annual returns, tax returns, statistics, plus various sectoral reports, e.g. health, education, and farming, based on a common data dictionary. I would label this the ‘Lego brick’ approach. This follows a common data modelling methodology where you build a core data dictionary with common concepts used across the different reporting requirements and then add ‘extensions’ for the specific area reporting requirements. An XBRL taxonomy designer would then create specific entrypoints for each major report. There is of course a limit to how many entrypoints one can manage and maintain, but the principle is sound.

Conclusion

The WG article summary does conclude by recommending the single unified entry-point approach:

The XBRL standard is flexible in terms of reporting data defined in multiple taxonomies and offers several mechanisms for that purpose, however, I would simplify the WG article by saying there are two main options (from the four listed):

• Individual taxonomy — as described in the WG paper, the inline XBRL document results in a single target document derived from one Taxonomy. There is a single, consistent data model and the data collected is independently analysed by the users.
• Multiple taxonomy references — the inline XBRL report includes references to multiple taxonomies and provides a single target XBRL document. This approach also enables the use of multiple entry-points for different ‘focus areas,’ e.g. industry sectors, to help issuers of the reports or an analyst focussed on a specific area (the “Lego brick’ approach).

The WG article summarises the benefits of single unified entrypoint for the data collection authority as the ownership and control over the complete taxonomy, i.e., it can decide to update to new versions of the underlying referenced taxonomies when it wants, e.g., ESMA can decide which version of the IFRS reference taxonomy it includes in the ESEF taxonomy, it can resolve issues like different context containers in the way it wants to, etc. In fact, as XBRL evolves the latter model becomes more the norm. Global bodies, such as XII and Eurofiling are publishing standardised taxonomies (‘bricks’) to add into a target taxonomy, e.g. XII taxonomy for global ISO codes.

The result is a unified data model, including a common dictionary and semantic relationships. This approach is in common with other developments in data modelling and data technology. The next upgrade to the XBRL specifications is called the Open Information Model (OIM), which aims to simplify the standard, e.g. remove the different context containers and to enable taxonomies and enable instance documents to be expressed in different formats. I believe it should also take account of this trend towards unified data modelling in XBRL.

For the UK FRC the recommendation from the above is clear to me, the UK should take ownership and use a unified single entry-point for the multiple taxonomies that need to be combined, resolving any technical and architectural issues between them. The IFRS reference taxonomy, maintained by the IASB, is the perfect base taxonomy for consolidated financial accounts as it will help comparison and multinational companies to report to multiple jurisdictions in the future. However, there is no need for the UK FCA to adopt the full ESEF set of Filing Rules and mandatory items which is very much based on the European Single Market Authority’s (ESMA) requirements.

In addition, creating a core UK reporting module to harmonise metadata on the report itself for the UK FCA and the UK Companies House would make sense for other future UK Taxonomies. Today, Companies House recognise companies via their UK registered number and have organised all their systems around this and the Balance Sheet Date. Without the individual accounts of the parent, registered at Companies House, embedded in the consolidated accounts there is no “peg” to hang a set of group accounts on. (Note, I am told that it is quite common to see group accounts filed on paper that has the CRN of the parent company hand-written on the front page of the paper scan — not exactly digital reporting). A core taxonomy including identification and support information metadata would resolve such issues.

One general observation, harking back to an earlier article, is that I see much of the confusion coming from a document approach vs a data model first approach. The first creates the view that I have a document, and these two systems need different data or identifiers, so why not employ two taxonomies. The second approach, and of course, my favoured one, says we need to collect this data so let’s build a Taxonomy which collects this dataset for these set of stakeholders.

So, it may be true that somewhere out in the world, both technical and governance related items may prevent the unification of taxonomies. In these cases, the multiple target document (MTD) approach could be an alternative, but I have yet to find one.

The author is Martin DeVille of AM2 Limited

This article was originally published on Medium.com as part of the Digital Reporting Made Simple publication.