XBRL Audit and Assurance: What Auditors Need to Know About iXBRL and ESEF Reports

Every listed company in the EU now files its annual report with eXtensible Business Reporting Language (XBRL) tags embedded in the document. The European Single Electronic Format (ESEF) mandate put those tags there, and the audit report changed with them.

Auditors must now state whether the iXBRL tagging of the consolidated financial statements complies with the mandate in all material respects. That conclusion covers the tagged financial data itself, and for many engagement teams, it is their first encounter with XBRL assurance.

Machine-readable financial reporting has a longer history than the audit obligation. CoreFiling invented the iXBRL format in 2010 and, since then, has supplied the iXBRL software used in several regulators, tax authorities and accounting firms.

This guide covers what an iXBRL audit involves, what regulators expect auditors to check, and how specialised software makes the process accurate and efficient.

What is an iXBRL audit?

An iXBRL audit is the independent check the company complies with the iXBRL parts of reporting regulations. This includes checks that the digital file is conformant with the iXBRL standard and related specifications and checks that the tags assigned to each individual item tell the truth about the underlying business information and other individually identifiable business facts. Tags written in eXtensible Business Reporting Language turn business reports into machine-readable data, and every tag is a judgement the preparer made. The audit tests those judgements.

The test confirms that the preparer applied the correct taxonomy concept to every line item in the financial statements, that the calculations defined in the file are mathematically consistent, and that the machine-readable financial data matches what the human readable pages show by separating primary audit objects that contain business facts from secondary presentation metadata needed for human readable form. Where the preparer decided to extend the taxonomy with entity specific elements, the auditor checks that this consistent with the rules around this.

That confirmation happens in three stages:

1. Automated validation: diagnostic tools run the iXBRL report against the technical rules of the standard and flag structural errors, broken calculations and invalid references in seconds.

2. Manual review: the auditor checks the tagging judgements against source records, because software cannot judge whether a chosen concept reflects the substance of a disclosure.

3. The assurance conclusion: the auditor’s written opinion on the electronic tagging, most often published as a distinct element of the audit report.

The focus of iXBRL assurance also extends across the full digital reporting supply chain, including whether the filed report is complete and timely when sent and received.

Together, the three stages make up iXBRL assurance, and the fact that regulators now require this, shows the role digital formats play in stronger corporate transparency and more efficient capital markets.

Why XBRL audit is now a regulatory obligation, not a choice?

The requirement comes from the ESEF Regulatory Technical Standard (RTS), the EU regulation that sets the rules for filing annual financial reports by listed companies. ESMA wrote the standard, national regulators enforce it, and the auditor’s part is a specific assurance conclusion on the iXBRL tagging, published in the audit report itself.

No XBRL-specific international auditing standard exists yet. The Committee of European Auditing Oversight Bodies (CEAOB) and Accountancy Europe have confirmed that in the absence of a national XBRL assurance standard, ISAE 3000 applies, so the profession already has a framework for the work.

UK rules impose parallel filing obligations. HMRC and Companies House mandate iXBRL/XBRL submissions in the UK under a common approach to online company accounts filing, while the Financial Reporting Council (FRC) provides guidance for tagged accounts of UK-listed companies. Whilst there is no assurance requirement in the UK, the FRC does recommend to companies to obtain voluntary assurance and have adopted ISAE (UK) 3000 to make this possible.

What the XBRL audit standard requires: ISAE 3000 and ESEF RTS

The standard for XBRL assurance is often ISAE 3000 (Revised), Assurance engagements other than audits or reviews of historical financial information. Under it, auditors must obtain reasonable assurance of ESEF Regulatory Technical Standard (RTS) compliance, which in practice means confirmation that the consolidated financial statements are tagged in all material respects as the RTS prescribes.

Reasonable assurance is the same level as the audit opinion itself carries.

The regulations set the requirement and leave the method to the profession. Guidance from the Committee of European Auditing Oversight Bodies (CEAOB) fills that space. It describes what regulators expect the assurance work to show, though evolving regulations and standards can increase the compliance burden for companies as well as auditors.

