Deposit Return Scheme Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the connected machine assumption catch so many builds?

Every proposal in this category shows the same picture: machines on the left, a pipeline in the middle, a reconciliation dashboard on the right. It is drawn as if events arrive in order, once each, shortly after they happen. In a supermarket estate none of those three things is reliably true.

A reverse vending machine sits in a store lobby on a network that also carries tills, scales and a card terminal. It loses connectivity for a shift. It gets power cycled by a duty manager. A site's router is replaced and the machine sits offline over a weekend. When it comes back it uploads what it has been holding, and those sessions arrive with timestamps from yesterday into a system that has already closed yesterday.

Two failure patterns follow, and they pull in opposite directions. If the pipeline has no idempotency, a retried upload writes the same sessions again and your container counts inflate, which looks like good news until the counting centre disagrees. If the pipeline discards anything outside the current window, real volume disappears and you claim less than you are owed. Either way, the reconciliation drifts and nobody notices, because a few hundred containers a week hides inside a total of hundreds of thousands.

The fix is a design constraint, agreed before anyone writes code. Every machine event carries a stable identifier from the machine itself, the pipeline processes each identifier exactly once regardless of how many times it arrives, and events are recorded against the time they occurred rather than the time they were received. Then run an offline exposure report from day one: hours per machine per day with no contact, and the container volume that eventually arrived from those windows. In the deposit and returns work we have delivered, that first report is always worse than the operations team expected, and it is the number that justifies the project.

What goes wrong when machine, till and counting centre data are joined?

The three way reconciliation is the point of the whole system, and it is where builds quietly go wrong, because the three sources do not share a key.

The machine knows a session. The point of sale (POS) knows a voucher barcode. The counting centre knows a bag or a cage and a count that arrives days later. Nothing in that chain carries a shared identifier unless you create one, and creating one means touching the physical process: the voucher has to carry the session, the bag has to carry the machine and the collection date, and the counting centre report has to come back keyed on something you issued.

Where projects go wrong is by attempting the join on time and volume instead. It works in testing on clean data and fails on real weeks, because two machines in the same store empty on the same day, a bag gets split, a cage goes out with a partial load, and a voucher printed on Friday is redeemed on Monday. What you end up with is a match rate in the low nineties and no way to investigate the rest.

Design the identifiers first, physically. A session identifier printed on the voucher and readable at the till. A bag label generated by the system rather than written on tape. A collection manifest that ties bags to a vehicle and a date. Then the exception queue is meaningful: machine offline window, voucher issued but never redeemed, redemption without a matching issue, count variance at the collection point. Finance stops looking at a total and starts working a short list of named breaks, which is the only version of this that anyone maintains after month three.

Why do the point of sale and machine vendor integrations break after launch?

Both integrations fail for reasons that are foreseeable, and both fail in ways that do not raise errors.

On the machine side, TOMRA and Envipco both ship capable fleet software, and both are built around their own hardware. The interface you get depends on your commercial relationship and the generation of machine, and it can differ across an estate acquired at different times. A build that consumes a daily summary export will look identical in a demo to one that consumes session level events with container detail, and only the second can support fraud work or genuine reconciliation. If the vendor changes an export format or a firmware release alters how a session is reported, a summary based integration keeps producing plausible numbers that are now wrong.

On the till side, voucher redemption is often just a barcode scan against a generic discount or refund tender. There is no structured record saying which voucher was redeemed, so the system infers it from the amount and the time. That inference degrades the moment a customer redeems two vouchers in one basket, or part redeems against a shop, or a supervisor keys a value manually because the barcode will not scan.

The protections are the same in both directions. Insist on session level machine data and name the interface in the contract. Insist that the point of sale writes the voucher identifier as a structured field even if it means a small change on the till. Then run a scheduled reconciliation between what the vendor believes it sent and what you recorded, with a named person receiving the exceptions rather than a dashboard nobody opens.

What happens when manual takeback and scheme audit trails are not covered?

These two get cut from scope together, usually with the words phase two, and they are the two that decide whether a claim survives challenge.

Manual takeback is real volume. Machines fill, jam, break, or do not exist in smaller stores, and in most schemes containers then come over the counter. Someone counts them into a bag, writes a number on a label, refunds the customer and the bag joins the collection stream. That handwritten number enters your claim with exactly the same authority as a machine reading, and it is attributable to nobody. When variance appears at the counting centre, you cannot tell whether it is shrink, a miscount or a machine fault, because a large slice of your volume has no operator, no timestamp and no trail.

The audit trail problem is quieter. Systems get built where a correction updates a record in place, because that is the natural way to write software. In a scheme claim, an updated record is not evidence. When a scheme operator adjusts a claim and asks how you arrived at your figure, you need to walk from the claim total down to individual sessions and show every adjustment as an entry rather than a change.

Both fixes are small. Manual takeback gets a deliberately minimal capture step on a handheld or tablet: count, operator, time, bag identifier, linked to the refund at the till. It is not sophisticated software, and its value is that manual volume becomes something you can trend by site and by person, which is where a surprising share of variance turns out to live. The ledger becomes append only, corrections are reversing entries with a visible reason, and the claim is a period object with a full trail rather than a number assembled in a spreadsheet.

Should you build custom or configure what you already own?

For a lot of retailers the honest answer is do not build, and we would say so before quoting.

If you run a small number of stores with a single machine vendor under one scheme, the TOMRA or Envipco portal plus a monthly export genuinely covers you. The reconciliation exposure is small enough to absorb, and the money does more good in store operations. Before commissioning anything, ask your vendor what session level reporting they can already expose to you, because plenty of operators are running on a summary export while a richer feed sits available under the same contract.

Equally, do not build against a scheme that has not launched. Specifications and dates in this sector have moved more than once, and building to a draft means paying twice. Wait for the rules to settle and confirm them with your scheme administrator rather than a software vendor.

Build when volume makes the small numbers large. A mixed hardware estate across enough sites that no single portal shows your position. Handling fee income that your finance team treats as a real line. A claim you have already been challenged on and could not defend. Or you are the scheme operator, in which case you will build, because no packaged product implements another jurisdiction's rules and your credibility with members rests entirely on settlement accuracy.

How do hidden costs get into the quote?

Five items account for most of the overruns in this category, and every one of them is knowable before you sign.

Vendor data access assumed rather than confirmed. The pacing item on these projects is usually getting session level data out of the machine vendor, not writing the software. Get the interface confirmed in writing before the build starts, because a quote that assumes an interface you do not have is a quote for a different project.

The second hardware vendor. Each adapter is genuine work, and vendor event models differ enough that a second one is not a configuration exercise. Price it separately.

Older point of sale estates. Writing a voucher identifier as a structured field is trivial on a modern cloud till and can be a small change request with its own vendor, its own queue and its own cost on an older estate. Check this in week one.

Connectivity tolerance. Late arriving events, duplicate suppression and reprocessing are architecture, not features, and retrofitting them is close to a rewrite. Any proposal that treats store connectivity as reliable is underpriced.

Counting centre integration. Weight and count data comes off industrial equipment rather than a documented interface, and it usually needs someone on site. It is the line most often left out entirely.

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

Ask how they will handle a machine that was offline for four hours and then uploads its backlog. If the answer does not include idempotent event handling and duplicate session detection, the reconciliation will drift and you will find out when a claim is adjusted. Late and repeated data is the normal condition here, not an edge case.

Ask what hardware they have integrated and at what level, naming the vendor and the interface. There is a large difference between a daily summary export and session level events with container detail, and only the second supports fraud work or a defensible claim.

Ask how they would prove a claim to a scheme auditor. The right answer involves an append only event store where nothing is quietly edited and a trail from the claim total down to an individual session. If history can be rewritten, your audit position is weak no matter how good the reports look.

Then insist on the sequencing that saves money: one machine vendor, one scheme, your highest volume thirty or forty sites, and the reconciliation run in observation mode alongside the existing process for a full claim period before it drives anything. Settle ownership of the repository and the cloud accounts in the contract before kickoff, which is how Digital Heroes ships, because scheme rules change on a regulator's timetable and you cannot afford to sit in a supplier's release queue when a settlement format is revised.