PDF Invoice from 2027: Input Tax Deduction and the €800,000 Rule

Does a PDF invoice still entitle the recipient to input tax deduction from 1 January 2027?

Direct answer: For a domestic B2B transaction that is subject to the e-invoicing obligation, an invoice recipient should no longer treat a simple PDF invoice from an invoice issuer with prior-year revenue of more than EUR 800,000 as a clean formal basis for input tax deduction from 1 January 2027. The safe route is to request a proper e-invoice, check the structured invoice component and set up the process cleanly for ERP, EDI or DMS.

The distinction is important: input tax deduction generally concerns the invoice recipient. The invoice issuer must issue the invoice in the correct form, but does not deduct input tax from its own outgoing invoice. This is exactly where a new risk arises in many finance processes from 2027: the supplier continues to send a PDF, but accounting needs an invoice for input tax deduction that formally fits the new e-invoicing logic.

This is not legal advice, but professional guidance for process, finance and IT decision-makers.

Why a simple PDF has no longer been the same since 2025

Until the end of 2024, a simple PDF sent by e-mail could still fall under the general concept of an electronic invoice. Since 1 January 2025, this has changed: an e-invoice only exists if it is issued, transmitted and received in a structured electronic format and enables electronic processing. According to the Federal Ministry of Finance (BMF), a simple PDF no longer falls under this definition precisely because it does not have a structured format. Invoices that do not meet these requirements have been considered “other invoices” since 2025; this includes paper invoices and unstructured electronic formats such as simple PDFs.

That is the core of the problem: a PDF can look digital, arrive by e-mail and be perfectly readable for humans. But that is not enough for the e-invoicing obligation: structured, electronically processable invoice data is required.

The EUR 800,000 threshold: what changes in 2027?

The transitional rules are staggered. From 1 January 2025 to 31 December 2026, according to the BMF, all invoice issuers may choose to issue an “other invoice” instead of an e-invoice. A paper invoice is always possible during this period; an “other invoice” in another electronic format, such as an e-mail with a PDF file, still requires the recipient’s consent.

In 2027, the rules become stricter. The extension until the end of 2027 only applies if the invoice issuer’s prior-year revenue does not exceed EUR 800,000. After the transitional periods expire, the use of an e-invoice is actually mandatory for transactions between domestic businesses.

For the central question of this article, this means: if the invoice issuer had revenue of more than EUR 800,000 in the previous year and no exception applies, it will no longer fall under the extended PDF / other-invoice transitional logic from 1 January 2027. In the domestic B2B standard case, a simple PDF is then no longer the correct invoice form.

What does this mean for the invoice issuer?

For the invoice issuer, the key issue from 2027 is the obligation to issue invoices in the correct form. If the issuer generated more than EUR 800,000 in revenue in the previous year and is billing a relevant domestic B2B transaction, it should no longer send a simple PDF invoice as the default, but an e-invoice in an accepted structured format.

This does not apply to every conceivable invoice. The e-invoicing rules only apply where there is an obligation under VAT law to issue an invoice at all. The BMF FAQ also names exceptions, such as B2C invoices, many tax-exempt transactions under Section 4 numbers 8 to 29 of the German VAT Act (UStG), and cases in which an e-invoice is not required despite an invoice obligation, for example small-value invoices up to EUR 250 gross, tickets and services provided by small businesses.

For day-to-day work, this means that the invoice issuer needs a simple decision logic in the outgoing invoice process by 2027 at the latest. Is the transaction domestic B2B? Does an exception apply? Is the prior-year revenue above EUR 800,000? Which format is being issued? Anyone who only answers these questions during dunning or when a customer asks has set up the process too late.

What does this mean for the invoice recipient and input tax deduction?

For the invoice recipient, the situation is particularly sensitive. The BMF letter dated 15 October 2025 clarifies: if there is an obligation to issue an e-invoice for a transaction, only such an e-invoice generally meets the requirements of Sections 14 and 14a UStG. If an “other invoice” is issued instead in such a case, it is generally not a proper invoice and therefore, in principle, does not entitle the recipient to input tax deduction.

