Timesheet app with overtime rules: weekly submit and approvals

What this timesheet app needs to solve

A timesheet app with overtime rules isn’t really about tracking hours. It’s about preventing confusion, reducing pay mistakes, and giving everyone the same predictable process.

When timesheets live in spreadsheets or chat messages, small problems pile up fast. People use different templates, forget to log breaks, or edit entries later without anyone noticing. Managers spend their time chasing missing hours instead of checking whether the week looks reasonable. By payroll day, you’re piecing together partial info and hoping it matches what employees remember.

Overtime is where disputes start. If the rule isn’t consistent (or isn’t written in a way people can follow), two employees working the same schedule can end up paid differently. Even when everyone is acting in good faith, unclear rules create rework: recalculations, retroactive edits, and awkward conversations.

Approvals are the safety gate before money moves. A manager approval step confirms the week is complete, the job or project codes (if you use them) make sense, and overtime is justified. It also creates a clear “this is final” moment, so payroll isn’t pulling numbers from an in-progress draft.

Weekly submission should become one simple habit: everyone works within a defined workweek (for example, Mon-Sun), submits by a clear cutoff time (for example, Monday 10:00 AM), and gets reminders before the deadline. After submission, edits should be blocked or require re-approval, and the status should be obvious (Draft, Submitted, Approved, Rejected).

Core requirements and boundaries

This kind of app only works if everyone agrees on the basics up front: when people submit, who can change what, and what counts as overtime. If you don’t set boundaries early, the app turns into a weekly argument.

Start with the submission rhythm. Weekly submission keeps things simple for most teams: people can enter time during the week, then submit once. The key boundary is whether you allow edits after submission. A common rule is that entries stay editable until the weekly Submit button is pressed.

Overtime rules have to be unambiguous. Decide whether overtime is triggered by daily limits (for example, over 8 hours in a day), weekly limits (over 40 hours in a week), or both. If both apply, state which one wins when they overlap so you don’t double-count overtime.

Manager approval should stay a tight loop so it’s quick to use: approve (hours become final), request changes (employee edits and resubmits), or reject (employee fixes and resubmits).

Once approved, lock the period. Locking prevents last-minute edits and keeps payroll consistent. If corrections are needed, use an “unlock with reason” action that records who unlocked it and why.

Payroll export should include approved hours only. Make that a hard boundary: anything unapproved stays out of exports, even if it looks complete.

Data you should capture (without overcomplicating it)

The goal isn’t to track everything. It’s to capture just enough to calculate hours, apply policy, and prove who approved what.

Start with roles. Most teams need three: employees who enter time, managers who approve, and payroll (or an admin) who can export and handle setup. Keep permissions simple so people don’t get blocked.

The minimum records to store

Think in three layers: people, a weekly timesheet, and individual time entries.

Store the basics for each person (name, employee ID or email, role, manager, and team or cost center). For each timesheet, store the owner, the week start date, the timezone used for that week, and a status (Draft, Submitted, Approved, Rejected). For each time entry, capture date, start time, end time, break minutes, project or task, and a short note.

You’ll also want calendar settings such as the week start day (Mon or Sun) and the timezone you’ll use for rules. If payroll needs it, add optional context like location or department.

Approval and audit fields you’ll be glad you saved

Approvals are where disagreements happen, so keep a small audit trail that’s boring and clear:

• Submitted at, submitted by
• Approved at, approved by
• Rejected at, rejected by, rejection reason
• Last edited at, last edited by
• Locked flag (to prevent edits after approval)

Example: an employee in Berlin submits on Sunday night. If you store the timezone used for that week, you avoid the classic issue where the submission time looks like Monday for a manager in New York.

If you capture only these fields, you can run overtime rules, route approvals, and export clean totals to payroll without turning the app into a complex HR system.

Define overtime rules in plain language first

Write the policy as simple sentences that anyone can read. If you can’t explain it clearly, the app will create surprises in payroll.

Start by choosing the trigger: overtime after 8 hours in a day, after 40 hours in a week, or both. If you use both, decide the order. A common choice is to calculate daily overtime first, then apply weekly overtime only to the remaining regular hours.

Be explicit about what time counts. Unpaid breaks can change everything, so say it plainly: “Lunch is unpaid and does not count toward hours worked.” If you round time, write that down too. For example: “Round each clock-in and clock-out to the nearest 5 minutes.” Over a month, small rounding choices add up.

Then cover special days. Weekends, holidays, and travel time often have different pay rules. Even if you don’t pay extra, you still need a clear statement like: “Saturday hours are treated the same as weekdays unless total weekly hours exceed 40.”

Policy sentences you can copy and adapt:

• “Overtime is any time worked over 8 hours per day.”
• “Weekly overtime applies only after 40 regular hours, excluding daily overtime hours already counted.”
• “Unpaid breaks are excluded; paid breaks are included.”
• “Holiday hours are paid at 1.5x and do not count toward weekly overtime.”
• “Travel time between job sites counts; commuting from home does not.”

Once these sentences are agreed on, building the logic becomes a translation task instead of a debate.

