How to Extract German Invoice
(Rechnung) Data to Excel
Most invoice extraction guides assume your invoices look like generic US-style bills. But when your supplier sends a Rechnung from Düsseldorf — with a Steuernummer, a Leistungsdatum that differs from the invoice date, and a VAT split between 19% and 7% rates — spreadsheet-import tools built for Stripe invoices or QuickBooks templates fall apart. This guide covers what actually matters for German invoices: the mandatory fields under §14 UStG, the VAT structures that determine what gets extracted where, and how to land data in a format your Steuerberater can use.
Key Takeaways
- Missing one field on a German Rechnung doesn't just mean incomplete data — the Finanzamt (German tax office) can deny your entire input VAT deduction, and the legal risk sits with your business, not the supplier who sent the invoice.
- A single German invoice can land in four different VAT regimes — standard 19%, mixed 19%+7%, §13b reverse charge (where the buyer self-assesses tax), or Kleinunternehmer exemption — each demanding a different set of spreadsheet columns, so a generic tool's single "tax" column produces data your Steuerberater (tax advisor) cannot use.
- Column names that describe what the data means — "USt-IdNr" for the supplier's VAT ID, "Leistungsdatum" for the service date — work across all four VAT regimes and every supplier layout, because ImageToTable.ai reads meaning not position on the page.
Why German Invoices Defeat Generic Extraction Tools
A German Rechnung is not a translated US invoice. It is a legal instrument governed by §14 of the Umsatzsteuergesetz (UStG) — the German VAT Act — with ten mandatory fields whose presence or absence determines whether your business can reclaim input VAT (Vorsteuerabzug). When a field is missing or incorrectly formatted, the Finanzamt can deny your input VAT deduction. The supplier gets paid either way. Your business bears the risk.
This is also why general-purpose invoice OCR tools — even ones that handle English-language invoices well — break on German invoices. They are not built to distinguish a Rechnungsdatum (invoice issue date) from a Leistungsdatum (date the service was performed) — two legally distinct dates required under German law. They do not validate whether a USt-IdNr follows the DE123456789 format. They collapse the 19% and 7% VAT rate distinctions into a single "tax" column, which is unusable for filing a Umsatzsteuervoranmeldung (German VAT advance return) through ELSTER.
None of this matters if you process 3 domestic invoices a month and manually key everything into Lexware. It matters considerably when you handle 80 Rechnungen a month from 25 German suppliers — each with different layouts, some as PDFs, some as photographed paper copies, some arriving with §13b reverse charge treatment that requires zero VAT extraction and a different booking logic entirely.
What §14 UStG Actually Requires on Every German Invoice
§14 Abs. 4 UStG lists ten mandatory fields — the Pflichtangaben — that every full German invoice must contain. If you are extracting data to Excel for accounting purposes, each of these fields maps to a column in your spreadsheet — and missing any one of them can mean your data is unusable for DATEV import or for claiming input VAT.
| German Field | English Translation | Why It Matters for Extraction |
|---|---|---|
| Vollständiger Name und Anschrift (des leistenden Unternehmers und des Leistungsempfängers) | Full name and address of both supplier and recipient | Two separate address blocks — supplier and buyer. Cheap OCR often merges them or misidentifies which is which. |
| Steuernummer oder USt-IdNr | Tax number or VAT identification number | Kleinunternehmer use Steuernummer. VAT-registered businesses use USt-IdNr (DE123456789 format). If you extract the wrong one or extract neither, the invoice is invalid for VAT deduction. |
| Rechnungsnummer | Sequential invoice number | Must be unique and gapless. Your extracted data needs this for audit trail matching. |
| Rechnungsdatum | Invoice issue date | Not the same as the delivery date. German invoices carry both dates — extraction tools that output a single "date" column conflate them. |
| Leistungsdatum / Leistungszeitraum | Date or period when the service was delivered | Unique to German and some EU invoices. Required to determine in which VAT period the input tax deduction belongs. Most generic extraction tools do not even look for this field. |
| Menge und Art der gelieferten Gegenstände oder Umfang und Art der Leistung | Quantity and description of goods or scope and type of service | German Rechnungen often carry lengthy, legally precise item descriptions. Line-item extraction needs to preserve the full description text, not truncate it. |
| Nettobetrag | Net amount (per tax rate) | Must be split by VAT rate — a single €100 net line that covers both 19% and 7% items is not compliant. Extraction must capture separate net amounts per rate. |
| Umsatzsteuersatz und -betrag | VAT rate and VAT amount | The rate (19% or 7%) and the corresponding amount must both appear. If the invoice applies §13b reverse charge, the VAT line says "0" and a reference to §13b must be extracted. |
| Bruttobetrag | Gross total amount | Must reconcile with net + VAT. Some tools extract a "total" that doesn't match because they missed a discount or surcharge line. |
| Hinweis auf Steuerbefreiung (if applicable) | Reference to tax exemption | For Kleinunternehmer (§19 UStG): "Gemäß §19 UStG wird keine Umsatzsteuer berechnet." For intra-EU: reverse charge notice. Missing these notices = invalid invoice for the recipient. |
Two practical exceptions reduce the field count. Invoices below €250 gross qualify as Kleinbetragsrechnungen under §33 UStDV, requiring only: supplier name and address, invoice date, description of goods/services, gross amount, and applicable VAT rate or §19 disclaimer. And for Kleinunternehmer under §19 UStG — businesses whose prior-year turnover did not exceed €22,000 — invoices must not show VAT at all and must instead include the statement that no VAT is charged per §19. Extraction rules change depending on which category the invoice falls into.
The German VAT Maze: When One "Tax" Column Won't Do
The extraction logic for a German invoice changes materially depending on which VAT regime applies. A single "VAT Rate" and "VAT Amount" column pair only works for the simplest case. German invoices can fall into one of four scenarios, each requiring different column definitions:
| VAT Scenario | Legal Basis | What to Extract | Common Source of Error |
|---|---|---|---|
| Standard rated (19%) | §12 Abs. 1 UStG | Net amount, 19% VAT amount, gross total. One row if only standard-rate items. | Tools that guess VAT rate from totals instead of reading the stated rate. |
| Mixed rates (19% + 7%) | §12 Abs. 1 + Abs. 2 UStG | Separate net and VAT columns per rate. Example: Net 19% column, VAT 19% column, Net 7% column, VAT 7% column — plus total gross. Common in hospitality and food invoices. | Tools that output one aggregated VAT figure. Your Steuerberater needs the split for the Umsatzsteuervoranmeldung, specifically Kennzahlen 81 and 86. |
| Reverse charge (§13b) | §13b UStG | Net amount only, zero VAT, plus the reverse charge reference text. Must also capture the supplier's foreign VAT ID and the recipient's USt-IdNr (both required per §14a Abs. 2). | Tools that still populate a VAT amount because they found a "tax" label — or miss the reverse charge notice entirely. |
| Kleinunternehmer (§19) | §19 UStG | Gross amount only, no VAT breakdown. Must capture the §19 disclaimer text to confirm the invoice is intentionally VAT-free. | Tools that flag "missing VAT" as an error. For a Kleinunternehmer invoice, missing VAT is correct — flagging it is wrong. |
For businesses that receive invoices from German suppliers across multiple VAT categories — a common scenario for hospitality groups that buy food (7%) as well as equipment (19%) from Metro and Transgourmet — the extraction tool needs to be flexible enough to output different column structures per invoice type, not force every invoice into the same template.
How AI-Powered Extraction Handles German Invoice Formats
This is where the difference between template-based OCR and AI-driven extraction becomes concrete. Template-based tools require you to define field coordinates for every supplier layout — a Metro invoice layout is different from a Transgourmet layout, which is different again from a local Handwerker's Rechnung. The maintenance burden scales with every new supplier.
ImageToTable.ai takes a different approach: Custom Column Extraction. Instead of teaching the tool where fields sit on the page, you define what you want extracted by typing column names — "Rechnungsnummer", "Leistungsdatum", "Nettobetrag 19%", "USt-Betrag 19%", "Nettobetrag 7%", "USt-Betrag 7%", "USt-IdNr" — and the AI locates each value anywhere on the page by understanding what the field means, not where it sits. This works across supplier formats without per-vendor configuration: one column definition covers Metro, Transgourmet, Selgros, and the independent Tischlerei next door.
Files are processed securely and not stored.
Try uploading a German Rechnung in the demo above. Define columns matching the §14 UStG fields you need — start with Rechnungsnummer, Rechnungsdatum, Leistungsdatum, Lieferant, Nettobetrag, USt-Satz, USt-Betrag, Bruttobetrag, and USt-IdNr — and see what the AI extracts. The same column definition works when you switch to a different supplier's invoice layout, because the AI reads meaning, not position.
For batch processing — uploading a month's worth of Metro and Transgourmet invoices in one go — the tool extracts each invoice into one row of a merged spreadsheet. You get one Excel file with every Rechnung as a row, ready for filtering by supplier, date range, or VAT rate before handing off to your Steuerberater.
From Extraction to Accounting: What Your DATEV, Lexware, or sevDesk Workflow Expects
Extracting data is only the first half of the job. In Germany, the second half is landing that data in accounting software in a format your Steuerberater can use without rework. The destination matters because each platform has different expectations:
DATEV — used by an estimated 60–70% of German tax advisors — expects data through Kanzlei-Rechnungswesen (CSV in DATEV-Format) or Unternehmen Online (XML). The CSV format requires specific columns: Belegdatum, Buchungstext, Gegenkonto, Betrag, and most critically, the correct Buchungsschlüssel (posting keys) and Kontierung (account assignments per SKR03 or SKR04). If your Steuerberater expects pre-coded accounts, your extraction output needs an extra column for the DATEV account number. If they handle Kontierung themselves, you can skip it — but ask them first.
Lexware Office (formerly lexoffice) — at €7.90/month, the most widely used cloud accounting platform for German SMEs — imports via its own CSV structure or direct bank feed. It auto-categorizes transactions but expects incoming invoice data to include the supplier's USt-IdNr for VAT validation. If that field is missing from your extraction, Lexware will flag the invoice for manual review.
sevDesk — the modern challenger at €12.90/month — imports contacts and Belege (documents) via CSV with its own template. The CSV upload is straightforward but expects Belegart (document type) classification: Eingangsrechnung, Ausgangsrechnung, or Gutschrift. If your extraction doesn't distinguish these, you'll be manually reclassifying rows after import.
The common thread: German accounting software expects German invoice data structures. A generic extraction that outputs "Supplier", "Date", and "Total" will require substantial manual reformatting before any of these platforms accept the import. Defining extraction columns to match the target software's schema directly — for example, naming your column USt-IdNr instead of "VAT Number", and Belegdatum instead of "Date" — eliminates the reformatting step.
The same approach to extraction also works for international invoices arriving in multiple languages and formats, since the column-name semantics remain consistent regardless of the invoice's original language.
GoBD and E-Invoicing: Keeping Your Extracted Data Audit-Ready
In Germany, extracting invoice data is not just an efficiency question — it carries legal obligations for record-keeping. The GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern) is the tax authority's framework for digital bookkeeping. Its core principles — Nachvollziehbarkeit (traceability), Unveränderbarkeit (immutability), and Verfügbarkeit (availability) — mean that every extracted data point must be traceable back to the original invoice, and every original invoice must be preserved for 10 years under §147 AO in its original format.
A July 2025 amendment to the GoBD clarified a critical point for e-invoice archiving: for structured e-invoices (XRechnung and the XML layer embedded in ZUGFeRD PDFs), the machine-readable XML is the authoritative record. The human-readable PDF only needs to be archived if it contains additional tax-relevant information not present in the XML — such as posting remarks or payment conditions handwritten on the visual layer. For most businesses, this means the extracted Excel file is your working data set, but the original XML file is what auditors will request.
Germany's B2B e-invoicing mandate (E-Rechnungspflicht) phases in as follows:
- January 1, 2025 — All German B2B companies must be able to receive e-invoices in EN 16931-compliant format (XRechnung or ZUGFeRD 2.1).
- January 1, 2027 — Companies with prior-year turnover above €800,000 must also send e-invoices.
- January 1, 2028 — All German B2B companies must send e-invoices. Paper and PDF invoices are no longer accepted for domestic B2B transactions, except for Kleinbetragsrechnungen under €250 and Kleinunternehmer under §19.
The practical implication for data extraction: your inbound invoice mix is already changing. ZUGFeRD PDFs arriving in your inbox carry an embedded XML data layer that a capable extraction tool can read directly, bypassing OCR entirely for those fields and delivering 100% accurate structured data. For suppliers still sending plain PDF Rechnungen (allowed during the transition period through 2027), AI extraction bridges the gap — reading the visual PDF and outputting the same structured columns.
What matters for compliance is that your extraction workflow preserves the connection between extracted data and source document. If you batch-extract 40 Rechnungen into one Excel file and archive only the Excel file, you fail GoBD. The original documents — whether XML, PDF, or scanned paper — must remain accessible and retrievable for 10 years.
Frequently Asked Questions
Does this work with scanned paper Rechnungen and mobile phone photos?
Yes. The AI reads document content semantically — it doesn't need a clean digital PDF. Photographed paper invoices, scanned documents, and screenshots of online invoices are all supported. Quality matters: if the photo is too blurry to read the USt-IdNr digits, no tool can extract them reliably. But for legible photos, extraction accuracy is comparable to PDF input.
Can the tool distinguish between Rechnungsdatum and Leistungsdatum?
Yes, provided you define separate columns for each. If you define a column called "Rechnungsdatum" and another called "Leistungsdatum", the AI understands these are two distinct date fields and returns the correct value for each. If you only define a single "Date" column, the AI will default to the invoice issue date as the primary date — it won't guess that you also need the service date. The column names you choose drive the extraction.
How does extraction handle §13b reverse charge invoices?
For §13b reverse charge invoices, define your columns to include the net amount, a VAT rate column (which will extract as 0%), and a column for the reverse charge reference text. The AI will not erroneously populate a VAT amount because the invoice itself does not charge VAT — it states that the recipient self-assesses. You should still extract the supplier's foreign VAT ID and your own USt-IdNr from the invoice, as both are mandatory fields under §14a Abs. 2 UStG for reverse charge treatment.
What about ZUGFeRD and XRechnung — can the tool parse embedded XML?
When you upload a ZUGFeRD PDF, the AI reads the visual PDF layer. It does not parse the embedded XML directly. For fields present in the XML, this produces the same end result — structured columns — but the approach is visual reading rather than XML parsing. For XRechnung pure XML files, the tool is not designed to process raw XML; you would need an XML-to-CSV converter for those. In practice, most German suppliers issuing ZUGFeRD invoices embed the XML inside a viewable PDF, which works with the visual extraction approach.
Can I process Metro, Transgourmet, and Selgros invoices in a single batch?
Yes. Since extraction is driven by column-name semantics rather than per-supplier templates, you upload invoices from all three wholesalers in one batch and define your columns once. The AI locates Rechnungsnummer, Lieferant, Nettobetrag, USt-Betrag, etc. on each document independently. The output is one merged spreadsheet with a row per invoice and consistent columns across all suppliers.
Is extracted data GoBD-compliant for audit purposes?
The extracted Excel file is a working copy, not your audit archive. GoBD compliance is about how you store the original documents, not how you use extracted data operationally. As long as you retain the original invoices — PDFs, XML files, or scanned paper copies — in an unalterable, retrievable format for 10 years, extracting data from them for accounting workflows does not violate GoBD. The extraction tool itself does not provide archival storage; you are responsible for document retention separately.
Getting Your German Invoice Data Where It Needs to Go
German invoice extraction sits at the intersection of three concerns that are usually treated separately: data accuracy, tax compliance, and software compatibility. The tools that handle one well tend to ignore the others. Template-based OCR can be accurate for a single supplier's format but requires rebuilding for every new supplier. Manual entry into Lexware keeps data in the right structure but doesn't scale past 30 invoices a month. AI parsing of ZUGFeRD XML gives 100% accuracy on e-invoices but does nothing for the paper Rechnung from the local Elektriker who still prints and mails his bills.
A workflow built around semantic extraction — defining what you need by column name rather than by template position — handles all three concerns simultaneously. It extracts the fields §14 UStG requires, preserves the VAT structure your Umsatzsteuervoranmeldung needs, and outputs columns that match your accounting software's import schema. And it works the same way whether the invoice arrives as a ZUGFeRD PDF, a photo from a supplier's camera phone, or a scanned paper document from 2023.
Free to try — no account required for the first 50 pages.