As companies grapple with how to handle the coming requirements of the ESMA ESEF mandate, it’s hard not to look at the upfront burden of the change and think, “What’s in it for us?” Here’s the answer: The ESEF mandate will give you greater control over the story your company tells with your financial statements. Moving to machine-readable iXBRL filings will limit third-party (data aggregator or analyst) interpretations of your financial information, allowing you to tell your story directly to your audience(s). That benefit comes with one major caveat, however: A direct connection means you can’t afford not to get it completely right from the start. Today, I’ll address why quality is so incredibly important when it comes to your XBRL tagging and XHTML filings required by the ESEF mandate.

Cutting out the middleman

Your financial statements contain critical information about your business. The troubling reality is that, traditionally, this information often goes through one or more intermediaries before it reaches your intended audiences. Investors, media and even regulatory agencies typically look to data aggregators and analysts for reports and insights. Those aggregators and analysts want to make direct comparisons between companies in order to draw meaningful conclusions and provide relevant, actionable insights. But currently, the lack of machine readability means that those comparisons start with human interpretation of your financial information. Furthermore, the lack of a universal format means that the third party must essentially translate the various ways that companies present their financial information into a consistent standard. The result: Your audiences don’t get your pure story — and you may not realize if important details or nuances are getting “lost in translation.”

The ESEF mandate solves that problem, providing standard formatting for machine-readable financial statements. That means no more middleman interpretation and no more lost-in-translation. The ESEF mandate gives your audiences more direct access to your financial data and enables immediate, consistent comparison and objective analyses between companies.

A direct connection makes quality essential

Removing the filter of third-party data interpretation/translation also presents a higher risk. Because the data can be directly consumed by machines, there is little chance that a savvy, experienced human will be looking at your financial statement to spot simple errors and correct for inconsistencies. Errors in your XBRL dataset will go directly to your audience. Moreover, we know that our modern, data-driven world has an infinite memory. Your financial data — including any errors — will live in perpetuity. In fact, the value of universally machine-readable data will only grow in the coming years, as there is more data for comparison and analysis. That means that, even if an error in your XBRL data isn’t discovered immediately, it may come back to haunt, embarrass or damage your company years down the road.

XBRL errors can have serious consequences

The most unavoidable consequence of even small XBRL errors is reputation damage. In my last blog, I mentioned the example of General Electric’s embarrassing XBRL error. Mistakes like this can have a lasting impact on your reputation — and can decrease investor confidence as a result. If those errors lead an investor to make an incorrect investment decision based on your bad data, you could be held liable.

You should also know that the ESEF mandate clearly states requirements for accuracy and quality. Put simply, you have the same accuracy and quality requirements for your XBRL dataset and XHTML filing as you do for your current financial statements and annual reports. That means there is legitimate legal risk in making errors in your XBRL data — including ESMA or local regulator comment letters, potential fines and, in theory, de-listing. In reality, it’s not likely that regulators will be handing down huge fines for errors — at least not in the first few years. But regulatory sanctions will augment damage to your company’s reputation and your investors’ confidence.

The bottom line is that you don’t want to look like an outlier in your peer group — unless it’s for a truly unique bit of news or performance. Today, it’s already so easy for a company to get painted in a negative light; you don’t want to give anyone reason to target your company with bad press.

Easy mistakes to make: Real-life examples

So, where can XBRL go wrong? Unfortunately, it can go wrong in all sorts of ways. Here are a few real-life cases — taken from SEC.gov — of common mistakes that IFRS issuers have made in their XBRL datasets:

1. Incorrect sign: The value is the opposite of the intention

Looking at the HTML financials on the left — the “human-readable” version that looks like your traditional paper financials — everything is as it should be. But looking at the XBRL dataset reveals a major error: The debit figures were input as negative values — even though debits are already an indicated part of the XBRL tag for these figures. This creates a double-negative effect, and these inputs ultimately get assessed as credits. Machine analysis of this XBRL data would lead your audience to think that your interest expenses were actually income. A machine recalculation of your net interest income would give a figure of 81.2 million, more than twice what it actually was — an embarrassing mistake that could be dangerously misleading.

HTML Financials  (Human-Readable Version)

XBRL Dataset  (Machine-Readable Version)

2. Incorrect value: Values 1,000 times lower than intended

Here again, nothing looks amiss in the HTML financials. Please note that all amounts are expressed in millions USD. However, this company did drop several zeros when they input the figures into the XBRL dataset. Machine analyses will think their sales values are 1,000 times lower than intended. That’s definitely not the story you’d like to tell.

HTML Financials (Human-Readable Version)

XBRL Dataset (Machine-Readable Version)

3. Incorrect value: 1,000,000 times higher than intended

On the HTML financials, please note that the first value is expressed in millions RUB, while the others are expressed in shares. When this company input the numbers into their XBRL dataset, they made the correct scale adjustment on the first figure — but then incorrectly made the same adjustment to all the share numbers, as well. The result is that XBRL data suggests these values are 1,000,000 times higher than intended.

HTML Financials (Human-Readable Version)

XBRL Dataset (Machine-Readable Version)

4. Incorrect unit: Values without units

