Attestwire

Rule reference

BR-DE-22 Two embedded attachments carry the same filename "a.pdf" — supportingDocuments[0] and supportingDocuments[1]

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.

This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.

Business term
BG-24 / BT-125
Severity
fatal

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

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 locates the element in the generated UBL document, which is where a KoSIT or Peppol validator will report the same problem.

A passing value

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

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.

All 292 rules →

Nearby: BR-DE-23-a — The payment means type code (BT-81) is "58", which XRechnung treats as a credit transfer, so the CREDIT TRANSFER group (BG-17) must be present; BR-DE-20 — The payment means type code (BT-81) is "59" (SEPA direct debit), so the debited account identifier (BT-91) should be a valid IBAN — but "DE98700500001234567891" fails the ISO 7064 MOD-97-10 check digits; BR-DE-23-b — The payment means type code (BT-81) is "58", which XRechnung treats as a credit transfer (codes 30 and 58), so the PAYMENT CARD INFORMATION (BG-18) group must not be present — but it is.

Check this rule against your invoice via the hosted API → https://api.attestwire.com/docs

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.