The content on this page has been converted from PDF to HTML format using an artificial intelligence (AI) tool as part of our ongoing efforts to improve accessibility and usability of our publications. Note:
- No human verification has been conducted of the converted content.
- While we strive for accuracy errors or omissions may exist.
- This content is provided for informational purposes only and should not be relied upon as a definitive or authoritative source.
- For the official and verified version of the publication, refer to the original PDF document.
If you identify any inaccuracies or have concerns about the content, please contact us at [email protected].
Structured Reporting: ESEF 2021
This report
This report has been prepared by the Financial Reporting Lab (Lab). This report assumes the reader has some understanding of XBRL (eXtensible Business Reporting Language). Those who are not familiar with XBRL may wish to review the XBRL glossary and background information at https://www.xbrl.org/the-standard/.
The appendix to this report includes an explanation of the UK requirements based on information available as at 12 October 2021. For the latest information and requirements for the UK market, please refer to the FCA website.
The report highlights aspects of some entities' reporting, but this should not be considered an evaluation of an entity's annual report as a whole.
If you have any feedback, or would like to get in touch with the Lab, please email us at: [email protected].
Quick read
Beginning the digital journey
For financial years starting on or after 1 January 2021, companies admitted to trading on UK regulated markets are required to start producing their annual financial reports in a structured electronic format ('structured report'). The FCA introduced this requirement (DTR 4.1.14) as part of the UK implementation of a cross-EU initiative known as the 'European Single Electronic Format' or 'ESEF'. Only the format of the Annual Financial Report will change – other obligations relating to the Annual Financial Report are not affected (see the appendix for further explanation of the requirements).
Aim of this report
This report from the Lab aims to support companies in their implementation of the requirements.
The Lab has looked at fifty early structured reports from across the UK and Europe. These reports were either voluntary filings or originated from EU countries where the requirements have already come into force. This report sets out the findings of our review and highlights some key considerations for companies.
Opportunities and challenges
As a result of the ESEF initiative, electronic data for thousands of companies across the UK and EU will become available for automated extraction, analysis and comparison. Ultimately, the availability of the data should make capital markets more efficient.
However, the data will only be useful if it is of high quality and subject to appropriate review.
In addition, these changes come with the potential for significant disruption. The corporate reporting process is highly controlled, time sensitive and involves multiple internal and external parties. Any changes to this process need serious consideration and attention from companies and boards. However, our recent survey showed that only 29% of company respondents had run a test and less than 20% had engaged their board.
Our key messages are:
- The majority of reports across the sample fell short of the quality that is expected for companies' official filings. More than 70% of the files contained tagging errors, more than half had issues limiting their usability and more than 25% had design issues.
- Although many issues were identified during the review, almost all issues could be solved with appropriate care and attention. A focus on quality by companies is crucial for a successful roll-out of structured reporting.
- The Lab identified practice tips across three broad areas: process, usability & appearance and tagging. Key tips for companies are summarised on the next page.
- Companies should be aware that the issues identified are clearly visible to users and, therefore, may negatively affect a company's reputation and the willingness of stakeholders to use digital information.
The rest of the report explores our findings on process, usability & appearance and tagging in more detail. Page 12 sets out some important questions for companies and boards to consider.
Diagram: Key Areas of Structured Reporting
A circular diagram divided into three segments, representing: * Tagging * Process * Usability & appearance
A central icon represents "Usability & appearance", with an arrow pointing to "Tagging" and another to "Process".
Quick read – Key issues and practice tips for companies
Companies will need to devote sufficient management and operational resource to ensure that they will be able to submit their annual financial reports in the required format, and in accordance with the required timeline.
Below, the Lab has set out some key tips for companies, which are explained further in this report:
Process
Companies should:
- understand the requirements and get the right teams involved.
- in choosing their approach, consider factors such as the impact on their timetable, desired level of company involvement, design and outsourcing risks.
- consider whether to tag information voluntarily, such as sustainability-related information.
- test, test, test. For example, companies can test their approach using a prior-year annual report.
- set up a robust governance process. It is helpful if companies provide disclosures explaining their approach to governance of the structured report and whether it was subject to audit or assurance.
Usability & appearance
Companies should:
- devote care and attention to their structured report as it becomes the official version of the annual report under jurisdictional transparency rules.
- make sure the structured report includes all the components of an annual financial report.
- minimise the time lag between their results announcement and the publication of the official (structured) report, to enhance the value of the report and its structured data to users.
- consider making the structured report available on their website with an Inline XBRL viewer.
- avoid specific non-standard formatting if they intend to create their structured report by converting a PDF into XHTML.
- test and review the report output – it is unlikely that the conversion from PDF to XHTML will be perfect right away.
Tagging
Companies should:
- make sure the tags they use correctly reflect the accounting meaning of the reported information and reflect the judgements made in preparing the human-readable report.
- avoid unnecessary extensions.
- be aware that producing a structured report introduces a risk of new types of errors. Plan a review process and look out for common issues such as wrong signs (+ or -) and calculation inconsistencies.
Process
Context
The corporate reporting process is a challenging one – deadlines are tight and processes have been honed over many years to deliver high-quality reporting and communication. Therefore, the introduction of a new format that replaces the traditional PDF-based annual report has the potential to be disruptive.
Our discussions with companies and other stakeholders have shown us that spending time on setting up the structured reporting process is highly valuable – key stages are summarised below. Our recent survey found that companies still have some important actions outstanding.
1. Understand the requirements and get the right teams involved
Companies should spend time to understand the specific impact of the requirements on their business, which depends on their structure and reporting jurisdictions (see appendix). Because the XHTML formatting affects the whole annual report, it is not just the finance team that needs to be involved - the annual report team and company secretary should also get on board.
2. Pick an approach (and service provider)
Companies should choose the approach that works best for them, considering factors such as timing and workflow and the desired level of company involvement and level of design, as explained in the table. Our survey found that 64% of company respondents had taken steps to identify service providers. XBRL International provides a list of XBRL Certified Software and XBRL Europe maintains a list of ESEF tools.
Timing and workflow
Understanding the timeline impact of different product offerings is key:
- Bolt-on: Some solutions are applied at the end of the usual reporting process (bolt-on). The tagging can only be applied when the report content is finalised, extending the overall reporting timeline. Fitting such an approach into a company's review and governance process may be challenging.
- Parallel: Other products are integrated with disclosure management and design tools, allowing the tagging to be applied in parallel to the finalisation of the accounts and design process. They are often more expensive, but also offer enhanced collaboration, automation and control throughout the entire reporting process.
Company involvement
- In-house
- Outsourced
Companies are likely to seek support from a third party in the preparation of their structured reports. Specialised providers can bring technical expertise and have the resources to keep up to date with the latest changes in the taxonomies, technical requirements and best practices.
However, the responsibility to meet the overall regulatory requirements remains with the company itself. In particular, companies need to prepare, or thoroughly review, the mapping of their accounts to the taxonomy. This aspect cannot be fully outsourced because it requires judgement and in-depth knowledge about the reported information. Companies should also consider specific outsourcing and supplier risks (see next page).
Design
- Compliance-based
- Adapted
- Full design
In our review, we found that most companies had chosen to produce a structured report in addition to, rather than as a replacement of, a PDF report. We identified three broad design approaches to structured reports:
- Compliance-based design – a very basic Word-style document with mainly plain text.
- Adapted design – a simplified version of the full-design PDF, adapted for limitations of tagging software.
- Full design - no compromises on design compared to the PDF.
A more advanced design increases the communication value of a structured report, but will be more expensive to produce and may be prone to formatting issues (see page 7). As processes and technology mature over time, companies may seek to move to a fully designed structured report that replaces their PDF report.
3. Consider whether to tag information voluntarily
Companies should consider whether they want to apply any tags voluntarily beyond the minimum requirements, particularly in areas of investor and regulatory interest such as:
- ESG disclosures (if permitted by the local regulator), such as Task Force on Climate-Related Financial Disclosures (TCFD) reporting. In future, it is likely that the scope of required tagging will expand beyond financial reporting. In our survey, many companies expressed an interest in tagging such information.
- key numbers that appear in the notes, rather than in the primary financial statements.
4. Test, Test, Test
Preparing a structured report is not a simple process and is likely to raise issues both in terms of design and tagging. Companies should test their approach beforehand to reduce delivery risk. Nevertheless, our survey showed that only 29% of companies had run a test.
Companies should consider:
- testing their approach using a prior-year annual report in this first year of implementation;
- preparing the mapping of their accounts to the taxonomy before the year-end; and
- running validation checks in their software or in testing facilities provided by regulators.
5. Set up a robust governance process
Although the structured report (theoretically) comes after the traditional paper-based sign-off of the annual report, it should go through robust board-level review. However, our survey showed that, so far, fewer than 20% of companies had engaged their board in the process of preparing their structured report.
Companies should make sure that the board has sufficient understanding of the process and sufficient time and resource to provide relevant and robust governance over the process. Companies may want to focus governance and review on areas where judgement was involved in the selection of tags and in creating extensions.
In the UK, where audit of the tagging is not currently required (see page 14), boards should also consider whether to seek internal or external assurance to provide comfort that they have fulfilled their responsibilities.
For many of the reports we reviewed, it was not clear whether the tagging had been subject to mandatory or voluntary audit or assurance. When such information was provided, it was described in different ways and in different locations. This variability is confusing for users. The filing repositories we used in our review did not indicate whether filings had been subject to audit or assurance.
It is helpful if companies provide disclosures explaining their approach to governance of the structured report and whether it was subject to audit or assurance.
PJSC Polyus Annual Report 2020, page 59
What is useful?
The company describes the audit committee's work around the structured report.
The Committee paid special attention to the preparation of PJSC Polyus' consolidated financial statements in digital form under the European Single Electronic Format regulatory technical standard ('ESEF RTS'). This report was prepared for the first time and the Committee additionally ensured that all necessary procedures had been completed, including the involvement of a qualified IT provider in the preparation of the report and necessary assurance procedures by an external auditor.
Outsourcing and supplier risks
Companies need to consider:
- the ability of the provider to deliver on time and to the specified quality. In particular, companies should consider provider capacity, given that a provider is likely to be supplying services to other companies within the same short space of time.
- the processes and controls that the provider has in place. Key considerations are the data and security controls of the provider and the location of any team working on the structured report, given its market-sensitive nature.
- contingencies in the continued disruption that may be caused by COVID-19 or other factors.
- their own monitoring processes.
Usability & appearance
Context
The annual report is seen by many companies as a central element of their communications to shareholders, employees and other stakeholders. Companies traditionally spend significant amounts of time, attention and resources on ensuring that communication is well-designed and accurate.
Companies should devote the same level of care and attention to their structured report as it becomes the official version of the annual report under jurisdictional transparency rules. However, our review identified a number of issues within the public files that negatively affect their usability, appearance and overall perceptions of quality.
Completeness
All companies in scope of the requirements must prepare their annual financial reports in XHTML. DTR 4.1.5 specifies that an annual financial report must include:
- the audited financial statements;
- a management report; and
- responsibility statements.
However, some companies submitted XHTML files that did not include all components of an annual financial report - for example, they only included the financial statements. Although most UK companies provide all components in a single document, this may not be the case for some dual-listed companies. Such companies may need to combine the content of multiple documents into a single filing to satisfy the requirements.
Timing
Some of the structured reports we reviewed were only made available a number of days or weeks after a PDF version of the annual report was released, which in turn was released a number of weeks after the company's results announcement. While a company's publication timetable depends on its specific circumstances, reducing the time lag between the results announcement and the official (structured) annual report is likely to enhance the value of the report and its structured data to investors and other users.
Package structure
Many files we reviewed had package errors – that is, the zip package did not follow the required naming and structure conventions. Package errors can make structured reports unreadable for software tools. A list of tagging software that has been certified to produce correct taxonomy packages can be found on software.xbrl.org.
Website accessibility
Many of the files we reviewed were not available on the company's own website or were not placed alongside the traditional PDF. This creates confusion for users over the status of the structured report and the PDF.
It is helpful if the structured report is made available and displayed prominently. Companies could also provide some explanation on their website or in their reports about the different reporting formats, their status and how to use them.
Formatting issues
- Fonts and symbols – Many companies use specialised or custom fonts within their annual reports, either for the main text or for special characters (like dashes) or symbols (such as arrows). These fonts sometimes create issues when translated into XHTML. Issues included text that disappeared, was hidden or appeared as white text. We also found some reports in which characters were replaced with incorrect alternative characters, either in the human-readable report or in the tag.
- Layered images – We have noticed that complex layered images do not always display correctly in XHTML. It is also worth noting that the ESEF manual provides some guidance on the permitted size and structure of images.
- Heat maps and graphs – Companies often use heat maps and graphs to add additional insight into a topic. However, often these did not work well within the XHTML files either because they were pasted poorly as images or, if adapted to fit the limitations of the tools used, lost their impact.
Many of these issues result from structured reports being based on PDFs that are not designed with XHTML conversion in mind. Companies consider:
- spending time to adapt or simplify their design upfront; or
- building in sufficient review and remediation time to ensure their structured reports display as expected across a range of viewers.
Inline XBRL viewers
Those companies that did provide the structured report on their website often only did so as a download of the zip file sent to their national storage mechanism. Whilst this is useful, it means that:
- users need to download a large zip file, which may cause some concerns around viruses, file size or other restrictions.
- to access the full content of the report, a user would need a specialised tool. Large investors may have such tools, but smaller investors or other stakeholders may not.
Therefore, companies are encouraged to provide on their website a version of their structured report with an Inline XBRL viewer, in addition to the zip file. A viewer is a tool that allows Inline XBRL reports to be viewed interactively in a web browser, displaying both the human-readable layer and the tags. The example on the right explains some viewer functionalities.
We also noticed that files did not always display in a uniform way across viewers - companies should consider testing their structured report in a range of viewers. Note that national storage mechanisms generally do not accept files with embedded viewers.
JDE PEET's Annual Report 2020
What is useful?
JDE PEET'S annual report is available in the traditional PDF format but also as an XBRL download (i.e. the official file) and in an Inline XBRL viewer. Each version is prominently displayed on its website.
This image shows the JDE PEET's N.V. Annual Report 2020 title with options to view as PDF, download PDF, view XBRL, or download XBRL.
Consolidated Income Statement in Inline Viewer
This screenshot displays an inline viewer showing a consolidated income statement. On the right, a "Fact Properties" panel is open, detailing "Cost of sales" with a value of €3,818,000,000 and other XBRL properties.
JDE PEET'S has opted for a full design approach with no loss of visual impact between the PDF and XBRL versions.
Most viewers allow a user to highlight all facts that have been tagged. Some viewers highlight extensions (see page 9) in a different colour.
Viewers generally allow a user to click on tagged facts to open up a pane with information about the applied tag.
Viewers generally allow a user to search for a specific tag and navigate to where the tag has been applied in the document.
Click here to open the Inline XBRL viewer version of this report and try out these features.
We also liked
- Signify who noted in their press release that the ESEF version was available and marked it as the official version on their website.
- Experian who have provided both a viewer and zip package version on their website and explained the voluntary nature of this year's structured report.
Many other examples of structured reports are available on filings.xbrl.org.
Tagging
Context
We observed some tagging errors in our review. Low-quality data undermines the benefits of structured reporting. Companies should thoroughly review their reports before submission and look out for common issues.
Choosing the right tag
When tagging a piece of information, companies should first look for a suitable tag in the core taxonomy (see page 10). Tagging is not a 'label-matching' exercise. What is important is that the accounting meaning of the tags used corresponds to the reported information. Therefore, tagging requires a good understanding of:
- the reported information – and which requirements in IFRS Standards the information meets. For this reason, a company's finance team should be highly involved in the tag selection and review; and
- the accounting meaning of the tags in the core taxonomy – carefully consider the definition (i.e. the 'documentation label') of a tag, its references to the related requirements in IFRS Standards and any additional guidance labels.
For example, some companies use the term 'provisions' in their human-readable report to mean provisions excluding those related to employee benefits, such as pension liabilities. If a company did a simple label search, they might apply the 'Provisions' tag to such amounts. However, the IFRS taxonomy tag 'Provisions' is defined as 'The amount of liabilities of uncertain timing or amount, including provisions for employee benefits. Such companies should instead apply the IFRS taxonomy tag 'Other provisions', which is defined as 'The amount of provisions other than provisions for employee benefits'.
| Non-current liabilities | £ |
|---|---|
| Non-current provisions | 231 |
| Net defined benefit liability | 459 |
☑ IFRS: Other non-current provisions ❌ IFRS: Non-current provisions
We note that, in preparing the human-readable financial statements, the company, its board and auditors have already considered that the reported information complies with the presentation and disclosure requirements of IFRS Standards. The tags used should reflect the same judgements, rather than making new ones.
Creating extensions
When no suitable tag is found in the core taxonomy, companies should create custom tags or 'extensions'. Extensions allow companies to tag entity-specific information. Extensions are much more difficult for users to analyse and compare than tags from the core taxonomy. Therefore, extensions should only be used when necessary.
In our review, we have seen some cases of companies creating unnecessary extensions. For example, one company created an extension for a line item in the balance sheet labelled 'Prepaid income taxes, current'. However, a suitable core taxonomy element exists: 'Current tax assets, current'. The tag label is different from the label the company used for its line item, but it has the same accounting meaning, which is what matters. Creating an extension in this case would complicate a users' understanding of the information, rather than enhancing it.
| Current assets | £ |
|---|---|
| Prepaid income taxes, current | 350 |
☑ IFRS: Current tax assets, current ❌ Extension: Prepaid income taxes, current
On the other hand, companies should not try to 'shoehorn' all of their disclosures into core taxonomy tags to avoid extensions at all costs. Applying IFRS Standards, companies are expected to disclose material entity-specific information. For example, companies may further disaggregate required line items in the primary financial statements or provide industry-specific disclosures. The required ‘anchoring' of extensions to the closest core taxonomy element(s) helps users to analyse extensions.
We have generally seen many legitimate extensions in the cash flow statement and the statement of changes in equity, where companies are more likely to report entity-specific items or the core taxonomy may not yet reflect common reporting practice.
Using the correct sign
Using the correct sign for a tag is important - income being reported as an expense or vice versa would be misleading. However, we found some sign errors in our review, especially in the statement of cash flows. Mistakes are easily made because the sign used to tag is not necessarily the same as in the human-readable report.
Generally, tags are expected to be reported with a positive value. Their debit or credit nature is captured in the definition of the tag. However, there are some tags that can have a positive or negative value, such as 'foreign exchange gain (loss)'. Such tags normally use brackets to indicate where a negative value should be used in the XBRL filing (e.g. '(loss)').
| Statement of profit or loss | £ |
|---|---|
| Revenue | 800 |
| Cost of sales | (350) |
| Foreign exchange gain (loss) | (50) |
In the example above:
- Revenue and cost of sales follow the general rule that tags should be reported with a positive value (despite the brackets used in the human-readable report for cost of sales).
- The foreign exchange loss should be marked up with the tag 'foreign exchange gain (loss)' with a negative value, because it is a loss.
Automatic validations exist that raise a warning when a reported value does not have the expected sign (see page 11).
Selecting the right core taxonomy
Companies should make sure they are using the most appropriate core taxonomy. The FCA specifies a list of permitted core taxonomies for reporting. In September 2021, the FCA put out a consultation proposing to permit companies to use both the ESEF and the UKSEF taxonomy for filing to the National Storage Mechanism.
The FCA's list is expected to change each year, as taxonomies are updated for changes in IFRS Standards, new tags for information that is commonly reported but for which no tag previously existed and other improvements.
If companies intend to use the most up-to-date taxonomies but initially prepared their mapping to an older version, they may want to have a look at the latest changes (see this IFRS Foundation webinar and slides).
Avoid using concealed facts
Using Inline XBRL, tags are normally attached to a number or piece of text in the human-readable document.
In our review, we noted that some companies have used 'concealed' or 'hidden' facts. This means that those tags are included in the file but are not attached to the related human-readable item. Often, companies have taken this approach to avoid HTML formatting issues or to report information that is not present in the human-readable layer.
However, using hidden tags should be avoided. It is not in line with the spirit of the regulatory requirement and the Inline XBRL specification. Some features of viewer software (see page 8) will not work for hidden tags, because those features rely on the link between the tag and the human-readable layer.
What is UKSEF?
The UKSEF taxonomy includes the ESEF Taxonomy (which, in turn, is based on the IFRS Taxonomy) and can be used with any other tag in the FRC taxonomies suite, including:
- tags for voluntary tagging of Streamlined Energy and Carbon Reporting (SECR), Task Force on Climate-Related Financial Disclosures (TCFD) reporting and Gender Pay Gap reporting; and
- tags required for companies that choose to submit their structured reports to satisfy the Companies Act obligations (e.g. UK Company Registration Number) – see page 13.
| Statement of profit or loss | £ |
|---|---|
| Revenue | 800 |
| Cost of sales | (350) |
| Administrative expenses | (150) |
Where 'hidden' or 'concealed' tags are used, the tag is not attached to the human-readable layer.
Validations
The UK National Storage Mechanism runs some automated checks on filings on submission, as do many tagging software tools. Such checks may flag:
- Errors - these must be resolved before the filing can be submitted. For example, a company will get an error message if they have not provided their Legal Entity Identifier.
- Warnings – these indicate that there is something about the file that is unexpected, but that is not necessarily an error. Warnings should be investigated but not all warnings must be resolved. For example, 'Explanation of change in name of reporting entity ...' is a mandatory tag and the absence of the tag will be flagged as a warning. However, if a company did not change its name in the period, the tag is not applicable and should not be used. We have seen cases where companies have tried to circumvent the warning by tagging wording such as 'not applicable' with this tag in another, unrelated disclosure.
- Calculation inconsistencies - these indicate that some of the numbers do not add up. Calculation inconsistencies do not make the report invalid but should be investigated. Such inconsistencies may indicate tagging errors such as wrong signs or missing tags, but are often due to rounding. While companies may historically have been comfortable with numbers not adding up due to rounding, they should be aware that automatic checks on structured reports make such inconsistencies more prominent.
Note that a file that passes all validations is not necessarily free from error. There are some errors, such as unnecessary extensions, that cannot be picked up by automated checks.
Other tagging issues
- Ensure that tags do not provide more information than the human-readable report – for example we found one filing where in the human-readable report the company described a line item as 'purchase of subsidiaries', for which they created an extension labelled 'purchase of subsidiary X and Y in Country Z'. Such detailed labels should only be used if the information was available elsewhere in the financial statements (for example in the notes). A similar principle applies to narrower anchors that provide more detailed information.
- Apply double tagging when necessary a single number or piece of text should be marked up with more than one tag if it corresponds to more than one accounting concept ('double tagging'). For example, when companies report a single value that represents both basic and diluted earnings per share, the value should be tagged twice as both 'Basic earnings (loss) per share' and 'Diluted earnings (loss) per share'.*
| Statement of profit or loss | £ |
|---|---|
| Profit (loss) for the year | 852 |
| Basic and diluted EPS | 1.25 |
- Tag multiple occurrences of the same fact consistently ('duplicate facts') – for example, profit before tax is often reported in the statement of profit or loss as well as in the statement of cash flows (as the starting point). Both occurrences of the same value should be tagged with 'Profit (loss) before tax'. We have seen cases where companies have created unnecessary extensions to tag duplicate facts.
- Avoid changing the labels of core taxonomy tags – we have seen cases where companies have amended the core taxonomy tag labels to match the wording used in the human-readable layer. However, this is unnecessary and can be confusing for users of the report.
- Tag zeros and tag dashes that represent zero – we have seen many zeros and dashes with a meaning of zero that were not tagged. Inline XBRL has a mechanism to allow such tagging.
- Tag any additional columns in the statement of profit or loss – companies are required to tag all monetary amounts in the primary financial statements. When companies present additional columns to disaggregate their income and expenses, it is helpful if those are also tagged, preferably with an extension dimension.
Also see:
- XBRL International's series of articles on common tagging errors and how to avoid them. They cover additional issues such as incorrect dates.
- The IFRS Taxonomy Preparer's Guide, which provides further guidance on topics such as how to find the correct tag.
*This approach to tagging basic and diluted EPS is introduced in the 2021 IFRS Taxonomy.
Key questions for companies and boards and next steps
Key questions for companies and their boards
As they are preparing to apply the requirements, companies should ask themselves:
Implementation process
- Who is leading the project internally? Are extra training or resources needed?
- Will the structured report be prepared in-house or will it be outsourced?
- If using an external supplier, have the relevant risks been mitigated (see page 6)?
- What is the impact on the timetable for the production of the annual report?
- How much work can be done before year-end or in parallel to the reporting process?
- Has sufficient time for testing and remediation been built into the timetable?
- Until what point in the process can changes be made to the content of the report?
Usability and appearance
- Will the structured report be prepared in addition to, or instead of, the traditional annual report in PDF?
- Will the structured report be displayed on the company website, with an Inline XBRL viewer?
- Is there any risk of inconsistency between the PDF and the structured report in XHTML? If so, has this risk been mitigated?
Governance
- Who in the organisation has governance over the preparation of the report, is digital different from paper?
- Who will provide governance over the tagging decisions? Will it be the audit committee?
- Should extra board or committee meetings be scheduled to plan the approach and approve the tagging?
- At what point will governance happen, before year-end? Or once the tagging is complete?
- What does governance and review of tagging look like? Should judgement in tag selection and the creation of extensions be signed off?
- Will the tagging be compared to peers' tagging as part of the review?
- If the tagging is not subject to mandatory audit or assurance, will internal or external voluntary assurance be sought?
Next steps for the Lab
Supporting high-quality filings
The Lab intends to continue supporting companies in their implementation of the requirements, helping them to produce high-quality filings:
- we will work together with the FCA to monitor the quality and usability of filings during the first year of mandatory adoption;
- we may produce further guidance if necessary; and
- we are planning to host a webinar later this year for companies and service providers.
Opportunities for using the data
Ultimately, the requirements aim to improve the accessibility, analysis and comparability of the information for investors and other users. However, we have heard that companies see structured reporting as a compliance exercise and cannot see any evidence of the benefits.
We plan to do further work to better understand:
- how investors and other stakeholders are using or may use the data;
- what tools are available to analyse the data; and
- what challenges investors and other stakeholders face in using the data (for example, timeliness) and how those could be resolved.
Appendix: UK requirements
Who?
The requirements apply to issuers with transferable securities admitted to trading on UK regulated markets. In the UK there are six regulated markets. The main regulated market in the UK is the LSE Main Market. AIM is not a regulated market under the definition.
What? (also see flow chart on the next page)
- All in-scope issuers are required to publish their Annual Financial Reports in XHTML, replacing the current PDF format. XHTML is a human-readable format that looks like a web page and can be opened with any standard web browser.
- In-scope issuers who prepare consolidated financial statements in accordance with IFRS Standards (i.e. most companies) are also required to mark up those financial statements using tags from a permitted core taxonomy.
- In-scope issuers who only prepare individual financial statements, for example many investment companies, are only required to prepare their annual financial reports in XHTML (without tags).
- Reports must be filed with the FCA's National Storage Mechanism (NSM).
- Only the format of the Annual Financial Report will change – other obligations relating to the Annual Financial Report are not affected.
When?
Implementation was initially planned for 2020 reports but was delayed due to COVID-19. The time table is now as follows:
2021 Voluntary filing for financial years starting on or after 1 January 2020
2022 Mandatory filing for financial years starting on or after 1 January 2021 – detailed tagging of primary financial statements and specified mandatory tags only
2023 Mandatory filing for financial years starting on or after 1 January 2022 – detailed tagging of primary financial statements and specified mandatory tags + block tagging of the notes
UK legal framework
In the UK, requirements for companies to prepare an annual report arise from both the Securities Regulation – the Disclosure Guidance and Transparency Rules (DTR) and the Listing Rules – and the Companies Act.
The XHTML structured reports become the official Annual Financial Report for the purpose of the Securities Regulation and must be filed with the FCA's National Storage Mechanism.
A company can also send its XHTML structured report to Companies House to satisfy the Companies Act requirements. However, a company can only do so if it includes some specific additional tags, such as the UK Company Registration Number and Balance Sheet Date (see the guides available on the FRC's taxonomy page for further information about UK-specific taxonomies including UKSEF).
| Securities Regulation | Companies Act 2006 |
|---|---|
| DTR 4 Annual financial report | Part 15 Accounts and reports |
| Must be filed with the FCA's National Storage Mechanism, within four months after the end of the reporting period. | Must be sent to Companies House (as the registrar) after approval by the AGM, within six1 months after the end of the reporting period |
| XHTML format. Although a PDF can be produced, the DTR requirements are only met by filing the XHTML format. | Silent on format of the report but requires the accounts to be made available on paper if requested by a shareholder. |
Summary of UK requirements
Flowchart: Summary of UK requirements for structured reporting
This flowchart illustrates the decision process for UK structured reporting.
- Start
- Is the company admitted to trading on a UK regulated market?
- No → No requirements under DTR 4.1.14 – consider other relevant UK/EU regulations.
- Yes ↓
- Does the company's annual financial report contain IFRS consolidated financial statements?
- No → Submit an Annual Financial Report in XHTML format to the National Storage Mechanism within four months after year-end.
- Yes (most companies) ↓
- Tag the IFRS consolidated financial statements and submit the Annual Financial Report in XHTML format to the National Storage Mechanism within four months after year-end.
- Does the company also want to use the XHTML accounts to satisfy its Companies House filing obligations?
- No → Send the printed PDF report that was approved at the AGM to Companies House as normal (within six months after year-end).
- Yes ↓
- Prepare the structured report with the extra mandatory tags and send it to Companies House after the accounts have been approved at the AGM (within six months after year-end).
Directors' sign-off and audit
In 2020 BEIS confirmed that the directors' sign off on the true and fair nature of the accounts stem from the Companies Act and therefore do not include any tagging.
Therefore, any assurance provided by a company's auditor on the tagging would be done on a voluntary basis and under a separate engagement. The FRC has adopted ISAE (UK) 3000 to support the delivery of such engagements.
Companies admitted to trading on a regulated market in the UK and in another jurisdiction
Such companies' requirements will depend on their listing venues and structure. They should consult relevant regulators to determine the exact requirements applicable to them and the taxonomies they are permitted to use. For example, the UKSEF taxonomy may not be accepted for filing in EU member states.
How is the DTR 4.1.14 requirement different from HMRC tagging?
- The DTR 4.1.14 requirement relates to consolidated financial statements, rather than individual financial statements.
- Different taxonomies and software tools are used.
- Extensions are required applying the DTR 4.1.14 requirements for entity-specific information that is not covered by the core taxonomy. Extensions are not allowed for HMRC.
- DTR 4.1.14 filings are public, HMRC filings are not.
- The timelines for submission are different.
Explore more work of the Lab
In September 2021, we published:
- the results of a survey the Lab conducted in May 2021 that asked companies and service providers about their preparations for the introduction of structured electronic reporting.
- a list of resources to help companies understand and implement the requirements.
This image displays an educational resource page titled "DTR 4.1.14 - Structured Reporting Resources for companies". It provides structured information on: * What are the requirements in the UK (with links to FCA, UK government, FRC taxonomy page, ESMA, Accountancy Europe resources). * How to find the right tool or service (with links to XBRL International, XBRL Certified Software, XBRL Europe ESEF tools). * How to produce the file (with links to IFRS Taxonomy Preparer's Guide, Lab blog, XBRL International articles, Filings.xbrl.org, FRC Lab contact for experience sharing). * How to submit the file (with links to FCA guidance).
The FRC does not accept any liability to any party for any loss, damage or costs howsoever arising, whether directly or indirectly, whether in contract, tort or otherwise from any action or decision taken (or not taken) as a result of any person relying on or otherwise using this document or arising from any omission from it.
© The Financial Reporting Council Limited 2021 The Financial Reporting Council Limited is a company limited by guarantee. Registered in England number 2486368. Registered Office: 8th Floor, 125 London Wall, London EC2Y 5AS
Financial Reporting Council 8th Floor 125 London Wall London EC2Y 5AS
+44 (0)20 7492 2300 www.frc.org.uk
Reports and information about the Lab can be found at https://www.frc.org.uk/Lab
Follow us on Twitter @FRCnews or Linked in
Financial Reporting Council
-
For public companies ↩