Implementing ESEF: what could possibly go wrong?

With 25 ESEF annual reports filed on the FCA’s National Storage Mechanism, we thought it would be interesting to take a deep dive into some of them to see what can be learned. 

The first thing to say is that any company that pioneers by filing on a voluntary basis deserves considerable respect. Each has provided stakeholders with machine-readable information where none existed before. Kudos to each of them.

That said, the level of errors we found when looking at some of the filings was of concern. We found filings in which a surprisingly high proportion of the disclosures that need to be tagged were either wrongly tagged or left untagged. Reasons for errors varied, so much so that it seems almost anything that can go wrong, will go wrong, at least occasionally. 

What follows is my personal ‘top ten’ list of problems to look out for. I’m sure this isn’t an exhaustive list of potential errors, but hope to provide pointers for those making plans for the first year of mandatory ESEF compliance: 

1. Choosing the wrong tag from the taxonomy. This can happen when using a word search to interrogate the taxonomy, then choosing the first potential match that appears. In this way tags that belong in, say, the cash flow statement can be wrongly applied to the balance sheet.
2. Creating an extension when a valid tag exists in the taxonomy. A well-known short-cut for the time-pressured tagger. Why go hunting for the right tag when the option to swiftly create a bespoke extension beckons?
3. Not creating an extension tag when one is needed. The mirror image of 2), where a tag is selected from the taxonomy when none apply to the facts and circumstances.
4. No tag applied. For example, sometimes when an additional column or row of analysis appears on the face of the P&L account, this doesn’t get tagged when it should be.
5. Getting the sign wrong. Each tag has a notional ‘sign’: either debit/credit or, where flows and movements are concerned, up/down. These signs can be reversed when necessary, but it's easy to go wrong, so proceed with caution. 
6. No anchor.  Anchoring is the innovative linking of an extension tag to the ESEF taxonomy and sometimes more than one anchor is required. Anchoring doesn’t always happen when it should.
7. Incorrect anchoring.  Anchoring rules are detailed and knowledge of both the rules and the ESEF taxonomy is necessary to ensure the most appropriate tag is chosen. 
8. Tagging is not ‘Inline’. An item of data has been tagged but the connection to the human-readable document doesn’t exist. This problem has been surprisingly pervasive in the first filings. Doesn’t necessarily affect machines using the data, but information that appears untagged is unsettling and not what the rules expect.
9. A problem with precision. If all the numbers are disclosed in, say, millions, getting the scaling right should be relatively straightforward. But some numbers aren’t disclosed that way, for example Earnings Per Share information, which can be in the single unit of pence per share. Figures can also be disclosed to different decimal point levels. Care is needed!
10. Calculation Linkbase. This is the name for coding the arithmetical relationships between numbers disclosed in the primary financial statements. Where it can be applied, it should be, but this doesn’t always happen.