Deposit Return Scheme Software: Why Machine Counts, Refunds and Scheme Claims Never Agree

Why deposit return turns a retailer into a cash handling business

A customer feeds 34 containers into a reverse vending machine at the front of a supermarket. The machine reads each barcode, validates it, crushes or stores the container, and prints a voucher. The customer redeems the voucher at the till or against a shop. Money has now left the store. Later the containers are collected, counted somewhere else, and the retailer claims the deposits back from the scheme operator along with a handling fee per container.

Three numbers now have to agree: what the machine says it accepted, what the store actually paid out, and what the scheme pays back. In practice they never do. A machine sits offline for six hours and its events arrive late or not at all. A bin fills and containers get taken over the counter and counted by hand into a bag with a note. A voucher is printed and never redeemed. Another is redeemed twice because a till operator keyed it manually. The counting centre reports 12,400 containers for a bag the machine says held 12,880, and nobody can tell whether that is shrink, a jam, a miscount, or a machine that double counted a stuck container.

Each container is only a few cents, five in many US deposit states and ten in Michigan, and that is exactly why it goes unmanaged. Nobody chases four cents. But a mid sized chain running high return volumes is moving a large amount of cash through machines that no finance system reconciles, and the handling fee that makes the whole thing viable is paid on counts that nobody can defend. In the deposit and returns projects we have delivered, the first honest report a client sees is usually the one showing how many machine hours were offline and unaccounted for, and it is always higher than the operations team expected.

Problem 1: the three counts are collected by three systems that never meet

The machine count lives in the reverse vending vendor's fleet software. The refund lives in the point of sale (POS), as a voucher redemption or a cash payout at the customer service desk. The claim lives in a file sent to the scheme operator on the scheme's own schedule and format. Each of those systems is competent inside its own boundary. None of them is designed to answer the only question that matters, which is whether the money that left the store is the money that came back.

What a custom build does: pull machine level events with timestamps, session identifiers, and container detail, pull voucher issue and redemption from the point of sale, and match them into one reconciliation object per session. Where the match fails, the exception carries a reason: 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 looking at a short list of named breaks. This is not sophisticated engineering. It is joining three logs that currently live in three companies.

Problem 2: the machines are a mixed fleet with vendor shaped software

TOMRA and Envipco both make good reverse vending hardware and both ship management software around it. The software is built around each vendor's own fleet, which is entirely reasonable for the vendor and inconvenient for a retailer who inherited a mixed estate through acquisition or bought on price at different times. You end up with two portals, two event models, two definitions of a session, and no consolidated position.

The deeper limit is scope. Vendor fleet software is strong on machine health, uptime, bin levels, and service dispatch, because that is the vendor's commercial interest. It is thinner on your commercial interest, which is cash reconciliation, handling fee revenue accuracy, and fraud exposure across sites you operate. It also has no view of your point of sale, so voucher redemption is invisible to it by construction.

What a custom build does: a per vendor adapter that normalises events into one internal model, so a session is a session whether the machine is a TOMRA or an Envipco. Then reconciliation, fraud, and reporting are written once. If a site later switches hardware, you write an adapter rather than a new system, which is the point.

Problem 3: fraud is small, constant, and structurally invisible

Deposit fraud is not dramatic. It is a container from a neighbouring jurisdiction with no deposit paid on it being redeemed where there is one. It is the same barcode presented repeatedly because the machine reads the label rather than a unique mark. It is a staff member printing vouchers against an empty feed at 6am. It is a commercial volume of containers arriving through a domestic customer route to capture the deposit at scale.

Schemes address part of this in the container itself. Newer schemes specify a security mark or a unique identifier so a container can only be redeemed once, and older schemes that validate only a standard product barcode cannot distinguish a first redemption from a fifth. Which situation you are in depends on your jurisdiction and you should confirm the current rules with your scheme administrator rather than assume, because these schemes have changed launch dates and specifications more than once.

