E-invoice receiving software: how to receive and process e-invoices

Short answer: receiving an e-invoice is five jobs, not one. Your client has to be reachable on the channel suppliers use (Peppol, email or a government platform), the XML has to be accepted and checked, turned into a correctly coded bill, approved, and the original file kept for the retention period. E-invoice receiving software is whatever covers those jobs, and for most firms that means a network provider for the first step and a processing tool for the rest.

This article is an overview, not tax advice. Rules are as published on 31 October 2026; see our e-invoicing deadlines tracker for changes by country.

What does receiving an e-invoice involve?

An e-invoice is structured data, usually XML following the European standard EN 16931. It is built to be read by software, not by people. Germany's Ministry of Finance says as much: the XML file is not suited to visual inspection by the human eye and is designed to be imported straight into processing systems.

So "receiving" covers more than getting a file into an inbox:

1. Be reachable. Register on the network the supplier's country uses, or give suppliers an address they can deliver to.
2. Accept the file. Take in Peppol UBL, CII, XRechnung, ZUGFeRD or Factur-X, and keep it unchanged.
3. Check it. Is it a valid e-invoice, is it addressed to this client, has it already been received?
4. Book it. Read every line, apply the right account and tax code, get it approved, register the bill.
5. Archive it. Keep the XML itself, not just a PDF view, for the full retention period.

Our overview of e-invoicing software covers sending as well. This article stays on the receiving side, which is where accounting firms spend most of the work.

How do suppliers reach your client?

The channel depends on the country, and it decides which part of the setup your client needs first.

Peppol, step by step. Peppol uses a four-corner model. The supplier (corner 1) hands the invoice to its access point (corner 2). That access point uses the buyer's participant ID to look up, through a central locator, which service metadata publisher holds the buyer's details and which access point (corner 3) receives for the buyer. The invoice is delivered there and passed on to the buyer (corner 4). Your client never connects to the network directly: the provider does the registration and receives on its behalf. Belgium's portal adds that publication in the Peppol Directory counts as agreement to receive structured e-invoices, so register only once the processing side is ready.

Germany and email. The Ministry of Finance states that it is sufficient for the recipient to provide an email inbox, and that the inbox does not have to be reserved for e-invoices. In practice that means many German clients already receive XRechnung and ZUGFeRD files today, mixed in with ordinary PDFs. For country detail see Germany and Belgium.

What happens after the file arrives?

This is where receiving software earns its place, or where a firm ends up printing XML files.

Reading the XML. A raw XRechnung or UBL file is a few hundred lines of tags. Someone has to turn it into a bill: supplier, invoice number and date, every line with description, quantity, unit price and VAT rate, and totals. If the software only reads the header and total, the team is back to coding lines by hand.

Hybrid files. ZUGFeRD and Factur-X carry XML inside a PDF. In Germany the structured part is the invoice: the Ministry of Finance says that where the XML and the image differ, the XML takes precedence, and input VAT is claimed from the structured part. Software that reads the PDF picture and ignores the XML can book the wrong figures.

Checking. Three checks catch most problems:

• Addressee. Is the invoice actually for this client, with the correct name and VAT number?
• Validity. Does the file meet the standard? Germany's guidance gives a recipient who receives a dataset that does not meet the requirements a claim to a proper invoice.
• Duplicates. The same invoice often arrives twice during the transition: once over Peppol, once as a PDF by email from the supplier's accounts team. See how to detect and prevent duplicate invoices.

Coding and approval. Structured data removes typing, not judgement. Someone still decides that a line belongs on repairs rather than equipment, and someone approves the bill before it is booked and paid.

How long do you keep the original?

The XML is the legal invoice, so it is the XML that must be archived.

• Germany: the structured part must be kept in its original form, unaltered and in a format the tax authorities can evaluate by machine.
• Belgium: the portal says the recipient must keep the structured electronic invoice for the full storage period, and make sure it can be read, usually through a PDF rendering or a viewer.

A common mistake is converting the XML to a PDF, booking the PDF and discarding the file. The bill looks fine in the accounting software, but the archive no longer holds the invoice.

What to look for in e-invoice receiving software

A checklist for firms choosing a setup for many clients:

1. Channels covered. Peppol receiving for Belgian clients, a mailbox route for German ones, and the platform or clearance connection where France or Poland apply.
2. Formats read in full. Peppol UBL, CII, XRechnung, ZUGFeRD and Factur-X, with every line and the VAT rate per line, and the XML used over the PDF image for hybrid files.
3. One route for everything. PDFs, scans and photos keep coming from small and foreign suppliers for years. Two separate processes double the checking.
4. Duplicate checks across channels, including against bills already in the accounting software.
5. Coding suggestions from each client's history, with a person approving before anything is posted.
6. The original file kept and linked to the bill.
7. Many clients, one view. A firm should not log in to 40 portals to see what arrived.
8. Where data is processed, stated in writing.

Belgium's portal lists software in three groups: tools that only send, tools that send and receive, and tools that also process e-invoices in the accounting system. That split is a useful test for any vendor: ask which group it is in.

A worked example

Take a firm with a Belgian client that receives around 120 supplier invoices a month. Most domestic suppliers now send over Peppol. A French supplier sends Factur-X by email, a German one sends XRechnung by email, and a dozen small suppliers still send PDFs or paper.

Without a processing step, the firm has three inboxes: the Peppol provider's portal, the email account and the scan folder. Each invoice is opened, typed or copied into the accounting software, and checked for duplicates by memory.

With a single processing route, the Peppol provider delivers its files into the same queue as the emailed XML and the PDFs. Each invoice is read line by line, coded from the client's history, checked against bills already booked, approved and registered, with the original file attached. The team checks and approves; it does not type.

Where Invoreg fits

Invoreg covers the processing side of receiving. It reads XML e-invoices (XRechnung, ZUGFeRD/Factur-X, Peppol UBL) alongside PDFs, scans and phone photos, reads every line including the VAT rate per line, suggests coding from the client's history, flags duplicates against bills already in the accounting software, and registers the bill only after a person approves it. Invoices can be forwarded to a mailbox, and firms see every client organisation in one queue. See how the email inbox connector works.

It is not a Peppol service provider or a clearance connector, so your clients still need one of those to be reachable on the network. If processing received invoices is where your team spends its time, try it on your own invoices: the first 20 invoices are free.