Home › Guides

Germany: receive, validate and preserve an E-Rechnung

Receiving an electronic invoice means more than opening a PDF. AP must retain the structured invoice, understand what it says, establish whether the billed supply is correct and retrieve the evidence later. These tasks need to work even while a supplier is still entitled to use an outbound transition arrangement.

This guide builds an incoming-invoice process and a controlled path to outbound readiness. Use the German receipt and retrieval worksheet to assign owners and record acceptance evidence. The examples and operating controls are illustrative, not a certification of a particular ERP.

Separate incoming capability from outbound timing

Section 14 UStG defines an electronic invoice through a structured format enabling electronic processing and sets the relevant domestic business invoicing framework. Other electronic formats and paper are a separate category. A PDF alone does not become a structured invoice merely because it arrived by email. Determine the establishment, transaction and applicable exceptions with tax. German VAT Act, section 14.

BMF's current indexed FAQ distinguishes reception from outbound transitional rules. It describes the general outbound alternative through 31 December 2026, the extension through 2027 for issuers with prior-year turnover up to EUR 800,000, and separate qualifying EDI transition treatment. Do not apply those issuer concessions as a reason to reject a valid structured invoice received now. BMF: E-Rechnung FAQ.

Create a source-backed entity decision with transaction scope, exceptions, receipt arrangements and the business's own outbound timing. Put public procurement in a separate branch: XRechnung's public-sector origins do not make every private invoice a public-contract submission.

Establish one controlled receiving process

Inventory mailboxes, portals, network endpoints and invoices delivered through purchasing systems. Assign one intake owner and preserve a clear route into AP. Restrict changes to addresses and routing so that a supplier cannot be redirected by an unverified email request.

Capture the original message/document, receipt time, supplier identity and intake reference. Link attachments that explain the supply. Apply appropriate file-security checks, while ensuring that security tooling does not replace the invoice with an image and discard its structured content.

Keep business authenticity checks separate from file syntax. An invoice can be technically valid yet originate from an unauthorized party or contain fraudulent payment details. Follow the established supplier-change verification process before releasing funds.

Identify the actual format and release

Ask the intake service which formats and profiles it supports, and test the actual files. The statutory format test is about structured content and interoperability, not a filename. Where hybrid formats are used, identify the embedded structured component and ensure AP can inspect it.

KoSIT's XStandards page states that XRechnung 3.0 remains in force at least through 31 July 2027 and that the 4.0 material published in September 2026 is a preview, with final publication expected later. Pin a currently applicable specification and validation bundle rather than selecting the largest version number visible on the website. KoSIT: XRechnung and version status.

Record the accepted profile, schema/business-rule bundle, validation software and configuration date. Preserve older test results with their release. When a new bundle is introduced, compare changed rules against real supplier files and document any effect on intake before deploying it.

Separate three reviews

The first review is technical: can the file be parsed, does it match the claimed structure and which validation errors or warnings exist? Record the actual report. An operator should distinguish an unreadable file from a readable invoice with a missing commercial reference.

The second review is tax/content: are the relevant parties, dates, supply details and tax amounts correct for the transaction? Tax or a trained AP reviewer owns that decision. Do not infer input-tax entitlement from a schema pass.

The third review is commercial: does the invoice match the purchase order, receipt or approved service? Procurement and the receiving manager should resolve quantities, prices and disputes. Keep their decision alongside the original document without editing that original.

Section 14 also requires authenticity, content integrity and readability, and recognizes an internal control process establishing a reliable audit trail between invoice and supply. The recommended three-review design makes that evidence visible; the law does not prescribe this particular team chart. Section 14: authenticity and audit trail.

Preserve the structured evidence and retrieve it

Section 14b currently provides an eight-year invoice retention period, with the statutory starting rule and relevant conditions. Other record categories or proceedings can require a different treatment, so approve a record schedule instead of deleting everything eight years after the upload date. German VAT Act, section 14b.

The 2026 GoBD text addresses retaining the structured part of an E-Rechnung and the continuing records requirements. A readable rendering supports people, but the archive design must preserve the required structured evidence and any other material that independently needs retention. BMF: GoBD in the 2026 tax handbook.

Run a retrieval exercise from a posted payable back to the exact original, validation report, approval and supply evidence. Confirm that the viewer remains available and that export does not depend on the current supplier subscription. A backup copy alone does not demonstrate indexed, readable retrieval.

Work through one AP invoice

Assume Beispiel GmbH receives a domestic structured invoice DE-100 for EUR 2,000 net plus illustrative 19% VAT, total EUR 2,380. Tax has approved this simple treatment and document scope. There are no exemptions, mixed rates or special deductions.

Intake stores the original and assigns an internal reference. The validator passes the agreed release. AP checks supplier identity and invoice content. The receiving manager confirms that the invoiced service was delivered. Only then does the payment process proceed under the business's normal controls. The archive links the original, posted payable and approval evidence.

Now assume the attached readable PDF says EUR 2,500 while the structured data says EUR 2,380. AP does not choose whichever amount matches the purchase order. It records the conflict and requests clarification/correction through the approved tax and supplier process, preserving both received components. The disputed document remains visible rather than being overwritten by a corrected rendering.

In a separate, approved correction test, the supplier reduces the net charge by EUR 200, with EUR 38 VAT, total EUR 238. The remaining amount is EUR 2,142, comprising EUR 1,800 net and EUR 342 VAT. Check the relationship between original and correcting document, the accounting result and evidence retrieval. This arithmetic tests the workflow, not the legal validity of an unspecified correction method.

Handle duplicates and failed validation

A second delivery of the same invoice is not necessarily a new liability. Compare supplier, invoice identity and content, and retain delivery history without posting another payable. If the content differs under the same identifier, open an exception; do not silently replace the original.

A malformed file needs a supplier/integration resolution. A commercially disputed but technically sound invoice needs a purchasing decision. Give these different queues, owners and escalation targets. AP should be able to explain why an item is blocked and what evidence will release it.

If the supplier uses a lawful transition format, assess it using the applicable rules and document the decision. Do not call it structured merely to make a dashboard green. Conversely, do not force suppliers already sending usable structured invoices back to PDFs because AP has not configured its viewer.

Approve readiness

AP owns intake and matching; tax owns scope and invoice-content decisions; integration owns parsing and validation; records management owns retention/retrieval; procurement owns delivery disputes. The controller should approve a sample covering ordinary, duplicate, malformed and corrected invoices.

• ☐ The entity's inbound scope and outbound transition decision are separate.
• ☐ All receiving channels feed a controlled AP population.
• ☐ The original structured evidence and relevant attachments are preserved.
• ☐ Current applicable format/validation releases are documented.
• ☐ Technical, tax and commercial results have distinct owners.
• ☐ Duplicate and conflicting representations do not create extra liabilities.
• ☐ Corrections reconcile to the original and expected balance.
• ☐ Retention starts and exceptions follow an approved record schedule.
• ☐ An independent reviewer can retrieve and read the complete evidence pack.

Use ERP cutover and tax history when changing archives, and localization acceptance tests when reviewing a supplier's proposed solution.

Worksheet: German E-Rechnung receipt control worksheet

Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment.

Sources checked: 17 October 2026. BMF's FAQ was available through current official indexed excerpts but direct retrieval returned 503; the statutory and GoBD pages were separately consulted. Reopen the latest complete FAQ before publishing detailed exemption or transition advice.

Related on this site

• Country pages: key facts with sources
• E-invoicing matrix: country × ERP support
• All guides

Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17.

Related: Glossary – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more).

Page last updated: 2026-10-17 · Markdown version