Create an e-Invoicing PDF Workflow for Regulatory Compliance

Share this page

Create Hybrid Invoices for People and Business Systems

Electronic invoices often need to serve two audiences at once. People need a stable, readable invoice, while accounting, tax, procurement, and automation systems need structured data they can validate and process. A hybrid e-invoice places both representations in one document package: the PDF provides the visual invoice and embedded XML carries the machine-readable data.

ZUGFeRD and Factur-X use this model for electronic invoicing in Germany and France. Their aligned hybrid format combines a PDF/A-3 document with UN/CEFACT Cross Industry Invoice (CII) XML. The two components must represent the same transaction, and the surrounding attachment and metadata structure must identify the invoice correctly.

pdfRest now provides a purpose-built workflow to create and validate these hybrid invoices. Lower-level Add to PDF and Convert to PDF/A operations remain available for specialized document workflows, but most ZUGFeRD and Factur-X implementations should start with the Create ZUGFeRD PDF API Tool.

Use the Purpose-Built Tool for ZUGFeRD and Factur-X

The purpose-built workflow coordinates the invoice layers that a general attachment or conversion operation cannot evaluate on its own. It validates the CII XML, creates or evaluates the visual PDF, converts the document to PDF/A-3, embeds the invoice XML, writes the required metadata, and validates the completed package.

It supports ZUGFeRD 2.5.2 and Factur-X 1.09.2 profiles MINIMUM, BASIC WL, BASIC, and EN 16931. Profiles such as EXTENDED and XRECHNUNG are outside the current product scope and return a clear PROFILE_UNSUPPORTED finding rather than an ambiguous result.

This endpoint is the recommended path when the business objective is a ZUGFeRD or Factur-X invoice, because it understands the invoice contract rather than only the PDF operations used to assemble it.

Start from XML, Existing PDF, or Both

Different billing systems begin with different assets. The creation workflow supports three common cases:

XML only: Submit CII XML and let pdfRest generate the readable invoice, apply optional branding and regional formatting, package the file as PDF/A-3, and validate it.
PDF plus XML: Submit an existing visual invoice with the canonical XML. pdfRest preserves the supplied design when the invoice information it can reliably compare agrees.
Regenerate when necessary: Enable regenerate_pdf when canonical XML should produce a replacement visual invoice after a mismatch or incomplete content confirmation.

Generated and regenerated invoices can use a logo, regular and bold fonts, RGB or CMYK colors, a footer, label language, locale, currency presentation, date formatting, and decimal precision. This gives product teams a practical middle ground between a rigid generic invoice and a custom renderer they must build and maintain themselves.

Validate the Final Hybrid Package

A finished invoice can look correct and still fail machine processing. The XML may violate a business rule, the PDF may not genuinely conform to PDF/A-3, the attachment relationship may be wrong, required Factur-X metadata may be absent, or the visible invoice may contradict the structured data.

The standalone validation endpoint accepts a completed ZUGFeRD or Factur-X PDF and checks:

PDF/A-3 conformance
Embedded CII XML and supported profile
Applicable schema and invoice business rules
Attachment filename, MIME type, and relationship metadata
Required XMP properties and PDF/A extension schema
Detectable agreement between visible and structured invoice values

The response separates the overall VALID or INVALID decision from content-match confidence. An UNVERIFIED content match means no concrete mismatch was found, but the arbitrary PDF layout did not allow every value to be confirmed. That warning can be routed for review according to the organization's risk policy; confirmed mismatches remain blocking.

When Lower-Level PDF Tools Still Make Sense

The Add to PDF API Tool and Convert to PDF/A API Tool remain useful building blocks. They may be appropriate when a workflow uses a custom XML vocabulary, packages a non-invoice attachment, targets a document format outside the supported ZUGFeRD and Factur-X profiles, or deliberately owns all invoice validation and metadata logic elsewhere.

In such a custom workflow, Add to PDF can embed an XML file and Convert to PDF/A can create a PDF/A-3 document. The application remains responsible for the invoice-specific work those general tools do not perform:

Validating the XML profile, schema, code lists, calculations, and business rules
Ensuring the PDF and XML describe the same invoice
Writing and checking the required Factur-X or ZUGFeRD XMP metadata
Setting the correct attachment filename, relationship, and MIME type
Validating the completed hybrid package as one document

That flexibility is valuable for specialized systems, but it should be a deliberate architectural choice rather than the default way to build a standard ZUGFeRD or Factur-X invoice.

Choose the Right pdfRest Workflow

Choose Create ZUGFeRD PDF when you need to create or validate a supported ZUGFeRD or Factur-X invoice and want invoice-aware checks built into the workflow.
Choose Add to PDF plus Convert to PDF/A when you are building a custom package and your application already owns the complete invoice-specific validation and metadata contract.
Choose standalone validation when a completed hybrid invoice comes from a supplier, ERP, migration, or another generator and must be checked without modification.

All three approaches can use direct file uploads or pdfRest resource IDs. Resource-ID chaining keeps intermediate files on the processing service and avoids unnecessary download and upload cycles.

Keep Document Processing Separate from Invoice Delivery

pdfRest creates and validates invoice documents. It does not replace an ERP, accounting platform, French approved platform, German delivery channel, tax-reporting service, or archival policy. The application remains responsible for transaction approval, recipient routing, transmission, and retention.

This boundary lets teams add specialized PDF and invoice packaging without replacing the business systems that already own the invoice process.

Common Hybrid E-Invoicing Questions

Are ZUGFeRD and Factur-X separate technical formats?

The current German and French releases are technically aligned around the same PDF/A-3 and CII XML model. Market terminology and regulatory context differ, but one pdfRest implementation can create and validate the supported profiles for both workflows.

Can I validate standalone XML?

There is no separate XML-only validation endpoint. Submit the XML to the creation endpoint. pdfRest validates it before document generation and returns actionable findings when the data cannot produce a supported invoice. The standalone validator accepts completed hybrid PDFs.

Should I still use Add to PDF and Convert to PDF/A for ZUGFeRD?

Use the purpose-built Create ZUGFeRD PDF API Tool for a standard supported ZUGFeRD or Factur-X workflow. Use the lower-level tools when you intentionally need a custom package and are prepared to implement the invoice-specific rules and final validation elsewhere.

Use the Invoice-Aware Path by Default

General PDF tools can assemble the physical parts of a hybrid document. A purpose-built invoice workflow also understands why those parts must agree. Start with Create ZUGFeRD PDF for supported ZUGFeRD and Factur-X invoices, and keep the lower-level APIs available for the custom document jobs they are designed to solve.

Try creation and validation in API Lab to see how the workflow fits your invoice architecture.