ESEF - same fact but different values lead to duplicated_facts error

Question

I am generating an ESEF report from my application.

Now I have a text e.g.: "this year we made a revenue of ~124 mio €"

And the value 123 mio € in a table.

Both values are connected to the same data value in the database which has the exact value of 123569815,46 €

In the report they are just displayed differently (123 - 124)

Now I have two different resulting nonFraction elements:

<ix:nonFraction contextRef="D-01012024-31122024" decimals="-6" format="ixt4:num-comma-decimal" id="esef-9696_2024_74477_1" name="ifrs-full:Revenue" scale="6" unitRef="euro">124,0</ix:nonFraction>

<ix:nonFraction contextRef="D-01012024-31122024" decimals="-6" format="ixt4:num-comma-decimal" id="esef-9696_2024_74375_1" name="ifrs-full:Revenue" scale="6" unitRef="euro">123</ix:nonFraction>

When I validate them via Arelle I get an error:

[message:tech_duplicated_facts1] Duplicated facts with different values have been reported for: ix:nonFraction, value:123000000 != 124000000 please review selected entries.

Is there a designated attribute or something similar for such cases?

EDIT

Ok, so on a concrete example that I currently have where the original value is 61477652,16 I have two displayed values 61,5 (mio) and 61.478 (thousand).

My app calculates 61,5 with a scale of 6 and with -6 decimals and 61.478 with a scale of 3 and with -4 decimals what should be like this if I understand it right:

61,5 with a scale of 6 and with -6 decimals is consistent with an exact value in the interval [61000000, 62000000].
61.478 with a scale of 3 and with -4 decimals is consistent with an exact value in the interval [61473000, 61483000].

So the upper bound 61483000 is in the interval [61000000, 62000000]
Shouldn't the value be treated as even then?

When validating with Arelle I get the error: Duplicated facts with different values have been reported for: ix:nonFraction, value:61500000 != 61478000

I just dont get it how the Arelle validation works because it should take the decimals into account but it only seems to take the scale into account (when I change the decimals nothing changes)

Answer 1

About Scale and Decimals

Scale and decimals have two different roles.

The scale is specific to the XHTML syntax (Inline XBRL) and says how many zeros should be added to get the machine-readable value (example: 61 with a scale of 6 means 61000000). It is purely cosmetic.

The decimals property is core to the data model and applies to all syntaxes, it expresses the precision of the machine-readable value, that is, you can derive the interval in which the exact value lies. The previous comment shows examples of the decimals property not being the negative value of the scale.

About Calculations 1.1

The new Calculations 1.1 specification, currently rolled out and recommended by the ESEF reporting manual as of 2024, clarifies the precision semantics for values used in calculations (which revenues typically are, as part of the income statement roll-up structure).

Concrete examples and discussion

123 with a scale of 6 and with -6 decimals is consistent with an exact value in the interval [122500000, 123500000].

124 with a scale of 6 and with -6 decimals is consistent with an exact value in the interval [123500000, 124500000].

An exact value of 123569815,46 is thus consistent with the 124 tag, but not with the 123 tag.

One could consider setting decimals to -7, however, Calculations 1.1 would then disallow the 3 in 123 as digits in excess of the precision.

The recommended course of action would be to check if the displayed value 123 in the table is correctly computed. If this has to do with the consistency between roundings and subtotals, the insights and advice given in Calculations 1.1 could help, in particular: calculations do not need to match exactly, but only require that the intervals of allowed exact values overlap.

Answer to the edit and second example

61,5 with a scale of 6 and with -6 decimals is disallowed by Calculations 1.1 because 5 is an excess digit. It should be 61,5 with a scale of 6 and with -5 decimals, corresponding to [61450000,61550000], or 61 with a scale of 6 and with -6 decimals, which corresponds to the interval [60500000,61500000].

61478 with a scale of 3 and -4 decimals is also disallowed as 8 is an excess digit. 61478 with a scale of 3 and -3 decimals corresponds to [61477500,61478500]. 61480 with a scale of 3 and -4 decimals corresponds to [61475000,61485000].

61477652,16 is in all four intervals.

If a public (non-editable) report contains <ix:nonFraction decimals="-4" scale="3">61.478</ix:nonFraction> then it does not follow Calculations 1.1 (e.g. it could be an older report) and does not benefit from the semantic improvements of this specification (the goal of which was precisely to reduce errors and warnings). Then, this report may need to be processed under Calculations 1.0 semantics, in the spirit in which it was produced.

However it is possible that not all errors and warnings will go away.