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

The `mimeCode` of an embedded attachment must be one of six values: PDF, PNG, JPEG, CSV, Excel xlsx or OpenDocument spreadsheet. Anything else fails.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Code lists, Process and references
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-24/
- Explanation last updated: 2026-09-24

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

| Term | Meaning | UBL element |
|---|---|---|
| BT-125 | Attached document | `cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject` |
| BT-125-1 | Attached document Mime code | `cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@mimeCode` |
| BT-125-2 | Attached document Filename | `cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename` |

## 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`.

## 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

```xml
<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

```xml
<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.

### What the validator reported

- The failing invoice reports **BR-CL-24** and `PEPPOL-EN16931-CL001`. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CL-24-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/supporting-document-valid.xml)

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

## 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](https://ironfang.uk/docs/finance/rules/BR-52.md)
- [PEPPOL-EN16931-R008 rejects an attachment element that has a MIME code but no file content](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-CL-24)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp