Nobody creates a duplicate on purpose. Somebody searched for “gloves”, the existing record was called “Latex Gloves Box 100”, and thirty seconds later there were two. Six months later the stock count disagrees with itself, neither reorder point fires, and the margin report averages two half-truths. This page is about the moment that could have been stopped, and about the nine fields nobody should be able to change quietly afterwards.
What a duplicate costs
This is why the control matters and why it is so hard to sell: a duplicate that gets prevented leaves no trace, and a duplicate that gets created does not hurt for months. Here is the timeline, which anybody who has run a stocktake will recognise.
Two records, one with 240 units and a reorder point, one with zero and no thresholds. Nobody notices, because the new one is not in anybody's way yet. The store staff who created it start using it, because it is the one they can find.
Consumption is now split between two records. The one with the threshold is consuming slower than expected, so it does not trip. The one being used has no threshold at all. Neither fires, and the first anybody knows is an empty shelf.
A buyer raises a request from the record they searched. It is the one with no history, so there is no price trail, no preferred supplier and no consumption pattern to size the order against. The order is a guess dressed as a requisition.
Two buying prices, two markups, two average costs. Inventory valuation adds both and gets a number that is arithmetically correct and operationally meaningless. Margin per item is now an average of two partial pictures.
The stocktake counts one shelf of gloves and finds two records claiming it. Merging them retrospectively means deciding which movements belonged to which record — and the movements are the evidence, so you cannot simply delete one. Both stay, and the mess becomes permanent.
Turnover, ABC banding, dead-stock aging, sales by item: all of them treat the two as separate. The figures are not wrong exactly; they are describing a catalogue that does not match the warehouse, and nobody remembers why.
The only cheap moment in that whole sequence is the first one. Thirty seconds of a person's attention at the point of creation, against six months of compounding arithmetic. That is the trade this feature exists to make.
Three checks at creation
A single blunt duplicate check is worse than none, because it is either so strict that it blocks legitimate variants — two genuine pack sizes, two grades of the same material — or so loose that it never fires. So there are three, with different severities, and the strict one is deliberately narrow.
The same name in the same category is not a variant of anything. It is the same item, typed twice, and it is blocked outright rather than warned about. This is the narrow, unarguable case, and keeping it narrow is what makes the block acceptable.
100% Identical name within the same category, refused at saveAbove eighty-six per cent similarity the candidate is surfaced beside the record it resembles, with that record's stock, barcode and thresholds shown. The person creating decides — because “box of 100” versus “box of 50” is a legitimate pair and no algorithm should be allowed to rule on it.
86% Similarity threshold, checked against up to 50 candidatesThe check nobody expects and everybody needs. A barcode is checked against the item catalogue and the asset register together, because both are scanned by the same handset — and a code that resolves to two different things makes the scanner unusable at exactly the moment it matters.
2 registers Items and assets checked in one pass, not separatelyWhy the barcode one is the sleeper. Most systems keep item barcodes and asset tags in separate worlds, each unique within itself. Then somebody scans a code in the warehouse and the app has to guess which register the person meant. Checking both at creation is a small piece of validation that prevents an unfixable-feeling problem in the field, and it applies to categories too: a category can be told to require specific attributes before an item in it can be saved at all.
Nine fields, held for approval
Fixing a spelling mistake in a description is housekeeping. Changing an item's inventory account moves where its value lands in your accounts. Changing its tracking mode changes what the system will let you do with the stock you already hold. Nine fields are in the second category, and a change to any of them is held until somebody with the authority to approve it does.
The physical link between the shelf and the record. Change it and every label already printed, every scan a handset makes and every reference on an existing document points at a code that no longer resolves. This is the field most often changed for an innocent reason with the widest consequences.
Drives reporting groupings, ABC banding, required-attribute rules and often the duplicate check itself. Recategorising an item retrospectively changes what every historical report says about that group.
Where the item's value lands in your chart of accounts. Changing it changes your balance sheet, and doing so mid-period gives you two accounts each holding part of the truth.
Decides how the item is taxed on a sale and what appears on a compliant invoice. In a jurisdiction with electronic invoicing, this field is the difference between a filing that matches and one that does not.
Whether the item is tracked as individual units or as a quantity pool. Switching this on an item that already holds stock changes what the system can say about the stock it holds.
Turning it on means every future movement needs a lot; turning it off means the lots you already recorded stop being enforced. Both are legitimate changes and neither should happen without a decision.
Same shape as lots, one level finer. A serialised item that stops being serialised loses the ability to answer "where is unit 4417", which is usually the reason it was serialised.
Governs whether the batch-expiry report can see this item at all. Switching it off makes an item silently disappear from the report that was watching it — the worst kind of change, because nothing appears to break.
Which batch gets picked first. Changing it changes what the system tells the picker to take, and therefore which stock ages on the shelf.
Everything else — the description, the reorder point, the buying price, the markup — is an ordinary edit and saves immediately. That distinction is the whole design: a governance control that held every edit would be switched off within a fortnight, and then none of the nine would be governed either.
What actually happens
A pattern worth being explicit about, because some systems do it the other way and call it approval: the edit is not applied and then reviewed. The proposed values are held on the approval, the live record is untouched, and it is the act of approving that writes them. A rejected change leaves no trace on the item at all.
A storekeeper corrects what they believe is a wrong barcode, or a buyer changes an item's category to match a new supplier grouping. They save as normal — there is no separate "request a change" screen to find.
The system compares the submitted values against the record and identifies which of the nine fields actually moved. Only the real differences are held; a field submitted with the value it already had is not a change and does not create anything.
The approval carries a fingerprint of the exact change. Submitting the same edit twice joins the existing request instead of raising a second one, so an impatient user cannot flood the approval queue by pressing save again.
It carries the item, the specific fields, the value before and the value after, who asked, and when. It lands in the approvals hub alongside every other decision waiting on somebody, and a notification goes out — deep-linked, so the mobile alert opens the approval rather than the app's home screen.
Approving writes the held values onto the item and clears the item's caches so every screen reflects the change immediately. Rejecting closes the request and leaves the record exactly as it was. Either way a comment can be attached, and the decision is recorded with the person who made it.
The requester cannot approve their own change. That is enforced rather than advised, and it is the reason this is a control rather than a formality.
If the person making the edit already holds the approving permission, the change applies immediately. This is on by default and it is the honest design: the control exists so that people who should not silently alter these fields cannot, not so that the person who is supposed to authorise them has to authorise themselves.
That bypass is configurable. Where your policy genuinely requires four eyes on every critical change, including from the item master owner, it can be switched off — and then nobody self-approves.
What is written down
That question has an answer, and it is not “the audit log says the record was updated”. The approval carries a pack: the item as it was, the specific fields that moved, the values on both sides, who proposed it, and the fingerprint that proves it is the change that was approved rather than a different one that arrived afterwards.
Held on the approval run, readable after the decision as well as before it
item.id / nameitem.barcode / categorychanges[]proposed_payloadchange_hashrequested_by / atpolicy.permissionpolicy.critical_fieldsdue_atThe straight answer
Those are different products and the second one is a much bigger promise. Here is precisely what is here.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
The merge tool for existing duplicates is the item in that middle column most organisations actually need on day one, because the catalogue arrives with duplicates already in it — and it is a scoping conversation about your movement history rather than a parser. Multi-step approval by field is the second. Tell us what your catalogue looks like today and we will come back with a written spec, a timeline and a price.
What it protects
The stock ledger that every one of the nine fields governs the behaviour of.
Open featureLot, serial and expiry tracking — three of the nine — and what they let you answer.
Open featureHow the catalogue arrives in the first place, and why the duplicate checks matter most on day one.
Open featureWhere a held item-master change waits alongside every other decision needing a person.
Open featureThe handset that reads the barcodes — and the reason a collision across items and assets is not academic.
Open featureThe other side of the same discipline: why an item that history still references cannot be erased.
Open featureWhat changes
Which is a strange thing to sell, because success looks exactly like nothing happening. The measure is the stocktake eighteen months in: whether the count and the catalogue are still describing the same shelves.
An exact duplicate is refused; a near one is shown beside what it resembles, with the stock figures.
Consumption stays on one record, so the threshold that was set actually trips.
A barcode is unique across items and assets together, not within each separately.
Account, tax treatment, tracking mode and the rest need a decision with a name attached.
The record is untouched while a request is open, so nothing has to be undone.
An audit pack with both values, the requester, the permission and the fingerprint.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
