Validating a multi-target (ESEF + DKGAAP) inline filing — DBA and ESEF

[afa.si...@gmail.com]

Hello,

I'm trying to work out the intended way to validate a Danish "combined" annual report: a single inline XBRL document with two targets — the default target carrying the IFRS/ESEF financial statements, and a named DKGAAP target carrying the Danish ÅRL supplement (facts tagged target="DKGAAP").

Using arl-2024-multi-target-preview (validate/DBA) on its own, it validates the default (IFRS) target rather than the DKGAAP one. On an official, known-good. filing I get:

[DBA.TH01] The 'link:schemaRef' must contain 'http://archprod.service.eogs.dk/taxonomy/'.
The 'link:schemaRef' as reported is http://xbrl.carlsberggroup.com/.../Carlsberg-...xsd.[DBA.TM12] IdentificationNumberCvrOfReportingEntity must be tagged in the document.
[DBA.TM25] AddressOfSubmittingEnterpriseStreetAndNumber must be tagged in the document.
[DBA.TM27] AddressOfSubmittingEnterprisePostcodeAndTown must be tagged in the document.

i.e. it reads the IFRS target's schemaRef and reports the DKGAAP facts (which carry target="DKGAAP") as missing.

  The only way I found to validate the DKGAAP target is via the command line with the IXDS plugin and an explicit target:

  arelleCmdLine --plugins "validate/DBA|inlineXbrlDocumentSet" \
    --disclosureSystem arl-2024-multi-target-preview \
    --parameters "ixdsTarget=DKGAAP" -f <filing> --validate

That validates the DBA/ÅRL side correctly, but only covers the DKGAAP target. If I instead validate the ESEF/IFRS side with validate/ESEF, Arelle loads the whole DTS (which includes the DKGAAP taxonomy via the second schemaRef) and treats the Danish taxonomy as the filer's extension taxonomy — producing many errors such as ESEF.RTS.Annex.IV.Par.11.customDataTypeDuplicatingXbrlOrDtrEntry on cmn:* types, ESEF.2.5.3.targetAttributeUsedForESEFContents, etc.

So my question is:

Is --parameters ixdsTarget=DKGAAP the intended way to point DBA validation at the DKGAAP target, or is the multi-target disclosure system meant to handle target selection automatically? If the latter is true, for this example how am I supposed to use it?

Thank you,

André

[Austin Matherne]

Hi André,

This is an unfortunately awkward process at the moment. The design of the validation plugins predates multi-target reports and so they apply to all loaded instances/targets. There's no auto selection mechanism by plugins to decide which targets they should apply to. Each validation request has to specify only the target that's intended to be validated by the plugin and disclosure system. Note, using parameters with ixdsTarget works, but --inlineTarget is equivalent in recent versions of Arelle.

For DKGAAP + ESEF the validation requests look something like this:
1. validate DKGAAP target

> arelleCmdLine --plugins "validate/DBA|inlineXbrlDocumentSet" \
    --disclosureSystem "arl-2024-multi-target-preview" \

    --inlineTarget "DKGAAP" \
    --file <filing> \
    --validate
2. validate ESEF target ("(default)" is a special value that matches the default/unnamed target)
> arelleCmdLine --plugins "validate/ESEF" \
    --disclosureSystem "esef" \
    --esefAuthority "DK" \
    --inlineTarget "(default)" \
    --file <filing> \
    --validate

We do have plans to streamline how all of this works (support multiple disclosure systems and plugins autoselect targets). So it will be simplified at some point, but it's going to require some changes to how the plugin infrastructure is implemented.

Kind regards,

Austin Matherne

[afa.si...@gmail.com]

Hello Austin

Thank you so much, that seems to to have done the trick. I will be on the lookout for that future simplified approach that you mentioned.

By the way, a slightly unrelated question that you may be able to help me with: does the dkfin-2024-multi-target-preview disclosure system correspond to DFSA (Finanstilsynet) filings? It looks like it's excluded from most of the DBA rules. And are there plans for a dkfin-2025 in the near future?

Best regards,

André

[Sara Oliveira]

Hello Austin,

Thank you for providing the command for the Arelle validation. It is successfully validating both the ESEF and ÅRL (Danish GAAP) taxonomies. However, I am encountering a false positive warning regarding the file naming conventions.

