X12 transaction guide · Returns
EDI 180 Return Merchandise Authorization and Notification
The X12 document trading partners use to request a return, authorize or deny it, or give notice that goods are being returned.
- Sent by
- Customer requesting a return, or supplier authorizing it
- Received by
- Supplier or vendor, or the customer
- Standard
- ANSI ASC X12
- EDIFACT equivalent
- RETANN (return announcement)
What is an EDI 180?
The EDI 180 Return Merchandise Authorization and Notification is the ANSI X12 transaction set that supports returning merchandise to a vendor. The same transaction set covers several steps of a return: a customer's request to return goods, the supplier's authorization or denial and the disposition it wants, notice that goods are being returned, and notice of returns made by consumers.
Each 180 identifies the items being returned, their quantities and prices, the original purchase order and the reason for the return, such as damaged or wrong goods. Because returns affect credits, inventory and warehouse handling, the 180 is usually linked to a credit memo or debit adjustment and to the receiving process at the return location.
How to read this diagram: the top row shows who sends the 180, to whom, and which documents usually come before and after it. The lower part shows what X12 release 004010 itself requires: the envelopes around the 180 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.
When it is used
- Requesting authorization to return damaged or wrong goods
- Authorizing, denying or setting the disposition of a return
- Notifying a supplier that goods are being returned
- Reporting consumer returns to the brand or manufacturer
Where it fits in the document flow
Structure
Key segments in the 180
The segments most implementations use, described in plain language. The last column shows what X12 release 004010 itself requires: "Required" marks a segment the standard requires in every 180; "Optional, common" marks a segment the standard leaves optional, or that sits in an optional loop, but that implementations often use. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, makes some optional segments mandatory and restricts the values, and requirements can differ between releases. The requirement status comes from one published X12 reference listing and has not been checked against a second source.
| Segment | Name | What it carries | In X12 004010 |
|---|---|---|---|
| BGN | Beginning Segment | Purpose code, the return reference number and the date of the request or notice. | Required |
| RDR | Return Disposition Reason | Whether the return is authorized, pending or denied, and the reason for it. | Optional, common |
| PRF | Purchase Order Reference | The original purchase order the returned goods were bought on. | Optional, common |
| N1 loop | Name | Parties such as the buyer, the vendor and the location the goods are returned to. | Optional, common |
| BLI | Baseline Item Data | Each item returned, with its product identifier, quantity, unit and price. | Optional, common |
Example
Sample EDI 180
A request (purpose code 13) to return six units of one item bought on purchase order PO45001. RDR02 gives the reason as damaged product (DA). The supplier would reply with its own 180 authorizing (RA) or denying (RD) the return.
Illustrative data only, not tied to one X12 release or trading partner. The interchange (ISA/IEA) and functional group (GS/GE) envelopes are omitted for readability.
ST*180*0001~
BGN*13*RMA5521*20261022~
RDR**DA~
PRF*PO45001~
BLI*UP*012345678905*6*EA~
SE*6*0001~The sample is the same one shown above, with a note beside each segment the first time it appears. Segment IDs are highlighted at the start of each line; the fields after them are separated by asterisks, and each segment ends with a tilde.
Avoid problems
Common 180 errors and how to prevent them
Returns without the original order
Without the purchase order or invoice reference, the supplier cannot price the credit or confirm what was shipped. Carry the original references on every 180.
Free-text reasons only
Reason codes drive credits, inventory decisions and vendor scorecards. Map returns to the coded reasons the partner accepts rather than relying on descriptions.
No link to the credit
An authorized return should lead to a credit memo or adjustment. Track each authorization until the credit is issued and matched.
How ECOM helps
Automate the 180 with ECOM
Industry
Retail
Retail and eCommerce EDI for suppliers and retailers, from purchase order to payment, with compliance built in.
Solution
Order-to-Cash Automation
Automate the flow from purchase order to payment across every customer channel.
Solution
EDI Integration
Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.
EDI 180 FAQs
Who sends the EDI 180?
Both sides can. A customer sends it to request a return or to give notice of one, and a supplier sends it to authorize or deny the return and to state how the goods should be handled.
Does a 180 create a credit?
No. It manages the return itself. The financial adjustment usually follows separately, for example as an 812 credit/debit adjustment or a credit memo.
What information does a supplier need to authorize a return?
The items and quantities, the original purchase order or invoice, the reason for the return and where the goods are, so it can decide the disposition and the credit.
More general questions about EDI are answered in the EDI FAQ.
Need help with the EDI 180?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.