Short answer: e-invoice sending software creates a structured invoice file, finds the customer on the network their country uses, delivers the file securely and tells you what happened to it. "Secure" and "tracked" are the two words to test. On Peppol, delivery between providers is signed and encrypted, and you get a transport acknowledgement. Whether you also see that the customer accepted, queried or paid the invoice depends on the business responses your software supports.
This article is an overview, not tax advice. Rules are as published on 3 November 2026; see our e-invoicing deadlines tracker for changes by country.
What does sending an e-invoice involve?
Our overview of e-invoicing software splits the job into creating, delivering, processing and archiving. On the sending side, that becomes five steps:
- Create a valid file. Structured XML, usually following the European standard EN 16931, in the format the channel expects (Peppol BIS, UBL, CII, Factur-X).
- Find the customer. Look up whether and where they can receive: the Peppol Directory, a national directory, or an agreed address.
- Deliver it. Through your provider, over the required channel.
- Track it. Know that it arrived, and ideally what the customer did with it.
- Keep it. The structured file is the invoice, so keep it, not a PDF copy.
Most sending software is not a separate product. It is a feature of the invoicing or accounting software, often with a certified network provider behind it. Belgium's government guide reflects this: choose e-invoicing software, and the software you choose handles the registration on Peppol.
How does e-invoice sending stay secure?
This is the question behind searches for "secure e-invoice sending software", and the answer depends on which part of the route you mean.
Between providers (Peppol). Peppol's AS4 specification says all communication in the network uses the Peppol PKI. The sending access point signs each message with its own Peppol certificate and encrypts it with the receiving access point's certificate, which it fetches from the receiver's metadata. Only certificates issued by OpenPeppol may be used, and transport runs over TLS. Sweden's SFTI guidance adds that the receiving access point signs the transport acknowledgement, which gives non-repudiation of origin and receipt between the two providers.
Between your client and its provider. This is the part Peppol does not cover. SFTI states plainly that participant-to-participant exchanges have no cryptographic mechanism for non-repudiation in the transport model, and that each participant is responsible for securing its own link to its access point. In practice that means the login, the API connection or the upload route into the sending software. Ask how it is protected and logged.
Inside the invoice itself. Belgium's e-invoicing portal notes that authenticity of origin, integrity of content and legibility must be guaranteed from the moment an invoice is issued until the end of the retention period, and that these rules have not changed. It lists internal controls, such as segregation of duties, as a way to support the reliable audit trail that proves this. Software that lets anyone edit and resend an invoice without a record weakens that trail.
Email. A PDF or XML sent by ordinary email has none of the network-level signing above. It is not automatically non-compliant: in Belgium, if the customer is not ready, the government FAQ allows another method provided there is agreement on a secure alternative. But it is the weakest route: nothing in the channel itself proves who sent the file or that it was not altered.
How do you track an e-invoice after sending?
There are two kinds of confirmation, and sellers often assume they have the second when they only have the first.
| Level | What it tells you | Example |
|---|---|---|
| Transport | The customer's provider received the file | Peppol AS4 signed acknowledgement; an ebMS error if that provider does not serve the customer |
| Business | What the customer did with the invoice | Peppol Invoice Response; French lifecycle statuses |
Peppol Invoice Response. OpenPeppol's Invoice Response lets the buyer tell the seller where an invoice stands. The status codes run from message acknowledgement (AB), in process (IP) and under query (UQ), through conditionally accepted (CA), to rejected (RE), accepted (AP) and paid (PD). A buyer that supports it must at least be able to send AB, RE and AP. It is informative only: it has no legal effect and the seller cannot demand it. So tracking beyond "delivered" depends on whether the customer's software sends responses.
France. Statuses are built into the reform. The DGFiP's start-up guide separates a rejection by the platform (format error, missing or inconsistent data, wrong identification, a routing problem), which the seller corrects and resubmits, from a refusal by the buyer. A refusal must give a reason from a fixed list and cannot be used for a simple commercial dispute. The guide also says decisions about resending should rely on the transmission and delivery statuses, which matters because resending without checking creates duplicates on the customer's side. See France for the timeline.
What if the customer cannot receive yet?
Check first. Belgium's FAQ says you can check yourself which customers are ready, using the Peppol Directory. Our guide to Peppol explains how to read a Peppol ID.
Agree an alternative. If a Belgian customer is not reachable, you may use another method, but for electronic invoices the customer must agree and there must be agreement on a secure alternative. The invoice is legally valid, and once the customer's system is working you should not resend old invoices retroactively.
Do not send both without a plan. A PDF by email followed by the same invoice over Peppol is the most common source of duplicate bills during the transition. If you must, mark one as a copy and tell the customer.
What to look for in e-invoice sending software
A checklist for firms setting up sending for many clients:
- Channels covered for each client's country: Peppol for Belgium, an approved platform for France, the clearance system where one applies.
- Validation before sending, so a file that will be rejected is caught in your queue, not the customer's.
- Directory lookup that tells you whether the customer can receive before you press send.
- Both levels of status visible per invoice: delivered, and accepted, queried, rejected or paid where the customer responds.
- Clear rejection reasons and a correction route that keeps the original invoice number trail intact.
- Access control and an audit log on who created, changed and sent each invoice.
- The original file kept and linked to the sales invoice for the retention period.
- Many clients, one view, so a firm is not logging in to a portal per client.
For the receiving end of the same route, see e-invoice receiving software.
A worked example
A firm handles a Belgian wholesale client that issues about 300 invoices a month. Its accounting software has a Peppol provider built in. Before switching on sending, the firm checks the client's 40 largest customers in the Peppol Directory: 36 are registered, 4 are not.
For the 36, invoices go over Peppol. The sending software shows each one as delivered once the customer's provider acknowledges it. Twelve customers' systems also send Invoice Responses, so for those invoices the firm sees "accepted" and later "paid", which shortens the debtor chase. For the four unregistered customers, the client agrees in writing on a secure alternative and sends PDF invoices until they are ready.
Where Invoreg fits
Invoreg works on the other end of the route. It reads the e-invoices your clients receive (XRechnung, ZUGFeRD/Factur-X, Peppol UBL) alongside PDFs, scans and 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.
It does not send e-invoices and is not a Peppol service provider, so your clients still need sending software for their sales invoices. If processing the invoices they receive is where your team spends its time, book a demo.