Step by step: weekly submission workflow

A weekly flow works best when everyone knows what counts as “this week,” and when it must be submitted. Pick a single week start day (often Monday) and a clear cutoff time (for example, Monday 10:00 AM in the employee’s time zone). Late submissions should be possible, but visible.

1) Set the week period and deadline

Define a week as a fixed date range and store it on the timesheet. This avoids confusion when someone opens the app mid-week or travels. Include a status field from day one (Draft, Submitted, Approved, Rejected).

2) Build the employee timesheet screen (add/edit entries)

Keep entry editing simple: date, start time, end time (or total hours), break time, project or cost code (if needed), and a short note. Let employees copy yesterday’s entry and edit it. That one shortcut reduces weekly effort a lot.

3) Show automatic totals (regular vs overtime)

As entries are added, show totals for the week at the top: total hours, regular hours, overtime hours. The split can be estimated until the week is complete, but it should update in real time so employees catch mistakes early.

If required fields are missing, show a clear warning instead of letting totals look “wrong.”

4) Submit and lock the week

Submit should do three things: validate entries (no negative time, no overlaps, required notes), change status to Submitted, and lock editing. If a change is needed, route it through “Return to Draft” (usually triggered by a manager send-back or rejection).

5) Notify the manager and show a pending queue

Once submitted, the manager needs a simple queue: employee name, week range, total hours, flagged issues (like missing notes), and a fast review screen. This is also the right place for automatic notifications when a timesheet moves to Submitted.

Step by step: manager approval flow

A manager should open one screen and immediately see what needs attention. Show a short queue of submitted weeks, each with employee name, week range, total hours, overtime hours (if any), and a quick indicator for notes. That summary helps managers spot problems without clicking into every day.

When the manager opens a week, keep decisions consistent:

• Approve: locks the week and marks it ready for payroll export.
• Send back: returns it to the employee with a required comment.
• Reject: used for policy issues (missing work, wrong project, suspected duplicate).
• Delegate: routes to a backup approver when the manager is out.

Comments matter. Require a short reason for send-back and reject, and store it with the record so the employee knows exactly what to fix.

Be clear about what can change after each decision. After send-back or reject, the employee can edit entries and notes, then resubmit. After approve, edits should be blocked by default. If you allow changes, use a “reopen week” action that starts a new approval cycle (and, if needed, a second approval).

Plan for absences. Assign a backup approver per team (or per employee) and allow HR or an admin role to reassign approvals during vacations.

Keep an audit trail: who submitted, who approved (or delegated), timestamps, and a simple change log (what field changed and when).

Overtime calculation logic and edge cases

Overtime sounds simple until the first messy week shows up. You need one source of truth for the math, and it must match what employees see, what managers approve, and what payroll exports.

Start by deciding what you calculate from: daily totals, weekly totals, or both. Many policies treat the first 8 hours per day as regular time, then count anything above as overtime. Others ignore daily limits and only look at weekly hours (for example, anything above 40 hours). If your policy uses both, define the order so you don’t double-count. A practical approach is: calculate daily overtime first, then calculate weekly overtime on remaining regular hours.

Edge cases you should handle upfront

These situations usually break totals or create disputes:

• Split shifts: two separate entries in one day should roll up to one daily total.
• Overnight shifts: store start and end as full date-time values, not just times.
• Missing end time: block submission or mark the entry incomplete so it can’t inflate hours.
• Overlaps and negatives: prevent entries that overlap or end before they start.
• Rounding rules: decide whether to round per entry (for example, to 5 minutes) or only on daily totals.

People self-correct faster when they can see a clear breakdown. Show each day’s regular hours, overtime hours, and unpaid breaks, then a weekly summary. If something looks off, highlight the exact entry causing it (for example: “Overlaps with 2:00 PM to 4:00 PM”).

Keep calculations consistent everywhere. Reuse the same overtime logic for the employee screen, manager view, reports, and the payroll export.

Export approved hours for payroll

Payroll teams rarely need everything the app tracks. They need a predictable file with the exact column names their system expects, delivered on a schedule. Decide this early so you don’t end up in a weekly back-and-forth.

Start by agreeing on the export format. CSV is common because most payroll systems can import it, but the real key is the field list and column names. If payroll says the column must be called EmployeeID, match that exactly.

A practical export file usually includes employee ID (not just name), the week ending date (or week start plus end), regular and overtime hours in separate columns, a cost center or project code (if you allocate labor), and the approval timestamp plus approver ID.

Only export weeks that are fully approved. Treat approval as a gate: no approval, no export.

Corrections are where teams get stuck. A clean approach is to avoid editing an exported record in place. Instead, create an adjustment entry payroll can import as a delta. For example, if Week 42 was exported with 5.0 overtime hours but should have been 4.0, generate an adjustment line for -1.0 overtime hours tied to the original week and employee.

Store exports as batches so payroll can rerun safely. Give each batch an export ID, the date and time it was generated, and the exact filters used (for example, “Approved weeks ending 2026-01-18”). If payroll imports the same batch twice, the export ID helps detect duplicates.

