A system that still makes sense on the days that go wrong

Smooth transactions are easy to record. A paper ledger and a basic till both cope perfectly well with somebody who buys, pays the exact amount, and leaves. The test arrives on the imperfect day.

The brake pads turn out to be the wrong specification. A filter arrives with two digits of the part number transposed. A new battery fails on test in front of the customer. A screen from the supplier has a line through it the moment the box is opened. A job finished three days ago comes back. Somebody keys a figure wrong.

All of that is normal. What is not normal is settling those events with a note scribbled in a margin while your stock figures and your receivables drift away underneath. A mature system is not the one that looks tidy when everything goes right; it is the one that still makes sense when things go wrong.

A sloppy return breaks more than it appears to

Take a case any workshop will recognise. A customer comes back because the brakes are still noisy a week after new pads. Stripped down, the pads were indeed the wrong specification. You fit the correct ones at no charge, and the old set goes into a drawer.

With no recorded path, that single act of goodwill sets off four separate problems:

1. The replacement pads leave the shelf with no document, so physical stock and system stock begin to disagree.
2. The wrong-spec set, which the supplier would have taken back, sits in the drawer until the claim window closes and becomes a real loss.
3. The cost of an item with no remaining value stays on the books as an asset.
4. At month end the margin is thinner and not a single line explains why.

At a counter the objects change and the ending does not: a screen swapped again for an unresponsive digitiser, the old one into a drawer, and three months later a pile nobody can sort into claimable and not.

Automan cuts that off by giving each event its own treatment instead of one all-purpose button.

Two decisions, not one

Most software collapses a return into a single button. In a repair shop there are genuinely two questions, they routinely have different answers, and you answer them line by line on the same invoice.

What happens to the item? Three choices:

• Back on the shelf — still saleable, returned to stock at the cost it left with.
• Damaged but claimable — out of saleable stock, but not written off. It waits on the Damaged Stock list until the supplier claim is settled.
• Written off — the value is genuinely gone, and it is recorded as a loss you can see rather than a shortfall that surfaces at the next stock count.

What happens for the customer? Two choices, and they are not tied to the first:

• Money back — offset against the outstanding balance first if the invoice is not settled, with only the surplus leaving the drawer.
• A replacement item — recorded in its own right: which product, how many, at what price, and its serial number where the item carries one.

So wrong-specification pads can go straight back on the shelf while the customer leaves with the correct set fitted, and a screen that arrived lined can sit in the claim list while the customer takes a refund. The reason is stored on the same line, so three months later you still know why the item came back — and for serialised goods a return traces to the individual unit.

Four events, four ways of recording them

Retail software treats every return the same: goods come back to the till. Repair businesses need the distinction, because the consequences are not alike.

• Repair returns — for completed work that fails again inside the warranty period. Connected to the repair workflow, so you can see whether it needs redoing or refunding, with the earlier job history intact while you decide.
• Sales returns — for goods a customer brings back: an accessory that does not fit, oil in the wrong specification, a loose part that was never used.
• Purchase returns — for goods you send back to a supplier because they were the wrong type or an over-order. Your payable to that supplier is offset in the same movement, so you stop paying for stock you no longer hold.
• Damaged stock and supplier warranty claims — a working list of defective components found during a job, claimed against the distributor using the original delivery recorded in spare parts inventory.

Two separate choices on one line: what happens to the item (back on the shelf, claimable, or written off) and what happens for the customer (refund or replacement). (App UI shown in Indonesian.)

Supplier claims stand on records, not on recollection

This is where money leaks fastest without anyone noticing.

A battery that fails on test, a filter that weeps from new, a screen lined out of the box — all of these are covered by supplier warranty. What decides whether the claim is accepted is rarely the condition of the item. It is whether you can show which delivery it came in on, and when.

Because Automan keeps the batch origin of every item, that answer is on screen: date received, which purchase, what it cost. You are not persuading the supplier; you are showing them a record.

And because defective items enter Damaged Stock rather than disappearing into a drawer, you have a list you can work through before the claim window closes — instead of a discovery made during a clear-out.

Returns against an invoice that is not fully paid

This is the case that makes a cashier hesitate, and workshops meet it more often because staged payment is ordinary there.

A customer collects a vehicle with a bill of Rp 1,500,000 having paid Rp 600,000, promising the remaining Rp 900,000 next week. Two days later they return a part worth Rp 400,000 that was not used after all.

In a basic till, the cashier might well hand over Rp 400,000 in cash — to somebody who still owes Rp 900,000. Money leaves the drawer for an account that is still in arrears.

Automan applies a consistent rule: the return value offsets the outstanding balance first. The debt drops to Rp 500,000 and no cash moves. Only when a return exceeds what is owed does the surplus become a refund. The cashier is not doing arithmetic in front of a waiting customer, and is not being asked to make a policy decision at the counter.

What adjusts on its own

When a return, a claim, or a correction is processed, the consequences do not stop at one screen:

1. Stock and cost. Returned goods follow the condition you chose: back onto the shelf, or into damaged stock. The value reversed is the cost of the delivery the item actually came from, not a round number.
2. Cash and channel balances. A cash or transfer refund reduces the balance on the day it happened, not on the day somebody remembered to write it down.
3. Payables and receivables. A purchase return offsets what you owe the supplier; a sales return offsets what the customer owes you before any refund is considered.
4. The books. It carries through to repair shop accounting rather than stopping as a separate note at the till.

One thing said plainly: edge cases such as costing a replacement item that leaves the shelf still need a decision and a check. Automan connects the main flow; we do not paper over specific accounting judgements with a promise that everything is automatic. That promise reads well and costs a great deal later.

Corrections that leave a trail, not a delete button

Mistyped figures and wrongly selected items are human and inevitable. Settling them with an unrestricted delete button is not.

An open delete function is the widest gap in any business whose owner is not always on site: a genuine sale removed after the customer leaves, the cash pocketed, and nothing left behind to notice.

Automan uses a correction flow with history. Mistakes still get fixed, and the trail keeps:

• who made the change,
• when it was made,
• the value before and the value after.

Staff can correct a typo without waiting for you to arrive, and you keep the context of what was corrected. Both matter; a system that provides only one of them either gets abandoned or gets abused.

Who this matters most to

• Workshops — wrong-specification parts are a weekly event, not an annual one. Purchase returns that offset supplier payables, and a Damaged Stock list you can work through, stop claim money evaporating on a deadline.
• Electronics counters — supplier-warranted components with a real factory defect rate, where the recorded delivery an item came in on is the whole basis of a claim.
• Shops with several people on the till — one rule applies to everyone, so how a return is handled stops depending on who is on shift.
• Shops with several mechanics or technicians — you can see which jobs come back under claim, which is quality information no sales report will give you.

What changes from the owner’s chair

Defective goods stop being an automatic loss. What is claimable has a list and a deadline instead of a drawer.

Money does not leave twice. A return against an unpaid invoice offsets the debt first, by rule rather than by mood.

Corrections no longer destroy the evidence. You can see what was amended without having to suspect everyone.

A bad day stops corrupting the reports, because a bad day has a correct path through the system too.

Test it with an imperfect day

The honest way to judge software is not to run a clean transaction through it. Run a messy one: create a part-paid sale, return part of it, and watch what happens to the receivable, the stock, and the report.

Lite is free permanently and takes no card, which is enough to run exactly that scenario on your own numbers. Pricing is in Rupiah — Lite at Rp 0, Pro at Rp 15,000 per month — and support runs in Bahasa Indonesia, which is worth knowing before you commit.

See the returns workflow demo, or read the wider picture for auto repair shops and phone repair shops.