Deposit Return Scheme Software: Is the Machine Vendor Portal Enough, or Do You Need Your Own Reconciliation Layer?
Site count and hardware vendor count decide this, and roughly 40 sites on one vendor is the line.
On this page
Site count and hardware vendor count decide this, and roughly 40 sites on one vendor is the line. Below it, with a single machine vendor and one straightforward scheme, buy: the TOMRA or Envipco fleet portal plus a monthly export genuinely covers you, and the reconciliation risk at that volume is small enough to absorb. Above it, and certainly with a mixed estate inherited through acquisition, no single portal shows your position and a reconciliation layer above both vendors starts to pay. Scheme operators are the exception at any size: they almost always build, because no packaged product implements another jurisdiction's rules.
When is off the shelf genuinely the right call here?
If you run a small number of stores with a single machine vendor under one straightforward scheme, do not build. TOMRA and Envipco both ship capable fleet software, and it is genuinely strong at the things that matter most when your estate is small and homogeneous: machine health, uptime, bin levels and service dispatch. Add a monthly export into a spreadsheet somebody owns, and your reconciliation risk is small enough to absorb without software.
Do not build if you are preparing for a scheme that has not launched. Specifications and dates in this sector have moved more than once, and building validation logic against a draft means paying for the same work twice. Confirm the current position with your scheme administrator before designing anything, particularly around container security marks and unique identifiers, because whether your jurisdiction requires them changes the entire fraud design.
The vendor portals are also the right answer for the part of the problem they were built for, whatever your size. Nobody should replace machine health monitoring and service dispatch.
The honest test for whether you need more is a question your operations team can attempt today. How many machine hours were offline and unaccounted for last quarter? If the answer arrives quickly and the number is small, the portal is doing its job. If nobody can produce the figure at all, that is not evidence the number is small.
When does a custom build actually pay off?
Deposit return turns a retailer into a cash handling business, and the software question follows from that. Each container is worth a few cents, five in many deposit states and ten in Michigan, which is exactly why nobody manages it. But a 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 nobody can defend.
Build when two or more of these hold. You run a mixed hardware estate across enough sites that no single portal shows your position. Handling fee income is a line your finance team watches rather than a rounding error. You have been challenged on a claim and could not defend the count. Or you are the scheme operator, and your credibility with member retailers rests entirely on settlement accuracy.
The underlying problem is that three numbers have to agree and they are collected by three systems that never meet. The machine count lives in the vendor's fleet software. The refund lives in your 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 is competent inside its boundary. None answers whether the money that left the store is the money that came back.
The breaks are individually tiny and structurally invisible. A machine offline for six hours whose events arrive late or not at all. A voucher printed and never redeemed. A voucher redeemed twice because a till operator keyed it manually. A counting centre reporting 12,400 containers for a bag the machine says held 12,880, with no way to tell whether that is shrink, a jam, a miscount or a double count on a stuck container.
How do they compare on the things that matter in this industry?
- Scope of interest. Fleet software is built around the vendor's fleet, which is entirely reasonable and structurally limiting. It is strong on uptime and service dispatch, thinner on cash reconciliation, handling fee accuracy and fraud exposure, because those are your commercial interest rather than theirs.
- Point of sale blindness. No machine vendor portal sees your tills, so voucher redemption is invisible to it by construction. That is not a gap a better portal fixes. It is a boundary.
- Mixed estates. Two vendors means two portals, two event models and two definitions of a session. A normalising adapter per vendor means a session is a session regardless of the machine, and reconciliation, fraud and reporting get written once.
- Late and repeated data. A machine offline for four hours then uploads its backlog. Idempotent event handling and duplicate session detection are the difference between a reconciliation that holds and one that drifts until a claim is adjusted. This is the normal condition in the category, not an edge case.
- Claim defensibility. An adjusted claim is only investigable if you can walk from the claim total down to an individual container session on an append only record. Without that trail, an adjustment is simply a smaller payment with no explanation attached.
- Multi scheme settlement. Claim file formats, submission cadences, handling fee schedules by material and size, and evidence requirements are set per scheme. Operating across a border means two rule sets, and no product implements another jurisdiction's scheme document.
What does total cost of ownership look like at your scale?
From Digital Heroes delivery experience there are two bands with a real gap between them. A focused first release runs $90,000 to $190,000 over 14 to 20 weeks: machine event ingestion for one hardware vendor at session level, point of sale voucher issue and redemption capture, three way reconciliation with an exception queue carrying named break reasons, and claim file generation for one scheme. The full platform runs $220,000 to $600,000 across 8 to 14 months, adding a second hardware vendor, manual over the counter takeback capture, fraud pattern detection, handling fee modelling, collection tracking and multi scheme settlement.
A worked shape: a grocery chain running reverse vending across 180 stores with two machine vendors from an acquisition, a mixed till estate and one scheme, lands near $254,000 across eleven months. The same chain taking only discovery, one adapter, point of sale ingestion, reconciliation and claim generation lands at about $136,000 in eighteen weeks, and that subset is where most of the recoverable money actually is.
Two cost drivers matter more than store count. Hardware vendor count, because each adapter consumes a different event model and handles offline backlog differently, so the second adapter benefits only modestly from the first. And till estate age, because on a modern cloud point of sale voucher events arrive structured, while on an older estate a redemption is a barcode scan against a generic tender type with no structured record, and extracting it sets your timeline more than the engineering does.
Running cost is a maintenance retainer at 15 to 20 per cent of build cost per year, plus event storage that grows every month because session level container detail is kept append only for as long as scheme evidence rules demand. Model that storage across five years. The retainer earns its keep here more than in most categories, because scheme file formats and handling fee schedules change on a regulator's timetable and machine interfaces change with firmware releases.
What does the hybrid look like, and when is it the honest answer?
The hybrid here is not optional, it is the architecture. Keep the vendor portals, build the layer above them.
TOMRA and Envipco continue to own machine health, uptime, bin levels and service dispatch, and your engineers never touch that. Your build owns the reconciliation: session level events normalised into one internal model, voucher issue and redemption from the point of sale, the three way match, the exception queue, the claim period object with its audit trail, and claim status tracking from submission through acceptance, adjustment and payment. If a site later changes hardware, you write an adapter rather than a new system, which is the whole point of normalising.
The second hybrid is scope. Start with your highest volume thirty or forty sites and one machine vendor. Those sites carry most of the cash and most of the variance, so proving the reconciliation there costs a fraction of proving it everywhere, and rolling the rest out afterwards is deployment work rather than development.
The third is temporal, and it is the one operators skip. Run the reconciliation in observation mode for a full claim period before it drives anything. It adds calendar and it removes the most expensive category of change, which is a rule written from how finance described the process rather than from how the process actually behaves. Every operator we have worked with found at least one such rule during observation.
Leave manual takeback capture, fraud detection and handling fee forecasting to phase two without exception. All three read from the reconciled data, and none is useful before the core match is trusted.
Which should you choose, by operator size and stage?
Under about 40 sites, one machine vendor, one scheme: buy. Use the fleet portal, take a monthly export, and give one named person ownership of the reconciliation spreadsheet. Ask them quarterly for the offline machine hours figure, because that number is your early warning that the situation has changed.
Forty to a hundred sites on one vendor: buy the portal, build the first release. One adapter, point of sale ingestion, the three way match and claim generation for one scheme. That is the $90,000 to $190,000 band and it is a self contained piece of work with a defined output, which is exactly what you want before committing to a programme.
Above a hundred sites with a mixed estate: build the platform, and phase it properly. Ingestion, then reconciliation in observation, then claim generation in parallel with your existing spreadsheet for one full period, then fraud and handling fee modelling. Hold ten to fifteen per cent of the budget back for the period after the first live claim, because there will be adjustments and you want budget attached to the team that understands why.
Anyone entering a scheme that has not launched: wait. Build the point of sale data capture if you like, since structured voucher events are useful regardless, and leave the validation and claim logic until the specification is final.
Scheme operators: build, at any size. Your obligations are defined by a scheme document that applies to one jurisdiction, so there is no market of competing products to buy from. You also carry work retailers never touch, including member onboarding, producer registration and fee collection, claim adjudication across many members, unredeemed deposit accounting, and network level fraud analysis that only works because you can see across sites no single retailer can.
If you would rather scope this before committing budget, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The right combination of digital transformation actions can unlock as much as US$1.25 trillion in additional market capitalization across Fortune 500 companies, while the wrong combinations put more than US$1.5 trillion at risk; companies with all three core factors (strategy, aligned technology, and change capability) saw a 5% market-value lift relative to peers. Source: Deloitte (2023) →
- A 100-millisecond delay in website load time can cut conversion rates by 7%; a two-second delay increases bounce rates by 103%; and 53% of mobile visitors leave a page that takes longer than three seconds to load. Source: Akamai Technologies (2017) →
- In the Flexera 2025 State of ITAM report, respondents reported roughly 33% of SaaS spend is wasted, underscoring how paying for off-the-shelf seats and tiers that go unused erodes the supposed cost advantage of generic SaaS. Source: Flexera (2025) →
- Qualtrics research (Q3 2023 survey of ~28,400 consumers across 26 countries) estimated bad customer experiences put roughly $3.7 trillion in global revenue at risk annually, a 19% jump from the prior year's $3.1 trillion; 64% of customers say they will switch companies over poor service regardless of how much they like the product. Source: Qualtrics XM Institute (via Forbes) (2024) →
Frequently asked questions
If we build now and change machine vendor later, how much is wasted?
Very little, provided the design normalises events into one internal model from the start. A session means the same thing regardless of which machine produced it, so changing hardware means writing one adapter, typically the smaller half of what the original cost, and backfilling history.
What you must avoid is a build that lets vendor specific field names and event shapes leak into the reconciliation logic. That is not a technical nicety, it is the difference between a hardware decision and a software project, and it is worth putting in writing before kickoff.
What happens if scheme rules or handling fee schedules change?
They will, and on a regulator's timetable rather than yours. File formats, handling fee schedules by material and size, and evidence requirements all move, which is precisely why the maintenance retainer at 15 to 20 per cent of build cost earns its keep more here than in most categories.
The design decision that limits the damage is keeping one internal container and session model with scheme specific rules and output formats layered on top. Then a rule change is a rule change rather than a rewrite, and a second jurisdiction is an adapter rather than a second system.
How long does a first release take?
Fourteen to 20 weeks, and the pacing item is almost never engineering. Getting session level data with container detail out of your machine vendor, and getting structured voucher redemption out of an older point of sale estate, both take longer than writing the code that consumes them.
Then add a full claim period running the reconciliation in observation mode before it drives any decision. That is calendar time worth spending, because it is where rules written from a description of the process get corrected against the process itself.
Is TOMRA fleet software enough on its own?
For a small single vendor estate, yes, and building would be wasted money. It is genuinely strong on machine health, uptime, bin levels and service dispatch, which is what matters when your estate is small and homogeneous.
What it cannot cover is your point of sale, so voucher redemption is invisible to it by construction, and it manages its own fleet rather than a mixed one. Once you run two vendors across many sites and handling fee income matters to finance, you need a layer above both portals rather than a better portal.
Should we replace the vendor portal entirely?
No. Machine health monitoring and service dispatch are the hardware vendor's commercial interest and they see failure patterns across an installed base far larger than yours. Rebuilding that is spending money to get a worse result.
The layer you build reads events and owns reconciliation, claims and fraud. Those are the parts nobody sells you, because they depend on your tills, your scheme and your commercial position rather than on the machine.
We run 60 stores on one machine vendor. Build or buy?
Buy the portal, build the first release only. At 60 stores on one vendor you are past the point where a spreadsheet holds, and short of the point where a full platform is justified.
Scope it to your highest volume thirty or forty sites, one adapter, point of sale voucher matching, the three way reconciliation and claim file generation for your scheme. That is a self contained piece of work with a defined output, and it tells you within one claim period whether the remaining phases are worth funding.
Can software actually reduce deposit fraud, or only report it?
It produces an investigation queue, which is the right output. The behaviour is small and repetitive rather than dramatic: a container from a jurisdiction with no deposit redeemed where there is one, the same barcode presented repeatedly, vouchers printed against an empty feed early in a shift, commercial volumes arriving through a domestic customer route.
No single signal proves anything. Repeated identifiers, session volumes outside a site's distribution, acceptance rates that jump on one shift, redemption clustering by till and out of market barcode ranges, ranked together, give loss prevention something to work. That is roughly $30,000 of a full platform and it belongs in phase two, after the reconciliation is trusted.
How do we justify this to a finance director with no licence to compare against?
With four numbers rather than a feature list. Finance and operations hours spent each claim period reconciling machine reports, till data and the scheme statement, at loaded salary. The value of claim adjustments accepted in the last two years that you could not defend. Handling fee income lost to sessions that never entered a claim because a machine was offline. And any fleet portal fees beyond your hardware service agreement.
If you cannot produce the third figure at all, that is the argument rather than a reason to skip the exercise. In the deposit projects we have delivered, the first report showing offline and unreconciled machine hours has consistently come in higher than the operations team expected.
If we build for 20 users now, will the software cope with 500 later?
It should, without a rewrite, if it was built on a standard cloud stack; going from 20 to 500 users is mostly a hosting configuration change costing hundreds a month, not a second project. What actually breaks under growth is sloppier work: database queries never indexed for volume and features designed assuming one office's worth of data. Before signing, ask the vendor what happens to the system at ten times today's data, and listen for a specific answer.
If an agency builds my software, who actually owns the code?
You should own everything, assigned in writing: the contract transfers full IP to you on final payment, the code lives in your GitHub organization, and hosting runs in cloud accounts you control. The red flag is a proposal that mentions the agency's proprietary platform or framework, which usually means you are renting, not buying. Digital Heroes structures every build this way precisely so a client can fire us and lose nothing but the relationship.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
Couldn't I just build my app in Bubble or another no-code tool instead of hiring an agency?
For validating an idea with real users, yes, and we tell clients that honestly. The walls come later: Bubble apps cannot be exported as code to run anywhere else, performance drops on complex data operations, and usage-based pricing climbs as you grow. A meaningful share of Digital Heroes custom builds are rebuilds of no-code MVPs that proved the business worked, which is the system operating as intended: validate cheap, then build the version that scales.
Does it matter which tech stack the agency wants to use?
Yes, but not in the way most buyers expect: the goal is boring, popular technology such as React, Node.js or Python, and PostgreSQL, because any future team can maintain it and hiring a replacement developer takes days, not months. The red flag is an agency-proprietary framework or an unusual language, which welds you to that one vendor no matter what your contract says about code ownership. A useful test: could you find three freelancers fluent in this stack within a week? If not, push back.
What should I have ready before I contact a development agency?
Three things, none of them technical: a one-page description of the problem in your own words, a list of the tools and spreadsheets the new system must replace or connect to, and a must-have versus nice-to-have split of features. Add a budget range, even a wide one, because it changes the conversation from fantasy to engineering. You do not need a formal specification; producing that is what a discovery phase is for.
We run everything on Airtable and spreadsheets. When is it time to go custom?
The switch usually makes sense when you hit one of two walls: Airtable's record caps (125,000 records per base on the Business plan) or logic the tool cannot express, like multi-step approvals with conditional pricing. There is also a simple cost signal: 25 people on Business at roughly $45 per seat per month is about $13,500 a year, forever, for a tool you are already fighting. Custom is worth it when the workflow is core to how you make money; for peripheral processes, staying on Airtable is the right call.
What is the biggest mistake first-time software buyers make?
Choosing the lowest quote without asking why it is the lowest. A bid 40% under the field usually gets there by skipping tests, documentation, and code review, which are invisible in a demo and brutal to pay for later; every stalled project Digital Heroes has been asked to rescue tells some version of that story. The second mistake is signing without a written scope, which reliably turns the winning cheap quote into 1.5x to 2x the price by launch.
Should I hire a freelancer or an agency for my software project?
A skilled freelancer is the right call for a single-discipline scope under roughly $15,000, like a website, a plugin, or one integration. Above that, projects need design, backend, testing, and project management at once, and a solo builder becomes the single point of failure: if they get sick or take a bigger client, your project simply stops. Agencies bill 20-40% more per hour but carry continuity, code review, and someone to escalate to, which is what you are actually buying.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
Published · Last updated .
