How to process a return at the counter without wrecking your inventory count

A plumbing and hardware distributor running two walk-in counters and one shared warehouse did a brisk trade in returns — not because anything was wrong with the stock, but because contractors buy fast and correct later. Wrong thread size, ordered one too many, the job got cancelled, the fitting was the wrong finish. None of it was fraud or carelessness. It was just the normal shape of a counter that serves people building things on a schedule.

The problem wasn't the returns themselves. It was what happened to them once they hit the till.

A return that isn't linked to anything

At both counters, a return was handled the same way a sale was voided: the cashier rang up a negative-quantity line for the item, handed back cash or knocked it off the next invoice, and moved on. Fast for the customer standing there. But that negative line had no relationship to the invoice the item was originally sold on. It didn't know which store the item came back to, whether it was resellable or should be written off, or which customer account it should adjust.

Multiply that by a few dozen returns a week across two counters and the damage compounds in three places at once. Inventory would show a part back in stock that was actually sitting in a "check condition" box behind the counter, because nobody restocked it — they just adjusted the count. A customer running an open account would see a credit applied to whichever invoice happened to be open that day, not the one the part was actually bought on, so the aging report told a story that didn't match reality. And at month end, the accountant had a pile of negative-quantity lines with no credit note behind any of them — no document to hand a customer, no paper trail if a return was disputed, nothing to reconcile against the bank deposit.

Why the workaround always got worse

The owner's first fix was more process: a logbook next to the register where cashiers were supposed to write down the reason for every return. It lasted about two weeks. A logbook doesn't stop a rushed cashier from ringing a return against the wrong SKU, and it doesn't connect to the stock count or the customer ledger — it just adds a second place where the truth might or might not be recorded. The real issue was structural: the till treated a return as a new, disconnected transaction instead of the reversal of a specific, identifiable sale.

That distinction matters more the bigger the counter gets. A single-register hardware shop can absorb some sloppiness because one person usually remembers what happened. Two counters and a shared warehouse can't — nobody at counter B knows what counter A already gave the customer credit for, and the warehouse doesn't know which of the two locations a returned part should physically land in.

The fix: a return traced back to its sale, every time

The change wasn't a new policy — it was making the return start from the original invoice instead of from a blank line. When a customer comes back with a part, the cashier pulls up the original sale, not a fresh transaction, and selects the specific line being returned. From there, three things happen together instead of separately:

• A credit note is generated automatically, referencing the original invoice number, with a printable copy for the customer and a record for the books.
• The stock decision is made at the point of return, not guessed at later — resellable stock goes back into that store's saleable count immediately; damaged or expired stock is flagged for write-off instead, so the count never shows something as available that's actually sitting in a box marked "check condition."
• The customer's ledger is adjusted against the correct invoice, not whichever one happens to be open, so the receivables aging report reflects what was actually owed and returned.

Because the return is tied to the original sale, it's also tied to the original store and the original SKU's cost basis — so a part returned at counter B against a sale made at counter A still lands in the right inventory pool and doesn't quietly inflate one location's count while starving the other's.

The effect showed up fastest in the aging report. Credit notes that used to land against whatever invoice was open now closed out the actual invoice they belonged to, and disputes about "did we already credit that" dropped because there was a document to point to instead of a memory. Inventory counts stopped drifting between what the register said and what was physically on the shelf, because restocking was a decision made at the counter, not an assumption baked into a negative line.

How to process counter returns without the mess

• Start every return from the original sale, not a blank transaction — pull up the invoice and select the line being returned.
• Generate a credit note automatically, referencing the original invoice, so there's a document for the customer and a record for reconciliation.
• Decide resellable vs. write-off at the moment of return, not later — the stock count should only ever reflect what's actually sellable.
• Post the credit against the correct invoice, not the nearest open one, so receivables aging stays accurate.
• Route the returned stock to the store it should physically live in, especially when a return happens at a different counter than the original sale.

iotoms ties every return at the counter back to the original invoice line: the credit note, the restock-or-write-off decision, and the customer ledger update all happen in the same transaction, at the same register, so the stock count and the receivables report agree with what actually happened at the counter.