Preparing payroll involves more than multiplying hours by a rate. Someone has to check that entries belong to the right person, have the right approval status and fall within the relevant period. Late submissions and missing rates still need a decision. A useful automation makes that work visible instead of hiding it behind a clean-looking spreadsheet.
Spiritus’ audited-timesheet project documents a workflow built around three familiar tools: Google Sheets for the records, n8n for processing, and Slack for operational visibility. The result is a design for preparing a payroll CSV alongside an audit record, with the final payment review kept with a person.
Start with separate records and clear ownership
The architecture separates timesheet entries, hourly rates and audit events into three sheets. That distinction matters: a contributor records work, the responsible team maintains rates, and the audit log records exceptions and changes relevant to review.
The operating instructions describe approving timesheets before processing. This gives the automation an explicit input state. It also makes the process owner’s responsibility clear: software can process an approved record, but it does not decide whether the underlying work should have been approved.
Connect the records without losing the exceptions
The documented n8n workflow normalises email and date fields, joins entries to rate records and calculates line-item totals. Cutoff logic distinguishes on-time and late submissions. Its outputs include payroll-ready CSV data and audit events; Slack is the visibility channel for relevant operational alerts and technical issues.
Consider an illustrative example: the same email address appears with different capitalisation in two sheets. A join that treats those strings differently may fail to find the correct rate. Normalising the identifier is a small technical step with a direct operational purpose. It belongs in a test, alongside the expected treatment of a genuinely missing rate.
Prepare a review; do not silently release a payment
The monthly-cycle runbook ends with a director receiving the CSV and audit log for payment review. Preparing the records and authorising payment are separate responsibilities.
That boundary is also useful when something goes wrong. A late entry may be legitimate, but accepting it is an operational decision. A wrong total needs investigation, not an automatic retry until a plausible number appears. The maintenance guide assigns ownership for process rules, automation maintenance and the operating cycle.
Test the cases that can produce a convincing wrong answer
The repository’s QA plan covers numeric totals, missing or incorrectly joined rates, case differences in email addresses, cutoff handling and Slack exception visibility. These are documented test scenarios, not evidence that every test has passed.
Before describing a deployment as proven, the next evidence should include completed results for the actual workflow version, representative exception cases and confirmation that the intended reviewers receive and can act on the outputs. A baseline and follow-up time measurement would be needed before claiming hours saved.
What this build illustrates
This is a workflow-automation example: explicit records, joins, calculations, checks and a human review. The documented architecture does not establish an AI model as necessary for the payroll calculations. The choice of technology should follow the task.
For another organisation, the starting conversation is equally concrete: where do the records arrive, who approves them, which exceptions matter, and what must a reviewer receive? Answer those questions before expanding the scope.
Explore Spiritus workflow automation or discuss one recurring process.
Sources and review notes
This article describes the documented workflow and operating instructions. The linked QA plan describes test scenarios; it is not a report of completed results.