Formula questions/issues with the ESRS taxonomy

78 views
Skip to first unread message

SK

unread,
Jul 21, 2025, 3:46:05 AMJul 21
to Arelle-users
Dear Arelle Team

Out of interest, I have started to create my first ESRS reports in the last few days.
In doing so, I came across a behavior of Arelle where I am unsure whether it is a bug on my part or the software (therefore no Gitub issue).

I would be grateful for any feedback and input.

For demonstration purposes, I have created a minimal ESRS report: An XHTML without extension taxonomy, and the report contains only one fact (esrs:ReportingPeriodEndDate with the value “2030-12-31”). 

With this small report I noticed something in one of the assertion sets of the ESRS taxonomy, namely the set "eu-tags". This set contains (if I have counted correctly) 104 assertions as to which tags must appear in the report.

In my opinion, my example report should therefore output 104 formula errors (plus of course many other warnings from the other assertion sets).
However, when I validate the report via Arelle GUI (2.37.37, Windows), 94 errors are reported.

For example, one formula that does not return an error is existenceAssertion ea_eu_tags_31.

I was also able to find the following message from Arelle via the various GUI options:

Line 16706: [formula:trace] Existence Assertion ea_eu_tags_31 evaluations : 1 satisfied, 0 not satisfied - https://xbrl.efrag.org/taxonomy/esrs/2023-12-22/all/formula/for_esrs_validation_mandatory_tags.xml 4659

However, I am of the opinion that this formula should not be satisfied (even if I do not know the formula syntax well):
- in the example report, the esrs:ReportingPeriodEndDate has the value "2030-12-31"
- The time contexts are also set in the year 2030 (although I guess this has no influence on the assertion).

I have also checked the XHTML with another XBRL processor to make sure and I get the message
(existence assertion: ea_eu_tags_31) [Unsatisfied].

Hence the question:
- Could this be a bug in Arelle, or.
- am I making a mistake in the validation (e.g. via the options in the formula checks)?

Thanks for any input!
875500F6U6IE1K6QVV54-2025-12-31-0-en.xhtml

Austin Matherne

unread,
Aug 1, 2025, 8:36:32 PMAug 1
to Arelle-users
Hi,

Thanks for reaching out. The formula you mentioned uses a parameter with a select attribute that relies on an XPath expression targeting a traditional XML instance:

> <variable:parameter xlink:type="resource" xlink:label="year1phaseInIsActive" xlink:title="year1phaseInIsActive" id="year1phaseInIsActive" name="year1phaseInIsActive" select="/xbrli:xbrl/esrs:ReportingPeriodEndDate ge xs:date('2025-01-01')"/>

Since an iXBRL document does not contain an xbrl element or an esrs:ReportingPeriodEndDate element, Arelle’s formula evaluator sees the select result as empty. Other processors may create a virtualized XML XBRL instance to evaluate the formula or have hard coded logic to handle ESRS differently, either would explain the difference in behavior.

The specification allows flexibility here. If no value is supplied and the parameter is not required, the value may be computed from the select expression, but this is optional.

You can supply parameter values in Arelle using the Tools > Formula > Parameters... menu. It should look something like this:

Screenshot 2025-08-01 at 8.03.44 PM.png

Hope that helps,
Austin Matherne

SK

unread,
Aug 13, 2025, 7:46:26 AMAug 13
to Arelle-users
Hi Austin,

Thank you for taking the time to investigate this and for your feedback.

I wasn't aware of this limitation with formulas, but your explanation about XPath expressions in XHTML has helped me understand.

It seems somewhat strange to me that ESRS - which are clearly designed for iXBRL - would use this mechanism, but I assume there's no better way, even though individual processors (as Arelle) consider these formulas as satisfied (when it probably shouldn't be in this particular usecase).

Your help with the formula parameters works and is functional, thank you. The "problem" from my perspective is that you have to manually set (or know) the value in the first place.

Thank you once again and best regards,
Sacha
Reply all
Reply to author
Forward
0 new messages