# UBL-DT-07: Add a filename attribute to every embedded attachment

A `cbc:EmbeddedDocumentBinaryObject` has no `filename` attribute. Give every attachment a file name, with an extension that matches its `mimeCode`.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Process and references
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-DT-07/
- Explanation last updated: 2026-09-28

## The short answer

`UBL-DT-07` fails for each embedded attachment, a `cbc:EmbeddedDocumentBinaryObject`, that has no `filename` attribute. Add the name the file should be saved under, such as `filename="timesheet.pdf"`, beside its `mimeCode`.

The schema lets this through, because UBL makes the file name optional while it makes the MIME code mandatory. The EN 16931 binding closes that gap, so that the receiver has a name to store and open the file under.

## What the rule checks

The rule looks at every element whose name ends in `BinaryObject`, so each attachment is checked on its own. When tried with two supporting documents and no file names, it reported twice, once at each `cbc:EmbeddedDocumentBinaryObject`.

The attribute only has to be present. When tried, `filename=""`, a name of three spaces and a name with no extension, `timesheet`, all passed every layer, so the file name is not checked for content or format.

An attachment given by address does not count. When tried, a supporting document whose `cac:Attachment` held only `cac:ExternalReference/cbc:URI` passed, because it contains no binary object.

Where the attachment sits does not matter. When tried, a PDF attached without a file name to a document reference on an invoice line reported this rule there as well, together with the warning `UBL-CR-544`, since files do not belong on a line, and `PEPPOL-EN16931-R101`, since that reference had no type code `130`.

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

## How an integration ends up here

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

- The attachment is built from the file content and its content type, and the original file name is not carried through.
- Attachments generated on the fly, such as a rendered timesheet, never had a file name to pass on.
- The mapping writes `filename` only when a field in the document store is filled, and older records leave it empty.

## How to fix it

1. Find each attachment named in the findings; there is one finding per attachment without a name.
2. Add a `filename` attribute holding the name of the file, with an extension that matches the `mimeCode`, for example `.pdf` for `application/pdf`.
3. Where no original name exists, derive one from the supporting document reference, such as `TIMESHEET-001.pdf`, rather than writing an empty value that satisfies the rule but helps nobody.
4. Make the file name a required part of every attachment in your export, next to the MIME code.

## Before and after

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

Fragment of the failing invoice: the timesheet PDF is attached without a file name

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

Fragment of the corrected invoice: the same attachment named timesheet.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>
```

The only difference is the `filename` attribute: absent in the failing invoice, `timesheet.pdf` in the corrected one; the reference, description, MIME code and content are the same. The failing document reports `UBL-DT-07` alone, at the `cbc:EmbeddedDocumentBinaryObject`, in the EN 16931 layer; the XSD and Peppol layers accepted it.

### What the validator reported

- The failing invoice reports **UBL-DT-07**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/UBL-DT-07-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/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 with an attachment lacking `filename` reported this rule in the same way.
- The MIME code is handled elsewhere: its value by `BR-CL-24` and `PEPPOL-EN16931-CL001`, and its presence by the UBL schema itself. When tried, an attachment without `mimeCode` failed the XSD layer, so no business rule ran.
- When tried, an attachment missing its file name and declared as `application/octet-stream` reported `UBL-DT-07`, `BR-CL-24` and `PEPPOL-EN16931-CL001` together; each needs its own correction.

## Related rules

- [BR-52 requires the reference of the supporting document whose file this attribute names](https://ironfang.com/docs/finance/rules/BR-52.md)
- [BR-CL-24 checks the MIME code that sits beside the file name](https://ironfang.com/docs/finance/rules/BR-CL-24.md)
- [PEPPOL-EN16931-R101 keeps line document references for invoiced objects, so a file belongs in a document-level reference](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R101.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

[The official definition of UBL-DT-07](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-DT-07/) 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.com/docs/finance/rules/UBL-DT-07)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp