September 20, 2026 · 5 min · Customer returns and invoicing

Lire en français

Odoo customer returns: connect inventory, credit notes and refunds

A parcel arrives back at the warehouse, a salesperson promises a refund, and accounting waits for supporting evidence. Without a shared record, each team may consider the return complete while another step is still outstanding. For businesses using Odoo in Belgium or France, the challenge is to connect commercial, physical and financial decisions. This guide draws on Odoo 19 documentation and proposes acceptance tests for an Odoo Enterprise project.

Separate receipt evidence from refund evidence

Odoo documentation describes goods returns through a reverse transfer from a delivery. Validation updates the sales order’s delivered quantity. A credit note can be prepared from the invoice; a cash refund also requires a recorded payment. Track these operations separately.

Our recommendation is to assign an owner to each decision. Customer service accepts the request under your commercial terms, the warehouse records the quantity and condition received, and accounting checks the amount to credit. A photo or customer message supports the case; it does not prove that every step is complete.

Build a return record people can use

Before configuring a workflow, agree on a shared reference and the required information: original order, delivery, product, requested quantity, received quantity, reason, relevant invoice and commercial decision. For tracked products, include the lot or serial number so the team can check that the received item matches what was shipped.

For a Belgium–France deployment, also check the selling company, receiving warehouse and language of customer documents. A customer shared across several companies does not identify the correct case on its own. Agree accounting checks with the finance lead of each entity.

Test a partial return from start to finish

Underside’s proposed test scenario: an order contains ten delivered and invoiced units, and the customer returns two. Ask the team to find the original delivery, record the two received units and explain the expected credit amount. If a refund has been agreed, match its evidence to the case before closing it.

Add a return before invoicing and a goodwill credit with no physical movement. Define the expected results according to your invoicing policy. Do not automatically copy a standard sales procedure into point of sale or marketplace operations: those workflows need their own acceptance tests.

Decide when goods become available again

Receiving a product does not necessarily mean it can be sold again. Define an explicit decision: restock, inspect, repair or another authorised treatment. Test locations and availability rules in your test database to prevent damaged goods from being reserved for a new order.

This complements work on lots and expiry dates and quality management in Odoo. During migration, include open returns too: an accurate opening stock balance does not capture existing commitments to customers.

Underside analysis: close cases with evidence

We recommend a pilot covering one warehouse and one product family. Track the time between receipt and decision, cases missing financial evidence, and returns requiring manual corrections. These measures help reveal unclear ownership before another automation is introduced.

First validate the standard process with sales, warehouse and accounting teams. For an eCommerce integration, then document which system triggers each operation and how previously processed events are recognised. Custom development should address a specific, reproducible gap rather than compensate for a missing shared procedure.

Official sources

Odoo 19 references: handling returns and repairs and credit notes and refunds. The acceptance scenarios and governance recommendations above are Underside’s analysis.

Bring a partial-return example and an unresolved case to scope your Odoo returns workflow with Underside.

Back to blog