Retail Loss Prevention Software: Why Exception Reports Never Turn Into a Case That Holds Up

Why exception reporting stops exactly where the case begins

It is 9pm on a Tuesday and a regional asset protection manager is working through the daily exception report for 340 stores. Store 118 shows a cashier with 41 no sale drawer opens on one shift. Store 402 shows a service desk associate who has processed 11 no receipt refunds to gift cards in eight days, every one of them landing just under the $75 supervisor approval threshold. A third flag is a buy online pick up in store order that was picked, marked collected, and refunded 40 minutes later at a different store. Three rows in a report. Not one of them is a case yet.

Turning those rows into something a prosecutor will accept means pulling video from two recorder brands whose clocks are 90 seconds apart, exporting POS journal detail at line level, matching a loyalty ID to a phone number that also appears on a marketplace listing, writing a narrative, and assembling the whole thing into a package that survives a defence attorney reading it. In the asset protection teams we have built for, an investigator burns six to twelve hours assembling a single organised retail crime package, and most of that is copying, renaming and cross referencing files. That is why the majority of flagged incidents quietly expire.

The typical stack is Appriss Retail scoring returns, Agilence or a POS vendor module producing till exceptions, Sensormatic or a similar system at the door, Everseen or another computer vision layer at self checkout if you have invested there, a separate video management system per acquisition, and a case file that is a folder on a shared drive named by store number and date. Every one of those products is competent inside its own boundary. None of them owns the object your team actually works: the case, with a suspect, a set of linked incidents across stores, an evidence list with hashes and custody, a restitution figure, and a status that a prosecutor or a civil recovery firm can act on.

Problem 1: the rule library is somebody else's shrink

Productised exception reporting ships with a rule library built from a broad sample of retailers. That is genuinely useful on day one and it is why Agilence and Appriss Retail earn their money at mid size chains. The limit is that your fraud is shaped by your policies, and your policies are not the sample. If you allow no receipt returns to a gift card up to $100, your abuse pattern forms at $99. If your price match policy permits an override without a manager code, that is where the leakage goes.

Vendor rules can be tuned, but tuning happens inside their model of a transaction. When your loss pattern depends on a field their schema does not carry, for example the specific override reason code your chain uses or the employee who authorised a produce markdown, the rule cannot be written at all. Teams then work around it by exporting to Excel every Monday, which is where an entire second shadow reporting function is born. That is not a reporting problem, it is an unbuilt system.

Problem 2: the case file is the product, and it lives on a desktop

A shrink number is an accounting result. A case is the thing that recovers money and stops the crew. The case has requirements no reporting tool was designed for: chain of custody on every clip and document, a record of who viewed what and when, notes that are discoverable and therefore must be written knowing they are discoverable, links between incidents that establish a pattern across seven stores in three districts, and a status pipeline that runs through interview, civil demand, police referral, prosecution and restitution.

When that lives in a folder plus a spreadsheet plus an inbox, two things break. The first is legal: you cannot prove an exported clip was not edited, and a defence attorney will ask. The second is intelligence: nobody can see that the store 118 incident and the store 402 incident share a vehicle plate captured six weeks apart, because those facts sit in two documents nobody has opened together. A custom build makes the case a first class record with append only evidence entries, file hashing at ingest, immutable audit logging, and entity resolution across suspects, vehicles, phone numbers and loyalty accounts. That entity graph is the single feature that converts a pile of incidents into an organised retail crime case, and it is the one no exception reporting tool will build for you because it depends on the identifiers your systems actually capture.

Problem 3: video, EAS and self checkout vision never agree on time

Correlating a transaction to footage sounds trivial and is not. Your POS timestamps come from one clock, your recorders from another, your Sensormatic pedestal alarms from a third, and stores acquired in the last merger run a video platform the rest of the estate does not. An investigator asked for the clip covering a 19:42:11 transaction gets footage that is a minute and a half off, and then spends fifteen minutes scrubbing.

What the build must include is unglamorous and it is the difference between a tool people use and shelfware. Clock drift measurement and correction per device. A camera to register mapping so a transaction resolves to the right lane view without a human choosing. Clip retrieval by transaction rather than by time, so an investigator clicks a line on a receipt and gets the frames. Automatic pull and retention of clips attached to an open case before the recorder's 30 day overwrite destroys them, which is the single most common way a case is lost.

Problem 4: refund abuse moved omnichannel and the rules did not

