Sending and receiving Peppol documents in other countries for your own company
Getting started with Peppol e-invoicing for your own company in another country: register and verify the company, send Peppol invoices and credit notes, pick up incoming documents, go live. Around thirty other countries work the same way: Peppol BIS 3 UBL on Recommand's own access point, with that country's own identifier schemes.
This guide walks through everything needed to exchange Peppol documents for a company registered in a country other than Belgium, France or the Netherlands, assuming you are setting up your own company in another country, and that the company sends and receives documents over Peppol. Change any of the three answers at the top of the page to get the guide for a different situation.
What you are setting up
You are putting one company, your own or one you represent, on the Peppol network, so it can exchange invoices electronically with its customers and suppliers.
The setup is a one-time affair: registering the company and getting it verified takes a few minutes in the Recommand dashboard, and there is nothing to gain from automating something you do once. What you do integrate is the part that repeats: sending and receiving documents. Our existing integrations can also connect Recommand to accounting or invoicing software you already use, with no code at all.
A single team can hold several companies at no extra cost, useful if you run more than one legal entity, and the document volume of all of them counts towards one plan.
Onboarding companies that are not yours?
If you are building e-invoicing or Peppol integration into a product for your own customers, and will be registering their companies rather than only your own, switch the first answer above to Many companies. The API is the same; what changes is how companies, verification and billing are organised.
Peppol internationally
Each country carries one of three support levels:
| Level | What it means |
|---|---|
| Supported | Companies work end to end, and the country's own identifier schemes are registered for you. |
| Partial | Companies are functional, but country-specific features or local requirements may not be covered yet. |
| Unsupported | New companies cannot be created there, and existing companies cannot be switched to it. |
The countries page on our website is the source of truth: it shows the level for the country you select.
Missing a country?
Support is added country by country. If the one you need is unsupported, or supported only partially in a way that blocks you, mail support@recommand.eu โ knowing there is demand is what moves a country up the list.
Create your account and API credentials
- Sign up at app.recommand.eu/signup.
- Your account starts with a team. The team holds your company, your subscription and your document history, and you can invite colleagues to it.
- Create an API key on the API keys page. Note the key, the secret and your team ID.
- Check the credentials with a request that needs no data of its own:
curl -X GET https://app.recommand.eu/api/v1/companies \
-u key_xxx:secret_xxxAll endpoints in this guide live under https://app.recommand.eu/api/v1 and
accept HTTP Basic authentication with the key as username and the secret as
password. If you would rather not store a long-lived secret, JWT API keys and
OAuth2 with a JWT assertion are available too, see the
authentication guide.
Not planning to write any code?
Sending and receiving can also be driven entirely from the dashboard or through an integration, and each section below says how. The dashboard is available in English, Dutch, French and German; pick your language on the account page.
Try it safely first
You do not have to get anything right the first time. Everything below, adding the company, registering it, sending and receiving, can be done in a playground team first, where nothing is delivered over the real Peppol network, nothing is registered on it, and nothing is billed.
Open the team switcher at the top of the dashboard and pick Add playground. Give it a name, leave the Peppol Test Network box unticked, and you are switched into the new team straight away โ there is nothing to set up beyond that.
Add a company to that team and use it as both sender and recipient to watch a document travel end to end. When the flow does what you want, repeat it once in your real team.
Two things worth knowing before you start:
POST /:companyId/generatetakes the same body as the send endpoint and returns the exact XML that sending would produce, fully validated, without transmitting, storing or billing it. It also returns the resolveddocumentType,doctypeIdandprocessId.- Failure addresses. In a playground that is not connected to the Peppol Test
Network, sending to
404:404or0208:1234567894always fails, so you can exercise your error handling. Any other unregistered recipient is skipped without an error.
A playground stays useful after you are live, too: it is the safest place to try a new invoice layout or a new integration. See how can I test without sending real invoices.
Playgrounds are separate
Playground companies are not registered on the Peppol network and playground documents never leave it, so nothing you do there affects your real company.
Register the company
You are registering one company, once, so the dashboard is the shortest path.
- Open Companies and start the company wizard.
- Fill in the legal name, address and country, plus the identifiers described in the next section.
- Choose whether the company should also receive documents over Peppol, or only send them.
- Save. The company is registered on the Peppol network as part of this step: its identifiers and the document types for its country are set up for you.
Right after saving, the dashboard offers the verification step, which the section below covers. Note the company's ID from its detail page โ every API call for sending and receiving takes it in the path.
Rather create it from code?
The create company endpoint does exactly
the same thing, and returns the company id and a verificationUrl in one
response. It is worth using when company creation is part of a flow you are
automating โ which is likely the case if you are registering many companies.
Switch the first answer above to Many companies for that version.
More than one entity?
Add each legal entity as its own company: run the wizard again. There is no per-company fee, and all of them share your document volume.
Identifiers and the Peppol address
Three fields decide how the company is published on the network:
| Field | Value |
|---|---|
country | ISO 3166-1 alpha-2, e.g. "DE", "SE", "IT" |
enterpriseNumber | The national company or organisation number |
vatNumber | The VAT number, starting with the same country code |
{
"name": "Exempel AB",
"address": "Storgatan 1",
"postalCode": "111 51",
"city": "Stockholm",
"country": "SE",
"enterpriseNumber": "5567321707",
"vatNumber": "SE556732170701"
}A VAT number whose country code does not match country is rejected โ that is
the one identifier rule enforced for every country. National format checks (the
modulo-97 check digit for Belgium, the KVK length for the Netherlands, the CVR
length for Denmark) only exist for the countries that have them; elsewhere the
number is taken as given, so check it before you send it.
There is also an optional enterpriseNumberScheme. It does not decide which
Peppol identifier is registered โ the country does, as the next section shows โ
but it is written into the documents the company sends, as the scheme of the
seller's legal identifier. Leave it out unless the country expects a specific
one.
Which schemes are registered for you
Each country has its own Peppol Electronic Address Scheme, and Recommand tries to automatically register the correct scheme for you.
No identifier means no sending
The Peppol address is also what a document is sent from. A company with no identifier at all cannot send: the attempt fails with no sending company identifier found, and it cannot be published as a recipient either, because there is no address to publish. In some countries, adding an identifier yourself is part of onboarding rather than an optional extra.
Adding identifiers by hand
Whatever the defaults do, the full set is yours to manage: list identifiers, add one, update one or remove one. Every identifier you add is registered in the SMP as another address the company can be reached on.
curl -X POST https://app.recommand.eu/api/v1/{companyId}/identifiers \
-u key_xxx:secret_xxx \
-H "Content-Type: application/json" \
-d '{"scheme":"0007","identifier":"5567321707"}'This is also the escape hatch for a country with no defaults, and for the case where your customers know a company by a different identifier than the one registered for it.
Registering for both directions
Sending needs no registration of its own; receiving does. So register the company as a recipient, which is the default:
{
"isSmpRecipient": true
}What that means:
- The company becomes findable on the Peppol network and can be delivered to through Recommand's access point, while sending its own documents out through the same access point.
- Recipient registration is exclusive. If the company already receives through another Peppol provider, registration fails until it is deregistered there. What that takes depends on the country, which the next section covers.
- The document types the company accepts are registered along with it, based on its country. Which ones those are is covered further down.
- The company is only published once it is verified.
Sending first, receiving later
If the company still receives elsewhere and you do not want to move that yet,
register it with isSmpRecipient: false and start with sending only. Flipping
the field later publishes it as a recipient.
Moving an existing registration
Recipient registration is exclusive everywhere: a company that already receives through another Peppol provider has to be deregistered there before it can be registered with Recommand.
If you do not know who the current provider is, look the company up as a recipient: the verify endpoint returns the SMP it is published on, which names the provider to ask.
Verify the company
A company cannot exchange documents on Peppol until an authorised representative
has confirmed their identity. The company object exposes this as isVerified,
and it stays false until the check is done.
The flow is short:
- Open the verification URL (from the create-company response, the dashboard, or a fresh one from the verify company endpoint).
- The representative fills in their name and completes the identity check.
isVerifiedflips totrueand the company is published on the Peppol network.
In some cases manual verification by our team will be required.
If that's the case, isVerified will remain false until this manual verification is completed.
The user is informed of this in the verification process.
Verifying once, in the dashboard
You have one company, and it is verified once. There is nothing here worth automating: open Companies in the dashboard, pick the company and start verification. If you are authorised to act for the company, complete the check yourself; otherwise use the button to forward the link to whoever is.
The page is self-contained and works in any browser โ the person completing it does not need a Recommand account.
That is the whole step. From here on the API takes over: sending and receiving documents is what you actually integrate.
Changing identifiers resets verification
Updating the company's vatNumber or enterpriseNumber sets isVerified back
to false, and the company has to be verified again before it can exchange
documents.
Pick the document format
Send Peppol BIS 3 UBL, over the standard Peppol billing process. It is the format most Peppol participants accept.
Some countries have a national CIUS on top of EN 16931 โ SI-UBL 2.0 in the
Netherlands, for instance. If a buyer asks for one and Recommand supports it, you
name its document type in doctypeId on the send request; the document you post
stays the same, because the format decides how the XML is written, not which
fields you fill in.
Before a first send to a new recipient, check two things:
- Is the recipient on the network? The verify endpoint answers that, and sending performs the same check automatically.
- Does the recipient accept this document type? The verify document support endpoint answers that, which matters more abroad than at home: a recipient in another country may be registered for its own national profile only.
See verifying recipients for the full flow, including what to do when a recipient cannot be reached.
Send a document
One endpoint sends everything: POST /:companyId/send. The companyId is the
sender, recipient is the Peppol address of the receiver, and document is the
invoice or credit note as JSON. Recommand will validate the document and generate the XML.
Already producing UBL or CII XML?
Raw XML sending is supported as well: set documentType to xml and pass the
document string in document, along with the correct doctypeId. See working
with raw UBL.
curl -X POST https://app.recommand.eu/api/v1/{companyId}/send \
-u key_xxx:secret_xxx \
-H "Content-Type: application/json" \
-d @send-invoice.json{
"recipient": "0208:0123456789",
"documentType": "invoice",
"document": {
"invoiceNumber": "INV-2026-001",
"issueDate": "2026-08-17",
"dueDate": "2026-09-16",
"currency": "EUR",
"buyer": {
"name": "Customer Company",
"street": "Customer Street 1",
"city": "Antwerp",
"postalZone": "2000",
"country": "BE",
"vatNumber": "BE0987654321"
},
"paymentMeans": [{ "iban": "BE68539007547034" }],
"lines": [
{
"name": "Consulting Services",
"quantity": "10.00",
"unitCode": "HUR",
"netPriceAmount": "100.00",
"vat": { "category": "S", "percentage": "21.00" }
}
]
}
}The seller block is filled in from your company when you leave it out, which is usually what you want: it keeps your registered identifiers and the document in agreement. The full field reference lives in sending invoices and sending credit notes.
Worth wiring up while you are here:
- Validation errors. Outgoing documents are always validated. A
success: falseresponse witherrorskeyed by field path is a document the recipient would have rejected โ surface it wherever the data was typed. - Email fallback. Pass
email.towithwhen: "on_peppol_failure"to fall back to email when a recipient turns out not to be reachable over Peppol, or send withrecipient: nullfor email-only delivery. See email delivery and notifications. - PDFs.
pdfGeneration.enabledattaches a generated PDF of the document. You can also attach an existing PDF (or other files) viaattachments; see adding attachments.
For a full field reference, see sending invoices and sending credit notes.
Sending without writing code
The same send is available two other ways, and they mix freely with the API:
- From the dashboard. Send document takes the recipient and the invoice lines, previews what the recipient will get, and remembers your usual settings. You can also drop an existing UBL or CII XML file into the upload zone if your software already produces one.
- From your accounting or invoicing software. If you use one of the supported tools, let it do the work: your invoices flow to Recommand and out over Peppol without retyping. See integrations for the current list, including Microsoft Business Central, Exact Online, Yuki, ClearFacts, ERPNext and Harvest.
Every outgoing document is validated
Whichever route you use, Recommand validates a document before it leaves. If a field is missing or malformed you get a clear error instead of a rejection from the recipient days later. See the troubleshooting guide for the errors you are most likely to run into.
Document types registered for you
When you register the company as a recipient, it is published for the two document types that carry almost all cross-border traffic:
| Document type | Process |
|---|---|
| Invoice (Peppol BIS 3 UBL) | urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 |
| Credit note (Peppol BIS 3 UBL) | urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 |
Anything sent to the company in one of these formats is accepted, validated, stored and handed to you. A sender who tries a document type the company is not published for gets an error before delivery, which is exactly the point of the registration.
Need more document types, such as a national CIUS your suppliers use, self-billing, message level responses, invoice responses? Register the combinations you want with the create company document type endpoint or through the dashboard.
Pick up incoming documents
Once the company is published as a recipient, everything sent to it arrives in Recommand automatically. There are two ways to get the documents into your own systems.
Webhooks (recommended)
Register an endpoint once with the create webhook
endpoint and events are pushed to you as
they happen, document.received among them:
curl -X POST https://app.recommand.eu/api/v1/webhooks \
-u key_xxx:secret_xxx \
-H "Content-Type: application/json" \
-d @create-webhook.json{
"url": "https://your-app.example/webhooks/recommand",
"companyId": null,
"secret": "your_webhook_signing_secret"
}Pass a secret and verify the HMAC SHA-256 signature on every delivery before
you trust the payload, then acknowledge with a 200 before doing the heavy
processing. Both are covered in working with
webhooks.
Polling the inbox
If you would rather pull, the inbox endpoint lists unread documents, and mark as read drops one off the list once your system has it. Fetch details, the original XML or a rendered PDF from the documents endpoints.
Receiving without writing code
- In the dashboard. Incoming invoices appear under Sent and received, with the original XML, a readable rendering, attachments and the delivery history.
- By email. Add notification email addresses per company so incoming documents land in the mailbox your bookkeeping already watches, attachments included. See email delivery and notifications.
- In your accounting software. Forward incoming documents straight to Exact Online, Yuki, ClearFacts or another supported tool, see integrations.
Two things worth setting up early, whichever route you take:
- Labels and suppliers to keep documents organised as volume grows, see suppliers and labels.
- Rules to act on incoming documents automatically: forwarding, labelling, notifying, see rules.
The full picture, including retries and idempotency, is in receiving documents.
Going live
A short list before you start sending or receiving real invoices:
- A valid subscription, so sending is not blocked. Playgrounds skip that check; production does not.
- The company verified, with
isVerifiedtrue. Until then it cannot exchange documents. - Errors surfaced, not swallowed. Validation errors name the field that is wrong; put that in front of whoever can fix it rather than logging it.
- Webhook endpoint hardened, if you took that route: signature verification, a fast 200, retries and idempotency on your side.
- One real document sent and received, ideally between two companies you control, so you have seen both ends.
- Notification addresses set, so incoming documents also reach a mailbox somebody reads.
Tell your customers and suppliers
Once you are live, your Peppol address is public on the network: suppliers can find and reach you without any action from you. Ask customers who still email PDFs to switch, and let your accountant know where the documents now land.
Where to get help
- Troubleshooting. Common rejections, delivery failures and validation errors are collected in the troubleshooting guide.
- Questions. The FAQ covers Peppol, addressing, VAT and billing.
- Email. support@recommand.eu:include the company ID and, for a delivery problem, the document ID.
- Discord. Join the server for release announcements and quick questions.
- Keep track of changes. New endpoints and behaviour are recorded in the changelog.
Other guides for other countries
- Sending Peppol documents in other countries for the companies you onboard
- Receiving Peppol documents in other countries for the companies you onboard
- Sending and receiving Peppol documents in other countries for the companies you onboard
- Sending Peppol documents in other countries for your own company
- Receiving Peppol documents in other countries for your own company