RotionDocs
Core concepts

How does deposit management work?

In Rotion, a deposit is charged on the issue scan and released on the return scan, and every venue and return point keeps a balance that updates itself.

Last updated: 29 September 2026

Rotion manages deposits by attaching them to scans: a deposit is charged when an asset is issued and released when it returns, so money and assets move on the same record. Each venue and return point keeps a balance that updates itself on every scan, nobody reconciles a spreadsheet at month end, and that is what makes deposit schemes workable across many partners.

How do deposit flows follow scans?

In Rotion, every deposit event is a scan event. When a returnable container, tray, or cup is issued, the scan that records the handover also records the deposit charged. When the asset comes back, the return scan releases the refund. There is no separate deposit administration to keep in sync with reality.

Because the deposit rides on the asset's digital packaging passport, a disputed deposit resolves by reading the record: who was issued the asset, when, and whether it was returned. Serialization matters here; per-item identity is what makes a deposit attributable, which is why deposit-bearing assets are usually serialized rather than batch-identified (see asset identification).

How do deposit balances reconcile across venues and return points?

Each venue and each return point carries its own running balance in Rotion: deposits taken, refunds paid, assets outstanding. Those balances update on every scan, so reconciliation is automatic and continuous instead of a monthly spreadsheet exercise where someone chases the difference between counted trays and counted euros.

For scheme operators this changes settlement from an argument into a report. A retailer's balance, a return point's balance, and the fleet owner's totals all come from the same scan history, so all parties settle from one shared record. The same record also carries rental and deposit billing between parties: what a partner owes for held assets, deposits, or rented containers is read from scans, not negotiated from memory. Which party sees which balances is governed by role-based access, described in roles and partners.

How does REPASYS run a deposit scheme on Rotion?

REPASYS runs a deposit scheme for reusable fresh-food packaging in retail on Rotion, and it is the worked example for how the pieces fit together at production scale across multiple retail partners.

REPASYS scheme factValue
Deposit per tray0.30 EUR
Retailers participating6
Packages in use100.000
Pilot durationSix months
Return handling timeSub-ten-second returns

Every tray carries its own identity, the 0.30 EUR deposit follows each tray from issue at the retailer to refund at return, and balances reconcile per store automatically. Sub-ten-second returns are what make the scheme viable at the checkout and the service desk: if returning a tray were slow, the deposit would become a queue, not an incentive.

Why not manage deposits in a spreadsheet?

A spreadsheet records what someone typed; Rotion records what was scanned. With deposits, that gap is money: unreturned assets that were never charged, refunds paid twice, venue balances that drift until nobody trusts them. Scan-based deposit management ties every euro of deposit to a named asset and a named handover, so the books and the fleet cannot disagree.

Unreturned deposits are only part of the cost. Estimate what asset loss costs your fleet per year:

What does asset loss cost you per year?

Assets lost per year

800

Annual replacement spend

€9,600

Capital in the fleet

€120,000

Your numbers, not ours: the calculation is fleet size × loss rate × replacement cost.

Designing a deposit scheme?

We walk through deposit amounts, return points, and settlement, using a scheme that runs in production.
Book a demo

On this page