{"id":79528,"date":"2022-06-03T06:38:51","date_gmt":"2022-06-03T06:38:51","guid":{"rendered":"https:\/\/fin-xsolutions.com\/?p=79528"},"modified":"2022-08-19T11:46:00","modified_gmt":"2022-08-19T11:46:00","slug":"structured-reporting-for-uk-listed-companies-key-factors-to-consider","status":"publish","type":"post","link":"https:\/\/fin-xsolutions.com\/structured-reporting-for-uk-listed-companies-key-factors-to-consider\/","title":{"rendered":"Structured Reporting For UK-Listed Companies \u2013 Key Factors To Consider"},"content":{"rendered":"

[vc_row row_height_percent=”0″ override_padding=”yes” h_padding=”6″ top_padding=”2″ bottom_padding=”1″ overlay_alpha=”50″ gutter_size=”3″ column_width_percent=”100″ shift_y=”0″ z_index=”0″][vc_column][vc_column_text text_lead=”yes” uncode_shortcode_id=”131010″]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.
\nThough 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.
\nThis blog covers a few key factors ESEF\/UKSEF filers need to consider.<\/p>\n

Key Factors To Consider<\/h2>\n

The UKSEF\/ESEF Taxonomy Version To Be Used<\/h3>\n

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.
\nThe Financial Reporting Council (FRC) released its 2022 suite of taxonomies in October 2021<\/a>. The latest taxonomy version that companies may use is UKSEF 2022, version 2.0.0. Companies may also use<\/a> the ESEF 2020 and UKSEF 2021 taxonomy versions for their current (2021) iXBRL annual reports.<\/p>\n

The UKSEF Tagging Process \u2013 What To Bear In Mind<\/h3>\n

The UKSEF iXBRL report that UK-listed companies submit to the FCA\u2019s National Storage Mechanism (NSM) consists of an instance document and a company taxonomy.
\nAn instance document is a company\u2019s 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.
\nThe 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.<\/p>\n

Tagging, Extensions, and Anchoring<\/h3>\n

Moving on, what does the creation of an instance document entail? There are three main activities involved in instance document creation. They are tagging \u2013 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 \u2018connecting\u2019 extensions to ESEF taxonomy concepts with the nearest accounting meaning.<\/p>\n

How UKSEF Tagging Works<\/h3>\n

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\u2019s an example:
\n\u2018ifrs-full_Revenue<\/strong>\u2019 is the machine-readable tag for revenue. The \u2018ifrs\u2019 portion indicates that this is an IFRS tag. \u2018ifrs-full_CurrentAssets<\/strong>\u2019 is the IFRS tag for current assets. A machine-readable tag has three attributes \u2013 data type, balance type, and period type.<\/p>\n\n\n\n\n\n\n
Element Name<\/strong><\/td>\nIfrs-full-Revenue<\/strong><\/td>\n<\/tr>\n
Data Type<\/td>\nmonetaryItemtype<\/td>\n<\/tr>\n
Balance Type<\/td>\nCredit<\/td>\n<\/tr>\n
Period Type<\/td>\nDuration<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The Data Type<\/strong> of a tag explains whether a disclosure represents a monetary value, shares, or percentage. For instance, the data type for the tag \u2018ifrs-full_Revenue\u2019 is \u2018monetaryItemtype\u2019.
\nThe Balance Type<\/strong> explains if a monetary concept is a \u2018debit\u2019 or \u2018credit\u2019. For revenue, the balance type would be \u2018credit\u2019.
\nThe Period Type<\/strong> explains if the value of disclosures is measured as of a particular date or over a period of time. Balance sheet disclosures have an \u2018instant\u2019 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 \u2018duration\u2019 period type.<\/p>\n

Why Extension Elements Are Created And How They Work<\/h3>\n

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.<\/p>\n

Anchoring Of Extension Elements<\/h3>\n

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 \u2018anchored\u2019 to ESEF Taxonomy elements with the closest accounting meaning possible.<\/p>\n

The Company Taxonomy<\/h3>\n

The company taxonomy represents the ESEF Taxonomy elements used in a company\u2019s 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.
\nPresentation linkbase:<\/strong> The presentation linkbase represents a company\u2019s annual financial report \u2013 as it is presented. Elements in the presentation linkbase need to be represented in the same sequence as they follow in an annual report.
\nCalculation linkbase:<\/strong> The calculation linkbase represents the arithmetic relationships between the disclosures in an annual report. For example, a calculation such as \u2018Revenue \u2013 Cost of sales = Gross profit\u2019 in an annual report should be mentioned in the company taxonomy.
\nDefinition linkbase:<\/strong> The definition linkbase, in simple terms, is used to represent anchored relationships as well as dimension and member structures in statements (in a shareholders\u2019 equity statement, for instance). Companies must ensure that their extension elements are anchored to the right fit elements in the ESEF Taxonomy.
\nLabel linkbase:<\/strong> 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 \u2018sales\u2019 for an item that the ESEF Taxonomy called \u2018revenue\u2019. This would have to be mentioned in the label linkbase.<\/p>\n

Errors And Pitfalls To Avoid \u2013 For A High-quality Report<\/h3>\n

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.
\nErrors are a more serious type of inconsistency because they will not let a UKSEF report go past the FCA\u2019s 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.
\nSome common inconsistencies in UKSEF filings are listed below.<\/p>\n

Incorrect Signs<\/h3>\n

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.
\nIn the example below, the \u2018other revenues\u2019 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.
\n\"Structured<\/p>\n

Inconsistent Duplicates<\/h3>\n

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 \u2013 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.
\nIn the example below, notice the difference in the values for the concept – \u2018Equity\u2019.
\n\"Structured<\/p>\n

Calculation Inconsistencies<\/h3>\n

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.
\nIn the example below, the value of \u2018income tax expenses\u2019 has been added to \u2018profit before tax\u2019, resulting in a calculation inconsistency. For the calculation to be correct, \u2018Income tax expenses\u2019 need to be deducted from \u2018profit before tax\u2019 to result in \u2018profit for the year\u2019.
\nThis inconsistency is a result of the negative sign assigned to the value for \u2018Income tax expenses\u2019. The XBRL report preparers have not considered the fact that \u2018expense\u2019 is a concept with a negative sign factored into its XBRL definition.
\n\"Structured<\/p>\n

Report Package Errors<\/h3>\n

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.<\/p>\n

\"StructuredIncorrect Dates<\/h3>\n

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 \u2013 in which case the value indicates a closing balance. However, the same value can also be considered an \u2018opening balance\u2019, or the value of an item just before the business opens on the first day of the next financial year.
\nHowever, XBRL makes no distinction between an opening and closing balance. The XBRL interpretation for balance or \u2018instant\u2019 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.
\nApart from \u2018instant\u2019 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 \u2018Ist January 2021 to 31st December 2021\u2019.<\/p>\n

\"StructuredRedundant Labels<\/h3>\n

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 \u2013 especially while creating extension elements.
\nExample –<\/p>\n

\"StructuredRounding and Inconsistent Calculations<\/h3>\n

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.
\nHere\u2019s an example.<\/p>\n

\"StructuredExample: Rounding up differences<\/p>\n

\"StructuredThe UKSEF xHTML document \u2013 Get The Look Right<\/h3>\n

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 \u2013 one displaying a company\u2019s 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.
\nHere\u2019s 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.
\nThe image shown below is a PDF document, with a normal display of graphs and charts.<\/p>\n

\"StructuredThe next image shows an xHTML document where the graphs and charts look elongated.<\/p>\n

\"StructuredCompanies 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.<\/p>\n

UKSEF Compliance Approach \u2013 In-house Or Outsourcing?<\/h3>\n

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.<\/p>\n

Outsourcing Model<\/h3>\n