---
title: "About Service Providers"
space: "eInvoicing"
url: "https://www.prilk.com/docs/edocument/integration/overview"
updated: "2026-05-14"
---

## About Service Providers

eInvoicing generates and validates PEPPOL XML, but it doesn't ship invoices over the network on its own. That's the job of a **service provider** — a PEPPOL Access Point with a contract with the PEPPOL authority. Your service provider is who actually puts your XML into the recipient's mailbox (and vice versa for incoming).

### Why you need one
- PEPPOL is a four-corner model: Sender → Sender's Access Point → Receiver's Access Point → Receiver. The two Access Points are service providers; they handle authentication, routing, retries, and standards compliance.
- You can't just POST UBL XML to a customer — they don't accept random HTTP. They accept it from a PEPPOL Access Point.

### Supported integrations

| Provider | API Reference | Strengths |
|---|---|---|
| **B2B Router** | [b2brouter.com](https://www.b2brouter.com/) | Multi-account support; API-based send + poll |
| **Recommand** | [peppol.recommand.eu/api-reference](https://peppol.recommand.eu/api-reference) | Webhook for real-time inbound, transparent pricing, multi-company, document verification, [GitHub](https://github.com/brbxai/recommand-peppol) |

Both providers handle the heavy lifting of the four-corner model. You configure credentials in eInvoicing, and the app routes outgoing documents to them and ingests incoming documents from them.

### How outbound works
```
Sales Invoice → EDocument (UBL XML) → Validate → Transmit via API
   → Service Provider (B2B Router / Recommand)
   → Peppol network → Recipient's Access Point → Recipient
```
The EDocument status updates to "Transmission Successful" and the provider's document ID is stored in the `reference` field for later tracking.

### How inbound works

| Mechanism | When |
|---|---|
| **Webhook** | Real-time — the provider POSTs UBL XML to `/api/method/edocument_integration.api.webhook` as soon as a document arrives |
| **Polling** | On a schedule — the app calls the provider's inbox endpoint hourly, fetches new documents, and creates EDocument records |

Both paths converge on the same EDocument lifecycle: create → detect → validate → match → create Purchase Invoice.

### Adding another provider
The integration is pluggable. To add a third provider:
1. Create `<provider>_api.py` with a client class exposing `transmit_invoice(xml)` and `poll_inbox()`
2. Add a route in `api.py`'s `transmit_edocument()` and `poll_incoming_invoices()`
3. Add the new value to the **EDocument Integrator** Select field on EDocument Integration Settings

Architecture details: see the [edocument_integration repo on GitHub](https://github.com/prilk-consulting/edocument_integration).

### Next
- [Setting Up a Provider](/docs/edocument/integration/getting-started) — credentials and DocType setup
- [Configuring a Service Provider](/docs/edocument/integration/service-provider) — webhook URL and polling
- [Sending & Receiving](/docs/edocument/integration/send-receive) — day-to-day usage