Retail Loss Prevention Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the exception reporting rebuild swallow the whole budget?

The commonest scope failure in retail asset protection is deciding to replace exception reporting. It sounds like the obvious starting point, because the reports are what the team opens every morning and because the vendor rule library cannot express your return policy. So the project gets scoped as rules, thresholds and dashboards, and six months later you own a slightly better version of a product you already subscribe to.

This happens because reporting is the visible artefact and the case is the invisible one. Everyone can describe a report. Almost nobody describes the six to twelve hours an investigator spends assembling an organised retail crime package, because that work happens off screen in folders, file renames and email. When requirements come only from what people can point at, the budget lands on the part that was already adequate.

The fix is to write scope around the object rather than the output. Start with the case: a suspect, a set of linked incidents across stores, an evidence list with custody, a restitution figure, and a status a prosecutor or a civil recovery firm can act on. Rules then earn their place only where they feed that object. In practice the first release is the case file, the evidence chain, and a small number of rules aimed at your single worst pattern, which for most chains is no receipt refunds. That is a system investigators live in. A rule library is a report they read.

What goes wrong when you migrate years of incident and case history?

Every chain has history: incident logs in a spreadsheet per region, case folders on a shared drive named by store number and date, an older case tool inherited from an acquisition, and a pile of exported clips whose filenames are the only record of what they contain. The plan is always to bring all of it across. It rarely survives contact with the data.

Three things break specifically here. Suspects were never entities, they were free text inside a narrative field, so the same person arrives as four spellings and the entity graph you are building the system for starts polluted. Evidence files have no hashes and no custody record, so importing them into an append only evidence store lends them a credibility they have not earned. And store numbers changed through remodels and acquisitions, so incidents attach to the wrong site and your per store loss attribution is wrong from the first day.

What works is importing history as reference rather than as evidence. Old cases come in read only, clearly marked as pre migration, with files held as attachments that are explicitly not represented as chain of custody records. Entity resolution runs over the old narratives and proposes suspect matches for an investigator to confirm, rather than the system asserting them. Budget several weeks for this. Expect the clip archive to be the part that defeats you, because most of it has no reliable link back to a transaction and never did.

Why do POS, video and EAS integrations break after launch?

They break because none of them is a single integration. A chain running one point of sale vendor still runs three journal versions across the estate, because remodels and acquisitions leave stores on older builds. Video is worse. Milestone or Genetec in the newer sites, a proprietary recorder in the group you bought in 2019, and a handful of stores where the only export path is a technician with a USB stick.

The failure surfaces after launch rather than during it because the pilot stores were the modern ones. Rollout reaches store 340, whose recorder has no documented interface, and the clip retrieval everyone has been relying on quietly stops working there with no error anyone sees. Meanwhile clock drift, measured once during the build and written into a config file, has moved again, because recorder clocks drift continuously and nobody owns them.

Two concrete fixes. Treat drift as a monitored value rather than a constant: measure it per device on a schedule, correct at query time, and alarm when a device moves outside tolerance. Then build a per site capability record stating exactly what each store supports, so an investigator sees clip retrieval by transaction at one store and an explicit manual request queue at another, instead of a feature that fails silently. Sensormatic pedestal alarms and self checkout vision events belong on the same timeline with the same drift handling, or they will disagree with the till by a minute and your team will stop trusting all of it.

What happens when the evidence chain and retention rules are not covered?

The system becomes unusable at the exact moment it matters. A defence attorney asks whether the exported clip was altered. If the honest answer is that an investigator copied it from a recorder onto a shared drive, the clip is worth very little and so is the case built on it. Hashing at ingest, append only storage and an immutable access log are not compliance decoration. They are the reason the file carries evidentiary weight at all.

Retention is the other half and it cuts both ways. Too short and you lose material supporting an open case or a civil recovery still running. Too long and you are holding personal data about identified individuals with no lawful basis, which becomes a different category of problem when a subject access request or a state privacy statute arrives. Loyalty identifiers, images of faces and vehicle plates all count.

Get your legal counsel into the design before the schema settles, not at user acceptance testing. What counsel needs to specify is retention per record type, who may view what, and what happens when a case closes with no action taken. What engineering needs to build is deletion that genuinely deletes, including from backups and derived stores, plus a log proving it happened. Teams that skip this ship a platform their own counsel later advises them not to rely on, which is a worse outcome than not building it.

Should you build custom or configure what you already own?

Configure, genuinely, if you are under roughly 40 stores. Agilence or Appriss Retail plus a disciplined store audit calendar will surface more exceptions than your team can work, and your constraint is investigator hours rather than detection. Spending six figures to avoid a subscription at that size is a mistake we would talk you out of.

Configure also if your loss sits at receiving and in damages rather than in theft. The fix there is a scale at the back door, a process that records damages when they happen, and a manager who owns the variance. No software project changes that outcome, and commissioning one lets everybody avoid the conversation.

Appriss Retail deserves a specific mention on returns, because it sees return behaviour across a consortium of retailers, and that is information you cannot generate from your own data no matter what you build. If serial returners are your problem, keep it and build around it. The same logic applies to Agilence on till level exceptions in a single vendor estate. It is competent, it is configurable, and reproducing it wins you nothing.

Build when the object you need is the case rather than the report. That means investigators assembling packages by hand, cases lost to recorder overwrite, loss that is organised across stores so you need suspect linking rather than per store reports, or fulfilment events in your order management system that no exception tool can join to point of sale data. Two or more of those and the arithmetic works.

How do hidden costs get into the quote?

Four ways, and every one is estimable in advance if somebody asks.

• Video platform count. Each distinct platform is real integration weeks, and a proprietary recorder with no documented interface may be unreachable at any price. Count them before you sign, including the estate you acquired.
• Point of sale journal formats. Two formats means two parsers, two rule sets and two sets of edge cases inside one system. Acquisitions are the usual source, and nobody volunteers this in a scoping call.
• Data volume. A 500 store chain produces a transaction line count that a general purpose database will not serve interactively, so you need a columnar store and the query work that comes with it. Discovering that in month five means rebuilding the query layer.
• Legal review. Retention, access control and deletion design need counsel time and usually a round of rework. Price it as a workstream, not a review meeting.

The quiet one is data cleanup, because the entity graph is worthless until loyalty identifiers, phone numbers and addresses are normalised, and retail customer data is not clean. Ask any developer how they will handle two records sharing an address with different spellings of a name, and whether that work sits inside the number they quoted.

What separates a build that works from one that fails here?

The successful ones start narrow and land in daily use. Returns and refund abuse at your worst thirty stores, with a real case file and a working evidence chain, video correlation deferred. Investigators adopt it because it gives back the hours they currently lose to copying and renaming files, and that adoption is what funds phase two. The failures start with a platform diagram covering every data source in the estate, and eighteen months later the team is still exporting to a spreadsheet.

The second differentiator is whether a control acts or merely informs. A report warning that a clip is approaching the overwrite window will be missed on the day it matters, because that is the day everyone is busy. A job that automatically pulls and preserves clips attached to any open case does not depend on anyone noticing. Apply that test to every control in the design.

Third, make a developer describe the evidence chain before the dashboard. You want hashing on ingest, append only storage, immutable access logs, retention per record type, and an unprompted question about who your counsel is. If they open with charts they are building reporting, and you already have reporting. Ask for integrations by name and version, Oracle Retail Xstore against NCR against Toshiba, Milestone against Genetec, rather than a general claim about integration experience. Then settle code and cloud account ownership in writing before kickoff, because a system holding evidence and access logs cannot sit inside a supplier account.