The refund went out. The unit never came back.

What it is

Cash went back to the customer and nothing came back to you. No receiving scan, no graded unit, no put-away. Sometimes that is a decision you made: a returnless refund on a low-value item, a replacement for a parcel the carrier lost, a goodwill credit. Often it is nobody's decision at all. The refund fired when the label was created, the customer never posted the parcel, and no process ever asked where the unit went.

It is the sibling of the refund-not-restocked problem and it hides in the same place. Refund totals reconcile with the processor. Inventory counts reconcile with the warehouse, because the unit was never expected back in the count. The only record that shows the gap is the join between refunds and receipts, and that join does not exist in any single system you run.

How it happens

The trigger point is the main cause. Returns portals let you choose when the refund fires: on approval of the request, on the carrier's first scan of the label, or on receipt at the warehouse. Refund on approval or on first scan is faster for the customer and is the default in several portals. Every refund issued at those points is issued on trust, and a share of them, typically small but never zero, is never followed by a parcel.

Support overrides come next. An agent refunds from the processor dashboard or the store admin to close a ticket, without opening an RMA. There is no label, no expected return, and no reason for the warehouse to look for anything. The refund is correct from the agent's side; the unit is simply not part of the story.

Then the parcel that did travel and did not arrive: lost in transit, delivered to the wrong dock, received but booked against the wrong order or against an exchange, or received as an empty box. The first two are carrier claims with a deadline; the third is a join failure you can fix; the last is fraud. They look identical in the refunds file and different in the receiving log.

Finally the deliberate cases: a returnless-refund rule for items under a value threshold or in categories that cannot be resold, marketplace policies that refund without a return on the seller's behalf, and replacements shipped for damaged goods where the original was told to be discarded. These are not leaks, but if nothing marks them as decisions, they cannot be separated from the leaks, and the working list is unreadable.

Why it matters

Two figures, and they answer different questions. On the ledger, the refund is a verified cash movement: refund.amount left, and it is visible at the processor. The unit is priced at what it cost you, cogs × qty, because it will never be sold. Ledger exposure = refund.amount + cogs × qty until the unit is received or the refund is recorded as a keep-it decision.

On the profit and loss, the comparison is with never having made the sale. The price came in and went back out, so the cash nets to zero; what is gone is the unit, the outbound shipping you paid, and the processor fee on the original charge, which most processors keep on a refund. Net loss per refund ≈ cogs × qty + outbound_shipping + unreturned_fees. For a returnless refund you chose, subtract the return shipping and handling you avoided; that is the calculation that justifies the policy, and it should be made per SKU, not once for the catalog.

The pattern compounds through the trigger setting. A portal that refunds on first scan converts every unposted parcel into a loss at the full ledger figure, and the customers who learn that the label alone releases the money are the ones who return most often.

How to diagnose

1. List the refunds in the period with refund id, order id, amount, issued_at, the refund reason code if the platform records one, and who issued it (portal, agent, marketplace). Add the SKU lines and quantity from the matching order.

2. Join the returns side on order id: whether an RMA exists, when the label was created, the carrier's first scan, the received scan. The refunds with no RMA at all are the support overrides; the refunds with an RMA but no first scan are unposted labels; the refunds with a first scan and no receipt are the carrier cases; the refunds with a receipt that failed to join are exchanges or mis-booked returns, and they move to the other list.

3. Compare timestamps. received_at minus issued_at tells you the trigger point in practice, whatever the portal setting says: a negative gap means the refund preceded the receipt. Group by that sign and by the size of the gap. A cluster of refunds issued within minutes of label creation is a setting, not a series of accidents.

4. Age the open ones. Days since issued_at against your return window plus normal transit. Anything past window plus 14 days without a receipt is closed: the unit is not coming, and the row should be recorded as a loss or as a keep-it decision, never left open.

5. Separate the decisions. Apply your returnless rules (value threshold, category, damaged-discard, marketplace-refunded) as explicit flags on the list, so that every remaining row is a case with no reason. The rows that remain are the working list.

6. Look for concentration. Group the working list by customer reference, by issuing agent, and by SKU. Several refunds without return to one customer reference is a fraud check; many from one agent is a process check; many on one SKU is usually a product or listing problem that a return would not have fixed anyway.

7. Check the join key before you trust any of it. An RMA export keyed on the order number of an exchange order, not the original, produces phantom refunds-without-return on the original and phantom receipts on the exchange. Fix the mapping first, then run the list again.

What AXIOTRA does with it today

There is no detector for this class. The refund detector raises only refunds with return_received true and restocked false; a refund with return_received false, which is what every row in this class looks like, is never raised, and no money is attached to it. That is deliberate: the ledger alone cannot tell a lost parcel from a returnless-refund policy, and a finding that cannot be judged from its evidence would be noise.

What the workspace does give you is the list. The Refunds screen shows every refund row with its order, amount, and whether a return was received and restocked, so once the returns join has been uploaded (see Preparing a returns file), the rows reading received = no are exactly step 2 above, without the spreadsheet. Refunds that arrive through a Stripe or Amazon connection start as received = no by construction; the flag becomes meaningful only after your returns data is joined in.

The rest of the diagnosis, the timestamps, the ageing and the decisions, is spreadsheet work on the same file today. If a detector for this class is added, it will be listed on the problem library and on this page, with its exact rule; until then, this page does not claim one.