Labor Cost Allocator: Split Every Paycheck Across the Jobs, Projects, and Grants It Belongs To
Take each person's wages plus loaded burden (employer taxes, benefits) and allocate it across departments, jobs, projects, or grants based on their coded hours — so labor lands correctly in job costing, departmental P&Ls, and grant reports, reconciled to actual payroll cost, with finance approving before it posts.
A logged-in tool where you import each employee's payroll cost (wages + burden) and their coded hours by cost object, the agent computes the burden rate and allocates total cost across departments / jobs / projects / grants in proportion to hours, reconciles the allocation back to actual payroll cost to the penny, finance reviews and approves, and you export an allocation CSV for job costing/GL plus a per-cost-object summary.
Before you start
- A Supabase account (free)
- A Vercel account (free)
- A Resend account (free)
- A payroll-cost export per employee (wages + burden) for the period
- A coded-hours export from your timesheet tool (hours by cost object)
- Claude Code or any AI coding agent
The problem this kills
Your payroll run produces one number per person: total cost — wages plus the loaded burden of employer taxes, benefits, workers' comp, and the rest. But that number has to land in a dozen different places. The carpenter's week splits across three jobs. The agency designer's hours go against five client projects. The nonprofit program manager's salary has to be split across two federal grants and a general fund — and the grant reports have to be defensible to an auditor.
Most teams do this split in a spreadsheet that one person rebuilds every pay period. They paste in payroll costs from one system and coded hours from another, eyeball a burden percentage, write proportion formulas by hand, and pray the columns total back to what payroll actually cost. They almost never do — there's a few dollars of rounding drift, an employee with hours but no cost, or a cost with no hours, and the allocation quietly disagrees with the books. By the time job costing, the departmental P&L, and the grant report are all wrong by slightly different amounts, nobody can trace why.
Labor is the biggest cost most of these organizations carry, and it's being allocated by hand on a Friday. It deserves to be a real, governed application that reconciles to the penny — not a workbook held together with hope.
What you'll build
A simple internal web app for your finance team. Each period you import two things: the payroll cost per employee (wages plus burden, however your payroll system breaks it out) and the coded hours by cost object (the hours each person logged against each department, job, project, or grant — straight from your timesheet tool).
The tool computes each person's burden rate (how much loaded cost sits on top of base wages) using the basis you choose, then allocates each person's total cost across their cost objects in proportion to their coded hours. It then does the thing the spreadsheet always fails at: it reconciles the allocation back to actual payroll cost for every employee and in total, flagging any penny of drift, any employee with cost but no hours, and any hours with no cost. Finance reviews the allocation, fixes the exceptions, and approves — and only then does it produce the allocation CSV your job-costing/GL import expects and the per-cost-object summary for your P&Ls and grant reports.
What's inside the Implementation Plan
The downloadable plan is a step-by-step file you paste into an AI coding agent. It opens by interviewing you about your business — what your cost objects actually are (jobs? projects? grants? departments?), how your payroll export breaks out wages versus burden, how you want the burden rate computed, what your coded-hours file looks like and how cost objects are named/coded, your period cadence, and the messy exceptions (salaried people with no hours, overhead/PTO time, an employee who appears in one file but not the other). It reflects a short tailored spec back to you and gets your thumbs-up before it builds anything — so the allocation matches your chart of accounts and your cost-object codes, not a generic template.
From there it walks the agent through the data model, the two-file import, the burden-rate and proportional-allocation engine, the reconcile-to-actual check that must total exactly, the finance approval gate, and the two exports. Every step ends with a ready-to-copy prompt. There's a full "No API yet?" path that runs entirely off your payroll-cost CSV and coded-hours CSV and produces a clean allocation CSV in the exact columns your GL or job-costing system expects — so you can build and run the whole thing this weekend regardless of what systems you're on.
The governance it includes (this is the point)
This posts labor cost to your books and to grant reports, so the controls aren't optional. The plan builds in login so only your finance team can use it, row-level security so you only ever see your own organization's payroll data, a complete audit trail of who imported what, who changed which allocation, and who approved it, a hard human-approval gate so no allocation posts to job costing or the GL until finance signs off, a reconciliation rule that the allocation must equal actual payroll cost to the penny before it can be approved, and duplicate guards keyed on employee + period so the same payroll run can't be allocated twice.
Who it's for
Controllers, FP&A, and payroll-accounting staff at organizations that have to split labor across cost objects — construction and trades (labor by job), agencies and professional services (labor by client project), and nonprofits and grant-funded organizations (salaries by grant and fund, defensible to an auditor). If you can describe what your cost objects are and how your payroll cost breaks out, you can build this.
You've got this — start with the plan, paste the first prompt, and answer the interview. You'll have your first reconciled, audit-ready allocation on screen before the weekend's out.