Hi Abdullatif,
Short answer: F&O won't give you PDF/A-3 out of the box. Neither the SSRS print path nor the ER (Electronic reporting) PDF output supports embedded file attachments, which is exactly why you land on PDF/A-1b. The XML side — the signed / cleared invoice plus the TLV QR — comes from the Electronic invoicing add-on, and the two artifacts are simply never merged. So this is a development task rather than a setting, and the design decision that matters most is where you do the merge.
1. Get the timing right before you write any code.
For standard (B2B) tax invoices, the XML you embed has to be the ZATCA-cleared document returned by the clearance call — not the one you signed locally. That means the PDF/A-3 must be produced after the Electronic invoicing service reports successful clearance, not at posting time. For simplified (B2C) invoices you can generate immediately and embed the signed XML, since those are reported within 24 hours. If you keep printing at posting, you'll ship PDFs with the wrong XML inside them, and that only surfaces during an audit.
2. Do the merge outside the AOS.
Take the ER/SSRS PDF/A-1b plus the cleared XML and post-process them in an Azure Function (or Logic App) using a library with real PDF/A-3 support — iText 7 and PDFBox both handle it. Then push the result back into F&O as a document attachment (DocuRef) on the invoice journal, or into blob storage if your archive lives outside. Doing it in-process through an X++ → .NET class library reference also works, but keeping it as a separate service makes the ZATCA retry / resubmit logic far easier to live with, and lets you re-generate a PDF without touching the ERP.
3. The PDF/A-3 conformance details are where these projects usually lose time:
the file spec needs /AFRelationship (use /Data for the invoice XML) and /Subtype /application#2Fxml
the attachment must be registered both in /Names → /EmbeddedFiles and in the catalog-level /AF array — add page-level /AF too if your validator is strict
XMP metadata must carry pdfaid:part = 3 and pdfaid:conformance = B; if you add invoice-specific metadata you also need a declared XMP extension schema
everything PDF/A-1b already required still applies: fully embedded fonts, an output intent with an ICC profile, no transparency
The good news is that since your current output is already PDF/A-1b, you're starting from a compliant base — you're mostly adding attachment plumbing and bumping the conformance level, not reworking the report itself.
4. Validate in two places, ideally in CI.
veraPDF for PDF/A-3B conformance, and the ZATCA SDK validator for the embedded XML. A file that opens perfectly in Acrobat can still fail veraPDF, and veraPDF is the one that counts.
One thing worth confirming before you build: check the current version of the ZATCA e-invoicing specification on whether PDF/A-3 is actually mandated for your invoice type or only permitted as the human-readable form. That determines whether this is a hard compliance requirement or an internal archiving improvement — and it changes how much you invest in it.
Happy to go deeper on the merge step if you share how you're currently triggering the print.
— PixelPlex team — custom software development & enterprise integrations https://pixelplex.io/services/custom-software-development-company/
