PAYORD — Payment Order Message (D.96A)

Le message PAYORD est l'ordre de paiement envoyé par le donneur d'ordre (ou son agent) à sa banque, pour qu'elle débite un compte et fasse parvenir un montant au bénéficiaire en règlement d'une transaction commerciale.

Objet du message

Selon la définition fonctionnelle UN/CEFACT, PAYORD est « sent by the Ordering Customer (or Payor or Agent on behalf of the Ordering Customer) to the Ordered Bank, to instruct the Ordered Bank to debit an account it services for the Ordering Customer, and to arrange for the payment of a specified amount to the Beneficiary ». Un PAYORD peut couvrir le règlement financier d'une ou plusieurs transactions commerciales (factures, avoirs, notes de débit, etc.). Il n'est pas destiné aux opérations de marché sur titres.

Structure segmentaire

Le message PAYORD D.96A est entièrement « plat » : pas de section Detail / Summary, mais un header suivi de huit groupes de segments. Les éléments sont définis dans payord_s.htm (segment table) et payord_d.htm (clarification).

Au niveau du header, les segments mandataires sont UNH M , BGM M , et DTM M . Les autres segments de tête sont conditionnels : BUS C , PAI C , FCA C , et FTX C .

Groupes de segments

Huit groupes de segments structurent le corps du message, dans cet ordre canonique :

