Tomas, CEO
Invoices and contracts have two long-term jobs: stay readable for the next audit, and carry machine-readable data for the e-invoicing mandates spreading across Europe. Plain PDF does neither reliably. PDF/A solves the first job, and PDF/A-3 with embedded Factur-X or ZUGFeRD XML solves both at once.
This guide explains which PDF/A version to pick, how the e-invoice formats fit in, and how to automate the conversion - with real input and output files at the end, each verified by the PDF/A validator.
A standard PDF can reference fonts it does not contain, load resources from outside the file, and use features that future viewers may drop. Open one ten years later and it may render differently, or not at all.
PDF/A (ISO 19005) is the archival profile of PDF. Every font, image, and color profile is embedded, external dependencies are forbidden, and the result renders identically decades later:
Regulators know this, which is why retention rules in finance, healthcare, and public procurement routinely require PDF/A for archived documents.
The converter supports every major version through the PdfaVersion parameter:
PDF/A-1 (ISO 19005-1:2005)
PDF/A-2 (ISO 19005-2:2011)
PDF/A-3 (ISO 19005-3:2012)
PDF/A-4 (ISO 19005-4:2020)
For e-invoicing with Factur-X or ZUGFeRD you need PDF/A-3, since only it may carry an embedded XML file. In practice the converter takes care of this: passing any InvoiceFormat automatically enforces PDF/A-3 output, whatever PdfaVersion says.
France's Factur-X and Germany's ZUGFeRD are the same idea under two names: a PDF/A-3 invoice that humans can read, with an EN 16931-compliant XML inside that accounting software can process. One file serves both audiences, which is why the format anchors e-invoicing across Europe:
The hybrid format has one limit worth knowing: it cannot travel over the Peppol network as-is, because Peppol expects UBL syntax rather than the CII XML these formats carry. If your invoices also need Peppol delivery, see our guide on converting ZUGFeRD and Factur-X to Peppol BIS Billing 3.0.
One request against the PDF to PDF/A converter. Without options it produces PDF/A-2b:
curl -X POST https://v2.convertapi.com/convert/pdf/to/pdfa \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-F "File=@credit-note.pdf" \
-F "StoreFile=true"Pick a different version with PdfaVersion (for example pdfA1b or pdfA4) when your compliance requirement names one.
What actually changes inside the file:
Add two parameters: the structured invoice XML and the format to embed. The output becomes a PDF/A-3 e-invoice:
curl -X POST https://v2.convertapi.com/convert/pdf/to/pdfa \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-F "File=@credit-note.pdf" \
-F "InvoiceFormat=zugferd2" \
-F "InvoiceFile=@credit-note.xml" \
-F "StoreFile=true"InvoiceFormat accepts facturX, zugferd2, and zugferd1. Pick the one your market expects - the French PDP ecosystem reads Factur-X, German systems read ZUGFeRD - and supply the matching EN 16931 XML in InvoiceFile.
The same call in C# with the official .NET SDK:
using ConvertApiDotNet;
var convertApi = new ConvertApi("YOUR_API_TOKEN");
var result = await convertApi.ConvertAsync("pdf", "pdfa",
new ConvertApiFileParam("File", @"C:\invoices\credit-note.pdf"),
new ConvertApiFileParam("InvoiceFile", @"C:\invoices\credit-note.xml"),
new ConvertApiParam("InvoiceFormat", "zugferd2")
);
await result.SaveFilesAsync(@"C:\invoices\archive");For batches, each conversion is independent - map your file list to tasks and run them in parallel. In an invoicing pipeline, generate the visual PDF and the XML from the same order data, then make this one call per invoice as the final step:
Do not trust metadata - a file can claim PDF/A while violating the ISO rules. Validate the result with the PDF/A validation endpoint, which returns a structured verdict:
curl -X POST https://v2.convertapi.com/convert/pdfa/to/validate \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-F "File=@credit-note-zugferd.pdf"Both sample files below were checked exactly this way and came back "validationStatus": "Compliant". For the full validation workflow, including CI checks, see how to validate PDF/A compliance programmatically.
One fictional credit note, run through the exact calls above:
Note the last one: no PdfaVersion was passed, and the converter still produced compliant PDF/A-3 because InvoiceFormat was set.
PDF/A is a constrained profile of PDF built for archiving. Everything the document needs is embedded, and features that endanger long-term rendering (external references, encryption, JavaScript) are forbidden.
PDF/A-3, because it is the first version that allows embedded files. You do not need to set it manually - any InvoiceFormat value switches the output to PDF/A-3 automatically.
No. The page content is preserved - the conversion embeds fonts and color profiles and strips forbidden features. File size can change in either direction, as the samples above show.
Not necessarily. Metadata can lie, especially in files produced by older tools. Run the file through the validation endpoint and trust the structured verdict instead.
ZUGFeRD 2.0 aligns with EN 16931 and Factur-X, and it is what current German requirements expect. Use zugferd1 only when a legacy system on the receiving end demands it.
Yes. Each conversion is stateless, so parallel calls work - and conversion workflows can chain generation, conversion, and validation server-side in one request.
Archiving and e-invoicing are one conversion, not two projects. Convert the PDF to PDF/A for durability, pass InvoiceFormat and InvoiceFile when the document is an invoice, and validate the output before it enters the archive. Try it with your own files on the PDF to PDF/A converter page - the interactive demo generates working code while you experiment.