Recipient List

The sender itself computes who should receive the message, on a per-message basis. More precise than a pub/sub channel, indispensable when the list depends on content — typically the regulatory Continuous Transaction Controls in e-invoicing.

Problem

A business event must reach a precise set of recipients that changes on every send: a UBL invoice has to reach the named buyer, the tax authority of the buyer's country (5-corner in Italy, France from 2026) and the archival vault. The pub/sub channel is too broad: it would broadcast to every subscriber, whereas we want a controlled distribution that depends on the content of each invoice (buyer country, amount, operation type).

Forces

• The list depends on the message. Audience varies with buyer country, operation type, amount.
• The sender owns the context. Only the sender knows the business rules that decide who must receive.
• Auditability. Regulatory frameworks demand proof of who received what; pub/sub with unknown subscribers makes that proof impossible.
• Precision > generality. Broadcasting to 200 subscribers when only 3 are relevant pollutes downstream systems and complicates idempotency.

Solution

EIP §249 (Hohpe & Woolf, 2003) prescribes: the sender computes explicitly the recipient set for this message, and dispatches a copy to each over dedicated channels. The typical component is a stateful router that: (1) reads the message, (2) applies business rules to produce the list, (3) emits one copy per recipient onto its dedicated point-to-point channel.

Producer chooses the audience explicitly
   ─────────────────────────────────────────

   ┌──────────┐    ┌────────────────────┐      ┌──▶ recipient A (buyer)
   │ producer │ ──▶│  Recipient List   │ ─────┼──▶ recipient B (tax authority)
   └──────────┘    │  [A, B, C]        │      │
                   └────────────────────┘      └──▶ recipient C (archive)

   The list is built per message; A/B/C don't pre-subscribe.

Difference with Publish-Subscribe

The contrast with Publish-Subscribe Channel is essential:

EDI implementation

• Multi-Receiver SBDH. The Standard Business Document Header (ISO/IEC 15000-5) supports several <Receiver> elements in the same header — the Recipient List natively encoded in the UBL / PEPPOL wrapper. The sending hub computes the list from rules, encodes it in the SBDH, routes a copy per receiver.
• X12 — multi-store 856 distribution. A Walmart supplier shipping to 12 stores receives the list of destination Store IDs in the routing manifest; it emits one 856 per Ship-To using that list.
• EDIFACT — targeted APERAK. A validation hub that detects 3 partners involved in an error (sender, receiver, third-party platform) issues 3 distinct APERAK messages in an explicit Recipient List, not a broadcast.

<?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
  <StandardBusinessDocumentHeader>
    <Sender>
      <Identifier Authority="iso6523-actorid-upis">0088:5798000000122</Identifier>
    </Sender>
    <Receiver>
      <Identifier Authority="iso6523-actorid-upis">0088:7300010000001</Identifier>
    </Receiver>
    <Receiver>
      <Identifier Authority="iso6523-actorid-upis">9925:BE0987654321</Identifier>
    </Receiver>
    <Receiver>
      <Identifier Authority="urn:archival:ediverse">archive-eu-1</Identifier>
    </Receiver>
    <DocumentIdentification>
      <InstanceIdentifier>inv-202605140001</InstanceIdentifier>
      <Type>Invoice</Type>
    </DocumentIdentification>
  </StandardBusinessDocumentHeader>
  <Invoice>
    <!-- UBL payload -->
  </Invoice>
</StandardBusinessDocument>

Reading: the SBDH above declares three Receivers (buyer, Belgian tax authority, archival vault). The sending hub computes that list from the buyer-country tax rules and the internal archival rules — a 4th or 5th receiver is added automatically if the amount exceeds a reporting threshold.

CTC and 5-corner PEPPOL

The pattern has become central with the adoption of Continuous Transaction Controls (CTC) in Europe: Italy (Sistema di Interscambio, 2019), Poland (KSeF, 2024), France (PPF / PDP, September 2026). The PEPPOL 5-corner model adds a "tax authority" corner that must receive a copy of every taxable invoice. The Recipient List, computed by the dematerialisation platform at send time, is exactly the mechanism: for each invoice the system decides which authorities are concerned (depending on sender and buyer countries, thresholds, special regimes).

Anti-patterns

• Hard-coded list in config. The list changes with regulation and countries; hard-coding slows every regulatory change (e.g. arrival of Polish KSeF in 2024).
• Pub-sub where Recipient List is needed. Broadcasting an invoice to a "invoice-issued" topic where dozens of systems subscribe makes regulatory audit proof impossible.
• List recomputed at the receiver. If every receiver decides for itself whether it is concerned, you waste bandwidth and create interpretation inconsistencies.
• No cross-receiver idempotency. Without a shared idempotency key, a targeted retransmission to one receiver can re-inject the message elsewhere.

Related patterns

• Publish-Subscribe Channel — the implicit-subscription alternative.
• Content-Based Router — a router picks one channel; Recipient List emits to several.
• Splitter — splits the message; Recipient List copies without splitting.
• Idempotency — prerequisite for per-receiver retransmission.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Recipient List (§249). enterpriseintegrationpatterns.com — Recipient List
• ISO/IEC 15000-5 — ebXML CCTS, formalises the Standard Business Document Header (SBDH), including multiple Receivers.
• OpenPEPPOL — 5-corner model. Document describing the extension of the 4-corner model to 5-corner for CTC. peppol.eu/peppol-explained
• Apache Camel — Recipient List EIP. Reference open-source implementation of the pattern. camel.apache.org — Recipient List