SG1 (C, ×5) — RFF + DTM : référence à un message précédemment envoyé.
SG2 (M, ×1) — MOA + CUX + DTM + RFF : montant du paiement, devises, taux de change, références liées.
SG3 (C, ×4) — FII + CTA + COM : institutions financières et comptes (banque émettrice, banque destinataire, banque intermédiaire…).
SG4 (C, ×6) — NAD + CTA + COM : parties non-financières (donneur d'ordre, bénéficiaire, etc.) et leurs contacts.
SG5 (C, ×4) — INP + FTX + DTM : instructions du donneur d'ordre vers les parties identifiées.
SG6 (C, ×10) — GIS + MOA + LOC + NAD + RCS + FTX : données réglementaires (BoP — balance des paiements, autorité de réglementation, nature de la transaction).
SG7 (C, ×10) — DOC + DTM : références aux documents commerciaux réglés par cet ordre (factures, avoirs).
SG8 (C, ×5) — AUT + DTM : détails d'authentification (signature, code MAC, date de validation).

Le message se clôt par UNT M .

Obligatoire / conditionnel

Quatre éléments sont strictement mandataires dans tout PAYORD D.96A :

UNH — ouvre le message, porte le type PAYORD et la version (D / 96A / UN).
BGM — donne le code de fonction, le numéro de l'ordre de paiement et son statut.
DTM — au moins une date dans le header (la spec autorise jusqu'à 4 répétitions).
SG2 MOA — le groupe 2 est lui-même obligatoire (M, ×1), et le segment MOA qui l'ouvre est mandataire : pas d'ordre de paiement sans montant.
UNT — ferme le message, déclare le nombre de segments et l'identifiant de référence.

Tous les autres segments (RFF, CUX, FII, NAD, INP, GIS, DOC, AUT, FCA, BUS, PAI, FTX…) sont conditionnels au niveau du standard. En pratique, l'usage bancaire impose presque toujours au minimum un FII (compte à débiter), un NAD (donneur d'ordre identifié), et un DOC (document commercial réglé).

Exemple réel

Un ordre de paiement d'un corporate français (ACME SAS) à sa banque, pour régler une facture d'un fournisseur allemand (SUPPLIER GMBH) :

edifact payord-d96a-example.edi

UNB+UNOC:3+5410000000123:14+BANKBEBB:25+260513:1430+CTRL000001'
UNH+1+PAYORD:D:96A:UN'
BGM+450+PAYORD-2026-0042+9'
DTM+137:20260513:102'
DTM+203:20260515:102'
RFF+CR:INV-2026-7788'
DTM+171:20260430:102'
MOA+9:12450.00:EUR'
CUX+2:EUR:9'
FII+OR+12345678901::25+ACME SAS:::5410000000123'
FII+BF+98765432109::25+SUPPLIER GMBH:::4012345000020'
NAD+OY+5410000000123::9++ACME SAS+12 RUE DES LILAS+PARIS++75011+FR'
NAD+BE+4012345000020::9++SUPPLIER GMBH+HAUPTSTRASSE 5+BERLIN++10115+DE'
DOC+380+INV-2026-7788'
DTM+171:20260430:102'
UNT+15+1'
UNZ+1+CTRL000001'

UNB — interchange entre le GLN de l'acheteur et le BIC de la banque (qualifier :25 = BIC).
BGM+450+PAYORD-2026-0042+9 — code 450 (payment order), numéro PAYORD-2026-0042, statut 9 (original).
DTM+137 — date de création. DTM+203 — date d'exécution demandée (execution date).
RFF+CR:INV-2026-7788 — référence client à la facture (CR = customer reference). DTM+171 = date de référence.
MOA+9:12450.00:EUR — montant payable (qualifier 9 = amount due / amount payable).
FII+OR — Ordering Bank (compte du donneur d'ordre). FII+BF — Beneficiary's Financial Institution.
NAD+OY — Ordering Customer. NAD+BE — Beneficiary.
DOC+380 — facture commerciale (code 380 = Commercial Invoice).
UNT+15+1 — 15 segments dans le message (UNH et UNT inclus), référence « 1 ».

Erreurs fréquentes

MOA absent ou hors SG2 — le segment MOA du groupe 2 est mandataire. Le placer au header sans le précéder du contexte SG2 est une erreur classique côté ERP qui code à plat.
FII sans qualifier de partie — le composant 3035 (Party Function Code) doit être renseigné (OR, BF, I1…) pour que la banque sache quelle institution financière est désignée.
DTM+203 sans format conforme — la date d'exécution doit suivre le qualifier du composant 3 (102 = CCYYMMDD). Format ISO non accepté.
Devise non cohérente avec le compte débité — MOA et le compte indiqué dans FII doivent être compatibles, sinon la banque renverra un APERAK applicatif (et non un CONTRL syntaxique).
Référence document manquante — sans DOC ou RFF+CR, la banque ne peut pas réconcilier le paiement avec une facture, et un retour manuel est probable.

Messages liés

Dans un flux Cash Management complet, PAYORD s'inscrit dans une conversation avec :

CONTRL D.96A — acquittement syntaxique automatique.
APERAK D.96A — acquittement applicatif ou rejet par la banque (erreurs de validation métier).
FINSTA D.96A — relevé de compte renvoyé par la banque une fois le paiement comptabilisé.
INVOIC D.96A — la facture commerciale réglée par cet ordre.

Équivalent JSON

Projection JSON de l'exemple ci-dessus pour faciliter l'intégration en environnements API modernes. Ce mapping n'est pas normatif — c'est une convention ediverse :

json payord-d96a-equivalent.json

{
  "interchange": {
    "controlRef": "CTRL000001",
    "from": { "id": "5410000000123", "qualifier": "14" },
    "to": { "id": "BANKBEBB", "qualifier": "25" },
    "datetime": "2026-05-13T14:30:00Z",
    "syntax": { "id": "UNOC", "version": "3" }
  },
  "message": {
    "ref": "1",
    "type": "PAYORD",
    "version": { "syntax": "D", "release": "96A", "agency": "UN" }
  },
  "paymentOrder": {
    "number": "PAYORD-2026-0042",
    "function": "450",
    "status": "9",
    "documentDate": "2026-05-13",
    "executionDate": "2026-05-15",
    "amount": { "value": 12450.00, "currency": "EUR" },
    "reference": { "qualifier": "CR", "value": "INV-2026-7788", "date": "2026-04-30" },
    "parties": {
      "orderingCustomer": { "gln": "5410000000123", "name": "ACME SAS" },
      "beneficiary": { "gln": "4012345000020", "name": "SUPPLIER GMBH" }
    },
    "banks": {
      "orderedBank": { "account": "12345678901", "qualifier": "25" },
      "beneficiaryBank": { "account": "98765432109", "qualifier": "25" }
    },
    "settledDocument": { "type": "380", "number": "INV-2026-7788", "issueDate": "2026-04-30" }
  }
}

Fondamentaux

Standards

Messages phares

Outils