Authorises the return before a credit gets written
The 180 is the document the partner's terms actually require. Raise the credit before it and the partner has grounds to call the credit a straight deduction.
AI Powered
EDI with expert operators
Loop Returns
EDI Integration
The partner gave you a go live date for the returns account, and three things have to be true by then: the RMA is authorised before any credit is raised, Loop's event notifications are feeding the ledger and not just the customer-facing status page, and someone is reading those payloads line by line, because a Loop return carries no quantity field of its own. Miss any one of the three and the first credit you post is a deduction waiting to be challenged.
Match the category before you argue the credit.
A partner chargeback lands against one of five categories: labelling, fill rate, short ship, PO accuracy or delivery window. None of them get defended with a Loop credit on its own, because a credit only stands up against an authorised RMA, an invoice line and the stock movement that closed it. Raise the credit before that authorisation exists in the ledger and the partner has grounds to reject the whole thing, not just argue the category.
- Labelling
- Fill rate
- Short ship
- PO accuracy
- Delivery window
Get these four things ready before the account trades.
Loop authenticates over REST with an API key, so the account needs that key issued and scoped before any return can move through it. Event notifications have to reach whichever system posts the credit, not just the one showing the customer their refund status. Get these four sorted and the first RMA has somewhere real to land.
- The API key issued for the Loop account, scoped to the returns the brand actually processes
- A fixed rule for where the event notification posts, finance ledger or order system, decided once and not both
- The RMA authorisation step mapped against the partner's own terms, before any credit note gets written
- A test return run end to end, five units counted as five lines, not one overwritten line
Follow a return through five documents.
A Loop return only closes clean when these five documents agree with each other, in this order.
Prices the credit against what the original invoice said
The 810 fixes the line price Loop has to match. A Loop return line arrives two ways, tax-exclusive on current orders, gross-shaped on older ones, and the 810 is what proves which shape applies.
Confirms the stock actually moved before it's booked back in
The ASN ties the physical units to the return, closing the gap between a refund issued and a unit that never reappears in stock.
Carries the original order terms the credit has to respect
The 850 is the reference point for quantity and price. Loop sends one line per unit with no quantity field, so the 850 is what confirms five lines really were five units.
Confirms the partner received what was sent
The 997 closes the loop on transmission, nothing more. It says the document arrived, not that the credit was ever authorised.
Skip the 180 and every document after it is defending a credit the partner never agreed to.
Read the event notification before the credit lands.
Loop pushes event notifications over REST, authenticated by API key, and that is the only reliable signal that a return has moved. Treat it as the trigger for the credit check, not the credit itself, because a Loop-to-NetSuite account has already shown penny rounding between Loop's amount and the sales order amount when nobody validated one against the other. Read the notification, match it to the 180 and the 810, and only then let the credit post.
- X12
- EDIFACT
- AS2
- SFTP
- Cloud storage
protocols
REST
authentication
API Key
webhooks
yes
event notifications
yes
Confirmed against your instance during onboarding.
Let two people carry the Loop account.
Two roles manage a Loop account day to day: one who reads the authorisation and invoice documents against each other, and one who owns the webhook feed itself. Split any further and the first miscounted return sits unexplained for a week.
Document match
Checks every 180 against its 810 before a credit posts, and flags return lines that don't carry the quantity the invoice expects.
Notification owner
Watches the REST event feed for returns that stall between authorisation and receipt, and for channel filtering that quietly drops updates a partner expected to see.
Ask these before the test cycle starts.
Where does a Loop return land before any credit gets written, and what does it get checked against?
A Loop return arrives through the REST feed as event notifications, authenticated by API key. Each one lands against the original order and the RMA Loop raised for it, and the match that matters is between the 180 and the 810, not just the system that shows the customer their refund status.
What happens to the credit matching when Loop's API interface changes?
Loop's REST interface and the webhook payload are the two things to watch, because the credit posting logic reads structure, not just data. The safer move is isolating that review to the notification layer rather than touching the ledger directly, which is the kind of boundary the integration layer through Patchworks is built to hold.
What do we need to hand over before Loop's first return gets authorised against our terms?
Before the first Loop return authorises cleanly, the brand needs the API key scoped, a confirmed rule for counting quantity since Loop sends one line per unit with no quantity field, and sign off on which system posts the credit once the RMA clears.
If the partner changes what their terms count as valid return authorisation, who updates the check on our side?
Whoever owns the match between the 180 and the partner's written terms is the person who updates it, because that authorisation step is specific to this partner and sits outside Loop's own notification structure.
Given the RMA has to clear before a credit posts, is the partner's return turnaround actually realistic?
The RMA has to clear before the 810 and the credit can follow it, so the real question is whether the authorisation step itself can run inside the partner's stated window, not whether Loop can send the notification fast enough.
Need help with this?
Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.