The BMF letter refers to general principles of proof and adds that, where an “other invoice” is correct and complete in terms of content, certain requirements may regularly be considered fulfilled if the invoice is not corrected by subsequently issuing an e-invoice.

In practice, however, the conclusion remains clear: the clean standard process should not be built on exceptions, evidentiary discussions or later corrections. If only a simple PDF is received in the affected case, the invoice recipient should request a proper e-invoice and clarify internally whether the invoice is to be blocked, flagged or transferred into a clarification workflow until it has been corrected.

Simple PDF, ZUGFeRD and XRechnung: they are not the same thing

A frequent mistake in projects is: “We receive PDFs, so we have e-invoices.” That is exactly what is not true.

A simple PDF is usually only a visual or text-based file. It may be readable for humans, but it does not contain a structured e-invoice data set within the meaning of the new rules.

An XRechnung is a structured XML-based format. It does not include an additional invoice representation in the form of a PDF file; companies therefore usually need a viewer for human readability.

A ZUGFeRD / Factur-X document is a hybrid format: it combines a human-readable PDF representation with structured XML data. According to the BMF, XRechnung and ZUGFeRD from version 2.0.1, with the exception of certain profiles, meet the VAT requirements for an e-invoice in particular.

With hybrid formats, however, the decisive element is not the attractive PDF visual layer. With the introduction of mandatory e-invoicing, the data in the structured part of hybrid e-invoices, for example XML, is leading. If the structured part differs from the visual part, the structured data is decisive.

For finance teams, this means: a PDF file in the inbox is not automatically bad. But it must be checked: is it a simple PDF or a hybrid e-invoice format with a structured data set?

The problem is not only legal. It is operational.

From 2027, the question “PDF or e-invoice?” will no longer only be a tax question. It will become a process question.

Many companies have worked with PDF invoices for years: the supplier sends an e-mail, accounting opens the PDF, someone reads the invoice, checks mandatory information, types values into the ERP system or uses OCR, and then approval, payment and archiving continue. This works as long as people carry the process. But it scales poorly when formal requirements, structured formats and systematic validation are added.

This is where the gap between human readability and machine usability appears. A PDF is visible. An e-invoice is processable. An ERP system, an EDI system or a DMS does not want to look at a pretty invoice; it needs clean fields: supplier, invoice recipient, invoice number, performance date, tax amount, line-item data, payment terms, references and validation status.

Where PEDIF comes in

PEDIF does not replace tax advice, an ERP system, a DMS or an e-invoicing compliance check. PEDIF comes in at a different point: converting document-based processes into structured, further-processable data flows.

PEDIF’s positioning is: the partner may remain document-based, while the receiving system receives structured data. PEDIF is not simply OCR. OCR reads characters. PEDIF recognizes recurring business documents, works with fingerprint / augmented-intelligence logic and, in validated project contexts, can convert recurring layouts into structured outputs for ERP, EDI, XML, CSV, API or DMS workflows.

In the context of e-invoicing, this does not mean: “PEDIF guarantees input tax deduction.” It means: PEDIF is one building block for making invoice data from PDF-based and document-based intake channels structurally usable, making exceptions visible and supplying downstream systems more effectively.

Practical workflow: from PDF intake to structured invoice

A sensible target process could look like this:

1. An invoice arrives by e-mail, portal or another channel.

2. The process checks whether it is an e-invoice, a hybrid format or a simple PDF.

3. For hybrid formats, the structured part is extracted and checked against defined mandatory-field and plausibility rules.

4. For simple PDFs, the case is treated as a clarification case or as a document case that needs structuring.

5. PEDIF can recognize recurring PDF layouts and provide structured invoice data for target systems.

6. ERP, EDI, API, DMS or archive systems receive the data they can actually process.

7. Exceptions remain visible instead of disappearing unnoticed in a manual process.

In this context, No-Touch does not mean No-Control. It means: standard cases run in a more structured way, while exceptions receive attention.

Checklist for invoice recipients from 2027

