Banked hours ledger for shift-based workforces

The moment a payroll administrator at a 24/7 factory or multi-shift operation realizes their time tracking system's hour bank is just a number field with no audit trail — not a running ledger showing what was deposited, why, what was withdrawn, and when — they start building shadow spreadsheets. That's the problem nobody has fixed properly.

The gap persists because major time tracking vendors are built around clock-in/clock-out accuracy as the core product. The hour bank is a secondary feature bolted on, with no real transaction history, no rules engine for when hours can be withdrawn versus forfeited, and no handling of overtime-fed bank deposits versus manually granted comp time. Vendors have no incentive to fix this because the person who suffers most (the overnight shift manager or the HR coordinator manually reconciling bank balances every two weeks) isn't the same person who signed the software contract.

What users actually describe: they can't let employees withdraw hours for previous days, they can't see how a balance got to where it is, and managing banks across a 24/7 operation with rotating shifts means manually touching records constantly. There's no difference between a legitimate balance and a data entry error because there's no history.

Without a proper ledger, payroll coordinators spend hours before every pay run reconciling bank balances against paper notes and manager Slack messages. When a dispute arises — and in unionized or regulated environments, they always do — there's no audit trail to defend the number. That's a compliance and labor relations risk that recurs every single pay period, not just once.

What to build

Build a standalone banked hours ledger that connects to time tracking exports (CSV or API) and maintains a double-entry transaction log per employee — showing every deposit with its source rule (overtime threshold, manual grant, schedule adjustment) and every withdrawal with the approver and date, exportable to payroll-ready formats.

Where to start

Start with unionized manufacturing plants where the collective agreement defines exact bank rules in writing — those rules can be translated directly into configuration, and the union contract creates a hard compliance need that justifies paying for a standalone tool even if it duplicates something in the existing HRIS.

The hard part

Every employer's bank rules are different — some banks cap at 40 hours, some have expiry windows, some pay out at 1.5x — so the rules engine has to be configurable without requiring a developer, which makes the onboarding flow genuinely hard to design without overwhelming first-time users.

How it makes money

Monthly subscription per employer location, priced by employee headcount band (e.g., up to 100 employees, 100–300, 300+), with a one-time onboarding fee to configure the rules engine against their specific policy document.