Common mistakes and traps to avoid

These apps usually fail for simple reasons: unclear “final” states, unclear time boundaries, and exports that don’t match what payroll expects.

The first trap is letting people edit time after a week is approved. It sounds flexible, but it breaks trust in the numbers. Treat Approved as locked. If someone truly needs a change, require a correction request that reopens the week and leaves an audit trail of what changed and why.

Overtime rules changing mid-period is another common source of disputes. If policy changes on Wednesday, document the effective date and the version used for each week. Otherwise, two people can have identical hours and different overtime results. Even a simple note like “Policy v2 effective Jan 15” attached to the week can prevent arguments.

Timezone decisions can quietly ruin totals. Pick one rule and stick to it: use the employee’s local timezone, or the company payroll timezone. If you do nothing, late-night shifts can drift into the wrong day and change daily totals and overtime.

Approvals without comments waste time. When a manager rejects or sends back a week, require a short reason so the employee knows what to fix.

A few rules worth enforcing:

• Lock submitted weeks unless a manager sends them back.
• Keep approved weeks locked except through a tracked correction flow.
• Version your overtime policy and store the effective date.
• Decide one timezone rule and display it on the timesheet.
• Export only fully approved weeks (not Submitted, not partial approvals).

Quick checklist before you roll it out

Before anyone starts logging time, agree on the settings that decide whether the process feels fair and predictable.

Lock down the calendar rules: week start day (Monday vs Sunday) and the submission cutoff (for example, “submit by Monday 10:00 AM for the prior week”). Put that in writing and repeat it in the UI so people don’t guess.

Write your overtime policy in plain sentences, then test it with a handful of real examples. Don’t test only one “normal” week. Try 3 to 5 scenarios including a late shift, a missed meal break, and a split shift.

Keep the rollout checks practical:

• Week start day and submission cutoff are set and communicated.
• Overtime rules are written and tested with 3 to 5 examples.
• Managers can see totals and employee notes before approving.
• Payroll export includes only approved data and can be reproduced.

Pay special attention to locking. Submitted should stop edits unless a manager sends it back. Approved should be effectively immutable except for a tracked correction flow. Otherwise payroll becomes a moving target.

Make payroll export boring. It should produce the same numbers for the same period, and it should include approved hours only. If rerunning last month’s export changes the result, pause the rollout and fix that first.

A realistic example scenario

A warehouse team pays overtime for anything over 40 hours in a Monday to Sunday week, and only approved hours can be paid. Each worker submits once a week, and a manager must approve by Monday noon.

Jordan works the early shift. By Friday, Jordan has logged 38 hours. On Saturday, Jordan stays late for an urgent shipment and logs 6 more hours. On Sunday night, Jordan reviews the week, adds a short note to the Saturday entry, and submits the timesheet with 44 total hours.

On Monday morning, the manager checks the submission. The app shows a simple split: 40 regular hours and 4 overtime hours. The manager notices the Saturday entry was created after the shift ended and asks for details. Jordan realizes the start time is off by 30 minutes and needs to correct it.

Because the timesheet is already submitted, the correction goes through a resubmission flow: the manager rejects the timesheet with a reason (“Fix Saturday start time, then resubmit”). Jordan edits the Saturday entry, resubmits, and overtime recalculates to 3.5 hours.

When the manager approves, payroll gets a clean export for that week: employee ID and name, week start and end dates, approved regular hours and overtime hours, optional cost center or location (Warehouse A), plus approval timestamp and approver name.

After launch, the team tracks a few simple numbers: late submissions (after Sunday), rejection rate (how often managers send timesheets back), and average time from submit to approval. If those numbers rise, it usually points to unclear rules or missing reminders.

Next steps and a simple rollout plan

Treat the first version as a controlled test, not a company-wide switch. Pick one pilot team with a normal mix of regular hours and overtime, and start with one clear overtime policy. This keeps feedback focused and lets you prove the workflow end to end.

Run the pilot for 2 to 4 weekly cycles. That’s enough real submissions to see where people hesitate, where managers get stuck, and whether your payroll export matches what finance expects.

A rollout plan that stays practical:

• Pilot with one team and one overtime policy (skip special cases in week one).
• Collect the five most common questions and fix the screens or labels that caused them.
• Lock down ownership: who can update overtime rules, pay codes, and approval settings.
• Agree on the payroll export schedule (for example, every Monday 9:00 AM after approvals close).
• Add one integration only when the manual export is correct for two pay periods.

Small UI text changes remove a lot of support tickets. Keep the submission flow short, and add help text only where people actually stumble.

Decide early who owns policy updates. HR might own overtime definitions, payroll owns export formats, and managers own approvals. Make those permissions explicit so a well-meaning admin doesn’t change a setting mid-pay period.

If you want to build this without custom coding, AppMaster (appmaster.io) is one option for prototyping and shipping it with visual data models, drag-and-drop workflows for submissions and approvals, and web/mobile UI builders. Start with the minimum workflow, then expand only after the pilot proves the overtime logic and payroll export match your process.