# EDIFACT REMADV: Remittance Advice Guide
> EDIFACT REMADV remittance advice explained: DOC, MOA 9 and 12, AJT deduction codes, two EANCOM examples, and how it maps to the X12 820 and TRADACOMS SRMHDR.
EDIFACT REMADV is the remittance advice message, the equivalent of the X12 820. The payer sends it to explain a payment: which invoices and credit notes it settles, how much was paid against each, and why anything was deducted. BGM+481 identifies it, DOC names each document, MOA 9 and 12 give amount due and remitted, and AJT gives the reason.
**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](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/remadv/toc.htm) 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](/guides/edi/edifact-message-types). For EDIFACT syntax and envelopes, start with [EDIFACT explained](/guides/edi/edifact).
## 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.
| Step | Message | Sent by | X12 | TRADACOMS |
|---|---|---|---|---|
| 1 | [ORDERS](/guides/edi/edifact-orders) | Buyer | [850](/guides/edi/850-purchase-order) | [ORDHDR](/guides/edi/tradacoms-ordhdr) |
| 2 | [DESADV](/guides/edi/edifact-desadv) | Supplier | [856](/guides/edi/856-ship-notice) | `DELHDR` |
| 3 | [RECADV](/guides/edi/edifact-recadv) | Buyer | [861](/guides/edi/861-receiving-advice) | [DLCHDR](/guides/edi/tradacoms-dlchdr) |
| 4 | [INVOIC](/guides/edi/edifact-invoic) | Supplier | [810](/guides/edi/810-invoice) | [INVFIL](/guides/edi/tradacoms-invfil) |
| 5 | **REMADV** | Payer | **[820](/guides/edi/820-payment-order)** | **`SRMHDR`** |
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.
| Segment | What it says |
|---|---|
| `BGM+481+CRM-RA-50077+9'` | Document `481` (remittance advice), number CRM-RA-50077, function `9` (original) |
| `DTM+138:20261110:102'` | The payment date: 10 November 2026 |
| `RFF+AEK:CRM-PAY-88120'` | The payment order this remittance relates to |
| `FII+RB+40112233:ASHBY MILL BAKERY LTD'` | The account that receives the funds (`RB`, receiving financial institution). The account number is fictional |
| `PAI+::42'` | Payment means `42`: payment to bank account |
| `NAD+PR` / `NAD+PE` | Payer and payee by GLN |
| `CUX+2:GBP:11'` | The payment currency is sterling |
| `DOC+380+AMB-24117'` | The second document is commercial invoice AMB-24117 |
| `MOA+9:864.00:GBP'` | Amount due on that invoice: 864.00 |
| `MOA+12:792.00'` | Amount remitted against it: 792.00 |
| `AJT+4'` then `MOA+165:-72.00'` | Adjustment reason `4` (short delivery), adjustment amount minus 72.00 |
| `AJT+66'` then `MOA+165:-30.60'` | Reason `66` (cash discount), minus 30.60 |
| `MOA+12:3539.40'` | Total remitted: 1,248.00 + 792.00 + 1,499.40 |
| `UNT+31+1'` | 31 segments from `UNH` to `UNT` inclusive |
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.
| Segment | What it says |
|---|---|
| `DLI+1+3'` | Line 3 of the invoice, action `1` (included in the document) |
| `MOA+38:360.00:GBP'` | Invoice item amount for that line |
| `PIA+5+5412345100256:SRV'` | The product on the line, by GTIN |
| `AJT+3'` | Adjustment reason `3`: damaged goods |
| `MOA+5:-120.00'` | Adjusted amount for the line. At line level, EANCOM allows only qualifier `5` |
| `MOA+12:2040.00'` (under the `DOC`) | The invoice is paid at 2,160.00 minus 120.00 |
| `MOA+12:2655.00'` | Total remitted: 2,040.00 + 615.00 |
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.
| Section | Segment | Name | Status | Repeats | Carries | X12 820 equivalent |
|---|---|---|---|---|---|---|
| Heading | `UNH` | Message header | M | 1 | `REMADV:D:01B:UN:EAN005` | `ST` |
| Heading | `BGM` | Beginning of message | M | 1 | `481`, remittance number, function | `BPR`, `TRN` |
| Heading | `DTM` | Date/time/period | M | 5 | `137` message date, `138` payment date | `BPR16`, `DTM` |
| Heading | `RFF` | Reference | C | 5 | `AEK` payment order, `CT` contract | `REF` |
| Heading | `FII` | Financial institution information | C | 5 | Paying or receiving account | `BPR06` to `BPR15` |
| Heading | `PAI` | Payment instructions | C | 1 | How payment is made | `BPR04` |
| SG1 | `NAD` | Name and address | M in group | 99 | `PR` payer, `PE` payee, `BY`, `SU` | `N1` loop |
| SG3 | `CTA`, `COM` | Contact | C | 5 | Accounts payable contact | `PER` |
| SG4 | `CUX` | Currencies | M in group | 5 | Payment currency, exchange rate | `CUR` |
| SG5 | `DOC` | Document/message details | M in group | 999999 | `380` invoice, `381` credit note, `383` debit note | `RMR01`, `RMR02` |
| SG5 | `MOA` | Monetary amount | M | 5 | `9` due, `12` remitted, `52` discount | `RMR04` to `RMR06` |
| SG5 | `DTM`, `RFF` | Document date, references | C | 5 | Invoice date, `ON` order number | `DTM`, `REF` |
| SG7 | `AJT` | Adjustment details | M in group | 100 | Reason code | `ADX02` |
| SG7 | `MOA` | Adjustment amount | C | 1 | `5`, `165` | `ADX01` |
| SG10 | `DLI` | Document line identification | M in group | 9999 | Line number on the invoice | `IT1` inside the `RMR` loop |
| SG10 | `PIA` | Additional product id | C | 5 | GTIN of the line | `IT1` product IDs |
| SG12 | `AJT`, `MOA` | Line adjustment | C | 10 | Reason and `MOA+5` | `ADX` |
| Summary | `UNS` | Section control | M | 1 | `UNS+S` | |
| Summary | `MOA` | Monetary amount | M | 99 | `12` total remitted | `BPR02` |
| Summary | `UNT` | Message trailer | M | 1 | Segment count, reference | `SE` |
The X12 column maps by purpose. The [EDI 820 guide](/guides/edi/820-payment-order) 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'
```
| Element | Name | Example | What it means |
|---|---|---|---|
| C002 / 1001 | Document name code | `481` | Remittance advice. The only code EANCOM allows here |
| C106 / 1004 | Document identifier | `CRM-RA-50077` | The payer's remittance advice number |
| 1225 | Message function code | `9` | `9` original, `5` replace, `31` copy |
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'
```
| Qualifier | Level | Meaning |
|---|---|---|
| `137` | Heading | Message date |
| `138` | Heading | Payment date |
| `203` | Heading | Execution date requested: the date the payer asked its bank to make the payment |
| `137` | Under `DOC` | Date of the referenced invoice or credit note |
| `140` / `265` | Under `DOC` | Payment due date / due date |
### FII and PAI: Bank Account and Payment Means
```
FII+RB+40112233:ASHBY MILL BAKERY LTD'
PAI+::42'
```
| Segment / element | Example | What it means |
|---|---|---|
| `FII` 3035 | `RB` | `RB` receiving financial institution (the payee's bank), `PB` paying financial institution |
| `FII` C078 | `40112233:ASHBY MILL BAKERY LTD` | Account number and account holder name |
| `FII` C088 | (not sent) | Optional bank identification, for example a code from list `25` under agency `5` (ISO) |
| `PAI` 4461 | `42` | Payment means: `42` payment to bank account, `56` bankgiro |
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'
```
| Element | Example | What it means |
|---|---|---|
| `DOC` 1001 | `380` | `380` commercial invoice, `381` credit note, `383` debit note, `82` metered services invoice, `83` and `84` credit and debit notes for financial adjustments |
| `DOC` 1004 | `AMB-24117` | Your document number, exactly as it appeared in your INVOIC |
| `MOA` 5025 | `9` | Amount due/amount payable: what the document was for |
| `MOA` 5025 | `12` | Amount remitted against this document |
| `MOA` 6345 | `GBP` | Currency. GS1 says it is not used with `12`, which is always in the payment currency, and is required with the other qualifiers |
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'
```
| Code | Meaning |
|---|---|
| `1` | Agreed settlement |
| `3` | Damaged goods |
| `4` | Short delivery |
| `5` | Price query |
| `9` | Invoice error |
| `40` | Deducted freight costs |
| `66` | Cash discount |
| `74` / `75` / `77` / `79` | Quantity, promotion, pricing and sundry discount |
| `90` | Treasury management service charge |
| `ZZZ` | Mutually defined |
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
| Data | EDIFACT REMADV | X12 820 |
|---|---|---|
| Message | `UNH` `REMADV` | `ST*820` |
| Payment total | Summary `MOA+12` | `BPR02` |
| Payment date | `DTM+138` | `BPR16` |
| Payment means and bank | `PAI`, `FII` | `BPR04` to `BPR15` |
| Trace or reference | `BGM` number, `RFF+AEK` | `TRN02` |
| Payer and payee | `NAD+PR` / `NAD+PE` with GLNs | `N1*PR` / `N1*PE` |
| Each document | `DOC` with code `380`, `381`, `383` | `RMR01` qualifier, `RMR02` number |
| Amount due / paid | `MOA+9` / `MOA+12` | `RMR05` / `RMR04` |
| Discount | `MOA+52`, or `AJT+66` with `MOA` | `RMR06` |
| Deduction | `AJT` reason + `MOA` amount | `ADX02` reason + `ADX01` amount |
| Line detail | `DLI`, `PIA` | `IT1` inside the `RMR` loop, where used |
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](/guides/edi/tradacoms-file-types) lists both.
## Common REMADV Errors and Fixes
| Problem | What you see | Fix |
|---|---|---|
| Invoice number does not match | `DOC` quotes a number your ledger does not hold | Check your INVOIC `BGM` number. Leading zeros and prefixes are the usual cause |
| Reconciling on the adjustment | Adjustments do not add up to the shortfall | Reconcile on `MOA+9` and `MOA+12`. GS1 says adjustments are informative |
| Sign convention assumed | Deductions applied as extra payments | Agree with each payer whether deductions are negative |
| Summary total differs from the deposit | Bank amount and `MOA+12` disagree | Look for bank charges, conversion, or a split payment across two REMADVs |
| Line-level detail ignored | Deduction cannot be traced to a delivery | Map `DLI` and `PIA`, then match the GTIN to your DESADV and RECADV |
| Replacement processed as new | The same payment applied twice | `BGM` function `5` replaces an earlier REMADV; update it |
| Unknown `AJT` code | Deduction lands in a suspense account | Load the payer's code list and route each code to the right team |
| Wrong `UNT` count | Translator rejects the message | Count every segment from `UNH` to `UNT` inclusive |
## 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](/edifact-inspector), and the payment detail in the [remittance reader](/tools/edi-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](/edifact-inspector) for structure and counts, the [remittance reader](/tools/edi-remittance-reader) to list payments and deductions from a REMADV or an 820, and the [EDI inspector](/edi-inspector) for any X12 file. If you want to see how order intake would work with your customers, [book a 15-minute walkthrough](/book-call).
## Frequently Asked Questions
### What is a REMADV in EDI?
REMADV is the UN/EDIFACT remittance advice message. A payer, usually a retailer or wholesaler, sends it to a supplier to explain a payment: which invoices, credit notes and debit notes it settles, the amount paid against each, and the reason for any deduction or discount.
### What is the X12 equivalent of REMADV?
The X12 820 Payment Order/Remittance Advice. The 820 can also carry the payment instruction to the bank, while REMADV only explains the payment. In TRADACOMS the remittance file is SRMHDR.
### What do MOA 9 and MOA 12 mean in a REMADV?
Under each DOC segment, MOA qualifier 9 is the amount due or payable on that document and qualifier 12 is the amount remitted against it. The summary MOA+12 after UNS is the total payment.
### What does AJT+4 mean?
AJT is the adjustment segment and code 4 is short delivery, from UN/EDIFACT code list 4465. Other common codes are 3 damaged goods, 5 price query, 9 invoice error and 66 cash discount. The partner's guide lists which ones it sends.
### Can one REMADV cover payments in two currencies?
No. GS1 says every remitted amount in a REMADV is in one payment currency, and each REMADV relates to one settlement date. A document invoiced in another currency can carry its own exchange rate in a CUX segment.
### Does a REMADV mean the money has arrived?
No. GS1 describes it as a notice of payment to be made. The DTM+138 payment date says when the payer expects to pay. Match the summary MOA+12 to the actual bank credit before closing the invoices.
### Is REMADV the same as PAYMUL?
No. PAYMUL is a multiple payment order the buyer sends to its bank to make the payments. REMADV goes to the supplier to say what the payment covers. The REMADV can reference the payment order in RFF+AEK.
## Related guides
- **[EDIFACT explained](/guides/edi/edifact)**: syntax, envelopes and the full X12 mapping
- **[EDIFACT INVOIC](/guides/edi/edifact-invoic)**: the invoices and credit notes a REMADV settles
- **[EDIFACT RECADV](/guides/edi/edifact-recadv)**: receiving discrepancies that turn into deductions
- **[EDIFACT DESADV](/guides/edi/edifact-desadv)**: the despatch advice that started the claim
- **[EDI 820 payment order/remittance advice](/guides/edi/820-payment-order)**: the X12 counterpart
- **[EDI 812 credit/debit adjustment](/guides/edi/812-credit-debit-adjustment)**: how X12 partners raise deductions as a separate document
- **[TRADACOMS file types](/guides/edi/tradacoms-file-types)**: SRMHDR and PAYHDR in context
- **[EDIFACT message types](/guides/edi/edifact-message-types)**: every message and its X12 equivalent
## Sources
- [EANCOM 2002 S3: REMADV remittance advice message](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/remadv/toc.htm), GS1: structure chart, segment layouts, code lists and worked example
- [EANCOM 2002 S3 Part I: message descriptions](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part1/part1_02.htm), GS1
- [UN/EDIFACT D.01B REMADV message](https://service.unece.org/trade/untdid/d01b/trmd/remadv_c.htm), UNECE
- [Global Location Number (GLN)](https://www.gs1.org/standards/id-keys/gln), GS1
Paste any REMADV into the free [EDIFACT inspector](/edifact-inspector) to check its structure, or into the [remittance reader](/tools/edi-remittance-reader) to see each payment and deduction laid out.