Retail barcode and label software is the layer that makes the rest of a store's systems work at speed: a code on every variant so it can be scanned at the counter, at receiving, at a count and at a pick; a price label that matches the item record; a shelf label that matches the price label; and a way to handle the items that arrive with no code at all. With Pentoggle, a retailer can describe how their items are identified and labelled and generate the starting application around it.
This page is about identification and labelling. What the codes are used for is covered elsewhere: Retail POS Software at the counter, Retail Goods Receiving Software at the door, Retail Inventory Audit Software at counts, and Retail Warehouse Management Software for locations. Where prices come from is Retail Pricing Management Software.
Most retailers already run an accounting system such as QuickBooks, Tally or Xero, and a POS with a scanner. Those stay where they are. What is often still managed outside them is the labelling itself: which items have codes, what the labels say, whether the shelf edge matches the till, and what happens to the carton of unlabelled goods that arrived this morning.
Key takeaways
- The code belongs to the variant, not the style. A single code across five sizes means every scan records something that is not what left the shelf.
- Items arriving without a usable barcode are a normal part of retail, and they need a defined route: assign an internal code, print, apply, then shelve.
- The price label, the shelf label and the till have to come from one record. When they are maintained separately, they disagree, and the customer notices at the counter.
- Labels are a physical workflow. The print has to happen where the stock is, on a device the person handling the stock already has.
- A useful number is the share of items received that needed an internal code, and the share of scans that fail at the counter.
The spreadsheet is often not the problem
A store where most items arrive with a manufacturer barcode, prices are on a printed list and the shelf edges are written by hand is a working system, and plenty of shops run this way.
The trouble starts at identifiable points.
When the code covers several variants
The style has one code. It is sold in four colours at the same price, so the till does not care. The stock record cannot say which colour sold, and the reorder is a guess.
When items arrive bare
A supplier ships goods with no barcode, or with one that does not scan, or with a code the store already uses for something else. The carton sits in the back until someone has time, or the items reach the shelf and are typed in at the counter.
When the shelf edge and the till disagree
A price changed in the system on Monday. The shelf label still shows the old price on Thursday. The customer is charged the new price and is right to object.
When labelling happens at a desk
The person with the label printer is in the office. The stock is in the back store. Labelling becomes a batch job that happens later, and "later" is when the item is needed on the shelf.
What retail barcode and label software holds
Codes per variant
A scannable code for every stock unit, whether the manufacturer's barcode, a code the store assigns, or both held against the same variant.
Internal code assignment
A rule for generating the store's own codes where none exists or where the supplied one cannot be used, with no risk of reusing a code that belongs to something else.
Label templates
Price labels, tags, shelf labels, promotional labels and any other format the store uses, each drawing its content from the item record.
Print jobs
What to print, how many, from which record, sent to the printer nearest the person doing the work.
Location and bin labels
Addresses for the back store and warehouse, printed and applied so that stock can be recorded to a place.
Reprint triggers
Price changes, promotion start and end, new stock arriving, and range changes, each producing a list of labels that need replacing.
Unlabelled stock queue
Items received without a usable code, held out of the sellable count until they have been coded and labelled.
Scan failures
Items that failed to scan at the counter or at a count, logged so the underlying code or label can be fixed.
The code belongs to the variant
The rule is short and it decides how useful every other system in the store will be: whatever the store sells as a separate thing needs its own code.
If a shirt is sold in five sizes, the store sells five things, not one. A single code across all five means the till records "shirt", the stock record deducts "shirt", and the store never knows it has run out of medium. The reorder is placed on a total, the ratio is wrong, and the pattern repeats.
The same applies to pack sizes, colours, flavours, finishes and any other dimension where the customer chooses one over another. Where two variants are genuinely interchangeable to both the customer and the buyer, one code is fine. Where they are not, separate codes are the only way the data means anything.
Manufacturer barcodes usually handle this correctly, because manufacturers assign codes per variant. The problems tend to arise with store-assigned codes, where it is quicker to make one code for a style, and with items received in bulk and repacked, where the pack the customer buys has no code of its own.
Where an item carries more than one code, a manufacturer barcode and a store code, both should point to the same variant so that either scan works. That is a small design decision that saves a great deal of friction at the counter.
Unlabelled stock needs a route, not a corner
Every store receives goods that cannot be scanned: imported items with no retail barcode, loose goods, repacked goods, items whose printed code is damaged, and items whose supplied code clashes with something already in the system.
Without a defined route, these accumulate. They sit in the back because shelving them means dealing with them; they reach the shelf uncoded and are typed in at the counter, slowly and sometimes wrongly; or they are given a code by whoever is doing it that day, with no rule about what codes look like.
The route is straightforward and belongs at receiving. When an item is received without a usable code, it is flagged, given an internal code from the store's own scheme, labelled, and only then shelved. Until it is labelled it stays in a state that is not sellable, so it cannot reach the shelf uncoded.
Two details make this work in practice. The label printer has to be at the receiving point, so the print happens as part of the receipt rather than as a separate trip. And the code scheme has to be generated by the application rather than chosen by a person, so codes are unique and no one reuses a number that belonged to a discontinued item three years ago.
Where items are repacked, the pack becomes a new stock unit with its own code and its own cost, and the relationship between the bulk item and the pack is worth holding so that stock is deducted from the right place.
One record behind the label, the shelf and the till
The price on the shelf, the price on the item and the price at the till should be the same number, and they will be if all three come from the same record.
They often do not, because each is maintained by a different process. The till price is updated in the POS. The item labels were printed when the stock arrived. The shelf edges were written or printed at some point and are updated when someone notices. A price change touches one of the three immediately and the others eventually.
Driving all three from the item record changes the workflow. A price change produces a reprint list: which items need new labels and which shelf edges need replacing, by aisle, so someone can walk the store once with a printed batch. A promotion produces the same list at the start and again at the end, and the end-of-promotion list is the one most often forgotten, which is how promotional prices run for two extra weeks.
Where a store wants the shelf edge to show more than the price, such as unit pricing, a comparison, or stock location for staff, the template holds it and it stays consistent across the store.
Price accuracy at the counter is also a customer trust matter, and in some places there are rules about displayed prices and what a customer must be charged. What those rules require where you operate is worth confirming with a suitable adviser; this page describes the workflow, not the requirement.
Where barcoding and labelling look different by business type
- Apparel Retail Software, where a style is many variants and the tag carries size, colour and often the season code.
- Grocery Store Software, where weighed items produce a code at the scale and shelf labels change frequently with promotions.
- Hardware Store Software, where thousands of small loose items need bin labels as much as item labels.
- Jewelry Retail Software, where each piece is a unique unit and the tag has to carry weight and identification as well as a code.
- Electronics Retail Software, where the serial number and the product code are different identifiers and both matter.
- Specialty Retail Software, where a large share of stock arrives from small suppliers with no retail barcode at all.
Why retailers choose Pentoggle for barcodes and labels
A code for every variant
Store-assigned codes generated by rule, alongside manufacturer barcodes, both pointing at the same stock unit.
Unlabelled stock cannot reach the shelf
Items received without a usable code are held out of the sellable count until they are coded and labelled.
One record behind label, shelf and till
Price changes and promotions produce a reprint list rather than a discrepancy at the counter.
Printing where the stock is
Print jobs sent from a phone at the receiving door or in the aisle, not from a desk in the office.
Sits around your accounting and your POS
QuickBooks, Tally, Xero and comparable systems continue handling the books. Your POS continues scanning at the counter. Pentoggle holds the codes and the labels behind both.
A useful number for barcodes and labels
Two small ones: the share of received items that needed an internal code, and the share of scans that fail at the counter.
The first sizes the labelling workload and identifies the suppliers that create it. A supplier whose goods always need coding is a cost that is not in the purchase price, and it is worth raising with them.
The second measures whether the labelling is working. Scans fail for several reasons, a damaged label, a code not in the system, a variant sharing a code, or a printer producing labels that will not read, so a rising failure rate is a prompt to look rather than a diagnosis. Logging the item that failed makes the cause findable.
Read both by location. A single store with a high failure rate usually has a labelling process problem rather than a data problem.
Ready to build retail barcode and label software?
You scan most of what you sell.
The items you type in are usually the ones you know least about at the end of the month.
Describe your items, how they arrive and what your labels have to show to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.