To send e-invoices from your application, you integrate with a certified Access Point’s API: you POST the invoice data, the operator validates it against the European standard, delivers it over the Peppol network to the recipient’s own operator, and reports delivery status back to you. You do not need to become a certified operator, run AS4 messaging or study the network’s internals – that is exactly what the Access Point (a certified e-invoicing operator, in Peppol terms) exists for. What you do need is three things: the recipient’s electronic address, invoice data that survives validation, and a provider whose API fits your stack.
What is an e-invoice, technically?
An e-invoice is a structured XML document conforming to the European standard EN 16931; the profile you will meet most is Peppol BIS Billing 3.0, a conformant implementation of that standard. A PDF attached to an email is not an e-invoice – machines cannot post it into an accounting system without OCR guesswork. Most Access Point APIs accept UBL XML directly, and some also accept JSON and generate the XML for you.
How does delivery work?
The network runs on a four-corner model: your system → your Access Point → the recipient’s Access Point → the recipient’s software. Recipients are addressed by a Peppol ID in the form `{scheme}:{identifier}` – an Estonian company, for example, is `0191:` followed by its business registry code. Whether a recipient is reachable, and which document types they accept, is public: query the Peppol Directory or your provider’s lookup endpoint before sending. Think of it as email with certified operators instead of open SMTP – and with a delivery receipt that actually means something.
What does the integration look like?
A typical flow has four steps. Look up the recipient’s Peppol ID. POST the invoice to the API – good providers validate synchronously and return structured errors, so a rejected invoice fails in your test suite, not three days later. Track delivery via webhook or a status endpoint, since transport is asynchronous. And run it all against a sandbox first: for a documented API, the first test document within one working day is a realistic expectation.
What should you check before choosing a provider?
Four things separate the options: certified Access Point status (the provider holds the accreditation so you don’t have to), synchronous validation with actionable error messages, recipient lookup built into the API, and a sandbox with environment-separated keys. If you also receive invoices, add webhook delivery for inbound documents to the list. The rules about when e-invoicing is mandatory vary by country: for the Baltic picture, see our overview of e-invoicing mandates in Estonia and Latvia and Lithuania.
Also available in: eesti keeles
Last reviewed:
Do I need Peppol certification to send e-invoices from my app?
No. Certification belongs to the Access Point operator. Your application calls the operator’s API; the operator handles AS4 transport, validation and network membership.
What format does an e-invoice API accept?
Most accept UBL XML conforming to EN 16931 / Peppol BIS Billing 3.0; some also accept JSON and generate the XML. A PDF is not an e-invoice.
How do I address the recipient of an e-invoice?
By Peppol ID: {scheme}:{identifier}, e.g. 0191:business-registry-code for Estonian companies. Reachability is public in the Peppol Directory.
How long does an e-invoicing API integration take?
With a documented REST API and sandbox, sending a first test document within one working day is realistic; production readiness depends on your invoice data quality.