BR-CL-24: Use a permitted MIME code for embedded attachments

The short answer

BR-CL-24 fails when the mimeCode attribute of a cbc:EmbeddedDocumentBinaryObject is not one of the six permitted values. Set it to the real type of the file, which has to be application/pdf, image/png, image/jpeg, text/csv, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet or application/vnd.oasis.opendocument.spreadsheet.

A file in any other format cannot be embedded as it is. Convert it to one of those formats first, PDF for a document, and change the file name to match.

What the rule checks

The rule reads the mimeCode attribute of every embedded attachment and compares it with the six permitted values as exact strings. Nothing is folded to lower case or trimmed: when tried, application/PDF and application/pdf with a trailing space both failed.

Near misses fail too. When tried, image/jpg, application/xml and text/csv; charset=utf-8 were each rejected; the JPEG value is image/jpeg, and a parameter after the type makes it a different string.

Only the attribute is judged. The rule does not decode the Base64 content, so it cannot tell whether the file really is the type the code claims.

An attachment with no mimeCode fails the XSD layer, since UBL requires the attribute on a binary object. A document linked through cac:ExternalReference/cbc:URI instead of embedded has no MIME code and is not checked; when tried, it passed.

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• The type comes from content sniffing that falls back to application/octet-stream when it cannot identify the file, as in the recorded example.
• A file extension lookup returns image/jpg for .jpg files or application/vnd.ms-excel for .csv files.
• The document store holds the original Word, XML or ZIP file and embeds it without conversion.
• The content type is copied from an upload form or HTTP header that adds a parameter, such as text/csv; charset=utf-8.

How to fix it

1. Identify the real format of each attached file.
2. If it is PDF, PNG, JPEG, CSV, xlsx or ods, set mimeCode to the exact value for that format, in lower case, with no parameters and no spaces.
3. If it is anything else, convert it to one of those formats before embedding it, and update the extension in filename to match.
4. Map formats with a fixed table of the six values rather than a general MIME library, so an unsupported file stops the export instead of being labelled application/octet-stream.

Validate your corrected invoice

Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: a PDF timesheet declared as application/octet-stream

<cac:AdditionalDocumentReference>
  <cbc:ID>TIMESHEET-001</cbc:ID>
  <cbc:DocumentDescription>Timesheet</cbc:DocumentDescription>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/octet-stream" filename="timesheet.pdf">JVBERi0xLjQK</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

Fragment of the corrected invoice: the same file declared as application/pdf

<cac:AdditionalDocumentReference>
  <cbc:ID>TIMESHEET-001</cbc:ID>
  <cbc:DocumentDescription>Timesheet</cbc:DocumentDescription>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="timesheet.pdf">JVBERi0xLjQK</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

Only the mimeCode attribute differs: application/octet-stream in the failing invoice, application/pdf in the corrected one, for the same content and file name. The failing document also reports PEPPOL-EN16931-CL001, the Peppol layer repeating this check against the same six values, so the one correction clears both.

Where it applies

• Applies to Invoice and CreditNote; when tried, a credit note attachment declared as application/octet-stream reported both rules.
• The same list is checked twice: BR-CL-24 in the EN 16931 layer and PEPPOL-EN16931-CL001 in the Peppol layer. Expect both findings together.
• The filename attribute is checked separately: when tried, leaving it out reported UBL-DT-07.
• An attachment element with a permitted MIME code but no content is reported by PEPPOL-EN16931-R008, not by this rule.

Related rules

• BR-52 requires the identifier of the supporting document that carries the attachment
• PEPPOL-EN16931-R008 rejects an attachment element that has a MIME code but no file content
• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of BR-CL-24 carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.