One of the most powerful features of the PSB is multi-channel delivery: through a single API integration you can reach recipients on Peppol, other procurement networks and by email. The PSB automatically selects the best channel, but you can also control the routing yourself.

By default, the PSB routes all invoices via Peppol. The system checks whether the recipient is registered on Peppol and sends the invoice through the Peppol network. If the recipient is not on Peppol, the fallback mechanism kicks in.

By configuring multiple hooks with Send* topics, you can activate additional channels:

The PSB selects the channel based on a priority order:

1. PartyId-level hooks take precedence over environment-level hooks. If you have configured a channel for a specific recipient, that channel is always used
2. Specific topics take precedence over wildcards. A hook for InvoiceSent takes priority over a wildcard hook
3. When several hooks with filters match the same topic: the longest filter (by character count) wins. A filter with an extra && clause wins over a shorter filter without that clause
4. When priorities are equal: hook-id as tiebreaker (alphanumeric: integer ids before text, for example 1 < 02 < 10 < dico < peppol)

Before sending an invoice, you can use queryRecipientParty to check which channel the PSB will use. There are two endpoints, one per document type:

POST /api/v1/{partyId}/salesInvoice/queryRecipientParty
POST /api/v1/{partyId}/purchaseOrder/queryRecipientParty

The body accepts a simple array ["0106:12345678"] or an object with meta attributes { "partyIds": [...], "metaAttributes": {...} }. Optional query parameters: ?preferredDocumentTypeId, ?includeOptions, ?documentFamily (purchaseOrder variant only).

The response shows the selected channel and the available alternatives.

In the same queryRecipientParty call, each scheme/agency code (for example 0106, 0190, 0208, 9944) may appear at most once. Several identifiers in different schemes in the same call are allowed.

On violation the PSB responds with:

EConnect.Psb.Models.EConnectException: 'Duplicate id agencies {code} requested.'

where {code} is the agency code without the leading zero (scheme 0208 becomes 208). To test several candidates in the same scheme, make separate API calls, one per candidate.

For advanced lookups (including Access Point URL and certificate) use the Peppol endpoint:

GET /api/v1/peppol/deliveryOption?partyIds=...&documentFamily=...&isCredit=...&documentTypeIds=...&preferredDocumentTypeId=...

The response contains partyId, documentTypeId, processId, protocol (As2/As4), url and certificate.

In some cases you may want to override the automatic channel selection. You can do this with the ?channel={hookId} query parameter on the send endpoints:

POST /api/v1/{partyId}/salesInvoice/send?channel=hook-123-abc

This forces the PSB to use the specified channel (hook), regardless of the automatic selection.

A popular combination is a Peppol hook with an email hook as fallback. Via conditional output topics, the Peppol hook publishes a Send*Fallback topic on delivery errors (HTTP 400, 404 or 500), which the email hook listens to. When the same email hook also explicitly listens to Send* (in addition to Send*Fallback), it automatically appears as channel peppol-fallback in the queryRecipientParty response. This allows the calling code to explicitly select the channel via ?channel=peppol-fallback on the send endpoints, which is useful for scenarios where Peppol is intentionally bypassed.

For German recipients you do not always know in advance whether the counterparty is on Peppol, and whether they expect ZUGFeRD (B2B) or XRechnung (B2G, mandatory for German public authorities) by email. German public authorities must not receive ZUGFeRD; they require pure XRechnung XML. The ZUGFeRD PDF container does not travel over Peppol.

Architecture (3 hooks): one Peppol hook with conditional output catches HTTP 404 (recipient not on Peppol) and publishes Send*Fallback. Two email hooks listen on that fallback topic and deliver ZUGFeRD or XRechnung by email, depending on the filter.

Peppol hook (Send*) --404--> Send*Fallback
                              |
                 +------------+------------+
                 |                         |
     ZUGFeRD email (DE)        XRechnung email (DE + DE:LWID)

Hook 1 -- Peppol with conditional fallback

{
  "id": "peppol",
  "action": "peppol",
  "name": "peppol hook",
  "topics": ["Send*"],
  "output": [
    { "when": "404", "topic": "Send*Fallback" }
  ],
  "isActive": true
}

Optionally also include 400/500 in output for a broader Peppol-with-email-fallback pattern. On a 404 this hook publishes Send*Fallback instead of the default Send* result.

Hook 2 -- ZUGFeRD by email (B2B, default German fallback)

