PDF/A3 Support

RolfG

Is there any chance that PDF/A-3 support could be added, with embedding of external files like XML e.g. for ZUGFeRD EN 16931?

Generating the XML itself is not necessary — that would be nice of course — but I think it would be too much effort given how often the format changes

Garry

Hello, and thanks for the request and for scoping it so sensibly.

Objo's PDF support today (printing, report output and chart export, added in 26.7.2) produces standard PDFs, so PDF/A conformance and embedded attachments are not there yet. The scope you describe is probably right: rather than Objo constructing and validating the invoice XML (which, as you say, changes often) Objo would produce a PDF/A-3 document from its own PDF output and embed caller-supplied XML along with everything the standard requires around it: an output intent with an embedded colour profile, the XMP metadata including the ZUGFeRD conformance level, and the XML attached with the correct embedded-file relationship. You would continue to generate your EN 16931 XML yourself and hand it to Objo to embed.

I've now logged this as a formal feature request: https://feedback.objo.dev/feature/1557

The implementation looks tractable as a first-party post-processing step over PDFs Objo itself generates, which keeps it dependable across all supported platforms without third-party plugins, and conformance can be checked with open-source validators during development. I'm not promising a release date yet, but I am well aware the 2027 e-invoicing obligation makes the timing matter, and this is exactly the kind of small-business workload Objo is meant to support.

Garry

This is now implemented and will be in the next Studio release. Thank you for the patient scoping; what you asked for is exactly what shipped.

PrintJob.SavePDF now takes an options object. Setting Conformance to PdfConformance.PdfA3B produces an archival PDF/A-3B document (ISO 19005-3), and attaching your invoice XML with the matching conformance level writes everything ZUGFeRD/Factur-X requires around it - the XMP extension schema, the embedded-file registration with the Alternative relationship, an sRGB output intent, and the rest:

Var options As New PdfSaveOptions
options.Conformance = PdfConformance.PdfA3B
options.ConformanceLevel = "EN 16931"

Var attachment As New PdfEmbeddedFile
attachment.Filename = "factur-x.xml"
attachment.Data = MemoryBlock.FromText(invoiceXML)
options.EmbeddedFiles = [attachment]

If job.SavePDF("Rechnung_2026-0042.pdf", options) Then
  Print("E-invoice saved")
End If

The division of labour stays as we discussed: you keep generating the EN 16931 XML with the tooling you already trust and hand the bytes to Objo. The visual invoice pages come from your normal RenderPage drawing, unchanged, and Objo takes care of the PDF container side. Your existing single-argument SavePDF calls keep behaving exactly as before. The other profiles work too - pass BASIC, XRECHNUNG, and so on as ConformanceLevel (with xrechnung.xml as the filename for XRechnung, and PdfFileRelationship.Data for the MINIMUM and BASIC WL profiles, per the specification; Relationship defaults to Alternative, which is what the German EN 16931, BASIC, EXTENDED, and XRECHNUNG profiles require).

On conformance, which I know from other conversations is your main worry: during development I validated the output with veraPDF, which reports fully compliant PDF/A-3B with zero violations, and with the open-source Mustang validator, which accepted both the PDF container and the embedded EN 16931 XML when I embedded the official KoSIT sample invoice through the new pipeline. As always, the conformance of a finished invoice depends on the XML you supply, but the container is done properly - no third-party plugin involved.

The documentation will cover the full API when the release ships.

RolfG

Garry
I am more than impressed!
Makes it a lot easier to implement.
Thank you so much!

Garry

You're welcome.

Remember to spread the word about Objo - it's all I ask 🙂