EDIFACT REMADV: Remittance Advice Guide

REMADV is the message that turns a lump sum on your bank statement into a list of settled invoices. Your customer's bank tells you that 3,539.40 GBP arrived. The REMADV tells you it paid three invoices, deducted 72.00 for a short delivery and took a 30.60 cash discount. Without it, your accounts team matches cash to invoices by hand and finds the short-pays weeks later.

This guide follows the GS1 EANCOM 2002 REMADV layout: directory D.01B, subset version EAN005. EANCOM 2002 is GS1's current edition and the one the other EDIFACT guides on this site use. Partners still on EANCOM 1997 send D.96A, and their UNH segment tells you which one you have.

What Is an EDIFACT REMADV?

REMADV (remittance advice) is the UN/EDIFACT message that gives "a detailed accounting relative to a payment, or other form of financial settlement, on a specified date", in GS1's words. It is a notice of payment to be made. It does not move money. The money moves through the bank, and the REMADV tells the payee what that money is for.

GS1's principles for the message are short and worth knowing before you map it:

• One REMADV can cover many commercial documents: invoices, credit notes and debit notes.
• It can quote a payment order, the instruction the payer sent its bank.
• Every remitted amount, for the whole message, each document and each line, is in one payment currency.
• Each REMADV relates to one settlement date.
• Either party can initiate it, by agreement. In retail it is almost always the buyer.

Who sends it? The payer's accounts payable system, usually a retailer or wholesaler paying its suppliers.

Who receives it? The payee's accounts receivable or cash application team.

When? With each payment run, normally a few days before the money lands. The DTM+138 payment date tells you when to expect it.

Why does it matter? Every invoice the REMADV does not explain stays open on your ledger, and every deduction it does not explain becomes a dispute you cannot start.

For the full list of EDIFACT messages and their equivalents, see EDIFACT message types. For EDIFACT syntax and envelopes, start with EDIFACT explained.

Where REMADV Sits in the Order-to-Cash Flow

REMADV is the last message in the cycle. Everything before it decides how clean it will be.

The links between steps are where deductions come from. A RECADV that books in fewer units than your DESADV said is the early warning; the REMADV deduction with AJT+4 (short delivery) is the bill for it. Reading the two side by side is usually enough to tell a genuine shortage from a receiving error.

Example 1: Three Invoices, a Short-Delivery Deduction and a Cash Discount

The fictional retailer Calder Row Markets (GLN 5412345000013) pays the fictional bakery Ashby Mill Bakery (GLN 5412345000020). The GLNs use GS1's documented example prefix 5412345 and carry valid check digits. The remittance is dated 6 November 2026 and the payment date is 10 November.

• Invoice AMB-24101 for 1,248.00 is paid in full.
• Invoice AMB-24117 for 864.00 is paid at 792.00: 72.00 is deducted for a short delivery.
• Invoice AMB-24130 for 1,530.00 is paid at 1,499.40: a 2% cash discount of 30.60 is taken.

Check the arithmetic the way your cash application system should: for each DOC, amount due plus adjustments equals amount remitted (864.00 minus 72.00 is 792.00), and the summary MOA+12 equals the sum of the document MOA+12 values.

Example 2: A Line-Level Deduction for Damaged Goods

A week later, Calder Row pays two more invoices. On invoice AMB-24152, line 3 (GTIN 5412345100256, worth 360.00) arrived partly damaged and the buyer deducts 120.00 against that line. REMADV can point at the exact invoice line with DLI, name the product with PIA, and attach the adjustment to the line rather than the whole invoice.

GS1 also uses DLI action 2 (excluded from the document) for lines that were not paid at all, as in its own short-delivery example. Line-level detail is optional, and many payers send only document-level adjustments. If yours sends lines, map them: the GTIN in PIA is what lets you trace the deduction back to a DESADV line and a RECADV discrepancy.

REMADV Structure at a Glance

Status and repeats follow the EANCOM 2002 message structure chart. M is mandatory, C conditional.

The X12 column maps by purpose. The EDI 820 guide covers the X12 side in detail; payers differ in which line-level segments they send.

Key Segments Explained

BGM: Beginning of Message

BGM+481+CRM-RA-50077+9'

Function 5 replaces an earlier REMADV sent in error, which GS1 says should be identified in the RFF group. Treat a replacement as an update to the original remittance, not as a second payment.

DTM: Payment and Document Dates

DTM+137:20261106:102'
DTM+138:20261110:102'

FII and PAI: Bank Account and Payment Means

FII+RB+40112233:ASHBY MILL BAKERY LTD'
PAI+::42'

Check the account in FII against the one you expect to be paid into. A REMADV naming an account you do not recognise is worth a phone call before anyone updates bank details.

DOC and MOA: Each Document Being Settled

DOC+380+AMB-24117'
MOA+9:864.00:GBP'
MOA+12:792.00'

GS1 makes the amount due and the amount remitted mandatory for every DOC. Other qualifiers allowed at this level include 39 (invoice total amount), 52 (discount amount) and 124 (tax amount). If a payment has no previous document behind it, GS1 says to leave the document code empty, put a dummy name in the document name element and a reference in the identifier.

AJT and MOA: Why the Amount Changed

AJT+4'
MOA+165:-72.00'

These are the codes EANCOM 2002 lists for AJT (UN/EDIFACT code list 4465). GS1 lets its member organisations add national codes for tax practices, and partner guides often narrow the list, so load the codes your payer actually uses.

The adjustment amount follows in MOA. At document level EANCOM allows 5 (adjusted amount) and 165 (adjustment amount) among others; at line level only 5. Two GS1 rules matter here:

• The adjustment is for information. GS1 says it "will not necessarily equal the difference between the amount due and the amount remitted". Reconcile on MOA+9 and MOA+12, and use the AJT group to explain the difference.
• Signs need agreeing. GS1 says a negative adjustment must carry an explicit minus sign, yet its own worked example sends a short-delivery deduction as a positive MOA+5. The examples on this page show deductions as negatives. Ask each payer which convention it uses.

AJT can be followed by RFF (for example ON, the order number), FTX and QTY, which help you find the order, delivery and line behind a deduction.

UNS and the Summary MOA

UNS+S'
MOA+12:3539.40'

UNS+S separates detail from summary, and the summary MOA+12 is the total being remitted. It should match the amount that arrives in your bank account. If it does not, the difference is a bank charge, a currency conversion or a second remittance, and the REMADV alone will not tell you which.

REMADV vs the X12 820 and TRADACOMS SRMHDR

Three differences matter when you map between them:

• The payment itself. An 820 often travels with, or inside, the payment: BPR carries routing and account numbers and can sit inside an ACH CTX addenda. REMADV is a separate message; the money goes through the bank on its own, so the REMADV references it rather than carrying it.
• Currency. REMADV states one payment currency in CUX and can carry the invoice currency and an exchange rate per document. Most 820s in US trade never need this.
• Codes. 820 deduction reasons in ADX02 come from the X12 adjustment reason list. REMADV uses UN/EDIFACT code list 4465 in AJT. The two lists are separate, so map reason codes through a table, never by number.

In TRADACOMS, the remittance file is SRMHDR (statement or remittance), with SRMINF detail messages and an SRMTLR trailer. Its field layout is its own, so a TRADACOMS remittance converts to REMADV by remap, not rename. The payment order file PAYHDR is a different thing: an instruction from the customer to its bank, closer to EDIFACT PAYMUL. The TRADACOMS file types guide lists both.

Common REMADV Errors and Fixes

REMADV Implementation Checklist

1. Get the payer's REMADV guide and confirm the directory (D.01B or D.96A) and the EANCOM version in UNH.
2. Confirm which MOA qualifiers it sends at document level, and whether it sends line detail.
3. Get its full list of AJT reason codes and decide what each one does in your ledger.
4. Agree the sign convention for adjustments and credit notes.
5. Store the REMADV number, RFF+AEK and payment date so you can match the bank deposit.
6. Test with a full payment, a deduction and a credit note before go-live.
7. Check every test file's envelope, UNT count and GLNs in the EDIFACT inspector, and the payment detail in the remittance reader.

Where OrderSync Fits

OrderSync works at the start of the cycle that REMADV closes. It reads inbound orders in any format, including EDIFACT ORDERS, X12 850s, PDFs, emails and spreadsheets, matches customers, items and units to your catalogue, and sends clean order data to your ERP. Orders that are right at intake produce fewer short-delivery and pricing deductions at the end.

For the remittance itself, use the free tools: the EDIFACT inspector for structure and counts, the remittance reader to list payments and deductions from a REMADV or an 820, and the EDI inspector for any X12 file. If you want to see how order intake would work with your customers, book a 15-minute walkthrough.

Frequently Asked Questions

Related guides

• EDIFACT explained: syntax, envelopes and the full X12 mapping
• EDIFACT INVOIC: the invoices and credit notes a REMADV settles
• EDIFACT RECADV: receiving discrepancies that turn into deductions
• EDIFACT DESADV: the despatch advice that started the claim
• EDI 820 payment order/remittance advice: the X12 counterpart
• EDI 812 credit/debit adjustment: how X12 partners raise deductions as a separate document
• TRADACOMS file types: SRMHDR and PAYHDR in context
• EDIFACT message types: every message and its X12 equivalent

Sources

• EANCOM 2002 S3: REMADV remittance advice message, GS1: structure chart, segment layouts, code lists and worked example
• EANCOM 2002 S3 Part I: message descriptions, GS1
• UN/EDIFACT D.01B REMADV message, UNECE
• Global Location Number (GLN), GS1

Paste any REMADV into the free EDIFACT inspector to check its structure, or into the remittance reader to see each payment and deduction laid out.