BR-DE-20 - Attachment Metadata Requirements

What this rule checks

BR-DE-20 verifies that document-level attachments (BG-24) embedded in or referenced from an e-invoice carry the required metadata. Specifically, when a cac:AdditionalDocumentReference includes an embedded or external attachment, the following attributes must be present:

MIME type (mimeCode attribute) — e.g. application/pdf, image/png
Filename (filename attribute) — e.g. invoice-details.pdf

These attributes are expected on the cbc:EmbeddedDocumentBinaryObject element.

Why this rule exists

Germany’s GoBD regulations (principles for proper management and storage of books, records, and documents in electronic form) require audit-proof archival of all invoice-related documents. When attachments accompany an e-invoice:

The MIME type must be known so receiving systems can correctly process and display the attachment
The filename must be present for unique identification and archival
Long-term readable formats must be used (PDF/A is preferred)

Without this metadata:

ERP systems cannot automatically process the attachment
Archival is not GoBD-compliant
The recipient cannot determine the attachment type before opening it

What triggers a failure

The warning is triggered when:

Embedded attachment without mimeCode — cbc:EmbeddedDocumentBinaryObject is present but the mimeCode attribute is missing
Embedded attachment without filename — The filename attribute is missing from the cbc:EmbeddedDocumentBinaryObject element
External reference without sufficient metadata — A cac:ExternalReference points to a document but type and name are not identifiable

Failing XML example

<cac:AdditionalDocumentReference>
  <cbc:ID>ATT-001</cbc:ID>
  <cbc:DocumentDescription>Service report January 2024</cbc:DocumentDescription>
  <cac:Attachment>
    <!-- ERROR: mimeCode and filename are missing -->
    <cbc:EmbeddedDocumentBinaryObject>
      UEsDBBQAAAAIAGRhbW15LXBkZi1jb250ZW50...
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

The validator reports: BR-DE-20: The element “Attached document” (BT-125) must include mimeCode and filename attributes when an attachment is present.

The fix

Add the mimeCode and filename attributes to the cbc:EmbeddedDocumentBinaryObject element:

<cac:AdditionalDocumentReference>
  <cbc:ID>ATT-001</cbc:ID>
  <cbc:DocumentDescription>Service report January 2024</cbc:DocumentDescription>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject
      mimeCode="application/pdf"
      filename="service-report-2024-01.pdf">
      UEsDBBQAAAAIAGRhbW15LXBkZi1jb250ZW50...
    </cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

For external references:

<cac:AdditionalDocumentReference>
  <cbc:ID>ATT-002</cbc:ID>
  <cbc:DocumentDescription>Technical specification</cbc:DocumentDescription>
  <cac:Attachment>
    <cac:ExternalReference>
      <cbc:URI>https://example.com/docs/spec-2024.pdf</cbc:URI>
    </cac:ExternalReference>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

Edge cases and common mistakes

Supported MIME types

XRechnung recommends the following MIME types for attachments:

MIME type	Description	GoBD-compliant
`application/pdf`	PDF document	Yes (PDF/A preferred)
`image/png`	PNG image	Yes
`image/jpeg`	JPEG image	Yes
`text/csv`	CSV file	Yes
`application/xml`	XML document	Yes
`application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`	Excel file	Limited

Note: For long-term archival, PDF/A (ISO 19005) is recommended. The MIME type remains application/pdf, but the document should conform to the PDF/A standard.

Maximum attachment size

The maximum size for embedded attachments is not defined in the XRechnung specification, but:

Peppol limits the total message size to approximately 100 MB
Many Leitweg-ID recipients accept a maximum of 10-15 MB per invoice including attachments
Base64 encoding increases data size by approximately 33%

Recommendation: keep embedded attachments as small as possible. For large documents, use external references.

External references vs. embedded attachments

Embedded attachments (cbc:EmbeddedDocumentBinaryObject): The file is Base64-encoded within the XML. Advantage: everything in one document. Disadvantage: file size.
External references (cac:ExternalReference/cbc:URI): A link to an externally hosted document. Advantage: small file size. Disadvantage: link may break, availability not guaranteed.

For GoBD-compliant archival, embedded attachments are preferred because the completeness of the document is guaranteed.

Base64 encoding

The content of cbc:EmbeddedDocumentBinaryObject must be valid Base64-encoded. Common errors:

Line breaks within the Base64 string (allowed in XML, but some parsers struggle)
Truncated Base64 data (file was not fully encoded)
Wrong encoding (e.g., URL-safe Base64 instead of standard Base64)

Multiple attachments

An invoice can contain multiple cac:AdditionalDocumentReference blocks. Each block with an attachment must satisfy BR-DE-20 individually. The cbc:ID must be unique within the invoice.

Object reference vs. attachment

Not every cac:AdditionalDocumentReference is an attachment. When cbc:DocumentTypeCode has the value 130, it is a reference to the invoiced object — not an attachment. BR-DE-20 only applies to actual attachments that contain an cac:Attachment child element.

BR-DE-20 Attachment Metadata Requirements