The HTML financials below give different exchange rates for multiple foreign currencies. However, when this company input the figures into their XBRL dataset, they failed to add the relevant unit information. Consequently, the XBRL data for these exchange rates is just a bunch of meaningless numbers, without the necessary context needed to make sense of them. A machine reading this data wouldn’t even know what to do with it, which makes it impossible for a user of the financials to apply these exchange rate to automatically recalculate the numbers into a different currency. That might not be terribly dangerous, but it’s still embarrassing.

HTML Financials (Human-Readable Version)

XBRL Dataset (Machine-Readable Version)

Mistakes are easy to make when you don’t “speak” the XBRL language

XBRL tagging is new to European companies. The IFRS Taxonomy used by ESEF — which is different than the U.S. GAAP Taxonomy used for submitting XBRL-tagged financials for the U.S. SEC — is also new to many renowned service providers. The real-life examples below show how easy it is to make honest mistakes when you simply don’t “speak” the XBRL language:

5. Incorrect tag selection #1

Looking at the highlighted line in the HTML financials, you might think that the correct XBRL tag would be “Investments in joint ventures.” But you’d be wrong. That tag is only for use in separate financial statements — not consolidated statements. The correct IFRS taxonomy tag is “Investments in joint ventures accounted for using equity method.”

HTML Financials (Human-Readable Version)

6. Incorrect tag selection #2

Here, we’re looking at the highlighted line, “Total current assets.” It would seem quite obvious to assume that the XBRL tag “Current assets” would be appropriate. But that would be wrong again — that tag in the IFRS Taxonomy includes assets classified as held for sale, which are reported separately by the company. The correct tag is “Current assets other than non-current assets or disposal groups classified as held for sale or as held for distribution to owners.”

HTML Financials (Human-Readable Version)

7. Incorrect tag selection #3

In this last example, looking at the highlighted line in the HTML financials, most people would naturally choose the tag “Depreciation and amortisation expense.” But that tag should be only used for the profit and loss statement — not the cash flow statement. The correct tag is “adjustments for depreciation and amortisation expense.”

HTML Financials (Human-Readable Version)

Why it’s so easy to make — and miss — XBRL errors

The first four examples have shown how easy it is to make serious errors when inputting your XBRL data. The last three show that XBRL tagging is sometimes not intuitive. Traditionally, if you made mistakes like these, there’s a good chance that someone would catch it and correct it. That likely won’t be the case going forward. In all of these examples, the HTML financials show no sign of the XBRL error underneath. Most companies today have review processes centered on these human-readable financials — and even if they did look at the XBRL, they’d likely miss the errors unless they were trained and experienced in XBRL tagging and the IFRS Taxonomy. That means this erroneous data will be used in ongoing analyses, and the errors will go unnoticed and uncorrected until they make themselves evident in peer comparisons — often in embarrassing and potentially damaging ways.

How to get your XBRL right — the first time

So, with so much that can go wrong, how do you make sure your XBRL data is telling the right story? Here are my three tips:

Some companies have attempted to pass XBRL tagging to their IT departments. But XBRL is much more than an IT exercise — it requires accounting and financial reporting knowledge, not just data science. One might say that sometimes it even borders on art. Making sure you have someone with deep experience with XBRL tagging and the IFRS Taxonomy — whether that’s an internal resource or an external partner — is absolutely key to getting this right. And, once again, please do remember that the IFRS Taxonomy differs significantly in many areas from the U.S. GAAP Taxonomy, so getting a U.S. GAAP expert is unlikely to be a solution.

The IFRS taxonomy changes — often substantially — every year. You need a dedicated expert that stays up to date on these changes and understands how to apply them. The ESEF rules are likely to evolve as well — make sure you are not surprised at the end of your reporting process with some new or amended requirements that you haven’t planned for.

The first instance of XBRL tagging will inarguably be a very different process compared to what you’ve done before. No matter how you approach it, you should expect that it won’t be completely seamless and will take more time. Plan for roughly an additional week — XBRL tagging will take a couple of days, but your review and quality control will as well. The good news is that you can prepare yourself in advance by working on XBRL for your 2019 financials. That will significantly reduce the amount of time in early 2021, when you will need to file your first XBRL.

All in all, XBRL tagging really isn’t rocket science. But it is a matter of speaking the language or ensuring the services of someone who does. And as I mentioned at the start of this blog, the beauty of the ESEF mandate is that it gets everyone speaking that same language, which allows you to speak directly to your audiences. Follow my three tips above and you can make sure that your XBRL data is telling the story you want it to tell.

A quick introduction to our ESEF expert: This new blog series features Bartek Czajka, Director of XBRL Consulting Services at Toppan Merrill. Bartek is one of the foremost experts on XBRL, having created the majority of updates and additions to the IFRS Taxonomy between the years of 2010-2017 during his tenure as Senior Technical Manager at the IASB, the organisation that issues the IFRS Standards. When ESMA was tasked with developing the European Single Electronic Format (ESEF), Bartek directly helped ESMA define the shape and form of the XBRL taxonomy to be used. He also participated in the field test organised by ESMA with 25 European issuers to assess the cost and benefit of using XBRL for ESEF. We can think of no one more qualified to help our clients understand, successfully implement, produce and confidently move forward with XBRL.