Last updated at
October 20, 2026
Learn more about this by booking a demo call with us. Our team will guide you through the process and answer any questions you may have.
Book NowA ZUGFeRD invoice shows a net amount of €5,000 in the PDF, but its embedded XML records €5,500. An accounts payable team reviewing the PDF may approve one amount while its accounting system imports another. The discrepancy can affect payment approval, accounting records and VAT checks.
Under the BMF's guidance applicable from 1 January 2025, the structured invoice data take precedence when they conflict with the human-readable PDF. This determines which representation governs the discrepancy, not whether the recorded values reflect the actual transaction.
ZUGFeRD is a hybrid e-invoice format that combines a human-readable PDF with structured XML invoice data in a single file. The PDF supports visual review, while the XML allows accounting and other business systems to extract and process invoice information automatically.
| Component | Purpose | What businesses should know |
| Displays invoice information in a readable layout | Employees can review the invoice visually, including its line items and totals. | |
| XML | Stores structured invoice information | Accounting systems can extract invoice fields for automated processing. |
For German VAT purposes, the structured component of a ZUGFeRD invoice must meet the applicable e-invoicing requirements. ZUGFeRD version 2.0.1 and later, excluding the MINIMUM and BASIC-WL profiles, can meet these requirements where the applicable EN 16931 requirements are satisfied. These requirements form part of Germany's e-invoicing framework.
Although both components represent the same invoice, their values can diverge. Mismatches can arise when invoice-generation software uses different data sources for the PDF and XML, a template contains outdated values, field mapping is incorrect, or an integration fails to transfer updated invoice data.
Germany’s e-invoicing rules distinguish between the information that takes precedence in a hybrid invoice and whether that information is correct. For ZUGFeRD invoices, this distinction matters when the human-readable PDF and embedded XML show different amounts or VAT details.
The Federal Ministry of Finance (BMF) addresses this issue in question 12a of its official e-invoicing FAQ. Until 31 December 2024, the visual representation could take precedence under the earlier approach. From 1 January 2025, the structured data became decisive when the PDF and XML conflict.
Accounts payable teams should use the XML to identify the invoice information that takes precedence. They must still verify the disputed amount against the underlying transaction and applicable VAT treatment.
Legal precedence, technical validation and factual accuracy address different questions.
| Question | What it establishes |
| Which representation takes precedence? | The structured data takes precedence when the PDF and XML conflict. |
| Does the XML pass technical validation? | The file meets the checks applied by the selected validation configuration. |
| Does the invoice reflect the actual transaction? | The amounts, commercial terms and VAT treatment must be checked against the underlying transaction. |
A technically valid XML file can still contain an incorrect price or VAT treatment. A PDF/XML mismatch does not automatically trigger § 14c UStG. The provision may become relevant where an invoice separately states a VAT amount that exceeds the tax due or states VAT without entitlement. Businesses should assess the actual tax statement and circumstances rather than treating the discrepancy itself as the legal trigger.
Compare the PDF with the embedded XML to identify which fields differ and whether the discrepancy affects invoice requirements, the agreed transaction or internal processing. Prioritise information that could change the amount payable, the VAT calculation or the identification of the parties.
| Information group | Details to compare | Why it matters |
| Invoice identity | Invoice number, invoice date, supplier details and buyer details | Differences can affect invoice matching, traceability and compliance with invoice requirements. |
| Amounts and VAT | Quantities, unit prices, net amount, VAT rate, VAT amount, gross total and currency | Incorrect values can lead to payment differences, inaccurate postings or VAT errors. |
| Transaction details | Description of goods or services, purchase order references and delivery information | These details help establish whether the invoice reflects the agreed transaction. |
| Payment information | Payment terms, due date and bank details, where relevant | Differences may disrupt payment processing or require confirmation. |
Not every field in the table is a statutory invoice requirement in every situation. Payment terms and bank details, for example, are not universally mandatory invoice fields. Their inclusion helps businesses identify operational problems as well as potential compliance issues.
If the PDF shows €5,000 before VAT but the XML records €5,500, check the line items, agreed prices and applicable VAT rate. The difference could originate in a unit price, quantity, calculation or underlying transaction. Comparing only the final totals may not reveal its cause.
The PDF view may not show the exact values that an accounting system extracts from the embedded XML. To investigate a mismatch, access the structured data and locate the disputed field before deciding how to resolve it.
The ELSTER E-Rechnungsviewer can display supported e-invoice data in a human-readable format. It may help finance teams inspect structured invoice information without reading raw XML.
Check the viewer's current upload requirements and supported formats before using it with a particular ZUGFeRD invoice. If the file is supported, compare the disputed value in the invoice information displayed by the viewer with the corresponding value in the original PDF. The viewer helps reveal what the structured data contains. It does not establish which value matches the contract or whether the invoice's VAT treatment is correct.
If a compatible viewer is unavailable, inspect the XML embedded in the PDF.
The embedded filename can vary by implementation, so do not assume every invoice uses the same filename. A dedicated invoice viewer is generally easier for non-technical users than reading raw XML, where values appear as structured elements rather than in the same visual order as the PDF.
Inspection and validation serve different purposes. Inspection reveals the values stored in the XML; validation checks whether the file meets the technical requirements and business rules applied by the validator.
Choose a validator that supports the specific ZUGFeRD profile used in the invoice and applies the relevant validation rules. The official XRechnung resources explain the XRechnung standard and its validation framework. However, an XRechnung validator should not be assumed to support every ZUGFeRD profile.
A successful validation confirms that the XML passes the checks applied by the selected configuration. It does not establish whether the invoice reflects the agreed price or correct VAT treatment. Those questions require a review of the underlying transaction.
A mismatch can disrupt invoice processing and raise questions about tax treatment. The consequences depend on the affected information and whether the discrepancy changes the amount payable, the underlying transaction or the VAT calculation.
If the PDF contains additional or conflicting invoice information, businesses should assess whether the circumstances meet the requirements of § 14c UStG, which addresses certain cases of VAT being incorrectly or unjustifiably stated. A mismatch between the PDF and XML does not, by itself, mean that § 14c UStG applies.
The BMF's e-invoicing FAQ explains the treatment of structured invoice data and conflicting information. Whether the discrepancy affects input VAT deduction or creates other tax consequences depends on the specific error and the applicable VAT provisions. A mismatch alone does not establish that input VAT deduction is unavailable or that a penalty applies.
Even where a discrepancy does not create a separate tax liability, it can affect routine finance operations.
Investigate the discrepancy before deciding whether the invoice can proceed through normal processing. The objective is to establish the correct transaction details, determine whether a correction is required and retain evidence of the decision.
Identify the affected field and record the value shown in the PDF alongside the value stored in the XML. Retain the original invoice, including its embedded structured data, so the investigation refers to the document actually received.
Compare the disputed information with the purchase order, contract, agreed prices, delivery records and applicable VAT treatment. This evidence helps establish whether the XML value is correct or whether the invoice contains an error.
For example, if the contract specifies €5,000 before VAT but the XML records €5,500, establish the reason for the difference before approving the amount.
Describe the discrepancy and request clarification. If the investigation confirms that the invoice requires correction, ask the supplier to issue a corrected invoice that meets the applicable requirements.
Where an e-invoice is legally required, the correction must also be issued as an e-invoice, using the appropriate invoice type for a correction. A revised PDF alone does not correct inaccurate structured invoice data when an e-invoice is required. However, the applicable transition rules may permit corrections in another format, subject to the relevant conditions.
A difference in presentation does not automatically mean the entire invoice must be replaced. The BMF allows certain minor differences, such as shortened descriptions for display or rounding differences, provided the PDF remains an equivalent representation of the same invoice and the differences do not affect the invoice’s substantive information. The appropriate correction depends on the discrepancy's nature and the applicable requirements.
After receiving clarification or a correction, compare the PDF and XML again. Verify that the invoice reflects the agreed transaction and passes the relevant validation checks before returning it to normal processing.
Record the discrepancy, supporting evidence, supplier communication, any correction received and the internal decision to approve, hold or reject the invoice. Retain the original invoice and any corrected version so finance and audit teams can trace how the issue was resolved.
Under § 14b UStG, invoices generally must be retained for eight years. For an e-invoice, at least the structured component must be retained intact in its original form. If the human-readable part contains additional tax-relevant information, that information must also remain available for tax review.
Separately, the GoBD set out broader requirements for the proper retention and accessibility of electronic records. Businesses must consider these requirements alongside the VAT-specific invoice retention obligation.
Conclusion
When a ZUGFeRD PDF and XML disagree, the structured XML takes precedence under German guidance applicable from 1 January 2025. Businesses must still verify that the recorded values reflect the actual transaction and correct VAT treatment. Investigating discrepancies, obtaining corrections where necessary and retaining all tax-relevant invoice information help prevent payment errors and unreliable records. For businesses managing structured invoices across multiple jurisdictions, global e-invoicing solutions can form part of a wider approach to managing country-specific invoice requirements and exchange workflows.
Which part of a ZUGFeRD invoice takes precedence if the PDF and XML differ?
From 1 January 2025, the structured XML takes precedence when the PDF and XML conflict under applicable German guidance. However, this does not confirm that the XML reflects the correct transaction or VAT treatment.
Can a ZUGFeRD invoice be valid if its PDF and XML contain different amounts?
Not necessarily invalid. The recipient must investigate the difference and check its effect on invoice requirements, transaction accuracy and VAT treatment. Depending on the circumstances, conflicting PDF information may have separate tax consequences.
Can I view ZUGFeRD XML without accounting software?
Yes. Use the ELSTER E-Rechnungsviewer if the format is supported, or extract the embedded XML using software that can access PDF attachments. A compatible invoice viewer can make the data easier to read.
Should I process or pay an invoice if its PDF and XML disagree?
No. Investigate the discrepancy, check the transaction records and request clarification or correction before approving payment.
Quick Navigation
Learn more by booking a demo with our team. We'll guide you step by step.