Why RVM daily totals can differ around midnight

Before investigating a mismatch between a reverse vending machine (RVM) counter and a daily report, check which time each report uses. A return can happen before midnight and reach the reporting service after midnight. The two reports may also apply different time zones or use different rules for closing the day.

Which timestamp belongs to a return?

Keep the time of the accepted-item event and the time the server received it in separate fields. Link both to the same event identifier so a delayed message can be reconciled with the original return. RFC 3339 provides a timestamp format with an explicit UTC offset, such as 2026-11-10T23:59:00+08:00. Store a qualified timestamp and document the time zone used to group records in the site’s daily report.

In this example, an acceptance-time report places the return on November 10. A receipt-time report places it on November 11. To explain the difference, compare the same event IDs across both dates and retain both timestamps. This helps the operator distinguish a delayed upload from a missing return.

How should a site define its reporting day?

Agree on the report’s time zone, start boundary and end boundary before comparing totals. For a midnight-to-midnight report, include the start and exclude the next midnight so a boundary event belongs to one day. If the site uses a trading day that ends after midnight, label that rule on the report.

For sites with seasonal clock changes, use the reporting system’s named time zone and its rules for the event date. Keep the recorded offset with the original event. If the equipment clock is known to be unreliable, flag the affected records for review and apply the agreed correction process with an audit note.

What happens when a late event arrives?

Show when the report was generated and whether it can still change. A provisional report can include a count of events received after its first generation. If the programme allows corrections to a closed period, retain the earlier report and link the revised version to its reason. When a message is delivered again, match its event identifier before updating the total.

Use the offline event recovery guide to plan delayed delivery and retries. The operations reporting guide helps define the other measures that should accompany daily counts.