On this page
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
filenameonly when a field in the document store is filled, and older records leave it empty.
How to fix it
- Find each attachment named in the findings; there is one finding per attachment without a name.
- Add a
filenameattribute holding the name of the file, with an extension that matches themimeCode, for example.pdfforapplication/pdf. - 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. - Make the file name a required part of every attachment in your export, next to the MIME code.
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: the timesheet PDF is attached without a file name
<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
<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 XMLDownload the corrected 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
InvoiceandCreditNote. When tried, a credit note with an attachment lackingfilenamereported this rule in the same way. - The MIME code is handled elsewhere: its value by
BR-CL-24andPEPPOL-EN16931-CL001, and its presence by the UBL schema itself. When tried, an attachment withoutmimeCodefailed the XSD layer, so no business rule ran. - When tried, an attachment missing its file name and declared as
application/octet-streamreportedUBL-DT-07,BR-CL-24andPEPPOL-EN16931-CL001together; each needs its own correction.
Related rules
- BR-52 requires the reference of the supporting document whose file this attribute names
- BR-CL-24 checks the MIME code that sits beside the file name
- PEPPOL-EN16931-R101 keeps line document references for invoiced objects, so a file belongs in a document-level reference
- 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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.
The official definition of 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.

