Reporting and operations
Report automation: handle late data and corrected weekly reports
Your Monday report reaches the team. An hour later, a completed job appears in the source sheet and someone corrects an amount. The figures in the email and the figures on screen now disagree. A reporting workflow needs a clear way to handle that change.
Key takeaways
The time a job happened determines its reporting period; the time you received it explains lateness.
A source retrieved recently can still contain incomplete data.
A report revision keeps the same period and adds a visible change record.
A resend of the same version and a correction to that version need different handling.
Keep the reporting period, data cutoff and report revision separate. Save the records behind each sent version. When late or corrected data changes a closed period, compare it with the saved version and route a revision or an adjustment for review. Show what changed and preserve the first report.
- Read a named period
- Check source readiness
- Save the first snapshot
- Review and send
- Compare later changes
- Approve a revision or adjustment
Separate the week you measure from the moment you close it
A reporting period selects the business activity you measure. A data cutoff states how much information was available when you produced the report. Keep both in the report record, together with the business timezone. Readers can then distinguish a new week from a new version of last week's figures.
For a weekly completed-work report, define the window as Monday at 00:00 through the following Monday at 00:00, excluding the ending instant. Use the completed-at timestamp to select jobs. A job completed exactly at the ending instant belongs to the next week. Store the explicit boundaries so a recovery run uses the intended period.
Suppose the team prepares the report at 08:00 and sends it after review at 09:00. Record 08:00 as the snapshot cutoff. A qualifying job imported at 10:00 is late for that snapshot even if it was completed on Sunday. Changing the send time alone will not explain which data the calculation included.
Choose an initial cutoff from the source's actual update pattern and the decision the report supports. A Monday planning meeting may accept a provisional report. Another team may wait for required sources. Write down that choice before scheduling the workflow.
| Field | Meaning |
|---|---|
| period_start / period_end | The business activity window, with an exclusive end |
| business_timezone | The timezone used to interpret that window |
| event_at | When the qualifying business event happened |
| received_at | When the workflow received the record |
| snapshot_at | When the saved report input was captured |
| revision | Which version of the same period the reader is viewing |
Check whether the source is ready to support the report
A successful read tells you the connection worked. It does not establish that the source contains every relevant record. Capture the source's available update or processing information separately from your retrieval time. If the source gives no reliable completion signal, make that limitation part of the reporting rule.
Google Analytics describes varying processing intervals and says data can change during processing. A recent API response can therefore describe a period that is still changing. Use the platform's documented freshness behaviour when setting your cutoff; an arbitrary waiting period cannot guarantee completeness.
Give each required source a readiness rule. For an internal job sheet, the operations owner might confirm that all completed jobs for the period have been entered. For a delayed analytics source, the report may use a later release time or an explicitly provisional metric. These are different checks and should stay visible in the workflow configuration.
If a required source is unavailable, hold the final report and notify the reporting owner. If a partial report is useful, identify the pending source next to the affected metric. Leave the missing metric unavailable rather than replacing it with zero.
Preserve the records behind each sent version
Save the included record IDs, source versions and calculation inputs with the report. Keep the metric definitions alongside them. A saved total alone cannot show whether a correction came from a late job, a changed amount or a different inclusion rule.
For a small Google Sheets workflow, create a values-only snapshot in a restricted report archive or save an export in an approved private location. Retain the exact input values used by the calculation. A link to a live sheet remains useful, but the live values can change after the email is sent.
The Google Sheets values API supports reading one or more explicit ranges and choosing how their values are represented. Agree the numeric and date handling in your reader. Formatted currency strings and spreadsheet date serials need deliberate parsing before you compare revisions.
For sources that change during extraction, use a source-supported snapshot or export, or coordinate a controlled capture with the owner. Reconcile the resulting records. Do not assume separate reads from several tools happened at one atomic instant. Give the saved input a stable identifier and prevent routine updates from replacing it.
Keep each report version as a separate record. Restrict who can alter the archive and record deliberate corrections to it. Store source records privately; the email normally needs totals, an explanation of exceptions and an access-controlled details link.
Reconcile a correction before creating another report
Worked example: a service team reports approved fees on jobs completed during 5–11 October 2026 in Asia/Karachi. Revision 1 uses an 08:00 snapshot on 12 October. Jobs A, B and C have fees of USD 120, USD 180 and USD 200. The report contains three completed jobs and USD 500.
At 10:00, job D arrives with a Sunday completion time and a fee of USD 60. The owner also corrects job B's fee from USD 180 to USD 150. Both changes affect the original reporting period. They produce four jobs and USD 530: the original USD 500, plus USD 60, minus USD 30.
Match the old and new input by persistent job ID. Job D is an added record. Job B is a changed record whose earlier amount is replaced in the comparison. Counting both versions of B would inflate the result. A repeated import of the same job version should produce no further change.
Save the comparison as a change record with an owner and a reason. Let the reviewer inspect the added and changed rows before releasing revision 2. Use the same metric definitions, currency and period boundaries for both revisions.
| Item | Revision 1 | Revision 2 | Change |
|---|---|---|---|
| Job A | USD 120 | USD 120 | USD 0 |
| Job B | USD 180 | USD 150 | USD -30; corrected fee |
| Job C | USD 200 | USD 200 | USD 0 |
| Job D | Not in snapshot | USD 60 | USD +60; late record |
| Completed jobs | 3 | 4 | +1 |
| Approved fee subtotal | USD 500 | USD 530 | USD +30 |
Choose how the team will communicate a changed period
Use a revision when readers need a corrected view of the same period. Put the revision number in the subject and report heading. State that it replaces the earlier version for that period, then show the old total, new total and reason. Keep the original version in the archive.
An adjustment in the next report can work when the team has agreed to keep earlier reports fixed. Show it as a separate prior-period adjustment, with the affected period and original report reference. Do not mix that adjustment into this week's completed-work total and then count the late job again.
Define which changes require a correction notice. A wrong recipient, missing required source or changed figure that affects an operational decision may need immediate review. Smaller changes may follow an agreed threshold. The reporting owner should set the threshold for this report; a universal percentage will not fit every business.
Give changes to metric definitions their own explanation. Switching from jobs completed to invoices paid changes what the report measures. A revision number cannot make those totals comparable. Where needed, recalculate the comparison period under the new definition and retain the earlier definition with its reports.
| Policy | Recipient sees | Record to retain |
|---|---|---|
| Revised report | Same period, a new revision and a change summary | Both snapshots and reviewer approval |
| Next-period adjustment | Current activity plus a separate prior-period adjustment | Affected period, source change and original report |
| Hold for review | A named pending issue and responsible owner | Failure or readiness evidence; no final send |
Keep a correction distinct from a retry
Use a report identity made from the report type, reporting period and revision. A second execution for an already-sent revision should stop at the existing send record. A newly approved correction receives a new revision and its own send record.
Keep the original period as an explicit input to a recovery run. In n8n, the Schedule Trigger uses the workflow timezone when one is configured, otherwise the instance timezone. Saving and publishing the workflow is required for the schedule to run. Check your installed version's missed-execution behaviour rather than assuming a delayed run will recreate the intended week's report.
Reserve the report identity in a shared durable log before sending. Coordinate simultaneous runs so two executions cannot both reserve the same revision. Apps Script's LockService can protect a participating section of script code after a lock is acquired. It does not freeze a spreadsheet for human editors or coordinate every external writer.
Keep data review and delivery review separate. If a send times out after the provider may have accepted it, mark the outcome uncertain and reconcile it before another send. A second email labelled revision 2 is still a duplicate if the first revision-2 send already succeeded.
Write the approved input snapshot, revision and recipient list into the delivery record. Save the provider's response when available. Acceptance of a send request is different from confirmed receipt or reading. Our workflow error recovery article covers the broader recovery process.
Test the reporting rule with records that arrive out of order
Use synthetic records and a test inbox before the workflow sends to the normal recipients. Reconcile each expected result manually. Test both the numbers and the decision to send, hold or review.
Start with the three-job USD 500 example, then apply the late job and corrected fee. The approved second revision should contain four jobs and USD 530. Run the same imports again: the comparison should remain unchanged and the already-sent revision should not generate another email.
Test a record exactly at the period end, a correction that arrives during review and a correction that arrives after sending. Check that the reviewed version is the version sent. If new data arrives after approval, keep it out of the approved snapshot and queue a separate review.
Simulate a failed source read and an uncertain send. Neither should silently become a zero-activity report or a new revision. Record which person can resolve each case and how they select the historical period.
Once the pilot passes, document the cutoff, source readiness rule and correction policy next to the report configuration. The person taking over the workflow should be able to find a sent version, explain its total and prepare a controlled correction.
- A late record belongs to the period of its business event.
- An unchanged re-import leaves the totals and revision unchanged.
- A changed record replaces its previous version in the comparison.
- A boundary record appears in one reporting period.
- A failed read holds the final report.
- An already-sent revision is not sent twice.
- A post-approval change requires a new review.
- An uncertain send is reconciled before retrying.
Agree the correction rule before connecting the next source
Write a short correction brief for one existing report. Name its reader and the decision it supports. Identify who can approve a changed total and who can alter the source data. Then choose the cutoff and the way revisions will reach the team.
Bring that brief, a redacted sample report and the tools you use to a reporting automation discussion. We can plan how the source, saved versions, reviewer and delivery record fit together. Keep the original report format wherever it already works for your team.
For the first scheduled email, read our Google Sheets reporting walkthrough. Use the weekly report data checks for metric definitions and source validation. This correction process adds the rules needed after a period has been reported.
Your ready-to-use checklist
0 of 10 checked
Make the next step clear.
Weekly report correction brief
Free templateSources and notes
Sources checked on October 19, 2026.
- Google Analytics: Data freshness
How Google Analytics collects, processes and updates report data.
- Google Sheets API: spreadsheets.values.batchGet
Reading specified spreadsheet ranges and choosing value and date representations.
- n8n: Schedule Trigger
Timezone settings, scheduled workflow publication and missed-execution options.
- Google Apps Script: LockService
Coordinating participating Apps Script executions with acquired locks.
