Returns, refunds and credit notes in ecommerce and ERP

Implementation scopes describe the order-to-cash process in detail: quote, order, allocation, pick, ship, invoice, payment. Returns appear as a line item. Then trading begins and the reverse flow turns out to involve more decisions than the forward one, because every return is a small negotiation with several possible outcomes and a statutory dimension the forward flow does not have.

A customer returns an item. Is it resalable? Was it faulty, or unwanted? Who pays the return shipping? Is the refund the full amount, the amount net of original delivery, or a store credit? Does the customer keep it and receive a refund anyway because the return freight exceeds the item's value? Was the original sale on a marketplace, so the refund is processed by the marketplace on its schedule rather than yours? Does the refund require a rectifying invoice, and does the tax authority need to see it?

Each of those is a branch, and each branch has an inventory consequence, an accounting consequence and a customer-facing consequence. A process that handles the common case and leaves the rest to judgement produces inconsistent customer treatment, an inventory figure nobody trusts, and a VAT position that is difficult to defend.

Why this matters

Return rates in consumer ecommerce are high enough that the reverse flow is not an edge case — for some categories it approaches a parallel business, and the handling cost per return frequently exceeds the margin on the original sale. A process that requires manual intervention on every return is a cost that scales linearly with growth.

The inventory consequence is where the quiet damage happens. Returned goods that sit unprocessed are neither available to sell nor written off. They are absent from availability, which suppresses revenue, and present in valuation, which overstates the balance sheet. Companies frequently carry a material quantity of returned stock in this limbo, and it is invisible precisely because it is nobody's metric.

The compliance dimension is real in Iberia specifically. Refunding a customer generally requires a credit note or rectifying invoice with proper sequencing and reference to the original document, and both Spanish and Portuguese regimes expect that trail in a defined form. Companies that refund through the payment provider without generating the corresponding accounting document create a VAT exposure that accumulates silently and surfaces at inspection.

At a glance: the decisions a return process must make

The row that produces the most operational pain is inventory timing. Crediting stock too early makes it available before it has been inspected, and some of it is not resalable. Crediting too late suppresses availability on goods you could sell. The answer is usually a two-step: receipt into a quarantine location, then disposition after inspection.

What works, and what to be honest about

What works:

Policy decided once, encoded, and applied automatically. Return window, freight responsibility, refund basis and restocking treatment are commercial decisions that should be made deliberately and then applied without case-by-case judgement. Most inconsistency in customer treatment comes from these never having been decided.

A quarantine location between receipt and disposition. Returned goods are received into a non-available location, inspected, and then dispositioned to resalable stock, refurbishment, or scrap. This single structural change resolves most of the availability and valuation distortion.

The accounting document generated automatically with the refund. Refund and credit note should be one action, not two, and the document should carry proper sequencing and reference to the original invoice. Separating them is how VAT exposures accumulate.

Agent-based triage on inbound returns. Matching an arriving parcel to an original order, identifying unauthorised returns, checking the return window, detecting duplicate refund requests, and flagging patterns that suggest return abuse — all high-volume, rule-bound work. The agent handles the routine and routes the genuinely ambiguous with the order history attached.

Reason codes captured and actually reviewed. Return reasons are the cheapest product quality and description accuracy data available, and they are usually collected and never analysed. A monthly review of reasons by product frequently identifies a listing error or a sizing description generating an outsized share of returns.

What to be honest about:

Marketplace returns follow the marketplace's rules, not yours. Refund timing, authorisation and customer communication may all sit outside your control, and the marketplace may refund before you receive the goods. Your process must accommodate that rather than assume it can be harmonised.

Some returns should never come back. Where return freight and handling exceed the item's recoverable value, refunding without requiring return is the rational answer. Companies resist this as it feels like accepting a loss, but the alternative is a larger one.

Keeping returned stock at full value is often wrong. Resalable-after-return is not always genuinely equivalent to new. If your accounting treats it as such, your inventory is overstated by whatever the difference is, and that gap grows with return volume.

Return abuse is real and needs a defined response. A small proportion of customers return at rates that make them unprofitable. Detecting the pattern is straightforward; deciding what to do about it is a commercial decision that needs making in advance rather than in the moment.

