E-Invoices: The Invoice Is in Your Inbox, the Payment Is in Your Bank Statement

You paid an invoice in March. In August your tax advisor asks for it. You know the payment is in your bank statement, because there is a line for €476,00 going out on the 14th. But which invoice was that? The email is somewhere in a folder, the attachment is called RE-2026-0417.xml, and opening it in a browser gives you 300 lines of angle brackets. The bank line and the document belong together, but they never live in the same place.

Two kinds of e-invoice, one line each

XRechnung is an invoice as pure data: an XML file, no picture of an invoice at all. Public authorities in Germany require it.

ZUGFeRD (also called Factur-X) is a PDF you can read normally, with the same data quietly embedded inside it. This is what most business partners send.

Both carry the same thing: seller, invoice number, dates, and the VAT breakdown as numbers a machine can read. VAT is Umsatzsteuer, the tax on the invoice that you may be able to reclaim.

Since January 2025, German businesses have had to be able to receive these. Being able to receive one and being able to find it again in August are, it turns out, different problems.

What Pinke does with it

Belege is the page for invoices you received. Drop the file in, click Upload, and Pinke reads it.

It accepts three carriers: an .xml file, a ZUGFeRD .pdf, or a .zip with either one inside. Detection goes by content rather than file name, so a PDF that somebody saved as .xml still works.

A plain scanned PDF is refused, with an explanation. That is not stubbornness: a scan carries no structured data, so there would be nothing to read. You get a message saying the PDF contains no embedded e-invoice XML and is probably a plain PDF invoice rather than a ZUGFeRD one, instead of a silently empty row.

Pinke reads the header and the VAT totals only: invoice number, issue date, seller, and net / VAT / gross. Line items are deliberately skipped. For linking a document to a payment and filing it for tax, the totals are what matter, and parsing every line of every supplier's invoice format is a lot of work for information you would not look at.

The file you uploaded is kept as it arrived: the original bytes, downloadable later. A Beleg is evidence, so the document that actually came in is the one that stays. Upload the same invoice twice (which happens, because the same PDF often arrives twice) and Pinke tells you it is already there instead of making a duplicate.

Walking through one

Say your hosting provider, Nordlicht Hosting GmbH, sends the March invoice as a ZUGFeRD PDF. Invoice number RE-2026-0417, dated 12 March 2026, €400,00 net, €76,00 VAT, €476,00 gross.

1. Go to /belege and upload the PDF.
2. A row appears: date 12.03.2026, seller Nordlicht Hosting GmbH, invoice no. RE-2026-0417, and the three amounts. Under the seller name you also see their USt-IdNr, if the invoice carried one.
3. The Payment column shows a Find payment button. Click it.
4. Pinke lists Suggested payments, bank transactions that could be this one. Each has a percentage badge:

96% 14.03.2026 NORDLICHT HOSTING -476,00 € [Confirm] 72% 05.04.2026 NL HOST GMBH SEPA -476,00 € [Confirm]

1. Click Confirm on the right one, and the row shows a green check with the payment date and merchant.

Three signals produce that ranking. The gross amount is the anchor: it has to match within two cents or the transaction is not offered at all. The date is weighted next. Pinke looks from 5 days before to 90 days after the invoice date, because payment follows an invoice and rarely precedes it. The seller name counts least, because bank statements mangle merchant names beyond recognition. A name match adds confidence; a name mismatch never rules a candidate out.

That is why the second row above is still on the list: same amount inside the window, but the wrong month, so it is offered and ranked below.

Pinke never links anything on its own. A wrong link quietly corrupts your tax record, so you always click Confirm. If nothing fits, None of these records a deliberate no-match, and the Beleg stops showing up in the queue instead of nagging you forever. Change your mind later and the reset button on the row clears the link again.

Where it pays off

Open Tax Overview. Every transaction you tagged as tax-relevant is there, sorted into its German deduction category. Rows that have a Beleg linked now carry a paperclip that downloads the original invoice (the one your advisor wants) straight from the table.

The summary at the top gained a With Beleg count. Read it against the total number of tagged rows: the gap is exactly what still needs proof before you file. You get a number instead of a vague feeling that "some receipts are probably missing".

The CSV export carries two extra columns, Beleg no. and Beleg VAT. So whoever prepares the return can see at a glance which deductions have a document behind them and which are still only a line in a bank statement.

What this doesn't do

The current limits:

• It reads structured e-invoices only. Your paper receipt from the hardware store is not one, and Pinke will not pretend otherwise.
• Line items are not parsed, so you cannot split one invoice across two categories from the Beleg itself.
• Matching only suggests; you confirm each link. There is no bulk "link everything" button.
• Belege have their own page and are not in the main navigation yet. Reach them from /belege directly, or via the manage Belege link in Tax Overview.

The outcome

In March you upload the invoice and confirm the payment. That takes about fifteen seconds. In August you do not go looking for anything, because the paperclip is already sitting next to the bank line, and the count at the top of Tax Overview tells you how many are still missing.

Import your statements on /ingest (the welcome post covers the first import), drop your received e-invoices on /belege, and link each invoice to its payment while it is still fresh.

Pinke does not give tax advice. What counts is what your tax office or your tax advisor says.