BR-DE-22Das "filename"-Attribut aller "EmbeddedDocumentBinaryObject"-Elemente muss eindeutig sein

Official rule text

KoSIT words this rule differently in the two files. Above is the UBL wording; here is the other:

Wording in CII

Not all filename attributes of the embeddedDocumentBinaryObject elements are unique

All attachments embedded in an invoice must carry distinct filenames — the name in the filename attribute is all that tells them apart. The recipient files them under exactly that name.

Severity: Error
Applies to: CII, UBL
Rule set: v2026-08-31
Checked on: 4 September 2026

Written and checked against the official KoSIT rule set by Dmytro Yalanskyi, NormAPI.

Why does BR-DE-22 happen?

The generator uses a constant name — every attachment is "anlage.pdf" or "attachment.pdf". With exactly one attachment this never shows; the second one triggers the error. The two syntaxes look different distances, too: in UBL the expression counts only the attachments at document level, while in CII it searches the whole document with // and so also picks up document references hanging off an invoice line. The same invoice can therefore fail in CII and pass in UBL.

What the validator checks

The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships. UBL and CII address different document trees, so the same rule reads differently in each.

UBL: count(cac:AdditionalDocumentReference) = count(cac:AdditionalDocumentReference[not(./cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename = preceding-sibling::cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename)])
CII: count(//ram:AdditionalReferencedDocument) = count(//ram:AdditionalReferencedDocument[not(./ram:AttachmentBinaryObject/@filename = preceding-sibling::ram:AdditionalReferencedDocument/ram:AttachmentBinaryObject/@filename)])

Source: rule set v2026-08-31

How do you fix BR-DE-22?

Give each attachment a unique name in the filename attribute (cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename in UBL, ram:AttachmentBinaryObject/@filename in CII) — simplest is the file's original name, with a running number if needed.

In the XML

A UBL fragment. The CII path is named above — same change, different element names.

Fails

<cac:AdditionalDocumentReference>
  <cbc:ID>1</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="anhang.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>2</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="anhang.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

Fixed

<cac:AdditionalDocumentReference>
  <cbc:ID>1</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="stundennachweis.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>2</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="lieferschein.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

Related rules

NormAPI provides technical validation, not tax or legal advice.