The obligation does not stop at the financial statements. Companies in scope of the Corporate Sustainability Reporting Directive (CSRD) will tag sustainability disclosures in iXBRL under the same XBRL specifications that govern ESEF filings, and the underlying XBRL standard does not change. XBRL assurance capability built for ESEF today covers sustainability reporting tomorrow, which is central to the future of digital reporting.

The XBRL audit checklist: five things every auditor must verify

Once the engagement starts, the auditor has five things to verify. Each covers a different part of the tagging, and a report has to pass all five.

1. Tag selection: is the right taxonomy concept applied to every line item?

Every value in a company’s financial statements has an identifying tag that maps it to a concept in the applicable XBRL taxonomy — the IFRS taxonomy which is used for ESEF filers has clear ownership and is maintained by an authoritative body, or custom extensions that auditors must validate separately. The auditor verifies each mark-up, one line item at a time, because that is how XBRL works for users in practice.

Two mistakes recur in the tagging process. Preparers apply a generic concept where a specific one exists, or they stretch a concept outside its defined scope. Revenue from contracts with customers tagged as just Revenue, where an exact IFRS 15 concept exists, is an example of this.

Software cannot catch either mistake because both tags are technically valid under the XBRL standard. Concept choice is a judgement call, and it takes the same knowledge of the appropriate taxonomy that the iXBRL tagging itself required, even where the tagging choice appears plausible on its face.

2. Calculation relationships: do sub-totals and totals add up correctly?

An XBRL report contains a calculation linkbase — machine-readable rules that state which values sum to which totals. The rules follow the XBRL specifications, so software can test the whole file at once, and once the data is structured correctly, computer software can automate analysis of those calculation relationships while automatic checking flags any sub-total that fails. Tools like CoreFiling’s Beacon run these consistency checks in seconds.

A clean pass has a limit, though. It shows the XBRL data obeys the rules the file declares. If a rule itself is wrongly defined, the file passes anyway, with the error built in.

So the auditor works one level up. The declared relationships must match how the financial statements actually roll up, and once that holds, the arithmetic relationships can be trusted.

3. Taxonomy extensions: are custom tags valid and properly anchored?

No XBRL taxonomy covers every disclosure every company can make, so preparers create extension tags where no standard concept fits, though doing so adds extra effort in both drafting and review compared with using a standard concept. Extensions are legitimate. They are also the most common source of ESEF non-compliance, which is why three separate checks decide whether one stands.

1. Justification: whether the appropriate taxonomy genuinely lacked a suitable concept, or the preparer missed one that exists.

2. Anchoring: ESEF requires every extension which does not relate to a subtotal to be anchored to the standard IFRS concept nearest to it in meaning. The requirement entered the rules to keep extended filings comparable, and a missing or wrong anchor is a compliance failure on its own.

3. Validity: whether the extension is defined in a valid taxonomy extension file that software can read, because strong XBRL tagging quality depends on software-readable extensions.

Software settles the third point in seconds. The first two need audit judgement.

4. Context and attributes consistency: are dates, consolidation scope, currency, scale and accuracy correct?

Every tagged value carries a context — the metadata that records the reporting period, the reporting entity, the currency unit, the scale and the precision. The context and attributes contribute to a full machine-readable description of the structured business data and financial information.

Picture revenue for the year to December 2025 tagged with a 2024 period. Every calculation test passes, because the value itself is correct, and every automated reader files it as last year’s figure. The error is invisible to software and misleading to everyone downstream, affecting later monitoring and risk assessment by regulators and other users.

The auditor verifies each context against the financial statements. The period must match the fiscal year end, the scope must match the consolidation basis, consolidated or standalone, the scale, accuracy and the unit must match the reporting. Those fields decide the accuracy of the XBRL data.

5. Year-on-year consistency: are comparative figures tagged consistently?

Comparative figures in an XBRL report must carry the same taxonomy concepts as the prior year’s filing, so tagging supports better insights across periods. A line item description can stay identical while the concept underneath changes. That mismatch, known as concept drift, breaks the time series for anyone who reads XBRL filings by machine.

