Companies in the UK have been using Inline XBRL since 2010-11 when HM Revenue & Customs mandated the format for financial statements submitted as part of Corporation Tax filings. In 2020, the European Single Electronic Format (ESEF) mandate came into force in the European Union. Companies in the EU were required to publish their 2020 annual financial reports in the new ESEF iXBRL format. The UK adopted ESEF requirements before December 31, 2020. However, mandatory compliance with ESEF came into force in the UK only with the 2021 annual reports.
Though the UK can be considered a mature iXBRL market due to the HMRC mandate, the ESEF mandate brings in more comprehensive requirements. Companies need to familiarise themselves with the ESEF and UKSEF taxonomies as well as understand how XBRL tagging and xHTML creation works.
This blog covers a few key factors ESEF/UKSEF filers need to consider.
Key Factors To Consider
The UKSEF/ESEF Taxonomy Version To Be Used
The UKSEF taxonomy is the starting point for structured reporting in the UK using the iXBRL format. The UKSEF taxonomy is an extension of the European Single Electronic Format (ESEF) taxonomy that companies in the European Union use for their structured reporting. In other words, the UKSEF taxonomy adds some UK-specific elements to the ESEF taxonomy. It includes elements that belong to the Streamlined Energy and Carbon Reporting (SECR) taxonomy. As of now, UK-listed companies have the option of using the UKSEF as well as ESEF taxonomies to prepare their structured annual reports.
The Financial Reporting Council (FRC) released its 2022 suite of taxonomies in October 2021. The latest taxonomy version that companies may use is UKSEF 2022, version 2.0.0. Companies may also use the ESEF 2020 and UKSEF 2021 taxonomy versions for their current (2021) iXBRL annual reports.
The UKSEF Tagging Process – What To Bear In Mind
The UKSEF iXBRL report that UK-listed companies submit to the FCA’s National Storage Mechanism (NSM) consists of an instance document and a company taxonomy.
An instance document is a company’s annual financial report in the iXBRL format. An iXBRL document is an xHTML or human-readable document with XBRL or machine-readable tags embedded in it. Therefore, a UKSEF annual report becomes human-readable and machine-readable at the same time. Moreover, the human-readable portion of the document, which is the xHTML, retains all the aesthetic features of a PDF annual report.
The company taxonomy is a collection of the UKSEF taxonomy elements that a company has tagged its annual report disclosures or line items with. It also includes the custom elements or extension (XBRL) tags a company might have created to represent disclosures with no matching element in the UKSEF taxonomy. Moreover, the company taxonomy expresses the relationships between all these elements with the help of four linkbases: Presentation linkbase, Calculation linkbase, Definition linkbase, and Label linkbase.
Tagging, Extensions, and Anchoring
Moving on, what does the creation of an instance document entail? There are three main activities involved in instance document creation. They are tagging – or mapping the disclosures in an annual report to the appropriate UKSE taxonomy concept; creation of extensions or custom tags to represent disclosures for which the right fit element cannot be found in the UKSEF taxonomy; and, anchoring, or the act of ‘connecting’ extensions to ESEF taxonomy concepts with the nearest accounting meaning.
How UKSEF Tagging Works
The XBRL tags embedded in an xHTML annual report lend the document its machine readability. The act of tagging, or mapping the line items in an annual report to the right UKSEF taxonomy concepts requires a good understanding of the UKSEF taxonomy. It would also help to know how an XBRL or machine-readable tag looks. Here’s an example:
‘ifrs-full_Revenue’ is the machine-readable tag for revenue. The ‘ifrs’ portion indicates that this is an IFRS tag. ‘ifrs-full_CurrentAssets’ is the IFRS tag for current assets. A machine-readable tag has three attributes – data type, balance type, and period type.
| Element Name | Ifrs-full-Revenue |
| Data Type | monetaryItemtype |
| Balance Type | Credit |
| Period Type | Duration |
The Data Type of a tag explains whether a disclosure represents a monetary value, shares, or percentage. For instance, the data type for the tag ‘ifrs-full_Revenue’ is ‘monetaryItemtype’.
The Balance Type explains if a monetary concept is a ‘debit’ or ‘credit’. For revenue, the balance type would be ‘credit’.
The Period Type explains if the value of disclosures is measured as of a particular date or over a period of time. Balance sheet disclosures have an ‘instant’ period type since they are reported on a particular data. Income statement disclosures, since they are measured over a 12-month period, will have the ‘duration’ period type.
Why Extension Elements Are Created And How They Work
While tagging their annual reports, companies will find that there are no appropriate ESEF taxonomy elements for certain disclosures. Companies may create extension elements or customized XBRL tags to represent such disclosures. However, it is good practice to create extension elements sparingly, since inappropriate use of extension elements might affect the quality of information and make the analysis and comparison of iXBRL reports difficult.
Anchoring Of Extension Elements
We have seen that companies preparing ESEF annual reports need to create extension elements to represent disclosures that do not have corresponding ESEF Taxonomy elements to tag with. Per ESEF tagging guidelines, such extension elements also need to be ‘anchored’ to ESEF Taxonomy elements with the closest accounting meaning possible.
The Company Taxonomy
The company taxonomy represents the ESEF Taxonomy elements used in a company’s ESEF annual reports. It includes both the base ESEF Taxonomy elements as well as the extension or custom elements created. All those elements are represented in the form of four linkbases which are listed out below.
Presentation linkbase: The presentation linkbase represents a company’s annual financial report – as it is presented. Elements in the presentation linkbase need to be represented in the same sequence as they follow in an annual report.
Calculation linkbase: The calculation linkbase represents the arithmetic relationships between the disclosures in an annual report. For example, a calculation such as ‘Revenue – Cost of sales = Gross profit’ in an annual report should be mentioned in the company taxonomy.
Definition linkbase: The definition linkbase, in simple terms, is used to represent anchored relationships as well as dimension and member structures in statements (in a shareholders’ equity statement, for instance). Companies must ensure that their extension elements are anchored to the right fit elements in the ESEF Taxonomy.
Label linkbase: The label linkbase lists out the labels a company uses for line items in its annual report. For instance, a company can use the label ‘sales’ for an item that the ESEF Taxonomy called ‘revenue’. This would have to be mentioned in the label linkbase.
Errors And Pitfalls To Avoid – For A High-quality Report
While UKSEF is intended to help companies produce transparent, high-quality structured reports, the format is no guarantee against mistakes or inconsistencies. In XBRL parlance, these inconsistencies are termed errors and warnings.
Errors are a more serious type of inconsistency because they will not let a UKSEF report go past the FCA’s National Storage Mechanism (NSM). Warnings, meanwhile, are less severe because they will not stop a UKSEF report from being submitted. However, both errors and warnings need to be addressed for a UKSEF report to conform to high standards of quality.
Some common inconsistencies in UKSEF filings are listed below.
Incorrect Signs
Calculation errors are the most common form of errors in XBRL reports. They occur when financial reporting teams assign a positive value to a concept whose XBRL definition factors in a negative value, and vice versa. To avoid calculation errors, one must consider the XBRL definition of a concept and not merely go by the calculation relationship it has with the concepts above and below it.
In the example below, the ‘other revenues’ concept has a positive XBRL definition though it is shown with a negative sign in the report. Ideally, other revenues must be reported as positive.
Inconsistent Duplicates
In an annual report, the same set of disclosures can appear multiple times under different sections of the report. When a specific disclosure is tagged with an XBRL element wherever it appears in the report, one can use an iXBRL viewer to navigate between the various instances. However, such navigation would not be possible if the numbers or values are inconsistent – probably because they were rounded off in a couple of instances. In such a case, it would be difficult for anyone analyzing the report to find the correct value of the disclosure.
In the example below, notice the difference in the values for the concept – ‘Equity’.
Calculation Inconsistencies
Calculation inconsistencies in XBRL reports occur due to incorrect signs or rounding-off errors. They also occur when there is no match between the concepts in a calculation tree and the values they represent in the report. Calculation trees, which are a part of an XBRL taxonomy, express simple arithmetic structures in an XBRL report.
In the example below, the value of ‘income tax expenses’ has been added to ‘profit before tax’, resulting in a calculation inconsistency. For the calculation to be correct, ‘Income tax expenses’ need to be deducted from ‘profit before tax’ to result in ‘profit for the year’.
This inconsistency is a result of the negative sign assigned to the value for ‘Income tax expenses’. The XBRL report preparers have not considered the fact that ‘expense’ is a concept with a negative sign factored into its XBRL definition.
Report Package Errors
A UKSEF filing is submitted to the FCA National Storage Mechanism in the form of a report package. The report package consists of multiple files placed in a well-formatted ZIP file. There is a prescribed structure for arranging files within the report package so that XBRL software can find them. If the files are not arranged according to the prescribed structure, they will not render correctly.
Incorrect Dates
Another common error in XBRL reports is tagging disclosures with the wrong dates. This error occurs due to the different ways in which dates and reporting periods are described. For example, the value of a balance sheet item is reported as on the last date of a financial year – in which case the value indicates a closing balance. However, the same value can also be considered an ‘opening balance’, or the value of an item just before the business opens on the first day of the next financial year.
However, XBRL makes no distinction between an opening and closing balance. The XBRL interpretation for balance or ‘instant’ disclosures is consistent. If a balance on a particular date is reported, it is considered as being the balance at the end of that date. For closing balances, this poses no problem. For opening balances, however, report preparers would do well to use the date of the previous day.
Apart from ‘instant’ facts, there are also facts reported over a duration of time. The XBRL tag for duration facts should include the period opening and closing date as ‘Ist January 2021 to 31st December 2021’.
Redundant Labels
The ESEF Taxonomy is a collection of machine-readable labels assigned to disclosures that match the concept description. ESEF filers need to use labels from the core taxonomy for their disclosures and create new labels for company-specific information for which there is no ready tag in the base taxonomy. However, it has been noticed that ESEF filers redefine tag labels unnecessarily – especially while creating extension elements.
Example –
Rounding and Inconsistent Calculations
We have mentioned that calculation inconsistencies are caused by certain tagged values not satisfying their expected calculation relationship. Sometimes, such inconsistencies also occur due to the rounding off of values. While the rounding-off might make perfect sense, it does not help satisfy a calculation relationship.
Here’s an example.
Example: Rounding up differences
The UKSEF xHTML document – Get The Look Right
Compliance with structured reporting requirements in the UK using the UKSEF taxonomy involves preparing a high-quality xHTML document. An xHTML is a document that has two layers – one displaying a company’s financials for a human reader and the second containing the computer-readable iXBRL tags. Companies need to ensure that not only is their digital annual report free from iXBRL errors but it also appears attractive from a human-readable perspective. This means companies need to take care that both the layers of their report meet the highest quality standards. More so because the xHTML document is one that investors and key stakeholders can access and use for their analysis and decision-making.
Here’s why the quality of an xHTML document needs special mention: When companies in the EU were submitting their early structured reports, some software or service providers were not able to meet quality standards in terms of the xHTML file. The result was as follows.
The image shown below is a PDF document, with a normal display of graphs and charts.
The next image shows an xHTML document where the graphs and charts look elongated.
Companies in the UK need to ensure that the software or service provider who is helping them create UKSEF reports has the capability to produce a good-looking xHTML document.
UKSEF Compliance Approach – In-house Or Outsourcing?
The two main compliance options for any company carrying out structured reporting are outsourcing UKSEF report creation to a service provider or creating the reports in-house. A third model exists, which combines the best of the in-house and outsourcing models.
Outsourcing Model
- The service provider prepares your UKSEF iXBRL report
- Your internal team reviews the UKSEF iXBRL tagging
- Suitable for companies without dedicated reporting teams
In-house Model
- Get an in-house cloud-based software license
- Get in-house teams trained for iXBRL tagging
- Your teams have full control of report creation
Blended Model
- A hybrid model that gives companies the best of outsourcing and in-house models
- You leverage the software provider’s XBRL experts for the 1st year of UKSEF tagging
- In subsequent years, you may have your UKSEF iXBRL tagging done by internal teams
- This approach works best for familiarizing yourself with the process before taking it in-house
Whichever compliance option you choose, make sure you have access to on-tap XBRL expert support.