On 6th December ’18, I represented Arkk at the Financial Reporting Council (FRC)’s event on UK Digital Reporting. The title could interchangeably also be “ESEF – what does it mean for us?”. The event was oversubscribed, though traffic and a giant internet fail by a major network provider (how did we ever operate without Google maps?!?) meant the room wasn’t quite as full as planned. The majority of the audience were design firms, keen to understand how the ESEF mandate might affect their business.
There were several sessions, led by various people from across the XBRL community. First, a great intro to XBRL by PwC’s John Rowden, which was useful given that the XBRL knowledge in the room ranged from complete novice to expert level. After that, we had a session by Jennifer Guest from the FRC, and then some panel discussions followed. There was finally an optional session I had to miss about creating xHTML documents that looked like .PDF ones. Here are my key takeaways:
It’ll be this year – right?
The working assumption since the summer of 2018 has been “it’ll be finalised before the end of the year”. That remains the working assumption, however we are now just 21 days from… the end of the year! If that doesn’t happen, the mandate will almost certainly get pushed back a year. It wouldn’t be the first time a regulation has been delayed, so it seems fair that a small amount of doubt appears to have crept into the minds of a few folk.
I guess it’s “watch this space”, but an extra year would be welcomed by some (e.g. the 4 UK firms who need to define an audit standard around this).
Once it’s finalised, it’s… you know, final?
Let’s say the Regulatory Technical Standard (RTS) gets finalised before the end of 2018, we then start a just-over-2-year countdown until the first ESEF reports start to be published. However, there is a somewhat awkward 3-6 month period in early 2019 when the standard is finalised, but will not yet be ‘the law’. The EC and European Parliament have a 3 month window to object, and then it has to be published in the Official Journal (which, incidentally, can also take up to 3 months).
But why is that important? Well, during that period, the FCA in the UK will remain tight-lipped on some of the key questions, such as whether (or not) the iXBRL will be subject to audit.
So, technical work, field tests, process design can all be worked on during early 2019 but cannot be finalised until we know exactly what the regulators have to say on some key topics.
The ESMA requirements are straightforward, but how useful are they?
One of the themes of the day was the comparison between ESEF and other international XBRL mandates. It’s pleasing that there is a general acceptance that ESEF is significantly easier to do than, for example, the SEC filings, where the volume of tags (in the thousands) makes it a considerably harder task. There was lots of good discussion around the ‘world at large’ being “more digital” (truer than ever!), but there seemed a general acceptance that ESEF, as it stands, is only a small initial step towards digital reporting for European listed businesses. We heard about how Japanese listed firms have done detailed iXBRL for some time now and that all analysts in Japan use XBRL data as part of their daily jobs (think Bloomberg, but powered by XBRL).
ESEF is no doubt a good move in the right direction, but falls way short of the Japanese story. Whilst the ESEF XBRL information will be used in this way, it will only form a tiny sub-set of the overall picture. One participant commented that only 20% of a firm’s value is shown in the Balance Sheet (tagged under ESEF) and 80% in other places such as the Intangibles note, this will only ever be block tagged (which is as useful as no tagging at all).
Detailed tagging is entirely “nice to have”
One viewpoint was offered that “firms will do detailed tagging of all of the notes, so that investors see they’re responsible and transparent firms”. Fortunately, a much more realistic viewpoint of “nobody will do detailed tagging unless it becomes mandatory” was offered up at least twice. We can also learn from the UK HMRC mandate, where the vast majority of firms have always done the minimum required of them since it started in 2011.
Detailed tagging would be in the order of 20-30 times more onerous than the ESEF mandate, for very limited benefit. I don’t think we’ll be seeing much of that come 2021. Until it’s mandatory, it isn’t happening (much).
Integrated XBRL, bolt-on processes, or outsourcing?
There are 3 general ways to produce the iXBRL for ESEF; an integrated tool where all data is tagged “up the chain”, or at the very least “real time”, a bolt-on to the end of the process, or an outsourced service.
One panel was heavily pushing the integrated approach (and therefore, not the outsourcing approach), giving the reason that adding additional time to the year-end process isn’t really going to work. This is informed by the, often, multi-week turnaround time for HMRC iXBRL documents. I entirely disagree with this logic.
Firstly, to make ESEF work, early preparatory activity is required before year-end to “pre-tag” the Primary Financial Statements (“PFSs”). The structure of the main statements is unlikely to change by more than a few rows, so “pre-tagging”, and getting that signed off by stakeholders, prior to year-end, is not only possible but a sensible approach.
Secondly, as indicated on one of the slides (image below), there is a time-lag between the preliminary results and the finalisation of the AFRs.
Based on what I’ve learned whilst speaking to a number of design agencies, the prelims tend to be lifted from the main draft AFR (often in Word). Given that the prelims contain the primary statements then it stands to reason that they could be tagged then, easily. Whilst this isn’t, standalone, a recommended approach, it could work well and this, plus some preparatory work before year-end, would be a solid approach.
Moreover, at Arkk, our standard turnaround time for ESEF tagging will likely be 24 hours. I think we’ll be able to offer even quicker turnarounds.
Integrated Disclosure Management solutions are good things, and integrated tagging is also an entirely workable approach to ESEF and other reporting requirements. However, ESEF alone does not provide a reason to move from post-production to integrated iXBRL. Post-production for ESEF will likely form the majority of filings for the first few years, after all.
xHTML / iXBRL vs PDF/design
This debate was given a full 1.5 hours after lunch (I wished I could have attended the session). It’s clear that there’s a big push to prove that xHTML, and therefore, iXBRL documents too, can be as visually engaging as the current PDF documents produced by design agencies at present. To demonstrate this, the panellists gave a couple of examples online of the GLEIF annual accounts. No doubt, these documents look great in xHTML, and I’m not disputing that xHTML documents can look as good as PDFs produced by design firms, but I will certainly dispute that this can be done with ease. In fact, it can be incredibly complicated and time consuming (and therefore, costly).
Take a look at the xHTML GLEIF account example. Not wanting to be too cynical, note that we get pages 1-3, then 39 onwards. Why is this the case? If you head to the published PDF report, you’ll quickly see that pages 4-5 would be very hard to represent ‘nicely’ in xHTML.
Being less cynical, even the examples they give aren’t quite the same. The image above shows – whilst the differences are small (different alignment on the logo, different font used on the text), they are noticeable. In statutory accounts these differences likely wouldn’t matter, but in glossy AFRs, they most certainly would. I note that these are only sample files, but the important point that comes over is that having a PDF and xHTML that are identical and equally well formatted is very hard, and therefore likely to be very costly.
Overall
Overall it was a great event and it’s clear that interest in ESEF is building. Lot of points to consider, and we’ll see what happens when the RTS finally get finalised!