What a custom build does: pattern detection over sessions rather than a single check at the machine. Repeated identifiers across sites, session volumes far outside a site's distribution, a machine whose acceptance rate jumps on one shift, redemption clusters at particular tills, and out of market barcode ranges. None of these is proof on its own. Together they produce an investigation queue that loss prevention can work, and a defensible record when a store is challenged.

Problem 4: manual takeback is real volume and nobody models it

Machines fill up, jam, break, or do not exist. Smaller stores in many schemes take containers over the counter. Somebody counts them into a bag, writes a number on a label, refunds the customer, and the bag goes into the collection stream. That count is a human estimate written on tape, and in most operations it enters the claim with the same authority as a machine reading.

What a custom build does: a simple staff facing capture step, usually on a handheld or tablet, that records the count, the operator, the time, and the bag or container identifier, and links it to the refund at the till. It is deliberately small software. Its value is that manual volume stops being an unattributed number and becomes something you can trend by site and by person, which is also where a surprising amount of variance turns out to live.

Problem 5: settlement is jurisdiction specific and the money is slow

The claim file format, the submission cadence, the evidence the scheme operator can demand, the handling fee rates by material and container size, and the treatment of unredeemed deposits are all set by the scheme, and they differ between jurisdictions. An operator running across a border is running two schemes with two file formats and two reconciliation calendars.

What a custom build does: model the claim as a period object with a full audit trail down to the session, generate the scheme's file format from that object rather than from a spreadsheet, and track claim status from submission through acceptance, adjustment, and payment. Then a rejected or adjusted claim is investigable, because you can walk from the adjustment back to the sessions that composed it. Without that trail, an adjustment is simply a smaller cheque with no explanation.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release covering machine event ingestion for one hardware vendor, point of sale voucher matching, three way reconciliation with an exception queue, and claim file generation for one scheme runs $90,000 to $190,000 and ships in 14 to 20 weeks. A full platform adding a second hardware vendor, manual takeback capture, fraud detection, handling fee modelling and forecasting, collection and logistics tracking, and multi scheme settlement runs $220,000 to $600,000 phased over 8 to 14 months.

What drives price up specifically here: the number of hardware vendors, since each adapter is real work and vendor event APIs vary in quality and in what they will expose to a customer. Point of sale integration, which is easy on a modern cloud till and painful on an older estate where voucher redemption is a barcode scan with no structured record. Site count, mainly through connectivity, because stores lose network and the system has to tolerate late arriving events without double counting. Fraud detection depth. And any physical counting centre integration, where weight and count data come off industrial equipment rather than an API.

What keeps price down: starting with your highest volume 30 or 40 sites and one machine vendor, and running the reconciliation in observation mode for a full claim period before it drives anything.

Build versus buy, and when buying is right

Do not build if you run a small number of stores with a single machine vendor and a simple scheme. The vendor portal plus a monthly export genuinely covers it, and the reconciliation risk is small enough to absorb. Do not build if you are about to enter a scheme that has not launched, because specifications move and building against a draft is paying twice.

Build when the volume makes the small numbers large. Specifically: when you run a mixed hardware estate across enough sites that no single portal shows your position, when handling fee income is a line your finance team actually cares about, when you have been challenged on a claim and could not defend the count, or when you are the scheme operator and your credibility with members rests entirely on settlement accuracy. Scheme operators almost always end up building, because no packaged product implements another jurisdiction's rules.

How to choose a developer for deposit return software

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 a way to detect duplicate sessions, the reconciliation will drift and nobody will notice until a claim is adjusted. Late and repeated data is the normal condition in this category, not an edge case.

Ask what hardware they have actually integrated and at what level. There is a large difference between reading a vendor's daily summary export and consuming session level events with container detail. Only the second supports fraud work or genuine reconciliation, so ask for the specific vendor and the specific interface.

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 container session. If history can be rewritten, your audit position is weak no matter how good the reports look.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts, and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, and any developer who hedges on that is building a dependency rather than a system.