No you don't have to go into each machine, since the 'main' reporting policy is 'No later than 24 hours after oldest completion'. The second rule is probably 'when work is fetched/needed, report at same time'. There are in total about 14 conditional tests which make RtR go up [see FAQs].

Result uploading and Ready to Report [the final confirmation], are 2 data streams. The first goes to the upload server that does not touch the key scheduler. The RtR does touch the [heavily loaded] scheduler, the same one that administers the work assignment and validation states [more copies to send or stop copying]. The more RtR are accumulated into a single report, the more efficient for the system.

Hi Jean,

Yes that works when you probably have set a network schedule. So, if your client is set to stop networking at 00:05 till whenever in the morning, the client will start clearing the RtR from 30 minutes before going off-line and any that complete up to 00:05 when network is suspended.

edit: And how to force an end of day reporting, yet remain online but for 1 minute is for instance set network schedule from 00:00 to 00:01. Then anything will clear from 23:3'0 to 00:00 and your client is only 1 minute offline.

Oh yes, that's it: I have set a network blackout between 23:55 and 00:10 in order to avoid/limit spills in my daily stats (too bad there is not a UTC option like in KAlarm, I have to think of adjusting it twice a year ).
Never thought that it could be linked to this spontaneous reporting. Although I often wondered why you never mentioned this "feature" to people worried about their client not reporting tasks...

Yep, it's condition #7 of your BOINC: "Ready To Report" tasks status and how to understand them FAQ.

But I never thought of checking a condition which I did not suspect and which was fine for me.
Although I confess that my own initial interpretation would probably cause a tremendous surge to the servers if it had been true.