EDIFACT message guide · Finance

PAYMUL Multiple payment order

The UN/EDIFACT message a company sends to its bank to debit an account and pay several beneficiaries.

Sent by
Ordering customer (payer) or its agent
Received by
Ordered bank
Standard
UN/EDIFACT · Batch message
X12 equivalent
No direct equivalent

What is the EDIFACT PAYMUL message?

PAYMUL is the UN/EDIFACT multiple payment order. The directory defines it as a message sent by the ordering customer, or a payer or agent on its behalf, to the ordered bank, instructing the bank to debit an account it services for the customer and to pay specified amounts to several beneficiaries in settlement of the referenced business transactions.

Companies use PAYMUL to send a supplier payment run or payroll to their bank in one file. Each payment can carry remittance information for the beneficiary. Many banks now also accept ISO 20022 payment formats, so the format choice is part of each bank connection.

How the EDIFACT PAYMUL message worksDiagram of the UN/EDIFACT PAYMUL Multiple payment order message. Ordering customer (payer) or its agent sends it to ordered bank. It usually starts the exchange. It is usually followed by BANSTA and FINSTA. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message) and DTM (Date/time/period) and body and segment groups: the required SG4 loop with LIN (Line item), the required SG6 loop with FII (Financial institution information) and the required SG11 loop with SEQ (Sequence details) and MOA (Monetary amount). 14 conditional segment groups are listed by their trigger segment.How the EDIFACT PAYMUL message worksMultiple payment order: who sends it, where it fits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangePAYMULSENDEROrdering customer(payer) or its agentRECEIVEROrdered bankCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYBANSTABanking statusFINSTAFinancial statement ofan account2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDsUNB … UNZMessage PAYMULUNH … UNTSTART OF MESSAGEBGMBeginning of messageDTMDate/time/periodBODY AND SEGMENT GROUPSMandatory group SG4 · repeats up to 9,999LINLine itemMandatory group SG6 · repeats up to 2FIIFinancial institution informationMandatory group SG11 · repeats many timesSEQSequence detailsMOAMonetary amount+ 14 conditional groups, starting with:RFFFIINADMOAINPGEIPRCAUTBlue box: mandatory segment group. Conditional groups are listed by the trigger segment that starts them; a group is sent only when its data applies.Conditional segments outside groups are not drawn.Structure: mandatory segments and groups in the UN/EDIFACT directory D.21A listing for PAYMUL. Your trading partner's implementation guide adds itsown requirements.
How the EDIFACT PAYMUL message worksDiagram of the UN/EDIFACT PAYMUL Multiple payment order message. Ordering customer (payer) or its agent sends it to ordered bank. It usually starts the exchange. It is usually followed by BANSTA and FINSTA. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message) and DTM (Date/time/period) and body and segment groups: the required SG4 loop with LIN (Line item), the required SG6 loop with FII (Financial institution information) and the required SG11 loop with SEQ (Sequence details) and MOA (Monetary amount). 14 conditional segment groups are listed by their trigger segment.How the EDIFACT PAYMULmessage worksMultiple payment order: who sends it, where itfits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangePAYMULSENDEROrderingcustomer(payer) or itsagentRECEIVEROrdered bankCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYBANSTABanking statusFINSTAFinancial statement of an account2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDs(UNB … UNZ)Message PAYMUL (UNH … UNT)START OF MESSAGEBGMBeginning of messageDTMDate/time/periodBODY AND SEGMENT GROUPSMandatory group SG4 · repeats upto 9,999LINLine itemMandatory group SG6 · repeatsup to 2FIIFinancial institutioninformationMandatory group SG11 · repeatsmany timesSEQSequence detailsMOAMonetary amount+ 14 conditional groups, starting with:RFFFIINADMOAINPGEIPRCAUTBlue box: mandatory segment group. Conditionalgroups are listed by the trigger segment thatstarts them; a group is sent only when its dataapplies. Conditional segments outside groups arenot drawn.Structure: mandatory segments and groups in theUN/EDIFACT directory D.21A listing for PAYMUL.Your trading partner's implementation guide adds itsown requirements.

How to read this diagram: the top row shows who sends PAYMUL, to whom, and which messages usually come before and after it. The lower part shows what the directory D.21A itself requires: the envelopes around PAYMUL and the segments and segment groups it marks mandatory. Conditional groups are listed by their trigger segment rather than drawn in full. This is the directory's minimum, not a trading partner's requirement: a message implementation guide, such as an industry subset or a partner’s own guide, usually makes some conditional groups mandatory, restricts the codes and may use an older directory.

Expand diagram Download SVG

When it is used

  • Sending a supplier payment run to a bank
  • Paying many beneficiaries from one account
  • Transmitting payroll payments

Where it fits in the message flow

This message PAYMUL Multiple payment order

Structure

Mandatory segments in PAYMUL (directory D.21A)

In UN/EDIFACT directory D.21A, the PAYMUL message has 89 segment positions arranged in 24 segment groups. These are the segments and segment groups marked mandatory at message level, in order; a mandatory group is shown with the segment that starts it. Segments inside conditional groups are needed only when the group is used. This is the directory’s requirement, not your trading partner’s: each partner’s message implementation guide names the directory it uses, often an older one such as D.96A or D.01B where the structure can differ, makes some conditional segments mandatory and restricts the codes.

  • UNH
  • BGM
  • DTM
  • SG4 (LIN)
  • UNT

Practical example

PAYMUL in practice

A manufacturer runs its weekly supplier payments. Its ERP produces a PAYMUL with 140 payments from its operating account, each with the supplier's bank account, amount, currency, execution date and invoice references. The bank validates the file, reports the processing status and executes the payments, and the next account statement shows the debit.

Implementation

Implementation considerations for PAYMUL

  • Confirm which formats and versions each bank supports, including ISO 20022 alternatives.
  • Secure the channel and apply approval controls before payments leave.
  • Include remittance references so suppliers can apply the cash.
  • Reconcile bank status messages and statements to the payments sent.

Need help with PAYMUL?

ECOM maps, tests and monitors EDIFACT messages for your trading partners and integrates them with your ERP.