PAYORD — Payment Order Message (D.96A)

PAYORD is the payment order sent by the ordering customer (or their agent) to their bank, instructing it to debit an account and pay a specified amount to the beneficiary in settlement of a commercial transaction.

Purpose

Per the UN/CEFACT functional definition, PAYORD is "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". A PAYORD may cover the financial settlement of one or more commercial trade transactions (invoices, credit notes, debit notes). It is not intended for use in securities trading.

Segment structure

PAYORD D.96A is entirely flat — no Detail / Summary sections, just a header followed by eight segment groups. Segments are defined in payord_s.htm (segment table) and payord_d.htm (data segment clarification).

Header

Mandatory header segments: UNH M , BGM M , and DTM M . Other header segments are conditional: BUS C , PAI C , FCA C , and FTX C .

Segment groups

Eight segment groups structure the body, in canonical order:

• SG1 (C, ×5) — RFF + DTM: reference to a previously-sent message.
• SG2 (M, ×1) — MOA + CUX + DTM + RFF: payment amount, currencies, exchange rate, related references.
• SG3 (C, ×4) — FII + CTA + COM: financial institutions and accounts (ordering bank, beneficiary bank, intermediary).
• SG4 (C, ×6) — NAD + CTA + COM: non-financial parties (ordering customer, beneficiary) and their contacts.
• SG5 (C, ×4) — INP + FTX + DTM: instructions from the ordering customer to the identified parties.
• SG6 (C, ×10) — GIS + MOA + LOC + NAD + RCS + FTX: regulatory data (balance-of-payments authority, transaction nature).
• SG7 (C, ×10) — DOC + DTM: references to the commercial documents settled by this order (invoices, credit notes).
• SG8 (C, ×5) — AUT + DTM: authentication details (signature, MAC, validation timestamp).

The message closes with UNT M .

Mandatory / conditional

Four items are strictly mandatory in every PAYORD D.96A:

• UNH — opens the message, carries the PAYORD type and the version (D / 96A / UN).
• BGM — gives the function code, payment-order number, and document status.
• DTM — at least one header date (up to 4 repetitions allowed).
• SG2 MOA — segment group 2 is itself mandatory (M, ×1), and the leading MOA segment is mandatory: no payment order without an amount.
• UNT — closes the message, declares the segment count and reference.

All other segments (RFF, CUX, FII, NAD, INP, GIS, DOC, AUT, FCA, BUS, PAI, FTX) are conditional at the standard level. In practice, banking usage almost always requires at minimum a FII (debit account), a NAD (identified ordering customer), and a DOC (the settled commercial document).

Real-world example

A payment order from a French corporate (ACME SAS) to its bank, to settle an invoice from a German supplier (SUPPLIER GMBH):

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 between the buyer's GLN and the bank's BIC (qualifier :25 = BIC).
• BGM+450+PAYORD-2026-0042+9 — code 450 (payment order), number PAYORD-2026-0042, status 9 (Original).
• DTM+137 — creation date. DTM+203 — requested execution date.
• RFF+CR:INV-2026-7788 — customer reference to the invoice (CR = customer reference). DTM+171 = reference date.
• MOA+9:12450.00:EUR — payable amount (qualifier 9 = amount due / payable).
• FII+OR — Ordering Bank (ordering customer's account). FII+BF — Beneficiary's Financial Institution.
• NAD+OY — Ordering Customer. NAD+BE — Beneficiary.
• DOC+380 — commercial invoice (code 380 = Commercial Invoice).
• UNT+15+1 — 15 segments in the message (UNH and UNT included), reference "1".

Common errors

• MOA missing or outside SG2 — the SG2 MOA is mandatory. Placing it at the header without the SG2 context is a classic error for ERPs that flatten the structure.
• FII without a party-function qualifier — component 3035 (Party Function Code) must be set (OR, BF, I1) so the bank knows which financial institution is designated.
• DTM+203 wrong format — execution date must follow the qualifier in component 3 (102 = CCYYMMDD). ISO format is not accepted.
• Currency inconsistent with the debit account — MOA and the account in FII must be compatible, otherwise the bank returns an application-level APERAK (not a syntactic CONTRL).
• Missing document reference — without DOC or RFF+CR, the bank cannot reconcile the payment with an invoice, and manual handling is likely.

Related messages

In a full cash-management flow, PAYORD takes part in a conversation with:

• CONTRL D.96A — automatic syntactic acknowledgment.
• APERAK D.96A — application acknowledgment or rejection by the bank (business validation errors).
• FINSTA D.96A — account statement returned by the bank once the payment is booked.
• INVOIC D.96A — the commercial invoice settled by this order.

JSON equivalent

JSON projection of the example above for integration in modern API-style environments. This mapping is not normative — it's an ediverse convention:

{
  "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" }
  }
}