Extract PDF attachments
The service task "Extract PDF attachments" reads the files embedded in a PDF. The most important case is the e-invoice in ZUGFeRD or Factur-X format: The PDF contains a factur-x.xml or zugferd-invoice.xml with all invoice data. The service returns the name of each attachment and, for XML attachments, additionally the content as text, which can be evaluated in the next step with Convert XML file to JSON.
Technical name prio_pdfExtractAttachments · Category in the "Select service task" dialog: Documents & PDF
When is this service used?
- Reading incoming invoices: Musterfirma GmbH receives invoices from its hardware suppliers as ZUGFeRD PDF and takes invoice number, amount and items from the XML, without reading the PDF with AI.
- Detecting e-invoices: A gateway checks whether an incoming PDF contains an XML at all and then chooses the path "e-invoice" or "analyze PDF".
- Documenting the attachment list: The names of all embedded files are stored on the record.
Input
| Field | Type | Required | Meaning |
|---|---|---|---|
pdf |
file object | yes | The PDF from the Pantarey storage as {referenceId, filename, contentType} |
{ "pdf": incomingInvoice.pdf }
Output
An array with one entry per embedded file:
[
{ "name": "factur-x.xml", "data": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><rsm:CrossIndustryInvoice …" },
{ "name": "Lieferschein.pdf" }
]
name: File name of the attachment.data: The content as text, only for names ending in.xml(lower case). All other attachments return only the name; their content is neither returned nor saved as a file.- A PDF without attachments returns
[].
The result is stored under the result path, e.g. attachments. The XML is then accessed with attachments[name='factur-x.xml'].data.
Errors and behavior
- Missing input throws
No PDF provided for Attachment extraction; a value that is not a file object throws on loading (expected a reference object like { referenceId, filename, contentType }). - Unreadable PDFs (damaged, encrypted, faulty attachment structure) throw as well.
- Every error continues via an error boundary event; without one the instance ends in error with a resume point and an error email to the process owner. The service never returns
{status, message}. - No attachments is not an error: The result is
[], the process continues. - Time limit 900 seconds. Nothing is saved; the original stays unchanged.
- In the dry run the step shows a sample output from the catalog that may differ from the real result.
Example
A supplier invoice arrives at Musterfirma GmbH by email; the PDF is under incomingInvoice.pdf.
- Extract PDF attachments with
{ "pdf": incomingInvoice.pdf }, result pathattachments. - Gateway:
$exists(attachments[name='factur-x.xml' or name='zugferd-invoice.xml'])→ path "e-invoice", otherwise path "analyze PDF". - Convert XML file to JSON with
{ "xml": attachments[name='factur-x.xml' or name='zugferd-invoice.xml'].data }, result pathinvoice_xml. - Next step: A database step creates the incoming invoice with number, date and gross amount from
invoice_xml.
Frequently asked questions
The attachment is called RECHNUNG.XML, but data is missing.
The content is returned only for names ending in lower-case .xml. Upper-case letters in the extension are not recognized; the attachment appears with its name only.
Can an embedded PDF or CSV be used further?
No. For formats other than XML the service returns only the name. The content is not returned and not saved as a file.
How can I check whether a PDF is an e-invoice?
Check the result for an entry with name factur-x.xml or zugferd-invoice.xml, as in the example. An empty array means: no embedded files.
Next step
Convert XML file to JSON: turn the extracted XML into an object that JSONata can access.