A customer return request is not proof that goods have been received and is not, by itself, a basis for financial closure. Operational processing of webshop returns should connect four separate steps: recording the request, physical receipt, returned-goods inspection and the refund decision. The financial transaction should follow only after receipt is recorded and an authorised role has made a decision under defined business rules.
This separation reduces the risk of closing a return before the warehouse confirms what actually arrived, in what condition and in what quantity. It also gives finance a clear operational signal instead of requiring staff to infer outcomes from a customer message, a shipment notice or a carrier status.
A webshop may receive a customer request before the parcel is sent, while it is in transit or after goods arrive at the warehouse. Each point represents different business information.
When a system skips the distinction between these steps, one status can conceal several different states. For example, a label such as "return in progress" does not state whether the customer has only opened a request, whether the parcel arrived or whether the goods were inspected. That status makes it harder for the warehouse to plan work, for finance to control liabilities and for customer service to communicate precisely.
The process does not need to be complex, but every transition should have an owner, an input and a visible record.
Customer service, the webshop or an integration opens a return record and links it to the original order. The owner of the input is the channel that received the request, while a business role remains accountable for checking core data.
Minimum inputs may include:
At this stage, the record has request status. It should not be treated as confirmed receipt or as an instruction for finance to issue funds.
When the process uses a return label, carrier or another return-delivery method, the record can include an expected parcel. The owner of this data update may be the webshop integration, customer service or logistics, depending on the organisation.
The notice supports operational planning. It does not replace scanning, counting or identifying the goods upon receipt.
The warehouse records the receipt date and time, location, parcel identifier when available, and the person or operational role that received the goods. If the parcel cannot be linked to an existing request, the warehouse should open an exception rather than close the return based on an assumption.
Physical receipt answers a limited but important question: did the parcel or goods arrive under the organisation's control? It does not yet answer whether the goods meet the internal criteria for further handling.
Returned-goods inspection compares what was actually received with the expected record. The owner of this activity is commonly the warehouse, quality team or another designated operational role.
The inspection can include:
The inspection result should remain separate from the financial decision. The operational team establishes facts about receipt and condition. An authorised business role applies business rules to those facts.
The decision may approve a refund, partial refund, replacement, further review or rejection under internal rules. The decision owner must be a named role, such as finance, customer service, a process manager or a combination of roles through an approval flow.
Decision rules should be documented separately. They should not be presented as legal requirements without a fresh review of an official source. The organisation should check which conditions, timelines and communications apply to its markets, products and sales channels.
Finance carries out the official ERP transaction after a visible record of receipt, the inspection result and the decision are available. The owner of the financial posting is the finance function or an authorised ERP role.
The system should retain links between the original document, return request, receipt record, inspection result, decision and financial transaction. This connection supports review of an individual case without manually collecting information from email, the webshop and warehouse notes.
The following is a hypothetical scenario, not a description of an ORKA customer or delivery.
A customer opens a return request for two units of an item. The webshop record links to the order, but the warehouse finds one unit on receipt. The warehouse operator records the actual quantity, adds an inspection status and opens an exception for the quantity mismatch. Finance does not close the return based on the original request for two units. An authorised person reviews the record, applies internal rules and records a decision. Finance then carries out the appropriate ERP transaction.
The value of this pattern is not the number of statuses. It is clear accountability. Nobody needs to guess whether the second unit was received, lost in the process or subject to further review.
Database constraints can protect basic record quality. For example, they can check identifier uniqueness, required fields and relationships between records. PostgreSQL documentation describes constraints such as uniqueness, required values and foreign keys in its Constraints section.
These constraints help prevent obvious errors, such as a return record without a linked order when the process requires that relationship. However, they do not determine a business decision by themselves. A database cannot independently determine whether product condition is acceptable, who may approve an exception or which financial outcome should follow an inspection.
Business rules need separate definition with the process owner. One rule may require an inspection for a specific item type, another may require approval for a quantity variance, and another may define handling for goods that cannot return to sale. Only after rules are defined should the organisation decide whether to implement them through work instructions, ERP configuration, an integration, reporting or a combination of these elements.
A well-designed process does not assume a complete match in every case. It should cover at least these exceptions:
For every exception, assign an owner, an internal handling timeline under your own rules, permitted decisions and a recording method. An unclear exception often creates more manual work than the routine return itself.
Before changing a workflow, configuration or integration, check the following.
The process is ready for operation when every processed return has a unique reference, a link to the original order or a recorded exception, a physical-receipt record, an inspection result or open exception, a named decision owner, and a link to the financial transaction after the decision has been completed. A verifiable measure is the share of reviewed records in a selected period that contain all required traces or a documented exception. The organisation can also track the number of cases where a financial transaction was opened before receipt confirmation.
When the current process mixes statuses or responsibilities, the useful first activity is not automatically a new integration. First map the actual workflow, owners and exceptions through Business process screening . In the ORKA approach, Orkasta owns day-to-day collaboration and official ERP transactions, while Trueforce provides specialised engineering capability when the process requires technical delivery. The next step is to select one return flow, review its records from request through posting, and remove transitions without a clear owner.