# EDI 180 Return Merchandise Authorization Guide
> EDI 180 explained: return requests, RMA authorizations and return notices, the BGN, BLI and RDR segments, reason and disposition codes, and live examples.
The EDI 180 Return Merchandise Authorization and Notification is the X12 transaction trading partners use to manage returns. A retailer or distributor sends it to request permission to return goods, the supplier sends one back to authorize or deny each line and issue an RMA number, and either side can use it to notify the other of a return.
**The EDI 180 replaces the return authorization email thread.** A distributor finds defective units, overstock or freight damage, asks the supplier if it can send them back, waits for an RMA number, ships, and then chases the credit. The 180 puts each of those steps into structured data: the items, the quantities, the reason for each line, and the supplier's decision on each line.
This guide covers what the 180 carries, the request and authorization flow, two live examples (a distributor's request and the manufacturer's answer), every segment you are likely to map, the reason and disposition codes, and how the 180 connects to the 810, 812 and 856.
## What Is an EDI 180?
**An EDI 180 is the Return Merchandise Authorization and Notification transaction set defined by the [ASC X12 standards body](https://x12.org/products/transaction-sets). The X12 purpose statement says it supports customary business practice for returning merchandise to the vendor, and can serve as a request for a return, an authorization or disposition of the return, a notification of a return, or a notification of a consumer return.** It travels in functional group `AN` (Return Merchandise Authorization and Notification).
Authoritative references for 180 work:
- The [X12 transaction set catalog](https://x12.org/products/transaction-sets) defines the 180 structure, its segment order and the return reason and disposition code lists
- The [Healthcare Distribution Alliance](https://www.hda.org/publications/edi-guidelines-for-180-return-merchandise-authorization-notification-812-credit-debit-adjustment) publishes industry guidelines for the 180 and the 812 Credit/Debit Adjustment between pharmaceutical manufacturers and distributors
- The [Stedi X12 4010 reference](https://www.stedi.com/edi/x12-004010/180) lists every 180 segment with its usage and repeat counts
- Each trading partner's 180 implementation guide decides which of the uses it supports and which segments and codes it requires
**Who sends it?** It depends on the use. The returning party (a retailer, distributor or pharmacy wholesaler) sends a request or a return notice. The supplier sends the authorization or denial. Some retailers send the 180 to drop-ship vendors to report that a consumer has returned an item.
**Who receives it?** The other side of the same relationship: the supplier's customer service or returns team for a request, the buyer's purchasing or returns team for an authorization.
**When is it sent?** A request goes out before anything ships back. The authorization comes back once the supplier has reviewed it. A notification is sent when goods have been returned, or when a consumer return has been received.
**Why does it matter?** Returns that move without an authorization tend to be refused at the supplier's dock, or accepted and never credited. A 180 exchange gives both sides the same record of what was approved, which is what the later credit is checked against.
## The Four Uses of a 180
One transaction set covers several steps of the returns process. Your partner's guide will say which it uses.
| Use | Sent by | What it says |
|---|---|---|
| **Return request** | Returning party (buyer) | These items, these quantities, for these reasons: may we send them back? |
| **Authorization or disposition** | Supplier | Per line: return authorized (with an RMA number), denied, keep with an allowance, dispose, or ship to a third party |
| **Return notification** | Returning party | These items have been (or are being) returned |
| **Consumer return notification** | Retailer | A consumer returned this item, for this reason, often in a drop-ship program |
The standard does not have one header flag that says "request" or "authorization" in every implementation. Partners tell them apart by which `RDR` elements are filled in (a request carries reasons, an authorization carries dispositions), by `BGN06` pointing an authorization back to the request it answers, and in some guides by a transaction type code in `BGN`. Read the partner's guide before you build the map.
## How a Return Authorization Flows
A typical distributor return to a manufacturer runs like this:
1. **Identify the return.** The distributor's warehouse or returns desk collects goods to send back: defective units returned by customers, damaged deliveries, excess or slow-moving stock under a stock rotation agreement.
2. **Request.** The distributor sends a 180 listing each item, quantity and reason, referencing the original purchase order and, where known, the invoice.
3. **Review.** The supplier checks each line against its return policy, the original sale and any agreement in place.
4. **Authorize.** The supplier sends a 180 back with an RMA number in `N9*RZ`, an expiry date, the address to return to, and a disposition for each line. Some lines may be authorized, some denied, and some marked for disposal in the field.
5. **Ship.** The distributor ships only the authorized lines, quoting the RMA number on the paperwork and cartons.
6. **Receive and inspect.** The supplier receives the return against the RMA and confirms quantity and condition.
7. **Credit.** The supplier issues the credit, as a credit memo, an [812 Credit/Debit Adjustment](/guides/edi/812-credit-debit-adjustment) or a credit [810 invoice](/guides/edi/810-invoice), depending on the relationship. Where the buyer has already taken a deduction, the credit closes it out.
Step 7 is where most return disputes land. If the credit does not match what the 180 authorized, both sides need the 180 exchange to work out why.
## Interactive Example: Distributor Return Request
A hardware distributor asks a tool manufacturer to accept three lines back against purchase order `PO-448812`: six cordless drills returned by customers as defective (used), four circular saws of excess stock (unused), and two drill bit sets that arrived damaged. Each `BLI` line carries the vendor item number, quantity and UPC, a `PID` description, and an `RDR` with the request reason in `RDR02` and whether the item was used in `RDR05`.
Use the **Plain English** tab for a readable summary, or click any segment to break it down element by element.
## Interactive Example: Manufacturer Return Authorization
Two days later the manufacturer answers. `BGN06` points back to the request, `N9*RZ` carries the RMA number, `DTM*036` says when the authorization expires, and an `N1*ST` loop gives the returns center address. Line by line: the drills are authorized (`RDR*RA`), the saws are denied with a response reason (`RT`, return window exceeded) and a short note, and the damaged bit sets are marked `DI` (dispose, do not ship).
## 180 Structure at a Glance
The 180 has a heading, a detail loop per item (`BLI`), and nested loops for quantities, locations and serial or lot data.
| Area | Segment | Name | Usage | Notes |
|---|---|---|---|---|
| Heading | **ST** | Transaction Set Header | Mandatory | `ST01` = `180` |
| Heading | **BGN** | Beginning Segment | Mandatory | Purpose, reference number, date, and the original transaction this answers |
| Heading | **RDR** | Return Disposition Reason | Optional | Reason or disposition for the whole return |
| Heading | **PRF** | Purchase Order Reference | Optional | The original PO |
| Heading | **DTM** | Date/Time Reference | Optional | For example the authorization expiry |
| Heading | **N9** | Reference Identification | Optional | RMA number, invoice number and other references |
| Heading | **PER** | Administrative Communications Contact | Optional | Returns contact |
| Heading | **SAC, G38** | Allowances, charges, claim payment | Optional | Restocking fees, handling charges, claim terms |
| Heading | **PKG, TD1, TD5** | Packaging and carrier details | Optional | How the return should ship |
| Heading | **NTE** | Note/Special Instruction | Optional | |
| Heading loop | **N1, N2, N3, N4, PER** | Name and address | Optional loop | Buyer, vendor, ship-from and return-to parties |
| Heading loop | **LM / LQ** | Code source and industry code | Optional loop | Industry code lists |
| Detail loop | **BLI** | Baseline Item Data | Mandatory in loop | Item IDs, quantity, unit and price |
| Detail loop | **N9, PID** | References and description | Optional | |
| Detail loop | **RDR** | Return Disposition Reason | Optional | Line-level reason or disposition |
| Detail loop | **SAC, AMT, MEA, CRC, NTE** | Charges, amounts, measurements, conditions, notes | Optional | |
| Detail loop | **PRF, DTM** | Line-level PO and dates | Optional | Used when lines come from different orders |
| Detail loop | **DD, GF, TD5, SDQ** | Demand, furnished goods, carrier, destination quantities | Optional | |
| Detail loop | **N1 loop** | Line-level parties | Optional loop | |
| Detail loop | **QTY loop** | Quantity, with AMT, DTM, N1 and LM | Optional loop | Alternative to the quantity in `BLI03` |
| QTY loop | **LX loop** | Assigned number, N9, DTM, N1 | Optional loop | Serial numbers, lot numbers and inventory data |
| QTY loop | **FA1 / FA2** | Financial accounting data | Optional loop | Accounting data, where the partner requires it |
| Trailer | **SE** | Transaction Set Trailer | Mandatory | Segment count and control number |
Most commercial 180s use a small part of this: `BGN`, `PRF`, `N9`, the `N1` loop, and `BLI` with `PID` and `RDR`. In the envelope, `GS01` is **AN**.
## Key Segments Explained
### BGN: Beginning Segment
```
BGN*00*RA-55120*20261107***RR-20261105-01~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **BGN01** | Transaction Set Purpose Code | `00` | `00` = original |
| **BGN02** | Reference Identification | `RA-55120` | This transaction's reference number |
| **BGN03** | Date | `20261107` | The date of this transaction |
| **BGN04 / BGN05** | Time and time code | | Optional |
| **BGN06** | Reference Identification | `RR-20261105-01` | The reference of an earlier transaction this one affects. In the example, the request being answered |
`BGN06` is what ties an authorization to its request. If your system cannot match on it, you end up matching on PO and item, which breaks as soon as there are two returns against the same order.
### N9: Reference Identification
```
N9*RZ*RMA-77310~
N9*IV*INV-77120~
```
`N901` is the qualifier and `N902` the value. `RZ` is the returned goods authorization number (the RMA), and `IV` is the seller's invoice number. The RMA number is the key the supplier's dock receives against, so it has to reach the shipping paperwork exactly as sent.
### PRF: Purchase Order Reference
```
PRF*PO-448812***20261002~
```
`PRF01` is the original purchase order number and `PRF04` its date. At heading level it applies to the whole return. When lines come from different orders, the same segment goes inside each `BLI` loop instead.
### BLI: Baseline Item Data
```
BLI*VN*RT-DRL-18V*6*EA****UP*081550200140~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **BLI01 / BLI02** | Product ID qualifier and ID | `VN` / `RT-DRL-18V` | The first item identifier. `VN` = vendor item number |
| **BLI03** | Quantity | `6` | Quantity to return (or authorized). The alternative is a `QTY` loop |
| **BLI04** | Unit of Measure | `EA` | Applies to the quantity, and to the price unless `BLI07` is sent |
| **BLI05 / BLI06** | Price identifier and unit price | | Sent as a pair when used |
| **BLI07** | Price unit of measure | | Only when the price unit differs from `BLI04` |
| **BLI08 to BLI13** | Up to three more ID pairs | `UP` / `081550200140` | For example a UPC, a buyer item number or a model number |
`BLI` allows four item identifiers per line. Send the ones the supplier's guide asks for, and make sure they all describe the same unit: a case UPC with a quantity in eaches is a common cause of a line being denied as an unidentifiable item.
### PID: Product/Item Description
```
PID*F****18V CORDLESS DRILL KIT~
```
`PID01` = `F` (free-form) and `PID05` the description. It helps the person reviewing the return, but suppliers match on the identifiers in `BLI`, not on the description.
### RDR: Return Disposition Reason
`RDR` is the heart of the 180. It carries the buyer's reason for the return, the supplier's answer, or both sides of the decision, at heading level or per line.
```
RDR**DR***Y~
RDR*RD**RT*OUTSIDE STOCK RETURN WINDOW~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **RDR01** | Returns Disposition Code | `RD` | What happens to the goods (authorized, denied, dispose, keep with allowance) |
| **RDR02** | Return Request Reason Code | `DR` | Why the returning party wants to return them |
| **RDR03** | Return Response Reason Code | `RT` | The supplier's reason for its response |
| **RDR04** | Description | `OUTSIDE STOCK RETURN WINDOW` | Free text, up to 80 characters |
| **RDR05** | Yes/No Condition | `Y` | `Y` if the item has been used, `N` if not |
X12 allows only one of `RDR02` and `RDR03` in the same segment, so a single `RDR` is either the request side or the response side.
**Common return request reasons (`RDR02`):**
| Code | Meaning |
|---|---|
| `DA` | Damaged product |
| `DT` | Damaged in transit |
| `DM` | Defective, found on store inspection |
| `DR` | Defective, returned by consumer |
| `WG` | Wrong goods or not ordered |
| `CO` | Customer ordering error |
| `EI` | Excess inventory |
| `EO` | End of season |
| `SR` | Stock reduction agreement |
| `DI` | Discontinued product |
| `SD` | Short-dated product |
| `BC` | Beyond code date |
| `PR` / `RE` | Product recall / recall |
| `SP` | Shipped past cancel date |
| `PE` | Price error |
**Dispositions (`RDR01`):**
| Code | Meaning |
|---|---|
| `RA` | Return with authorization number |
| `RN` | Return without authorization number |
| `RP` | Return authorization pending |
| `PA` | Partially authorized |
| `RD` | Request denied |
| `DI` | Dispose: destroy or dispose of the goods, do not ship |
| `KA` | Keep with an allowance |
| `KR` | Keep and repair |
| `RF` | Return for factory repair |
| `MW` | Manufacturer warranty service |
| `RT`, `SC`, `SD` | Ship to a third party, for charitable contribution, or for disposal |
| `CR` | Consumer returned directly to the vendor |
**Response reasons (`RDR03`)** explain a denial or a condition: `NR` (no record of original sale), `RT` (return time limit exceeded or beyond warranty), `OS` (out of season or discontinued line), `IN` (item not defective), `QD` (quantity difference), `PC` (pricing or cost difference), `UI` (unidentifiable item), `MI` (more information requested), `PR` (picture requested) and `SR` (sample requested), among others.
These code lists are the X12 4010 values. Partners use a subset, and the subset is in their guide.
### DTM: Date/Time Reference
```
DTM*036*20261207~
```
`DTM01` = `036` (expiration) and `DTM02` the date. On an authorization it says how long the RMA is valid. On a notification, partners often use `050` (received) for the date the goods or the consumer return arrived.
### N1 Loop: Parties and the Return Address
```
N1*ST*RIDGELINE RETURNS CENTER*92*RC01~
N3*88 FOUNDRY RD~
N4*DES MOINES*IA*50313~
```
The `N1` loop names the buyer (`BY`), the vendor (`VN`), where the return ships from (`SF`) and where it ships to (`ST`). On an authorization, the ship-to is the address the returning party must use. It is often a returns center or a third-party processor, not the warehouse the goods first shipped from.
### QTY and LX Loops: Serial and Lot Detail
When each returned unit has to be identified, the quantity moves out of `BLI03` into a `QTY` loop, and an `LX` loop under it carries serial numbers, lot numbers and inventory data in `N9` segments, with an optional `N1` naming the manufacturer of that serial or lot. Electronics, medical devices and pharmaceuticals are the usual users. Which qualifiers carry the serial and lot numbers is set by the partner's guide.
## Retail, Distribution and Healthcare Returns
The same transaction set behaves differently by industry.
- **Wholesale and industrial distribution.** The distributor requests, the manufacturer authorizes. Excess stock returns usually fall under a stock rotation or stock reduction agreement, which is why `SR` and `EI` exist as reasons. [EDI for wholesale distribution](/edi-for/wholesale-distribution) covers the wider document set.
- **Retail and drop ship.** Some retailers use the 180 to notify a drop-ship vendor that a consumer has returned an item, with a reason code per line, so the vendor can restock or credit. Others run returns through a vendor portal and never send a 180.
- **Healthcare distribution.** Pharmaceutical manufacturers and distributors use the 180 alongside the 812 under the HDA guidelines, with short-dated, expired and recalled product as common reasons, and lot detail on each line. See [EDI for pharmaceutical suppliers](/edi-for/pharmaceutical).
## EDI 180 vs 812, 810, 856 and 824
| Document | Sent by | Purpose | Relationship to the 180 |
|---|---|---|---|
| **180 Return Merchandise Authorization and Notification** | Either side | Request, authorize, deny or notify a return | The return record itself |
| **[812 Credit/Debit Adjustment](/guides/edi/812-credit-debit-adjustment)** | Either side | Credits and debits outside an invoice | Often how the credit for an authorized return is issued, or how a buyer deducts for it |
| **[810 Invoice](/guides/edi/810-invoice)** | Supplier | Bills for goods | The original sale the return refers to; some partners issue a credit 810 for returns |
| **[856 Ship Notice](/guides/edi/856-ship-notice)** | Supplier | Describes an outbound shipment | The original shipment. A return is not an 856 unless the partner's guide asks for one |
| **[824 Application Advice](/guides/edi/824-application-advice)** | Receiver | Reports content errors in a received document | May be sent if a 180 fails the receiver's business rules |
| **[997 Functional Acknowledgment](/guides/edi/997-functional-acknowledgment)** | Receiver | Confirms receipt and syntax | Says the 180 arrived, not that the return is approved |
Two confusions come up often. The [855](/guides/edi/855-purchase-order-acknowledgment) and [860](/guides/edi/860-purchase-order-change) have no role in returns: rejecting a line on an 855 declines to ship it in the first place. And a 997 accepting your 180 request is not an authorization. Only the supplier's 180 response (or its returns portal) is.
## Where the 180 Sits in the Order Lifecycle
1. **Order.** [850 purchase order](/guides/edi/850-purchase-order), acknowledged on an 855.
2. **Ship.** 856 ship notice, goods received.
3. **Bill.** 810 invoice, paid with an [820 remittance](/guides/edi/820-payment-order).
4. **Return request.** 180 from the buyer, referencing the PO and invoice.
5. **Authorization.** 180 from the supplier with an RMA number and per-line dispositions.
6. **Return shipment.** The buyer ships authorized lines quoting the RMA.
7. **Credit.** 812, credit 810 or credit memo, matched to the authorization.
The full lifecycle is in our [EDI order lifecycle guide](/guides/edi/edi-order-lifecycle).
## Common 180 Errors and How to Prevent Them
| Error | What happens | Prevention |
|---|---|---|
| **No PO or invoice reference** | Supplier denies with `NR` (no record of original sale) | Send `PRF` and `N9*IV` from the original order and invoice |
| **Item identifiers that do not match the original sale** | Line denied as unidentifiable (`UI`) | Use the same vendor item number and UPC as the 810 |
| **Case code with an each quantity** | Quantity difference or wrong credit | Keep unit of measure and identifier at the same level |
| **Reason code the partner does not accept** | Request rejected, or held for manual review | Map reasons to the subset in the partner's guide |
| **Both `RDR02` and `RDR03` in one segment** | Syntax error on the 997 | One `RDR` per side of the decision |
| **Shipping denied or disposal lines** | Goods refused at the dock, or no credit | Ship only lines with an authorizing disposition |
| **RMA number missing from the paperwork** | Return received as unknown freight | Print `N9*RZ` on the bill of lading and cartons |
| **Shipping after the authorization expires** | Return refused | Watch the `DTM*036` date |
| **Authorization not linked to the request** | Responses matched to the wrong return | Populate `BGN06` with the request's `BGN02` |
Returns that go wrong usually show up later as [deductions and chargebacks](/edi-chargebacks). The [EDI inspector](/edi-inspector) lays out each `BLI` and `RDR` element by name, which makes a 180 quick to check before you send it.
## 180 Implementation Checklist
- Confirm which uses the partner supports: requests, authorizations, notifications, consumer return notices
- Get its 180 guide and the subset of `RDR` codes it accepts on each side
- Confirm how it tells a request from a response (`RDR` content, `BGN06`, a `BGN` transaction type code)
- Confirm the item identifiers it wants in `BLI`, and whether quantity goes in `BLI03` or a `QTY` loop
- Confirm whether serial or lot numbers are required, and in which `N9` qualifiers
- Agree how the credit is issued: 812, credit 810 or memo, and what it references
- Make sure the RMA number flows to your shipping paperwork
- Test a full request, a partial authorization, a denial and a disposal
If you are mapping a new partner's document set, the [EDI document types reference](/edi-document-types) and [EDI compliance guide](/edi-compliance) show where returns fit alongside orders, ship notices and invoices.
## Getting the Original Orders Right With OrderSync
Most returns trace back to the order: a wrong item, a wrong unit, a quantity keyed twice. Distributors and suppliers receive those orders as EDI 850s, but also as emails, PDFs and spreadsheets, and each one has to be matched to the right customer, item and unit before it ships.
OrderSync reads inbound orders in any format, matches customers, items and units to your catalog, and outputs valid X12 or clean data to your ERP. Paste any 180 into the [free EDI inspector](/edi-inspector) to see it parsed with a plain-English summary, or [book a 15-minute walkthrough](/book-call) to see your own orders processed.
## Frequently Asked Questions
### What is an EDI 180 used for?
The EDI 180 manages merchandise returns between trading partners. A buyer uses it to request permission to return goods, the supplier uses it to authorize or deny each line and issue an RMA number, and either side can use it to notify the other that goods or consumer returns have come back.
### Who sends the EDI 180?
Both sides. The returning party, usually a retailer, distributor or wholesaler, sends return requests and return notices. The supplier sends the authorization or denial. Some retailers also send it to drop-ship vendors to report consumer returns.
### Where does the RMA number go in an EDI 180?
Most guides carry it in an N9 segment with qualifier RZ, which X12 names the Returned Goods Authorization Number. It can appear at heading level for the whole return or inside a BLI loop for a single line, depending on the partner's guide.
### What is the RDR segment?
RDR is the Return Disposition Reason segment. RDR01 is the disposition (authorized, denied, dispose, keep with allowance), RDR02 is the returning party's reason, RDR03 is the supplier's response reason, RDR04 is free text and RDR05 says whether the item was used. Only one of RDR02 and RDR03 may appear in the same segment.
### What is the difference between EDI 180 and EDI 812?
The 180 is about the goods: whether they can come back and what happens to them. The 812 Credit/Debit Adjustment is about the money: the credit or deduction that follows. Many relationships use both, with the 812 referencing the authorized return.
### Is a 997 for my 180 request an approval?
No. A 997 only confirms the 180 arrived and passed syntax checks. Approval comes from the supplier's own 180 response, with a disposition on each line, or through whatever returns process its guide names.
### What functional group does the EDI 180 use?
The 180 travels in functional group AN in GS01. Most commercial implementations use release 004010, but the version is set by each partner's implementation guide.