What serialization solves.
A serialized SKU is one where every individual unit has a unique identifier — IMEI for phones, VIN for vehicles, serial number for laptops or appliances, unique barcode for high-value items. The system tracks each unit through receipt, transfer, sale, and return as a distinct record, not as a quantity in a pool.
Why bother? Three reasons. Warranty claims need to confirm the customer's unit was sold by you and is in warranty. Theft and grey market goods need to be excluded — you cannot accept a return of an IMEI that was never in your inventory. Regulatory and customer expectation — telecom regulators in many jurisdictions (FCC in the US, Ofcom in the UK, ACMA in Australia) require unit-level records for mobile imports.
When to use it and when not to.
Use serialization for: mobile phones, laptops, tablets, vehicles (cars, motorbikes, generators), appliances above GBP 150, anything with a manufacturer warranty that the customer might claim against you, anything regulated. Do not use serialization for low-value, high-volume items like batteries, cables, accessories — the operational cost is not worth the benefit.
A practical cutoff: serialize anything above GBP 75-100 unit value, or anything with regulatory requirement, or anything where the warranty period times the unit value matters more than the cost of scanning and tracking individual units. Most electronics retailers serialize about 20-30% of their catalog; 70-80% stays as standard quantity-tracked inventory.
The serialization workflow.
On receipt: scan or enter every serial number. Goods receipt cannot post until serial count matches quantity received. Each serial becomes a record in inventory with status "available", linked to the source GRN, supplier, and cost. On transfer: scan each serial moving. The destination receives those specific serials, not a quantity. On sale: scan the serial sold. The sale invoice records the specific IMEI/VIN/serial, the cost moves at the actual cost of that specific unit, and the serial flips to status "sold".
Returns are where serialization shines. The customer brings back a phone. The cashier scans the IMEI. If the IMEI was sold by you, the original sale is found instantly and the return processes against the original cost. If the IMEI was not sold by you, the return is rejected. This is impossible without serial tracking — quantity-only systems accept any returned phone as if it were yours.
- Receipt: serial count must equal quantity, no exceptions
- Transfer: each serial is moved individually, costs follow exactly
- Sale: serial is bound to the invoice, cost = actual cost of that unit
- Return: serial must match an original sale to be accepted
A worked example: phone retailer.
A London phone retailer receives 50 iPhones from a distributor. Invoice price GBP 800 each, total GBP 40,000. On receipt, the receiver scans 50 unique IMEIs. The system creates 50 inventory records, each at cost GBP 800, status "available". The retailer marks them up to GBP 920 each.
Customer A buys IMEI 357...891. The sale records the IMEI on the invoice, COGS posts at GBP 800, the IMEI flips to status "sold". A week later customer A brings the phone back saying it was DOA. The return scans the IMEI, finds the original invoice, processes the return at GBP 920 refund and GBP 800 inventory addback. The phone goes to a "returns" location for inspection — the same IMEI is still tracked, never lost.
Costing serialized vs unserialized.
For unserialized inventory, cost is WAC across the pool. For serialized inventory, cost is the actual cost of the specific unit — what was paid for that exact unit on its specific GRN. There is no pooling. If you bought Phone A for GBP 800 and Phone B for GBP 820 (same model, different shipment), and you sell Phone B, COGS is exactly GBP 820.
This is closer to specific-identification cost flow, which IAS 2 explicitly permits for items that are not interchangeable. For serialized goods, specific identification is the natural and required method — WAC across IMEIs would not even make conceptual sense.
Common pitfalls in serialization.
Pitfall 1: receiving short on serials. The supplier invoice says 50 phones, the box has 49, but the receiver posts the GRN as 50 because they did not scan each one. Now you have a phantom IMEI that does not exist. Fix: enforce scan-each-serial at receipt. No exceptions.
Pitfall 2: customer returns of grey-market goods. Without serial tracking, the customer brings back a phone bought elsewhere and your shop credits it. With serial tracking, the IMEI is rejected at scan. Pitfall 3: warranty register confusion. The warranty database needs to be linked to the sales database via IMEI; otherwise warranty claims become a manual PDF hunt. Nonari ties IMEI sale records to warranty automatically.
How nonari implements serial tracking.
Nonari supports per-SKU configuration: a SKU can be standard, batch-tracked, or serial-tracked. For serial-tracked SKUs, every transaction (receipt, transfer, sale, return, adjustment) requires the specific serial. The system stores the full lifecycle of every serial — from supplier GRN through final sale or write-off — in a permanent record.
Reports show serial-level inventory at any branch, the in-stock-days per serial, the original supplier and cost, and warranty status. For a phone shop owner, this means "where is IMEI 357...891 right now?" is a one-second query. For telecom regulator compliance audits, the same query produces evidence of legal import for every IMEI on shelf.