How an invoice leaves: Peppol and email

Two channels, and in Germany they are peers rather than a first choice and a fallback. The mandate is about the format of the document, not the pipe it travels down.

Email is a complete answer in Germany

The German rule is a format obligation. The BMF letter of 15 October 2025 says no channel is prescribed, and that email, a portal, an interface or any channel the parties agree all qualify. An EN 16931 document attached to an email discharges §14 UStG exactly as a Peppol transmission does.

So Zeppol treats email as a first-class channel. The buyer gets the same UBL document and a human-readable PDF of the same invoice. Emailed e-invoices are unlimited on every paid plan, because they cost almost nothing to send.

Peppol, and what a send actually does

Peppol works on a four-corner model. You hand the invoice to your Access Point, it routes over the network to your buyer's Access Point, and that one delivers it into your buyer's system. Zeppol connects through a certified Access Point rather than being one.

Before sending, Zeppol looks the buyer up on the network to confirm they are published as able to receive this document type. A buyer who is not published stops with RECIPIENT_UNREACHABLE, which is a routing fact rather than a fault, and the invoice can go by email instead.

Why the final state is "handed over"

This is the most important paragraph on the page, and it is the one that differs from what several competing apps show you.

A Peppol send is a signed, non-repudiable AS4 exchange between two Access Points. When it succeeds, the receiving Access Point has taken legal custody of your invoice. That is a real and strong fact, and it is the strongest one a sender is entitled to.

It is also the end of what anyone can tell you. Specifically:

• There is no delivery-status endpoint to poll, and no delivered webhook to wait for.
• Peppol's message-level status explicitly excludes business acceptance. Whether your buyer agreed with the invoice is not a thing the network reports.
• Reaching an "accepted" state would require registering your company as the exclusive Peppol recipient, which would break inbound delivery for any merchant already published by another provider.

So Zeppol's terminal state is handed over and it stays there. The word "delivered" does not appear anywhere in the product, and neither does "accepted". An app that shows you either for a Peppol invoice is showing you something it cannot know.

What you get as evidence

• The AS4 receipt id returned by the receiving Access Point.
• The Access Point's own document id.
• A timestamp for every state the invoice passed through: created, approved, queued, handed over.
• The document itself, as UBL and as a PDF.

One honest limitation on the receipt. Peppol signs the compressed payload, compression is not deterministic, and no party keeps the compressed bytes, so a receipt cannot be re-validated against the document afterwards. That is a known open problem at the European Commission rather than a defect in any one vendor. It is why the archive of record is Zeppol's own timestamped record, and the receipt id is stored alongside it as corroboration rather than as the evidence itself.

Why a failed send is never retried automatically

If a send times out or returns an error, Zeppol parks the invoice for review. It does not try again.

The reason is specific. The Access Point's send endpoint accepts no idempotency key and no client reference, it mints the document id on its own side, and it performs the AS4 exchange before it writes its own record. A timeout can therefore mean the invoice is already legally on the network with nothing recorded anywhere. Retrying into that uncertainty can put a second valid copy of the same invoice in front of your buyer.

A parked invoice is reconciled by its invoice number, the one identifier both sides share. Stopping and asking is the correct behaviour here, and it is deliberate.