BIS 3 XML attachments: formats, limits and PDF invoices

A Peppol BIS Billing 3.0 invoice is an XML document. That XML is the invoice: it contains the structured data that accounting software can validate, post and process automatically. Sometimes the invoice also needs supporting material, such as a timesheet, a delivery record or a human-readable PDF. BIS 3.0 supports sending that material with the invoice as an XML attachment.

This distinction matters. A PDF can make an invoice easier for a person to read, but it does not replace the structured BIS 3 invoice. The XML remains the document that systems should use for validation and automated processing.

Where an attachment belongs in BIS 3

Attachments are carried in cac:AdditionalDocumentReference/cac:Attachment. The group is optional and may occur more than once. The official UBL Invoice syntax in Peppol BIS Billing 3.0 describes the complete structure and the difference between a document reference, an external URL and an embedded document.

For an embedded file, the important element is cbc:EmbeddedDocumentBinaryObject. It has two mandatory attributes:

• mimeCode, which identifies the media type of the file;
• filename, which gives the name that the recipient should use for the file.

A minimal embedded PDF looks like this:

1
2
3
4
5
6
7
8
9

<cac:AdditionalDocumentReference>
  <cbc:ID>invoice-representation</cbc:ID>
  <cbc:DocumentDescription>Human-readable invoice representation</cbc:DocumentDescription>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject
      mimeCode="application/pdf"
      filename="invoice-2026-0042.pdf">JVBERi0xLjQK...</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

The value in the element is not the raw PDF. It is the PDF represented as Base64 text.

Which formats are supported?

BIS Billing 3 does not allow an arbitrary MIME type. The receiver must accept the restricted list defined by the official Media type code of attached document code list:

The mimeCode must be one of these values. The filename extension should agree with it. For example, do not label a ZIP file as a PDF or send an Excel file with mimeCode="application/pdf". A validator may reject the invoice, and a receiving system should not have to guess what it has received.

BIS also supports an external document reference instead of embedding the file. That means the invoice contains a URL in cac:ExternalReference/cbc:URI. An embedded attachment is usually more reliable for invoice evidence because the file travels with the invoice and does not depend on a future HTTP request, authentication or link lifetime.

10 MiB versus 100 MiB

Two size figures are often mixed together:

• 10 MiB is the commonly checked limit for the complete XML message. This is not a limit for one attachment. The check normally covers the BIS XML invoice together with its embedded attachments and the message content that the Access Point receives. Several attachments can therefore exceed 10 MiB even when each individual file is small.
• 100 MiB is the general transport capability. A message should generally be able to work up to 100 MiB, but the exact limit is an Access Point policy. Some Access Points can reject a message much sooner, including messages that are below 100 MiB.

Base64 makes each embedded binary value roughly one third larger than the original file, before the surrounding XML, MIME packaging and security overhead are counted. The relevant size check is therefore the final message as sent, not just the size of the files on disk. Implementations should measure the complete encoded message and leave room below the limit enforced by the chosen Access Point.

For large supporting material, use a smaller, relevant export or an external reference agreed with the recipient. Do not turn the invoice into a general-purpose file archive, and confirm the effective size limit with the receiving Access Point before sending large messages.

How is the file encoded?

The file bytes are encoded as Base64 and placed in cbc:EmbeddedDocumentBinaryObject. Base64 uses ordinary XML-safe characters, so the binary file can travel inside the XML structure without being interpreted as markup.

When producing an attachment:

1. Read the original bytes without converting them through a text encoding.
2. Base64-encode those bytes.
3. Set the correct mimeCode and filename.
4. Decode the value before sending and compare it with the original file in tests.
5. Validate the complete BIS invoice, including the attachment metadata and size checks.

The receiver reverses the process: it reads the Base64 value, decodes it into bytes, and stores or processes the resulting file. The encoding protects the XML syntax; it is not encryption and does not prove that the file is safe. Access Points and receiving applications still need normal malware scanning and content validation.

Why send an attachment at all?

Structured XML is excellent for automation, but it cannot carry every piece of evidence that a business process may need. An attachment can keep related material together with the transaction:

• a timesheet supporting service hours;
• a delivery or acceptance report;
• a calculation or usage statement;
• a photo or other image relevant to the invoice;
• a spreadsheet used to explain a complex charge;
• a PDF representation for people who need to review or archive the invoice visually.

Sending the supporting file through the same Peppol exchange improves traceability. The recipient does not have to match an email attachment or download a file from a link that may later expire. At the same time, the attachment should support the invoice, not contradict it. Amounts, tax information and supplier or buyer identifiers must be taken from the structured BIS data and validated there.

Why might an Access Point add a PDF?

Some Access Points generate a PDF representation of an XML invoice and add it as an attachment as an invoice preview. This can be useful when the recipient’s accounting workflow still includes a human review step, when a user wants a familiar printable view, or when an archive needs a visual representation alongside the machine-readable source.

That PDF is a convenience representation, not a second authoritative invoice. It should be generated from the XML after validation, clearly named, and labelled with mimeCode="application/pdf". It must not silently change the invoice totals, VAT categories, payment references or parties. A receiving system should prefer the XML for posting and use the PDF as a view or reference.

An Access Point should also make this behaviour clear. Recipients may not expect a generated PDF, and adding one increases message size. If an existing PDF was supplied by the sender, the Access Point must not replace it with a different representation without a clear rule and an auditable reason.

A practical checklist

Before sending a BIS 3 invoice with attachments, check that:

• the XML invoice itself is valid Peppol BIS Billing 3.0;
• every embedded file uses an allowed MIME type;
• every embedded file has a meaningful, unique filename;
• the bytes are Base64-encoded and can be decoded byte-for-byte;
• each attachment stays within the 10 MiB practical limit;
• the complete AS4 message stays comfortably below 100 MiB;
• the attachment supports the invoice and does not become the source of financial truth;
• recipients know whether a PDF was supplied by the sender or generated by the Access Point.

The result is a useful compromise: the XML remains precise and automatable, while the supporting documents travel with the transaction and remain available to the people who need them.

Sources: Peppol BIS Billing 3.0, UBL Invoice syntax, Media type code of attached document, and the Peppol AS4 Profile.