Skip to content

Ironfang Finance - Rule reference

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.

EN 16931Fatal: the document is invalidProcess and references

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.

TermMeaningUBL element
BT-125-2Attached document Filenamecac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename
BT-125Attached documentcac: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.

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

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.

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.