Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-60 | Fatal (error) | cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject |
| Schematron ID: ibr-075 | Field: Item attached document (ibt-125), filename attribute (ibt-125-2) | ||
Classification
Syntax & Integration — a structural attribute check on the same binary object element as BR-59, tested independently.
What the Rule Is Checking
Any embedded binary attachment must carry a filename attribute alongside its mime code. The rule tests only for presence, not for a sensible or unique value — a filename of doc.pdf passes as readily as one that actually identifies the content.
Why This Rule Exists
A mime code tells a receiving system what kind of file it has; the filename tells a human what to call it once extracted. In practice, buyer AP teams and ASPs frequently pull attachments out of the XML into a document store, and a missing filename means the file lands with a generated placeholder name that carries no context — useless when someone is trying to locate the delivery note for a specific invoice six months later during an audit. The two attributes solve different problems and PINT-AE requires both rather than treating them as interchangeable.
Standard / Code List
No restricted code list applies. The filename is free text, though in practice it should reflect the actual document (for example delivery-note-INV-2026-0842.pdf) rather than a generic label.
UAE Data Example
PASSES ✓: <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="signed-goods-receipt.pdf">...</cbc:EmbeddedDocumentBinaryObject>
FAILS ✗: The mime code is present but the filename attribute is entirely absent, because the attachment was generated through an API call that only mapped the content-type field and never mapped a name field from the source document management system.
What Your ERP / IT Team Must Ensure
Map both attributes from the source document, not just the one that happens to be readily available in the integration you built first. Where attachments originate from a third-party DMS, confirm the API response actually returns a filename field and that it survives the round trip into the UBL payload rather than being dropped during transformation. Keep filenames meaningful and traceable back to the invoice they belong to — this matters operationally even where the schematron rule itself only checks presence.
Related Rules
Paired with the mime code requirement in BR-59. Both attributes sit on the same element and both are independently mandatory.