attestwire, n.Get an API key

Attestwire › Rule reference › BR-DE-22

BR-DE-22 Attachment filenames must be unique within the invoice

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

For a sample invoice, the library reports: Two embedded attachments carry the same filename "a.pdf" — supportingDocuments[0] and supportingDocuments[1].

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

Business term
BG-24 / BT-125
Severity
fatal

The 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.

A passing value

the shape this field expects
"attachment": { "filename": "2026-000142-stundennachweis.pdf", "mimeCode": "application/pdf", "content": "JVBERi0xLjQK" }

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:

TeachingError
{
  "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.

All 306 rule pages

Nearby: BR-DE-23-a — A credit transfer code obliges the credit transfer group; BR-DE-20 — The debited account on a SEPA direct debit should be a valid IBAN; BR-DE-23-b — A credit transfer code rules out card and direct debit details.

Want a worked example for BR-DE-22? Ask, and it gets written.

Check your invoice in the browser, or over the API. Something wrong on this page?