The interesting fraud is no longer at a single till. It is a return of an item that was never shipped, a ship from store order cancelled after pick, a curbside handoff marked complete with no customer present, a gift receipt refunded at a store 200 miles from the purchase, and a marketplace listing of items that match your shrink profile SKU for SKU. Appriss Retail is strong on the returns side specifically because it sees a consortium view of return behaviour. What it does not see is your fulfilment system's pick, pack and handoff events, because those live in your order management platform.

A custom build joins order lifecycle events to POS and returns in one timeline per customer identity. That lets you write the rules that actually matter to an omnichannel chain: refund issued without a corresponding fulfilment completion, collection scanned by an associate who also processed the refund, repeat cancellations from one account across many stores, or return velocity by delivery address rather than by loyalty ID, since the fraudster changes the ID and keeps the address.

Problem 5: you cannot separate theft from process loss, so you fund the wrong fix

Every asset protection budget conversation eventually reaches the same question: how much of this shrink is theft. Most chains cannot answer it because receiving variances, unrecorded damages, markdown errors, expired product write offs and actual theft all land in the same inventory adjustment bucket at count time. So the response is uniform: more guards, more locking fixtures, more source tagging, applied evenly across stores whose loss has different causes.

What a build adds is attribution. Receiving variance is captured at the door against the ASN, not reconciled at count. Damage and markdown are their own coded events with a photo and an employee. Then the shrink number decomposes by cause, by store, by category and by shift, and the investment argument changes completely. In our delivery experience this analysis is what wins the budget argument, because a VP of Asset Protection can finally say which portion of the number is addressable by which intervention.

What this costs and how long it takes

A first release covering exception rules against your own POS, returns and fulfilment data plus a proper case file with evidence chain and audit logging runs $90,000 to $180,000 and ships in 14 to 20 weeks. That is a system your investigators work in daily, not a dashboard. A full platform adding video correlation with clock drift handling, EAS and self checkout vision events, entity resolution across stores, civil recovery and restitution tracking, store audit workflows and executive shrink attribution reporting runs $250,000 to $600,000 phased across 9 to 15 months.

What pushes the number up in this category specifically: the number of distinct video platforms in the estate, because each integration is real weeks and some older recorders have no usable API at all. POS heterogeneity after acquisitions, since two journal formats means two parsers and two sets of rules. Data volume, because a 500 store chain generates a transaction line volume that forces a columnar store rather than a general purpose database. And legal review of retention and access, which is not optional when the records are discoverable.

What keeps it down: starting with returns and refunds only, at your worst 30 stores, with video correlation deferred to phase two. Refund abuse is usually the fastest recoverable money and it proves the case model before you spend on integrations.

Build versus buy, and when buying is the right call

Buy if you are under roughly 40 stores. Agilence or Appriss Retail plus a store audit programme will surface more than you can act on, and a build would be spending capital to avoid a subscription. Buy if your shrink is concentrated in receiving and damages rather than theft, because your fix is a process and a scale at the back door, not software. Buy if your video estate is a single modern platform and your POS is one vendor across the chain, since the integration pain that justifies a custom build is largely absent.

Build when two or more of these are true. Your investigators assemble case packages by hand and cases are being lost to recorder overwrite. You run more than one POS journal format or more than two video platforms. Your loss is organised rather than opportunistic, meaning you need cross store linking and an entity graph rather than a per store report. Your return policy has enough exceptions that vendor rules cannot express it. Or you have been asked by a prosecutor for something you could not produce, which is the moment most chains we work with pick up the phone.

How to choose a developer for loss prevention software

Ask them to describe the evidence chain before they describe the dashboard. A developer who has done this will talk about hashing on ingest, append only storage, immutable access logs and retention policy per record type, and they will ask who your legal counsel is. A developer who opens with charts is building reporting, and you already have reporting.

Ask specifically how they handle clock drift between POS and video, and how a clip gets pulled and preserved before the recorder overwrites it. If they have not hit this, they have not shipped in retail asset protection and you will discover it in month four.

Ask what they have actually integrated by name. An Oracle Retail Xstore journal is a different problem from a NCR or Toshiba one. Milestone or Genetec video export is different from a proprietary DVR with no documented interface. Sensormatic pedestal events are different again. Ask for the vendor and the version, not a claim about integrations in general.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit, and given that this system will hold evidence, a developer who wants to keep the repo or host it on their own accounts is a risk you should refuse.