Drift tends to appear after restatements and annual IFRS taxonomy updates, when preparers retag from scratch. Nothing looks wrong on the page, so the check has to happen at concept level.

The auditor compares this year’s concepts against last year’s line by line and asks for an explanation of every change. A deliberate retag can be the correct treatment. An unexplained one undermines the accuracy of both years and creates risks when broken trend analysis distorts the filing history.

Auditing ESEF iXBRL reports: specifics of the EU mandate

The five checks apply under any mandate. An ESEF audit adds obligations on top, and auditors of companies listed on EU capital markets need to know where they are.

An ESEF filing is one XHTML file. It opens in a browser like any web page, and the inline XBRL tags that make it machine-readable are embedded in the text itself, with the ability of iXBRL to preserve a human-readable form at the same time. That gives the auditor two review obligations in one document. The pages people read get one review, the tagged data gets another, and a report can pass one and fail the other.

The work also starts earlier than many teams expect. Companies share draft reports before the report is complete, and the auditor’s comments at that stage already need to take the ESEF reporting requirements into account, even though companies still remain responsible for correct tagging and statutory compliance when they rely on software providers or accountants. Compliance problems found in the final file are the most expensive ones to fix and the most stressful.

The conclusion itself is specific. It must state whether the tagging of the consolidated financial statements complies with the ESEF RTS in all material respects. In most jurisdictions, the regulation is named in the audit report itself.

Since the 2022 financial year, the mandate also covers the notes, the text disclosures that follow the primary statements. Notes are block-tagged, with tag wrapped around the sections of text and tables. Often multiple nested block tags are applied on the same disclosures.

The auditor’s checks change with the technique. For the primary financial statements, the question is whether each number has the right concept. For the notes, it is whether every required disclosure is tagged at all, and whether each block covers the full text.

ESMA publishes a report on ESEF filing statistics every year, with the errors national regulators found in the XBRL filings from the previous cycle. Engagement teams can use it to see which mistakes come up most often and plan their assurance work around them.

UK ESEF (UKSEF): what changed post-Brexit for UK auditors

Brexit split the mandate in two. The Financial Conduct Authority does accept ESEF filings using the EU taxonomy, however, the FRC also provides an alternative optional UKSEF taxonomy in place of the EU version. UKSEF also uses the IFRS Taxonomy and the annual financial statements are still filed in iXBRL, so the XBRL filings themselves look much like their EU counterparts.

What changes for UKSEF is the UK-specific taxonomy brings in other components of the FRC taxonomies which allow filers to tag Company and report information, the Auditor’s Report, the Director’s report, the Streamline Energy and Carbon Reporting disclosures and the parent company financial statements.

How Beacon supports the digital assurance workflow?

An engagement team could run all five checks by hand. One XBRL report contains thousands of tagged facts, though, and no audit budget covers a manual review of every one. The tagged format permits automatic checking, and that is what audit software tools are for.

CoreFiling’s tool for this work is Beacon for assurance, a platform subscription built for XBRL and iXBRL review.

Beacon is read-only by design. It cannot alter the report it reviews, so the file the company tagged is the file the auditor tests, untouched from upload to sign-off. For audit independence, a review tool with no power to change the evidence is exactly what the engagement needs.

The capabilities follow the checklist.

• Automated compliance checks: Beacon runs the iXBRL file against the ESEF, UK iXBRL and core XBRL rule sets and flags every technical error in seconds.

• Calculation validation: The calculation linkbase relationships from the second check are tested automatically, with every inconsistency highlighted for review.

• Extension review: Beacon identifies every extension tag in the filing and flags whether anchoring is present and correct.

• The assurance report: a structured output with four parts, Reported Facts, Calculation View, Validation Results, and a Changes log that records every difference from the prior year’s filing.

• API integration: Beacon APIs connect the platform to the audit workflow software and issue tracking systems the firm already runs.

Checks that took days of manual work finish in seconds, and the efficiency changes how the hours get spent. Automated processing covers the rules and the arithmetic. The team’s time goes to the judgement calls that no software can make, tag selection, and extension justification.

What the Beacon assurance report contains?

