Return reconciliation: connect the request, parcel, item and money

A customer requests a return of two items. One parcel arrives, containing only one item, while the marketplace deducts the value of both from the seller's settlement. The warehouse marks the parcel received. Finance marks the deduction matched. The missing item disappears between those two green statuses.

A return needs four linked records: the authorised request, parcel movement, item-level receipt and disposition, and financial effect. Reconciliation asks what each record proves and what remains missing. A parcel scan proves neither its contents nor a completed refund.

Join the records at the lowest useful level

Use return or RMA ID, original order line, SKU and quantity. Link parcel IDs to the expected lines, but allow one parcel to contain several lines and one return to arrive in several parcels. Preserve marketplace identifiers and original pack mappings so a returned multipack is not interpreted using a later catalogue version.

Shopify's return-creation workflow separates creating the return from later processing. Its processing workflow supports partial processing and financial actions. The proposed reconciliation view should retain these distinctions across whichever systems the retailer uses.

Work the missing-item case

Assume return R52 covers a ₹1,200 shirt and an ₹800 mug, with no tax, shipping or discount complication in the example. The return request value is ₹1,200 + ₹800 = ₹2,000.

Parcel P8 arrives. Receiving identifies the shirt, which passes inspection and becomes eligible for the approved stock disposition. The mug is absent. A marketplace settlement line deducts ₹2,000 against R52.

The case has two separate exceptions:

• Physical: one expected mug remains unreceived. The parcel record must not create a fictitious receipt.
• Financial: the marketplace debit exceeds the value of the physically accepted shirt by ₹2,000 − ₹1,200 = ₹800.

The ₹800 is an investigation amount under this example, not automatically an amount the marketplace owes. The marketplace's policy, customer remedy, evidence and allocation rules may justify a different settlement outcome. Finance needs the contractual basis before raising or closing a dispute.

Do not issue another ₹2,000 refund simply because the local system lacks a refund ID. First establish whether the marketplace already refunded the customer and whether the deduction represents that action. Otherwise the retailer can duplicate the customer remedy while trying to reconcile the seller account.

1. Authorise R52Shirt ₹1,200 and mug ₹800 are expected.
2. Receive parcel P8Only the shirt is identified and inspected.
3. Match the moneyMarketplace deduction is ₹2,000; ₹800 needs explanation.
4. Resolve each gapTrace the mug and review the debit under the applicable terms.

Exception: A parcel scan or settlement match cannot manufacture the missing item receipt or authorise a second refund.

Preserve the inspection decision

A recognised item can still be damaged, incomplete or unsuitable for resale. Record received quantity, accepted identity, condition, disposition, evidence reference and reviewer. Keep sellable, repair, supplier-return and disposal outcomes distinct where the business uses them.

If an unrecognised item arrives, quarantine the item identity and preserve proportionate evidence. Do not map it to the expected SKU merely to close the return. Restrict access to customer and parcel evidence, and retain only what the approved operational policy requires.

A later mug receipt should update the existing return line. If it passes inspection, the physical gap can close. If the marketplace later reverses ₹800, preserve that correction as a new financial event linked to the original debit. Do not overwrite the original settlement line and lose the sequence.

Choose a reconciliation workflow that shows missing joins

Joined exports can be enough for a bounded pilot. Freeze each extract's period, retain stable IDs and show unmatched rows on both sides. An inner join that displays only matched returns creates a reassuring but incomplete report.

Event integrations help when volume or response time makes manual reconciliation impractical. They still need periodic completeness checks because missing events never enter the queue. Compare authorised quantities, received quantities, financial effects and unresolved cases by cutoff, allowing for legitimate timing differences.

Assign a returns lead to physical exceptions and finance to monetary exceptions, with one case owner coordinating customer communication. A carrier claim, marketplace dispute and customer refund can have different deadlines and states. Store the actual contractual due dates rather than inventing one universal closure SLA.

Test the mismatches deliberately

Use a complete return, split parcels, a missing item, an unknown item, a duplicate scan, a partial refund and a marketplace correction arriving in a later period. For each, show the expected open records before and after resolution.

The pilot passes when a reviewer can identify the missing evidence without reading free-text notes across four tools. No received parcel should automatically close an unreceived item; no marketplace debit should automatically trigger another provider refund. The refund reconciliation guide covers that financial completion boundary.

Close the case at the right granularity

The return is explainable when physical quantities and financial effects reconcile independently and the remaining exceptions have owners. A single status can summarise the case only after those underlying facts are preserved.

1. Link authorisations, parcels, items and money using stable line identities.
2. Reproduce the one-item, two-item-debit example in the current records.
3. Assign physical and financial exception owners with evidence requirements.
4. Test split and late events before automating closure.