This is genuinely harder to design than the forward flow. More branches, more owners, a statutory dimension and a physical inspection step. Scoping it as a fraction of the forward flow's effort is the mistake that produces the discovery in week one of trading.

Decision framework: designing the reverse flow

Run in order. Stop at the first match.

1. Is your return policy written down, unambiguous, and encoded in the system?
If not, start here. Window, freight, refund basis, restocking treatment, unauthorised returns. This is a commercial decision set, not a technical one, and everything downstream depends on it.

2. Do returned goods pass through a non-available quarantine location before disposition?
If not, implement it. This resolves most availability and valuation distortion and is usually a configuration change rather than a project.

3. Is a properly sequenced credit note or rectifying invoice generated automatically with every refund?
If not, fix this before anything else operational. It is a compliance exposure and it compounds with volume. Confirm the required form with a local adviser for both Spain and Portugal if you trade in both.

4. Can an inbound return be matched to its original order automatically?
If not, this is the highest-return automation available in the reverse flow, and unmatched inbound parcels are a persistent warehouse cost.

5. Are disposition outcomes recorded and reflected in valuation?
If resalable-after-return is valued identically to new, review the treatment. If disposition is not recorded at all, that is the more urgent gap.

6. Are return reasons captured and reviewed monthly by product?
If not, start. It is the cheapest available source of product and listing quality information, and it reduces returns at source rather than processing them faster.

7. All of the above in place and returns still costly per unit?
The remaining cost is likely physical — inspection and refurbishment labour — or a product mix with structurally high returns. That is an operations and assortment conversation rather than a systems one.

Indicative cost and effort

Assumes one ERP instance, one fulfilment location and up to three sales channels. Third-party logistics or refurbishment operations extend this. Get a quote for a scoped estimate.

Frequently asked questions

When should inventory be credited — on customer dispatch, on receipt, or on inspection?
On receipt into quarantine, then on disposition into available stock. Crediting on customer dispatch makes availability wrong for goods that may never arrive or arrive damaged; waiting until inspection suppresses availability unnecessarily on the resalable majority.

Do we need a credit note for every refund?
For a refund against an issued invoice, generally yes — and in Spain and Portugal the form, sequencing and reference to the original document matter. This is one of the few areas in this series where the answer is genuinely jurisdiction-specific and worth confirming with an adviser rather than inferring.

How do we handle a customer who refuses to return but wants a refund?
As a defined policy branch — refund without return, above or below a value threshold, with the goods written off and the decision logged. Handling it case by case produces inconsistency and, eventually, customers who have learned the pattern.

Should we charge restocking fees?
A commercial decision with consumer protection constraints depending on jurisdiction and customer type. Whatever you decide, encode it and apply it consistently — inconsistently applied fees generate more complaint handling cost than they recover.

Where do agents help most here?
Matching inbound returns to orders, validating against policy, detecting duplicate refund requests and flagging abuse patterns. They are least useful at disposition, which requires physical inspection, and at the policy decisions, which should be settled in advance rather than decided per case.

Closing — Next steps

The reverse flow is where ecommerce operations either scale or quietly consume their own margin. It is under-designed because it is invisible at implementation time — there are no returns before go-live, so there is nothing to test against, and the scope reflects that.

A practical starting point: take last month's returns and check three things. How many required manual intervention, how many produced a properly sequenced credit note, and how much returned stock is currently sitting in neither available nor written-off. The third number is usually the one that changes the conversation.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication. Credit note and rectifying invoice requirements are jurisdiction-specific — confirm with a local adviser.

• Oracle NetSuite, return authorisation and credit memo documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• Agencia Tributaria (Spain), rectifying invoices and VAT adjustment — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), credit notes, ATCUD and document sequencing — https://info.portaldasfinancas.gov.pt
• European Commission, Consumer Rights Directive — right of withdrawal and refund obligations — https://commission.europa.eu
• IFRS Foundation, IFRS 15 — refund liabilities and right of return — https://www.ifrs.org
• Atypical Tech engagement experience, mid-market ecommerce operations across Iberia