The output of a Beacon review is a structured assurance report with four parts, and each part documents evidence for the conclusion.

• Reported Facts lists every tagged value in the XBRL report, checked for correctness and for consistency between what the readable pages show and what the machine-readable data says. Any gap between the two appears here.

• Calculation View confirms the roll-ups, movements and calculations are correct, so the arithmetic behind the second check arrives already tested.

• Validation Results hold the outcome of automated checks against the filing manuals of each regulator, plus any custom business rules the firm adds for its own methodology.

• Changes gives a complete list of differences between the current report version and the previous one, which turns the year-on-year consistency check into a reading exercise. Concept drift has nowhere to hide when every change is on one list.

Together, the four parts document the accuracy of the tagged filing, and the engagement file has its XBRL assurance evidence in one place.

Common XBRL audit errors and how to avoid them

Every year ESMA reports which errors national regulators found in ESEF filings, and every year the list looks familiar. These are some of the common errors, and they create compliance, operational, and reputational risks:

1. Extension tag where a standard concept exists: A company labels a line item its own way, the preparer searches the taxonomy for that exact wording, finds nothing, and creates a custom tag. Meanwhile, the right concept existed all along under a different name. So the first thing to establish on every extension is whether the XBRL taxonomy was searched properly before extending it.

2. Anchor to the wrong standard concept: Here the extension itself is justified, but its anchor points at something too generic to mean anything. Take a specific cost line anchored to total expenses. Anchors exist to show what a custom item means in standard terms, and a vague one tells readers nothing. ESEF treats that as a compliance failure in its own right.

3. Wrong scale or sign: A value gets tagged in thousands when the unit says millions, or an expense goes in with the sign flipped. Nothing on the printed page changes, so the mistake slips past every human reader and straight into every extracted dataset. These do the most damage to the accuracy of the data, because the numbers look normal right up until someone computes with them.

4. Calculation linkbase inconsistencies: Sub-totals reconcile on the page, then fail when the software extracts them. Usually, a rounding choice caused it, or an element is missing from the defined relationship. Automated validation catches these in seconds, which is why the calculation check runs early in the engagement.

5. Stale context: Somewhere in last year’s file or an old template, a period date survives that nobody updated, and a prior year comparative ends up tagged with the current year. The figure itself is correct, which is exactly why the mistake survives review, and every automated reader books it in the wrong year.

6. Notes coverage gaps: Since notes tagging became mandatory, whole disclosures go untagged in otherwise valid iXBRL filings, or block tags stop short of the full text of a note. Both gaps pass every technical test, because a missing tag breaks no rule that the software can see. Only a completeness check finds them, line by line, so downstream users receive complete business information rather than just a filing that appears to meet disclosure requirements.

All six cost less to fix in a draft than in a filed report. Preparers who validate before submission and auditors who validate on day one of the engagement leave fewer findings between them.

How CoreFiling supports auditors at every stage of XBRL assurance?

CoreFiling wrote the iXBRL format, and regulators run CoreFiling software on the filings they collect. An audit team that asks what correct tagging looks like gets the answer from the side that checks it.

Firms meet XBRL assurance in stages, and each stage has its own tool.

• Run the review: Beacon for assurance gives the engagement team automated checks, extension flags and the four-part assurance report from day one of fieldwork.
• Put the checks in firm systems: True North Data Platform APIs add the same validation to the audit workflow software the firm already runs, so no engagement depends on a second tool.
• Escalate the hard questions: CoreFiling cooperates closely with data collectors and regulators, and its team provides expert support on assurance issues no filing manual answers.
• Build the capability: XBRL training puts tagging knowledge inside the audit team, so concept judgements no longer depend on one external specialist.

A firm can enter at any of the four. CoreFiling’s digital assurance solution covers the whole path, from the first validation run to the evidence behind the conclusion.

For audit teams encountering ESEF or other iXBRL/XBRL assurance for the first time, CoreFiling offers both the tools and the expertise to make digital report assurance fast, accurate and defensible, reflecting standards shaped by XBRL International and supporting continued adoption in different countries as digital reporting expands.