A timesheet approval workflow is not complete when a manager clicks Approve.
That action answers one question: does this person confirm the work represented by this version? It does not prove that the entries passed policy checks, that payroll accepted the payable-time projection, that billing accepted the commercial classification, that both destinations reconciled the same current version, or that a later correction preserved the original record.
In week 13 of our category series, we used SwarmCraft to structure a 68-task Timesheet Approval project and complete the resulting customer-owned application. The operation replaces the authoritative time record inside its agreed boundary: capture evidence, time entries, versions, validation, purpose-specific review, lock, correction, projection, delivery, reconciliation, retention state, access decisions and audit history.
Payroll calculation, tax, payment, invoicing, accounting, HR, scheduling, project and customer records remain explicit adjacent boundaries. They are not pulled into the operation merely because they consume or explain time.
If you are choosing the wider category first, start with Best time tracking software. If several subscriptions already touch the same weekly record, read Why time-tracking subscriptions pile up when approvals stay messy.
The week looked closed, but it was not
The case study begins with an apparently healthy portfolio. The worker has submitted a version. Manager, payroll and finance or billing review purposes are approved. A conventional approval dashboard could colour the week green and move on.
The authoritative operation refuses that shortcut.
It distinguishes Open, Submitted, Under review, Approved, Locked and Closed. It also tracks projection, delivery, acknowledgement, retry, reconciliation, dispute, source freshness, correction and retention as separate obligations. An approved week stays visibly open while any required work remains.
That is the story spine for the entire product:
- deterministic validation prevents a flawed submission from advancing;
- several people approve for different purposes;
- approval still does not close the week;
- payroll and billing receive separate minimum projections;
- one downstream path succeeds while the other remains partial;
- later evidence requires an additive correction rather than an overwrite;
- the original version, approvals and delivery outcomes remain reproducible; and
- the week closes only when every required path matches the current authoritative version.
Why the record boundary matters globally
Time records can support pay, minimum-wage, billing and employment obligations, but the applicable rules vary by jurisdiction, worker and purpose. The software therefore cannot replace legal interpretation with one universal retention switch.
Official guidance illustrates the shared design pressure without pretending the requirements are identical:
- Australia's Fair Work Ombudsman says covered time and wage records generally need to be retained for seven years and cannot be changed except to correct an error.
- The US Department of Labor's FLSA recordkeeping guidance requires covered employers to keep accurate identifying, hours-worked and wage information, while allowing different timekeeping methods when the result is complete and accurate.
- The UK's minimum-wage employer guidance requires records sufficient to show compliance and describes the relevant retention period.
Those examples support an architectural conclusion, not a claim of universal compliance: an owned time-record operation needs explicit versions, correction history, access, retention, reproducibility and accountable authority. Customer-specific legal and operating requirements still need to be configured and assured.
Project stats
| Measure | Week 13 evidence |
|---|---|
| SwarmCraft project | Timesheet Approval |
| Project scope | 68 tasks, with all 68 represented by task-specific completion commits |
| Final board state | 68 Done, zero remaining in Todo, Doing, Checking or Reviewing |
| Target repository | 406 tracked files and 43,229 non-blank lines across source, configuration and documentation formats |
| Database | PostgreSQL with 11 versioned Flyway migrations |
| Test surface | 63 unit, integration and system test/spec files |
| Maintained browser evidence | Nine deterministic workflow screenshots |
| Verification | 157 API tests, 63 web tests and 15 infrastructure checks passed; targeted downstream and clean full-stack audit journeys also passed |
| Delivery target | Customer-managed cloud environment |
The repository history is the strongest completion evidence. A final recovery pass synchronized the completed board after a long-running driver hiccup, but it did not retain trustworthy aggregate build-agent request, token or elapsed-time totals. We therefore report the completed task history and verification evidence without inventing missing telemetry.
The authoritative timesheet operation we built
The application centres one weekly time-record aggregate and its complete operating lifecycle.
Raw timer, manual, calendar, import and approved-project signals enter as provenance-bearing evidence. They do not become worked time merely because they exist. A worker assembles a version; deterministic rules check it; authorised reviewers make purpose-specific decisions against that exact version; the server locks the accepted current version; and minimum payroll and billing projections leave through replay-safe delivery records.
The operation owns:
- weekly periods, cut-offs and closure obligations;
- source evidence, provenance, freshness and replay identity;
- time entries, explanations and immutable record versions;
- deterministic validation outcomes;
- manager, payroll and finance or billing review decisions;
- lock and supersession history;
- post-lock corrections and field-level comparisons;
- payroll and billing projections, attempts, responses and retries;
- reconciliation, disputes, stale-source review and retention state; and
- organisation-scoped access decisions and append-only audit events.
Provider-neutral contracts keep retained systems outside that boundary. HR or identity can supply bounded worker facts. Project systems can supply permitted coding. Payroll and billing destinations can receive minimum approved projections. None of those responses silently changes the authoritative time record.
Who does what
| Role | Responsibility in the owned operation |
|---|---|
| Worker | Reviews their own evidence, corrects validation failures, explains exceptions, submits a version and opens an authorised correction without seeing another worker's private record |
| Manager | Confirms the work represented by an exact immutable version within an assigned authority boundary |
| Time-operations administrator | Inspects the end-to-end lifecycle, owns exceptions and lock progression, and keeps approval separate from closure |
| Payroll reviewer | Decides whether the version is acceptable for the payroll-facing purpose and reviews payable-time delivery independently |
| Finance or billing reviewer | Decides whether the version is acceptable for billing and reviews commercial classification independently |
| Audit and compliance reviewer | Reads retained versions, decisions, access outcomes and operational history without gaining edit or approval authority |
| Organisation administrator | Manages organisation-level configuration without automatically receiving access to worker time records |
Navigation makes those work areas understandable. The API remains authoritative: every protected read and mutation reconstructs the principal, organisation, permission and resource boundary server-side.
Timesheet approval workflow steps
The implemented timesheet approval process follows a governed sequence:
- Configure the weekly period, time zone, cut-off, working pattern, policy version, permitted codes, review purposes, correction authority and retention rules.
- Admit bounded worker, project, schedule and source facts through provider-neutral contracts with stable references and freshness evidence.
- Capture timer, manual, calendar, import or approved-project signals as evidence rather than inferred truth.
- Create an immutable weekly record version and preserve its provenance.
- Let the worker add or correct entries and explanations within their own authorised scope.
- Run deterministic checks for overlaps, gaps, duplicate evidence, period boundaries, durations, codes, cut-offs and required explanations.
- Reject an invalid submission without erasing the draft or manufacturing time.
- Route the accepted version to manager, payroll and finance or billing review purposes independently.
- Record every disposition against the exact immutable version and retain the reason.
- Lock only the approved current version in one transaction.
- Derive minimum payable and billable projections from that locked version.
- Persist replay-safe outbound records before attempting delivery.
- Keep acknowledgement, rejection, retry and reconciliation separate for payroll and billing.
- When material evidence changes, create a linked successor with an explicit correction reason and retain the original lock and decisions.
- Revalidate, collect the reviews required for the changed version, deliver the appropriate delta and close only when every obligation is complete.
These timesheet approval workflow steps form a reusable timesheet approval workflow template: evidence is not time, submission is not approval, approval is not lock, delivery is not reconciliation, and correction is not overwrite.
Validation gives the worker a recovery path
The worker experience does more than display a red banner. It explains three distinct problems in the deterministic fixture: overlapping entries, a missing explanation and duplicated source evidence. Each condition identifies the affected records, the policy version and the next corrective action.
The failed submission keeps the current version and entries unchanged. That matters for both usability and authority: the worker can recover without losing their draft, while the system refuses to treat incomplete evidence as accepted time.
Approved is a stage, not a synonym for closed
Once all required review purposes approve, the week still remains Open. The screen names what is missing: lock, projection, delivery and reconciliation.
The manager, payroll reviewer and finance or billing reviewer do not share one generic approval flag. Their decisions remain separate because they answer different questions. Time operations can inspect the combined state, but that role cannot collapse distinct authorities into one convenient green status.
Payroll success does not hide a billing failure
After lock, the server derives separate payroll and billing projections and records their transport lifecycle independently. In the partial-failure fixture, payroll is acknowledged but not yet reconciled; billing is acknowledged with only a partial downstream result and requires retry.
The authoritative record remains unchanged. Destination responses are evidence about delivery, not permission for an external system to rewrite accepted time. The week stays open and the next operational obligation remains visible.
That separation is central to useful timesheet approval automation. A webhook receipt proves transport. A successful import proves more. Reconciliation proves that the destination result matches the intended current version. Treating those as the same state creates false closure.
A post-lock correction creates a new version
Later evidence sometimes changes the correct coding without changing the fact that the earlier version was genuinely reviewed and locked. Silent edits would make it impossible to reproduce what payroll, billing or a reviewer saw at the time.
The worker therefore starts a correction as a new version. The product states explicitly that version 7 remains locked with its approvals and history while version 8 must pass validation and review before it can replace the accepted record.
The PostgreSQL boundary enforces this design. Append-only triggers reject mutation of locked and superseded history. The correction records its actor, reason, provenance, field-level comparison and supersession link, then produces only the downstream consequence appropriate to the changed version.
Audit history preserves the decision chain
The audit view makes the corrected record current without hiding its predecessor. It shows version 2 as authoritative, version 1 as superseded, separate retained review decisions, independent delivery and reconciliation outcomes, and the ordered operational trail.
The browser image demonstrates readable history. The clean full-stack system test supplies the stronger proof behind it: the fixture is loaded through PostgreSQL, read through the public API and browser, checked against role scope, subjected to a real access denial, and tested against attempted mutation of append-only records.
Closure is earned by the whole operation
The final state is deliberately uneventful. The current version is locked, required reviews are complete, both downstream paths have been delivered and reconciled, no dispute or stale-source obligation remains, and the retained timeline explains how the operation arrived there.
Only then does the authoritative week become Closed.
What the custom timesheet approval workflow includes
| Capability | Week 13 implementation | Production work still required |
|---|---|---|
| Capture and provenance | Provider-neutral manual, timer, calendar, import and approved-project evidence with stable identity, freshness and replay handling | Connect and certify customer sources; minimise fields and define source service levels |
| Authoritative record | Weekly aggregate, immutable versions, explanations, supersession and current-version selection | Confirm customer policy, migration inventory, continuity window and historical import rules |
| Validation | Deterministic overlaps, gaps, durations, time zones, codes, evidence, cut-offs and explanation checks | Encode jurisdiction-, agreement- and organisation-specific rules with accountable review |
| Review and lock | Separate manager, payroll and finance or billing decisions plus transactional locking | Confirm delegations, segregation of duties, escalation and operational service levels |
| Correction | Additive post-lock successor, retained original history and field-level comparison | Define material-change thresholds, selective reapproval and cut-off handling |
| Delivery | Minimum payroll and billing projections, transactional outbox, retries, dead-letter and response evidence | Implement and certify real destination adapters and contracts |
| Reconciliation | Independent destination state, mismatch handling and closure obligations | Agree reconciliation tolerances, ownership, recovery and period-close procedures |
| Security and audit | Opaque verified-session boundary, server-side authorisation, safe denials and append-only security events | Configure production identity, access reviews, threat modelling and penetration testing |
| Operations | Health and readiness checks, containers, Kubernetes baseline, backup, restore, cutover and rollback runbooks | Deploy, rehearse recovery, load test and gather live operating evidence |
Technology implemented
| Layer | Week 13 implementation |
|---|---|
| Browser application | React, TypeScript and Vite with worker self-service, role-specific review, operations and audit surfaces |
| API | Node.js and TypeScript modular monolith with server-side workflow authority and provider-neutral ports |
| Persistence | PostgreSQL 16 with 11 Flyway migrations and database-enforced append-only history |
| Source boundary | Manual, timer, calendar, project-evidence and temporary Harvest migration adapters |
| Destination boundary | Payroll and billing contracts with replay keys, acknowledgements, retries, dead-letter outcomes and reconciliation callbacks |
| Background reliability | Transactional outbox and durable delivery lifecycle records |
| Security | Verified-session port, scoped roles and permissions, safe route denial and persisted security audit events |
| Delivery | pnpm monorepo, Docker Compose, non-root production images and customer-managed Kubernetes manifests |
| Verification | Vitest, Node infrastructure tests, isolated PostgreSQL migration checks and Playwright browser/system tests |
The current repository does not configure a production identity provider, live payroll or billing adapters, or an AI provider. Those are explicit go-live dependencies, not capabilities implied by the architecture.
AI is optional; authority is not
The approved scenario allowed AI to summarise conflicting evidence, draft exception explanations and suggest only permitted mappings. The implementation made a responsible narrower choice: no AI provider is configured or assumed, and the accepted-time projections contain no AI proposal fields.
The complete operation still works.
Deterministic rules validate the record. People decide for their authorised purposes. Server-side software locks, projects, delivers, reconciles and remembers. If AI is added later, it can prepare cited summaries or suggestions inside that boundary; it cannot create time, decide payability or billability, approve, lock, correct or close a week.
That is a useful lesson for AI-built workflow software. AI can accelerate construction and later assist the operation without becoming the source of truth inside the product.
What the browser evidence proves
The maintained browser and full-stack evidence covers:
- worker recovery from overlaps, missing explanations and duplicate evidence;
- an apparently approved week remaining open;
- immutable lock and current-version rules;
- separate payroll and billing delivery states;
- rejected, partial, retrying and unreconciled outcomes;
- additive post-lock correction and retained predecessors;
- role-specific allowed and denied access;
- append-only audit and operational history; and
- closure only after every required downstream and blocker check completes.
The fixtures are fictional and privacy-safe. They prove the implemented operation and its security boundaries; they do not prove a customer's labour, payroll, tax, privacy, billing or retention compliance.
How SwarmCraft structured the build
SwarmCraft created a 68-task Timesheet Approval project. The plan moved from product boundary and repository foundations through identity, immutable records, validation, purpose-specific decisions, locking, projections, corrections, provider-neutral integrations, browser surfaces, system proof, deployment and migration operations.
The board screenshot shows the initial plan before implementation began. The target repository now preserves one completion commit for every task, followed by verification and maintained-evidence work. A long-running driver recovery synchronized the completed board successfully; the repository and tests, rather than incomplete aggregate runner telemetry, are the evidence for the finished application.
The build sequence matters. Record authority, history and permissions were not retrofitted onto a timer screen. They were established before the delivery and reporting surfaces that depend on them.
When time-tracking software is enough
Keep an off-the-shelf time-tracking product when its capture methods, policies, approvals, integrations, reporting and operating controls already fit the organisation. A maintained vendor product may be the safer answer when the organisation needs broad mobile or kiosk capture, workforce scheduling, location features, global rule content, a large integration catalogue or vendor-backed support.
Consider an owned authoritative operation when the difficult part is specific to how the organisation establishes and changes time:
- several evidence sources must remain distinguishable from accepted time;
- worked, payable and billable purposes require separate authority;
- a manager-approved week must not hide unresolved delivery;
- corrections must preserve exactly what was previously approved and exported;
- payroll and billing need different projections and recovery paths;
- retained records must reproduce policy, evidence, actor, reason and outcome; or
- the incumbent time platform owns a critical record but does not fit the operation around it.
This is not a requirement to reproduce every feature in Harvest or another time platform. It is a decision about whether the complete authoritative time-record lifecycle is coherent, important and supportable enough to own. The Harvest alternatives page examines that boundary from the switching side.
What operator-builders should take from week 13
To automate timesheet approvals, begin with the record lifecycle rather than the approval button:
- Define the authoritative time record and every adjacent record explicitly.
- Keep capture evidence separate from accepted worked time.
- Make every submitted, rejected, locked, corrected and superseded version reproducible.
- Give each review purpose its own authority and retained decision.
- Lock only the approved current version.
- Project minimum fields to each destination through a replay-safe outbox.
- Distinguish delivery, acknowledgement and reconciliation.
- Keep partial success visibly open with an owner and recovery action.
- Correct by addition and supersession, never silent overwrite.
- Let AI prepare bounded suggestions only after the deterministic and human authority model is sound.
The result is more than an employee timesheet workflow or a reminder sequence. It is an owned business system of record for the agreed time boundary: one that can explain what was accepted, what changed, who had authority, which external systems received it and whether the current version truly reconciled.
Use Deep Discovery for an authoritative time-record replacement
Replacing a time-record system crosses worker data, policy, migration, continuity, access, payroll and billing boundaries. Deep Discovery is the appropriate route when those sources, controls and record responsibilities need structured investigation. It is currently available through a limited account-enabled rollout.
The goal is not another approval inbox. It is a complete, governed time-record operation that earns the right to say a week is closed.
