Aydınlatma metni yükleniyor…
B2B returns management is a reverse-logistics process that follows one identity from a dealer request through warehouse receipt, inspection, physical disposition and financial closure in ERP. An RMA (Return Material Authorisation) number can be the reference for that process, but it is not the process itself. A dependable system separates “authorised to ship” from “arrived”, “defect confirmed”, “available for stock” and “financial record completed”.
This guide helps distributor operations, warehouse, quality, after-sales, finance and technology teams define shared scope. The “Kumsal eight return receipts” and expected–received–decision reconciliation are original planning tools developed for this article. Return rights, warranties, defects, invoices and tax treatment depend on contract and applicable law; this is not legal or financial advice. Qualified reviewers should approve the organisation's policy.
A request, shipping authorisation, warehouse receipt and financial outcome are different records
A dealer reports a wrong, damaged, excess or allegedly defective item. Preliminary review can permit shipment or propose an outcome that does not require a physical return. A carrier event shows that a parcel is moving; warehouse receipt confirms that a particular parcel and quantity actually arrived. Inspection decides whether the item can be resold, repaired, scrapped, returned to vendor or sent back to the dealer. A financial record should follow the relevant evidence and organisational rules.
Compressing these events into one Returned flag can make goods in transit appear as available inventory, treat a short receipt as complete or create credit before inspection. Keep the owner, timestamp, inputs and permitted next action for each state.
What should the RMA number represent?
The RMA should be a persistent reference connecting the request to the dealer account, originating sale or order line, product, quantity, serial or lot, reason, receiving warehouse and validity period. Carry it through portal, shipping document, warehouse receipt, inspection and ERP. Knowing the identifier must not grant authority; each action still needs user and company-scope validation.
Microsoft's sales-returns documentation uses the RMA number as an alternate key through a return order and describes linking a return line to an invoiced sales line to retrieve product, quantity, price, discount and cost context. It also separates RMA arrival and receipt from an associated replacement order. The wider design principle is valuable: link original-sale evidence, physical movement and follow-up commerce without collapsing them into one record.
The Kumsal eight return receipts
Each transition should produce evidence so teams can see exactly where a return stopped:
- Request receipt: Dealer, account, product/sales line, quantity, reason, explanation and attachments.
- Eligibility decision: Policy revision, reviewing role, accept/reject or request for evidence.
- Shipping authorisation: RMA identity, destination warehouse, ship-by date and packing instructions.
- Carrier hand-off: Parcel identity, carrier reference, parcel count and hand-off time.
- Warehouse arrival: Actual parcels, product, serial/lot, quantity, packaging and visible condition.
- Inspection decision: Accepted/rejected quantity, finding, photograph and disposition.
- Physical and financial action: Inventory status, location, repair/replacement/scrap decision and related ERP document.
- Closure receipt: Dealer-facing outcome, open discrepancies, completion time and owner.
The chain exposes the operational work between Request approved and Return complete. Every receipt belongs to one return identity even when a different team or system produces it.
Separate the return reason from the item's disposition
A reason code records why the dealer wants to return an item: wrong product, transit damage, alleged defect, over-shipment or another contractual reason. Disposition records what happens after inspection: return to available inventory, quarantine, repair, refurbishment, replacement, scrap, return to vendor or return to dealer. Do not automatically treat the request reason as the inspection outcome.
Microsoft's return-disposition documentation separates reason and disposition codes and explains that a disposition action can determine physical, financial and replacement implications. An organisation may configure its own code list, but every code needs a clear inventory, finance and communication effect.
Preliminary review does not replace physical acceptance
Photographs, video, serial numbers and invoice details can reduce unnecessary shipping but may not conclusively establish physical condition. Store preliminary approval as Shipping authorised and warehouse/quality outcome as Receipt and disposition. Explain that distinction to the dealer.
A rejection needs a reason and a visible missing-evidence path. When more information is required, collect it within the same revision chain rather than forcing a new request. Once shipment is authorised, provide destination, validity period, permitted items and quantities, packing conditions and multi-parcel behaviour. An RMA label supports identification; it does not replace safety, hazardous-material, temperature or carrier rules.
Reconcile expected, received and decided quantities by line
| Field | Expected | Received | Inspection decision | Difference handling |
|---|---|---|---|---|
| Product and variant | Authorised item | Scanned/identified item | Match, mismatch or unknown | Quarantine and review task |
| Quantity | Authorised quantity | Physical count | Accepted/rejected quantity | Short/over receipt record |
| Serial/lot | Requested identifiers | Scanned identifiers | Confirmed or mismatched | Original sale and ownership check |
| Condition | Reported issue | Packaging and item observation | Finding and disposition | Photo, note and owner |
| Document | RMA and sales reference | Carrier/parcel reference | ERP transaction reference | Block closure while links are missing |
Partial receipt is normal: one of two units may arrive, parcel quantity may differ, or individual items may receive different outcomes. Track open quantity by line and, when necessary, by serial or lot instead of closing the whole return header at once.
Keep quarantine separate from available inventory
An item should not become saleable merely because it crossed the warehouse door. Initial registration proves physical arrival; quality and disposition determine availability. Distinguish return, inspection, repair, scrap and resale locations to reduce accidental reservation and fulfilment.
Microsoft's warehouse location-directive documentation gives the example of using a return disposition to route goods to inspection or quarantine. SAP returns-inspection documentation likewise describes recording warehouse inspection results for full or partial quantities. Products and warehouse technology differ, but the core distinction remains: physical arrival is not quality acceptance.
Design serial, lot and multi-parcel relationships up front
With serial-controlled products, every unit may have a different sale and decision history. Lot-controlled products add batch, quantity and quality context. Even without serials, one parcel can contain several RMA lines and one RMA can arrive in several parcels. The model should support many-to-many relationships between RMA, parcel, line and serial/lot.
Warehouse staff should be able to scan an RMA, parcel or product identity and safely create an exception when reality differs from expectation. A barcode or QR code does not ensure accuracy by itself: define the represented object, reprint authority and duplicate-scan behaviour.
Do not blindly bind disposition, inventory and finance to one rule
Accepted does not always mean available inventory or immediate credit. An item may enter quarantine, repair, scrap or vendor return. The financial result can depend on contract, original sale, accepted quantity, charges and policy. State which system owns product condition, inventory value and the financial document across portal, warehouse and ERP.
If the ERP call fails, preserve the warehouse decision and do not create a second physical receipt. Retry technical failure under the persistent return/line transaction identity; route data errors to human review. Use our ecommerce–ERP integration guide for broader ownership across inventory, orders, payments and returns.
Show meaningful milestones to the dealer
A generic Processing state can remain unchanged for weeks. Use business-appropriate milestones such as request received, awaiting evidence, shipping authorised, handed to carrier, arrived at warehouse, under inspection, decision made, awaiting financial action and closed. Replace raw technical errors with safe, actionable explanations.
Every state needs an owner and expected next action. If the dealer owes evidence, expose the required document; if the warehouse owes a count, identify the parcel; if finance owes an entry, provide the relevant decision package. A notification is not the state itself—the portal record should remain correct even when an email fails.
Acceptance tests must cover real discrepancies
| Scenario | Expected behaviour | Evidence |
|---|---|---|
| Two units authorised; only one arrives | Process the received line and keep the remainder open | Count and outstanding balance |
| A different serial number arrives | Do not release to stock; create a review exception | Expected/received serial difference |
| The same parcel is scanned twice | Do not create a second physical receipt | Parcel identity and prior event |
| One line is resale-ready and another is scrap | Split lines into different dispositions and locations | Line-level decision history |
| Connection drops before ERP responds | Retry safely with the same transaction identifier | One financial/ERP record |
| Return period or contract condition is ambiguous | Route to authorised review instead of automatic rejection | Policy revision and decision owner |
Do not measure success by closure time alone
Measure request-to-preliminary-decision, shipment-to-arrival, arrival-to-inspection and decision-to-financial-closure separately. Track first-time valid requests, missing evidence, expected/received quantity differences, serial mismatches, exception age, reopened requests, disposition distribution and ERP queue errors. Skipping inspection or authority controls to increase speed is not success.
What should an implementation proposal deliver?
- Decision table for reasons, eligibility and required evidence
- Data model for RMA, parcel, line, serial/lot and original sale
- Pre-review, shipping, receiving, inspection and closure states
- Expected–received–decision reconciliation and partial receipts
- Disposition, quarantine, inventory-location and resale controls
- ERP fields, transaction identity, retry and exception queue
- Dealer visibility, notifications, documents and photo permissions
- Boundary-condition acceptance tests and operating ownership
For wider self-service scope across membership, documents, requests and payments, use our customer portal scope guide.
Conclusion: a return is an evidence chain, not one approval
A B2B returns platform should reconcile the dealer's report with warehouse reality, the inspection outcome with inventory behaviour and financial closure with the correct ERP record. The RMA identity connects the chain; it does not replace its stages. To plan an organisation-specific journey from dealer request through warehouse and ERP closure, explore Kumsal Agency ecommerce services.