A readable PDF and structured data are different things
A standard PDF displays content for people. Structured invoice data assigns details to machine-readable fields. ZUGFeRD combines a PDF with embedded XML; XRechnung is a structured XML format. The linked primary sources explain applicable formats and exceptions.
The German Federal Ministry of Finance lists XRechnung and suitable ZUGFeRD formats as e-invoice options. The ZUGFeRD profile also matters. This validates neither an arbitrary export nor an OOKI feature. Check the actual file, specification and recipient requirements.
Three files, different checks
| File type | What is examined | What else needs clarification |
|---|---|---|
| Standard PDF | Visible details and readability | Whether the agreed or required format is present |
| XRechnung XML | Structured fields and business rules | Appropriate specification and receiving-channel requirements |
| ZUGFeRD | PDF representation and embedded XML data | Version, profile and consistency between both representations |
Include version and profile in acceptance testing
FeRD provides ZUGFeRD 2.5.2. A newly published specification does not mean a particular application already implements it. Nor does an export button label establish the profile actually used.
For a product test, record export date, application version, detected format version and profile. Validate that exact file with a suitable tool. Testing another file later is new evidence and should not silently replace the earlier test.
Prepare a meaningful export test
Fictional test invoice
Use a manageable example with clear items and traceable calculations. Do not use real client or bank details in a public test.
Identify the file
Keep the original file and test result together. Filenames can be confused across repeated exports; a checksum can support identification.
Compare both representations
For hybrid documents, compare recipient, items, quantities and totals in the visible document and structured data.
Test the receiving channel separately
Clarify how the recipient expects the file. Passing a local test does not confirm acceptance by their system.
What a successful validation report does not replace
Technical validation checks specific rules, not every question about the actual service, agreement or master data. A formally valid recipient name can still be the wrong recipient. Format validation therefore needs a substantive content review.
A useful sequence is: review services, review draft, export, validate format and confirm receipt requirements. Mixing these steps makes causes of errors harder to identify.
Legal requirements can change and include exceptions. Use current primary sources and professional advice where needed. This article explains a validation process, not the legal validity of an individual invoice.
Frequently asked questions
Is PDF/A-3 alone an e-invoice?
No. The container alone proves neither suitable structured invoice data nor correct content. The actual document and applicable format rules are decisive.
How do I test invoicing before adoption?
Generate a sample in the required format and test it with the recipient. Compare visible amounts and structured data. An export button or PDF preview is not enough.
From the guide to the sample project.
Try the steps in the OOKI demo: tasks, client view, time entries and invoice draft with fictional data. No login required.
Try the demo (DE)Further sources
- German Federal Ministry of Finance: e-invoicing FAQ ↗
Questions on formats, validation and transitional rules; check the current primary source for your case.
As of: - FeRD: ZUGFeRD 2.5.2 ↗
Format package and release notes. This does not identify the version implemented in OOKI.
As of: - KoSIT / XStandards Einkauf: XRechnung FAQ ↗
Structured invoices, technical validation and responsibilities.
As of: