Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-59 | Fatal (error) | cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject |
| Schematron ID: ibr-074 | Field: Item attached document (ibt-125), mimeCode attribute (ibt-125-1) | ||
Classification
Syntax & Integration — the rule checks a structural attribute on the embedded binary object element, not the business content of the invoice line.
What the Rule Is Checking
Wherever an invoice carries a supporting document as a binary attachment — a PDF backup, a signed delivery note, a scanned certificate — the element that holds that attachment must carry a mimeCode attribute. No attribute, no pass. The rule does not check whether the mime type is correct for the actual file content, only that the attribute is present.
Why This Rule Exists
A recipient system that receives a binary blob with no declared type has to guess what it is before it can render or store it correctly, and guessing from file signatures is exactly the kind of brittle logic an e-invoicing platform is meant to eliminate. The mime code lets the receiving corner — buyer AP system, ASP, or FTA platform — decide immediately whether to display the attachment, reject it as an unsupported format, or pass it through untouched. Without it, a valid PDF backup can arrive unusable on the other side simply because nothing told the recipient what to do with the bytes.
Standard / Code List
Mime type values follow the IANA media type registry (for example application/pdf, image/jpeg). PINT-AE does not restrict which mime types are acceptable, only that one is declared.
UAE Data Example
PASSES ✓: <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="delivery-note.pdf">...</cbc:EmbeddedDocumentBinaryObject> — a scanned delivery note attached to a UAE B2B invoice with the mime code declared.
FAILS ✗: The same PDF embedded with the mimeCode attribute dropped during export, because the ERP's attachment module was configured for a different document type that doesn't require it. The base64 content is otherwise valid, but the invoice fails validation before it reaches the buyer.
What Your ERP / IT Team Must Ensure
Confirm that whichever module generates attachment references — scanned document management, DMS integration, or a manual upload feature in the invoicing screen — populates the mime code from the actual file type rather than leaving it blank or hardcoding a single value across all attachment types. Test with more than one file format, since a hardcoded application/pdf will pass validation but mislabel an actual image attachment. Treat this as a checklist item during any attachment-handling change, because it is easy to miss in testing when the attachment feature itself is rarely exercised.
Related Rules
The filename attribute on the same binary object element is covered separately in BR-60 — the two attributes are checked independently, and a payload can fail on either one alone.