If your business sells to companies or public bodies in the European Union, an invoice is no longer just a PDF. Many buyers expect Peppol e-invoicing: a structured electronic document, sent over a standard network, that the receiving system can read without manual entry. Your invoicing software has to produce that structure correctly, validate it and deliver it. This guide explains what to build in, based on the work we have done on online invoicing for Luxembourg businesses.
What Peppol e-invoicing means in practice
Peppol is a set of specifications and a network for exchanging business documents. For invoices, the most common profile is Peppol BIS Billing, which follows the European standard EN 16931 and uses the UBL 2.1 XML syntax. Each invoice is an XML file with defined fields, not a free-form layout. The buyer's system reads the fields directly, which removes re-typing and reduces disputes about amounts and VAT.
Documents travel between companies through access points. Your software does not need to talk to every buyer directly. It sends the document to an access point, which looks up the buyer's Peppol participant identifier in the network directory and delivers the file to the right receiver.
What your invoicing software must support
- Valid UBL 2.1 output that conforms to the Peppol BIS Billing rules, including mandatory header, party and line-level fields.
- Participant identifiers for both seller and buyer, stored per customer and checked before sending.
- Tax breakdown by VAT rate and category, so the document shows taxable amounts and tax amounts for each rate used.
- Credit notes and corrections in the correct structured form, linked to the original invoice.
- Pre-send validation that rejects a document before it leaves your system, with a clear error message the user can act on.
- Delivery status tracking that records when the access point accepted, delivered or rejected a document.
- Archiving of both the structured file and the human-readable copy for the period your local rules require.
Mandatory data, not optional fields
The most common build error is treating the XML as a cosmetic export. A PDF can show a missing buyer address or an unclear tax category and still look finished. The structured file will be rejected. Build your data model around the required fields first, then generate the PDF from the same record. One source of truth prevents the PDF and the XML from disagreeing.
Sending and status handling
Sending should be asynchronous. Queue the document, transmit it, store the transport identifier and poll or receive status updates. If the access point is temporarily unavailable, the invoice must stay in a retry state and must not be marked as sent. Users need to see the difference between "created", "sent", "delivered" and "rejected", because a rejected invoice that looks sent creates payment delays.
VAT and multi-country rules
Peppol gives you the structure, but VAT logic is still your responsibility. A business selling across EU countries must handle domestic VAT, intra-community supplies and reverse charge cases, and each one needs the right category code and exemption reason in the document. The table below shows the areas to design explicitly.
| Area | What to build | Why it matters |
|---|---|---|
| VAT rates | Rate tables per country with effective dates | Rates change, and old invoices must keep the rate that applied at the time |
| Reverse charge | Buyer VAT number check and the correct category code | Wrong categories lead to rejected documents and tax queries |
| Exemptions | Mandatory exemption reason text on the invoice | The buyer's system and the tax authority both expect it |
| Currency | Document currency plus a tax currency where required | Mixed-currency invoices need consistent totals |
| Numbering | Gap-free, per-series invoice numbers | Sequence breaks are a common audit finding |
In our work on Facture, an online quoting and invoicing product for Luxembourg businesses, the platform handles Luxembourg and EU VAT, online payments, automatic reminders and Peppol UBL output in one flow. You can see the scope in our project portfolio. The lesson from that build is that the VAT and numbering rules are the hard part, and they need to be tested with real invoice scenarios before launch.
Build, buy or extend?
Many companies can start with an off-the-shelf tool that already supports Peppol. This works when your invoices follow standard patterns and you do not need custom workflows. Build or extend your own system when invoices depend on your business logic, such as project billing, milestone payments, or integration with an existing ERP System. In that case, the e-invoicing module should sit inside your accounting data, not beside it, so that stock, receivables and tax reports stay consistent.
If you are not yet selling into the EU but expect to, design the data model now. Adding participant identifiers, VAT categories and structured line items later usually means changing the invoice table, the PDF template and the reporting queries at the same time.
Common mistakes to avoid
- Generating the PDF from one template and the XML from another, so the two drift apart.
- Skipping validation until after go-live, when rejected invoices have already reached customers.
- Storing buyer VAT numbers as free text instead of validated fields.
- Treating a sent status as a delivered status.
- Not testing credit notes and corrections, which are often the first things an auditor asks about.
For Egyptian businesses, the rules differ from Peppol, so read our guide on E-Invoicing in Egypt: What Your Software Must Support if your customers are local. Many Middle Eastern companies serve both markets, and a system that handles both needs separate rule sets.
If you are planning an invoicing system and want a clear scope before committing to a build, contact our team with your invoice volumes, target countries and current tools. We will map the requirements and the work needed.
Frequently asked questions
What is Peppol e-invoicing?
Peppol e-invoicing is the exchange of structured invoice files between businesses through a standard network. The invoice is an XML document that follows the Peppol specifications, so the buyer's system can process it automatically. It is sent via an access point rather than emailed as a PDF.
Do I need a Peppol access point to send invoices?
You usually connect through an access point provider rather than running one yourself. Your software sends the document to the access point, which routes it to the buyer. Your system is responsible for producing valid data and tracking the delivery status.
Is UBL the same as Peppol?
No. UBL is an XML syntax for business documents, and Peppol is a network with its own specifications built on top of standards such as UBL and EN 16931. A Peppol invoice uses UBL, but it must also follow the Peppol rules for fields and validation.
How long does it take to add Peppol support to existing invoicing software?
The timeline depends on how cleanly your data model already stores parties, tax details and line items. Teams with well-structured invoice data can add the output and validation layer in a focused phase, while systems with loose data need cleanup first. A requirements review usually gives the most accurate estimate.
