A controlled ecommerce returns reconciliation process.

An ecommerce returns reconciliation compares the expected return from the order and returns authorisation with carrier events, warehouse receipt, inspection outcome, refund, inventory movement and finance entry. Matched items can close. Unmatched items need a reason, owner, next action and ageing clock.

Refund timing and customer rights depend on the sale and circumstances. Check GOV.UK's returns and refunds guidance and the underlying rules where relevant. The multi-system reconciliation design below is Clerq's operational synthesis, not a prescribed legal architecture.

What records need to be reconciled?

The exact systems vary, but the process normally spans the order platform, returns portal or authorisation, carrier, warehouse, payment or refund provider, inventory ledger and finance system. Each source observes a different event and may update at a different time.

Create a simple source dictionary: the identifier, event, timestamp, amount, quantity, status and source owner. This exposes gaps before teams try to join the data.

• Order and line-item details
• Return request and authorisation
• Carrier label, scan and delivery events
• Warehouse receipt and inspection disposition
• Refund instruction and settlement result
• Inventory movement and finance posting

The end-to-end reconciliation sequence

Start with expected returns, enrich them with observed events and only then apply matching rules. A status should describe the evidence available, not the outcome the team hopes has happened.

• Create the expected-return population from approved requests.
• Attach carrier events using the return or parcel identifier.
• Attach warehouse receipt, quantity and disposition.
• Attach refund instruction, amount, method and outcome.
• Attach inventory and finance entries where relevant.
• Apply approved time, quantity and amount tolerances.
• Close complete matches and route exceptions by reason and owner.
• Review aged exceptions and retain resolution evidence.

Design the exception queue before the happy path

The commercial value sits in the mismatches. Define the main exception types, their severity, the team able to act and the escalation deadline. Keep ‘waiting for an external event’ separate from ‘no owner’.

• Carrier shows delivered but warehouse has no receipt.
• Warehouse quantity or condition differs from the return request.
• Refund was approved but failed or remains unsettled.
• Refund value differs from the approved policy or order value.
• Inventory was adjusted without a corresponding physical event.
• Finance contains a posting with no linked operational record.

Human review and customer treatment

People should review ambiguous identity matches, policy exceptions, suspected abuse, high-value cases and any action that may disadvantage a customer. The workflow should expose the supporting records and recommendation, not hide them behind a confidence score.

Customer communications need their own approval rules and should state what is known. Do not make a definitive claim about a parcel, refund or entitlement when the underlying evidence is incomplete.

Measures that reveal whether the process improved

Track the proportion matched without manual handling, exception volume by cause, age of open exceptions, time from receipt to refund, rework and unresolved financial difference. Segment results by source and reason so a system failure does not look like a staffing problem.

Define the population and time window in every measure. Returns created, parcels received and refunds settled are different populations.

Frequently asked questions