DATIMORE · WEB-010
Pre-send checklist for a recurring report
Plan one report that arrives ready for the review. Print or save this page and record an owner, evidence and pass/hold decision for each check. This is a planning template, not an automated control.
Synthetic demonstration. All teams, counts and schedules below are invented. No client outcome or measured saving is claimed.
Agree the reporting routine
Example: weekly completed-request summary for Teams A, B and C. Each request belongs to one team and is counted once, when completed. All files cover 21–27 September 2026 inclusive. Expected files are approved by their team owners and ready by Monday 28 September, 08:30 Asia/Riyadh; intended delivery is 09:00 in the same time zone. Adapt the dates, rules and recipients to your work.
Owner / deputy: ____________________
Sources / reporting period / time zone: ____________________
Delivery deadline / authorized recipients: ____________________
One example: hold, correct, check again
| Starting input | Decision |
|---|---|
| Team A: 20; Team B: 15. Both approved for 21–27 September. Team C: 18 for 14–20 September. | HOLD. Team C is from the wrong week. Do not publish a combined total. Notify the report owner with the source and reason. |
| Team C supplies an approved replacement: 17 for 21–27 September. Recheck all three files and the output. | 52 = 20 + 15 + 17. Eligible to send only if all remaining checks below pass. The replacement supersedes the old file; it is not an additional input. |
Before every send
- □ The expected sources are all present, available and approved for the agreed period. A missing source is not a zero.
- □ The files cover the same period and the agreed cut-off. A recent download of an old file is still old data.
- □ Each request is counted once under the agreed definition. Duplicate files or records are held for correction.
- □ The prepared report matches the checked inputs, uses the right filters and labels its period and preparation time.
- □ Unusual totals have been reviewed against an agreed reference. A large change needs explanation, not automatic removal.
- □ The recipient list is current and authorized for this report. Check the actual attachment or link and access; do not assume a hidden dashboard column is hidden in an export.
- □ Every required business approval is recorded. Missing approval, unavailable checks or unexplained differences mean HOLD.
- □ The same report version has not already been sent. Recheck the final version and recipients immediately before sending.
- □ The owner and deputy know how to handle a hold. If the deadline is at risk, send a delay notice without sensitive figures; never silently replace current data with last week’s report.
- □ Record the reporting period, source versions, check results, approver, final report version, recipients and send status. If delivery is uncertain, reconcile the mail or destination record before resending. A successful send request does not prove it was read.
Evidence / reason: ____________________
Reviewer / date: ____________________
Correction owner / next update time: ____________________
Test the routine before relying on it
Try the correct set (52), an old-period source (hold), a missing source (hold), a duplicate (hold), an unauthorized recipient (hold), and a repeat send of the same version (do not send again). If a send times out, mark delivery uncertain and check what happened before retrying. After a correction, repeat all checks on the final version. Record the actual result and reviewer for each trial.
Limits: these controls detect the problems you define; they cannot establish that every source record is true. Keep human review for interpretation, exceptions and changes to report definitions. A static checklist does not implement access control, stop delivery or confirm receipt.