France - Recipient Identifiers & Routing

You can deliver a French invoice to a legal entity, one of its establishments, or a specific service via a routing code (code de routage) or address suffix (suffixe d'adressage). This page covers which identifiers to send and how eezi resolves them.

The three French identifiers

recipient.taxId accepts any of them:

They all lead back to the same place: the SIREN is the first nine digits of a SIRET and the last nine of a VAT number. Whichever one your customer has on hand works.

Extra identifiers go in recipient.customInfo.fra

taxId holds one identifier. Anything else your customer gives you goes here:

recipient: {
  taxId: string;            // SIREN, SIRET, or FR VAT number
  customInfo?: {
    fra?: {
      siren?: string;       // deprecated — use recipient.taxId
      siret?: string;       // establishment, when taxId holds the SIREN or VAT number
      vatNumber?: string;   // required if VAT-registered and taxId isn't the VAT number
      routingCode?: string; // "code de routage" (Annuaire: identifiantRoutage) — needs a SIRET
      suffix?: string;      // "suffixe d'adressage" (Annuaire: suffixeAdressage) — a billing channel on the SIREN
    };
  };
};

Two rules worth knowing:

• One SIREN everywhere. Every identifier on a document must point at the same legal entity. If the SIRENs embedded in taxId, customInfo.fra, or an explicit peppolId.endpointId disagree, the document is rejected before any lookup runs.
• A routing code needs a SIRET. Without one, the routing code can't form a valid address and is ignored. Routing codes and suffixes exist only if the recipient registered them - use one when your customer provides it, never guess.

The 0225 Peppol endpoint ID convention

Behind the scenes, French recipients are addressed with a 0225 Peppol endpoint ID - the address format used on the Peppol delivery network. It has four forms, from an entire legal entity down to a specific service:

The format is unambiguous: the first segment is always the SIREN; a 14-digit second segment is a SIRET, anything else is a suffix; a third segment can only follow a SIRET and is a routing code.

You never need to build this yourself — eezi assembles it from taxId and customInfo.fra. If you do set recipient.peppolId.endpointId, eezi parses it by this convention and uses its values for routing. customInfo.fra.siret, routingCode, and suffix are then ignored, and taxId is still required either way. vatNumber still applies — it carries VAT information, not routing.

How eezi finds the receiving platform

eezi looks the recipient up on the Annuaire, walking a fixed ladder of four lookups. A suffix outranks even an establishment address, because the buyer configured it deliberately as a billing channel. Each step only runs if its identifiers were provided, and the first step with an active registration wins:

A miss on steps 1–3 is never an error, the walk just falls through. A routing error is raised only when step 4 fails: if the SIREN itself isn't on the Annuaire, the company isn't registered to receive electronic invoices and the document can't be delivered.

Common cases

Rows without a vatNumber assume the recipient is not VAT-registered; if they are, add customInfo.fra.vatNumber or use the VAT number as taxId — the lookups don't change.

If a document comes back with a routing error, the fix sits with your customer, not your payload: their SIREN is not registered on the Annuaire yet, so they cannot receive electronic invoices at all.