For finance, AP, IT and ERP / EDI teams, a short checking logic is particularly important:

1. Is the transaction domestic B2B?

2. Was the service performed after 31 December 2026?

3. Did the invoice issuer have revenue of more than EUR 800,000 in the previous year?

4. Does an exception apply, for example small-value invoice, ticket or small-business service?

5. Is the incoming file a simple PDF or a structured format?

6. For ZUGFeRD / Factur-X: is the structured XML component present and evaluable?

7. If it is only a PDF: is a proper e-invoice being requested?

8. Is there a correction process?

9. Are exceptions documented?

10. Can ERP, DMS, EDI or API receive the structured data?

11. This checklist does not replace legal review. But it helps identify the typical breaking points in invoice intake early.

Common misunderstandings

Misunderstanding 1: “A PDF is electronic, so it is an e-invoice.”

No. Since 2025, “electronically transmitted” alone has no longer been enough. What matters is the structured electronic format that enables electronic processing.

Misunderstanding 2: “ZUGFeRD is simply a PDF.”

No. ZUGFeRD is relevant if the structured data set is present and the requirements are met. For hybrid e-invoices, the structured part is decisive.

Misunderstanding 3: “The invoice recipient only needs to be able to receive e-invoices from 2027.”

No. Since 1 January 2025, domestic businesses have had to be able to receive e-invoices; according to the BMF, an e-mail inbox is already sufficient for receipt.

Misunderstanding 4: “If a PDF is wrong, the input tax deduction is always definitively lost.”

This should not be stated so broadly. The BMF letter describes correction and proof logic. Operationally, however, it is safer to request a correct e-invoice and not to base the case on exception arguments.

Conclusion

From 1 January 2027, a simple PDF will no longer be sufficient for many domestic B2B invoices if the invoice issuer had revenue of more than EUR 800,000 in the previous year and no exception applies. For the invoice recipient, this is not a small format detail, but an input-tax and process risk.

The key decision is not: “Ban PDFs or not?” The better question is: “Which documents need to become structured, validated and system-ready?”

FAQ

Does a simple PDF invoice still entitle the recipient to input tax deduction from 1 January 2027?

In the affected domestic B2B standard case with an invoice issuer whose prior-year revenue exceeds EUR 800,000, a simple PDF invoice from 1 January 2027 should not be treated as a clean formal basis for input tax deduction. The BMF letter states that, where an e-invoicing obligation exists, only an e-invoice generally meets the requirements and an “other invoice” generally does not entitle the recipient to input tax deduction. However, there are references to principles of proof and correction, which is why individual cases should not be assessed too broadly.

Does the EUR 800,000 threshold apply to the invoice issuer or the invoice recipient?

The extended transitional period until the end of 2027 is linked, according to the BMF, to the invoice issuer’s prior-year revenue. If prior-year revenue does not exceed EUR 800,000, the deadline is extended until the end of 2027.

Is a PDF always an “other invoice”?

A simple, unstructured PDF is an “other invoice”. A hybrid format such as ZUGFeRD can, however, be an e-invoice if the structured data component is present and the requirements are met. For hybrid e-invoices, the structured part is leading.

Have companies had to be able to receive e-invoices since 2025?

Yes. According to the BMF, domestic businesses have had to be able to receive e-invoices since 1 January 2025. An e-mail inbox is sufficient for receipt.

What exceptions are there to the e-invoicing obligation?

The BMF FAQ mentions, among other things, B2C transactions, many tax-exempt transactions under Section 4 numbers 8 to 29 UStG, and certain cases such as small-value invoices up to EUR 250 gross, tickets and services provided by small businesses. In such cases, an “other invoice” may also be issued.

Can PEDIF automatically make a PDF invoice legally compliant?

No, it should not be phrased that way. PEDIF is not tax advice and does not guarantee legal compliance. In validated project contexts, PEDIF can help convert PDF-based invoice processes into structured data flows for ERP, EDI, XML, CSV, API or DMS. The legal classification of the specific case must be reviewed separately.