Attestwire › Rule reference › BR-DE-22

BR-DE-22 Attachment filenames must be unique

noun · XRechnung · fatal · BG-24 / BT-125

Your invoice was refused because two embedded attachments carry the same filename. In an XRechnung every filename must be unique, so rename one of the attachments. In the standard the attachment sits in group BG-24 as field BT-125; BR-DE-22 is the rule that checks the names are unique.

Diese Regel auf Deutsch: BR-DE-22 — auf Deutsch erklärt.

Business term

BG-24 / BT-125 — Attached document

Severity

fatal

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Rename one of the attachments. Put the invoice number or an index in front, 2026-000142-anlage-1.pdf and 2026-000142-anlage-2.pdf, so the names stay unique even for documents of the same kind.

What the rule requires

The filename of each embedded attachment must be unique within the invoice. Two attachments called anlage.pdf break the rule even when their contents differ.

The reason is simple: two files with the same name cannot be told apart. Which of the two a receiver files or displays is unpredictable, and the rule stops the question from arising at all.

In this library the filename is supportingDocuments[].attachment.filename.

Das "filename"-Attribut aller "EmbeddedDocumentBinaryObject"-Elemente muss eindeutig sein

A passing value

"attachment": { "filename": "2026-000142-stundennachweis.pdf", "mimeCode": "application/pdf", "content": "JVBERi0xLjQK" }

Why it exists

On public contracts the attachments are often the actual evidence: timesheets, delivery notes, acceptance records. If one of them can no longer be matched, the invoice is cut or put on hold, and the cause is hard to see from outside. The rule catches it before it can happen.

What the library returns

The full error returned by @attestwire/en16931. It includes the rule ID, affected field and suggested correction. Developers can use this object in their application:

{
  "rule": "BR-DE-22",
  "field": [
    "BG-24",
    "BT-125"
  ],
  "severity": "fatal",
  "message": "Two embedded attachments carry the same filename \"a.pdf\" — supportingDocuments[0] and supportingDocuments[1]. XRechnung requires the filename attribute of every EmbeddedDocumentBinaryObject to be unique, because the receiving system writes the attachments out to one directory: a duplicate name means one document silently overwrites the other, and the one that survives is whichever the parser happened to reach last.",
  "fix": "Rename one of them. Prefix with the reference (BT-122) or an index — \"2026-000142-anlage-1.pdf\", \"2026-000142-anlage-2.pdf\" — so the names stay unique even when two attachments genuinely are the same kind of document.",
  "example": "\"attachment\": { \"filename\": \"2026-000142-stundennachweis.pdf\", \"mimeCode\": \"application/pdf\", \"content\": \"JVBERi0xLjQK\" }",
  "xpath": "/ubl:Invoice/cac:AdditionalDocumentReference[2]/cac:Attachment/cbc:EmbeddedDocumentBinaryObject",
  "docsUrl": "https://attestwire.com/rules/BR-DE-22"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

See also: BR-CL-24 — the MIME code an embedded attachment must carry.