The two frameworks have distinct naming patterns for the filing package and HTML file:

• ESEF pattern: {base}-{date}-{version}-{lang}

• ÅRL pattern: {base}-{date}-{lang}

Because our package follows the ÅRL standard, the final validation throws an unexpected ESEF warning:

<entry code="ESEF.2.6.3.incorrectNamingConventionReportPackageReportFile" level="warning">
 <message fileName="5299001O0WJQYB5GYZ19-2025-12-31-da.html" pattern="{base}-{date}-{version}-{lang}">[ESEF.2.6.3.incorrectNamingConventionReportPackageReportFile] Inline XBRL document filename SHOULD match {base}-{date}-{version}-{lang} - 687656456465-2025-12-31-da.html </message>
 <ref href="687656456465-2025-12-31-da.html"/>
</entry>

Since the file strictly adheres to the required ÅRL pattern, it shouldn't trigger an ESEF naming violation.

Is this a known limitation when combining both plugins, and do you plan to address this rule conflict in an upcoming release?

Thanks in advance,

Sara Oliveira

[Austin Matherne]

Hi Sara,

The naming pattern rule in Arelle is configurable. Do you have link or reference to where the ÅRL file naming pattern rule is specified by the regulator so I can verify the requirements?

Thanks,

Austin

[24lap...@gmail.com]

Hi Austin,

To give you a concrete reference, we have analysed the official, accepted report packages submitted to the Danish regulator by financial institutions.

As you can see from their live filings, they can follow either the 3-part pattern {base}-{date}-{lang}.xhtml or the 4-part pattern {base}-{date}-{version}-{lang}.xhtml:

• 4-Part Pattern (with version):

  • 636700ETUBNNGWAQ6963-2025-12-31-1-en.xhtml (Filing Link)

• 3-Part Pattern (no version):

  • NTG-2026-03-31-en.xhtml (Filing Link)

  • RealkreditDanmark-2024-12-31-en.xhtml (Filing Link)

As shown in the 3-part examples, there is no {version} component included in those packages. From what I read, ÅRL does not enforce a strict naming pattern requiring a version element, so the system should accept filenames that do not follow the rigid ESEF convention and in my point of view, Arelle should not trigger the ESEF.2.6.3 warning in this case.

Best regards,

Sara Oliveira

[24lap...@gmail.com]

Hi Austin.

I’m just following up to see if you had a chance to review my last response.

Thanks in advance, 

Sara Oliveira

[Austin Matherne]

Hi Sara,

Yes. There should be an update to Arelle to address this within the next couple of weeks.

[24lap...@gmail.com]

Hi.

Good. Thank you Austin.

[24lap...@gmail.com]

Hi Austin.

Was this fix already released?

Thanks in advance,

Sara Oliveira

[Austin Matherne]

Hi Sara,

Yes. This should be working in the latest release of Arelle.

Kind regards,

Austin

[24lap...@gmail.com]

Good! Thank you for your support Austin.

Kind regards,

Sara Oliveira

[afa.si...@gmail.com]

Hi Austin (and all),

Just circling back on this, as I don't think my earlier question ended up getting answered.

Does the dkfin-2024-multi-target-preview disclosure system correspond to DFSA (Finanstilsynet) filings? It looks like it's excluded from most of the DBA rules.
Also, are there any plans for a dkfin-2025 version in the near future?

Thanks again for the help earlier!

Best regards,
André

[Volodymyr Tur]

Hi André,

Yes. dkfin-2024-multi-target-preview is the DBA plugin’s disclosure system for DKFIN (Finanstilsynet / DFSA) filings, typically the Danish target of a combined ESEF + DKFIN report. It lives in the DBA plugin because DKFIN is embedded in Erhvervsstyrelsen’s ÅRL taxonomy and uses the same target="DKGAAP" pattern, but it is not the ÅRL rule set.
We have no plans for a dkfin-2025 system. We added arl-2025-preview / arl-2025-multi-target-preview for the 2025 ÅRL taxonomy, but not a parallel DKFIN 2025 selector. If there are 2025 DFSA checks this set does not cover, we can look into making an update.

Kind regards,

Volodymyr