• Topics: ["Send*Fallback", "Send*"] (also on Send*, so the channel appears as peppol-fallback in queryRecipientParty)
• Filter: receiver.contains("DE")
• targetDocumentTypeId forces hybrid ZUGFeRD/Factur-X (PDF/A-3 with embedded CII) before sending: econnect-docid::urn:peppol:doctype:pdf+xml##urn:cen.eu:en16931:2017#conformant#urn:econnect:germany:billing:Factur-X:1.0::D22B
• The recipient gets a readable PDF with machine-readable XML. The source XML must already embed the PDF; the PSB does not generate a PDF on demand.

Hook 3 -- XRechnung by email (B2G, German government)

• Topics: the same ["Send*Fallback", "Send*"]
• Filter: receiver.contains("DE") && receiver.contains("DE:LWID")
• targetDocumentTypeId forces pure XRechnung 3.0 UBL (no PDF): urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0::2.1
• DE:LWID is the Leitweg-ID in the recipient identifier (Peppol schemeID 0204).

No double delivery for DE:LWID

Both email hooks match a government recipient, because a DE:LWID identifier also contains DE. When several hooks match the same topic, the PSB prefers the longest filter (by character count): the XRechnung filter is longer and wins, so the ZUGFeRD hook is not triggered for government recipients. You do not need to make the filters mutually exclusive by hand. This filter-length rule sits on top of the general priority order above (partyId before environment, specific topic before wildcard, alphanumeric hook-id as tiebreaker).

Email-hook parameters (fallbackEmail, includeAttachment, filename, templateId, default sender noreply@econnect.email) are described in Configure email hooks. Format details: Factur-X / ZUGFeRD and XRechnung.

eConnect automatically transforms UBL invoices into the cXML format that Coupa expects. The connection requires:

1. Your client creates accounts on the Coupa CSP test and live environments
2. The receiving party creates a Shared Secret
3. TechSupport configures the connection in the PSB

The Ariba connection works with 1-to-1 trading relationships, unlike the open Peppol network:

1. The supplier shares their AN-ID with the buyer
2. SAP may require a paid subscription at higher volumes
3. The test environment uses an AN-ID with suffix "-T"

eConnect transforms a UBL invoice into cXML and delivers it to the Ariba recipient, in the same way as the Coupa transformation above. The onboarding process works as follows:

1. You register with the SAP Business Network.
2. You agree with the recipient on how they want to receive the cXML and complete the eConnect onboarding form accordingly.
3. Based on the form, eConnect establishes the connection with the recipient, first via the test network, then live.

SAP subscription threshold: for automated sending/receiving of cXML via your own ERP package (via eConnect), a minimum SAP subscription level of Silver (Enterprise) is required. This level covers volumes of 25 to 99 documents per year.

The PSB automatically converts between all common e-invoice formats. If you send an invoice in NLCIUS format but the recipient expects XRechnung, the PSB transforms the document automatically. This works for all supported standards: BIS Billing, NLCIUS, PINT-SG (other PINT variants are on the roadmap), XRechnung, Svefaktura, ebInterface, DICO, SETU, Factur-X, CII and more.

Transformation is available from the 10K package onwards.

The PSB supports transformation in both directions between SI 2.0 and SALES005:

• SI 2.0 → SALES005
• SALES005 → SI 2.0

Note: SALES005 must not be sent via Peppol. Sending SALES005 requires an email connection. Multi-channel covers this: send primarily via Peppol, with automatic fallback to email when needed.

On email, SFTP and HTTPS you can pass a targetFormat. The PSB then transforms the invoice on the fly to the requested format. A customer who wants a UBL invoice as SALES005 passes a targetDocumentTypeId on download or send.

Peppol does not support targetFormat (SALES005 is not allowed there). Every other channel does.

Multi-channel delivery is not included in the base service and must be purchased separately. Contact TechSupport for the options in your situation.

A large company sends invoices to:

• Dutch clients → Peppol (automatic)
• Construction sector companies → DICO (specific hook per partyId)
• A multinational on another procurement network → specific hook
• Small suppliers without a network → email fallback
• Collabrr platform users → Collabrr (automatic via Collabrr ID)

All invoices are sent through the same API (POST /api/v1/{partyId}/salesInvoice/send). The PSB handles the correct routing, format and channel for each invoice.

Need help setting up multi-channel delivery? Contact TechSupport.