Job Costing for Labour: From Clock-In to Cost Per Site.

What is job costing

Job costing is an accounting method that tracks the labour, materials and overhead costs of a specific, unique job or project, so a business can measure the profitability of each job, price new work accurately and control its costs. This piece focuses on the hardest and most valuable part of that picture for a waged workforce: direct labour.

Direct labour is the wages and benefits paid to employees and contractors for the time they spend actively working on a specific job. For a business that pays hourly, waged workers across many locations, direct labour is usually the largest and most variable cost - and the hardest to attribute back to the job that actually incurred it. Materials and overhead are a separate question; everything below is about labour.

What did this job actually cost, and can we trace that number back to the time and activities behind it?

Every waged workforce is really a grid of sites and activities

Job costing for direct labour is not specific to one sector. It applies to any business with a distributed, waged workforce - wherever people are paid for time worked across more than one location. Two ideas describe almost the whole operation: the site (the physical location where work happens, grouped into regions), and the activity (the task an employee performs while there). The labels change from one industry to the next; the mechanics do not.

• Agriculture - sites are farms, orchards, fields and blocks; activities include picking, pruning, planting, packing and spraying.
• Construction - sites are building sites; activities include masonry, concrete, plastering and site cleanup.
• Manufacturing - sites are warehouses, plants and production lines; activities include assembly, machining, packing and quality control.
• Security - sites are guarding posts; activities include patrols, access control and monitoring.
• Mining - a site can be an individual mine or a location within it (crusher, workshop, offices); activities include drilling, hauling, processing and maintenance.
• Cleaning, logistics, retail and hospitality map the same way - client premises, depots, stores or venues as sites, with their own everyday tasks as activities.

A construction firm costing masonry at one site and a mine costing drilling at the north shaft are doing exactly the same thing: attributing an hour of paid labour, premiums and all, to a physical location and a task. This walk-through uses construction as the worked example because it shows the pattern in its most demanding form - the same workforce moving fluidly between distinct jobs and distinct trade activities, often within a single day.

The scenario: one workforce, many jobs in a day

A construction company runs a team that moves between multiple building sites, performing different trade activities at each. On some days an employee splits their time across several activities on several sites - bricklaying at one site in the morning, slabs at another in the afternoon. On other days they spend the whole day on a single activity at one site. The mix is irregular and decided day by day, driven by where the work is needed. To cost each job accurately, every hour worked must resolve to a single site-and-activity combination, because that is the granularity at which the business needs to understand its labour cost. We follow one employee through a week as a representative slice of a workforce that can run into the hundreds.

Why job costing for labour is deceptively hard

On paper it sounds simple: take the hours an employee worked, allocate them to the activity and site they worked on, and you have your cost. For one employee on one day, it is simple. The difficulty is doing it accurately, at scale, and consistently - across a workforce of dozens or hundreds, over a full month. And the cost of an hour is not flat. A worked hour can carry a premium depending on when it happened:

• Overtime - hours beyond the normal threshold cost more (commonly 1.5x).
• Public holidays - typically paid at a premium rate.
• Saturday hours - often a different rate, or a lower ordinary-hours cap.
• Sunday hours - often a higher rate again (commonly 2x).

These premiums have to be apportioned correctly across whatever sites and activities the employee worked that day. Splitting hours evenly is not the same as splitting cost correctly. Done by hand, reconciling this for a whole workforce every month is enormously time-consuming - and, worse, the method drifts from month to month unless the exact same process is followed every time, producing job costs that cannot be compared or trusted.

The overtime trap: no single right answer, only a consistent one

The easy case: an employee works their required 8 hours doing masonry at one site. Straightforward - 8 x the hourly rate, and the whole cost lands on masonry at that site. Nothing to decide. The hard case: an employee works 3 hours of masonry at one site, then 7 hours of concrete at another. That is a 10-hour day against an 8-hour requirement, so 2 hours are overtime - spread across two activities and two sites. Now the question 'which work was the overtime?' has no self-evident answer, because overtime is defined by exceeding the expected hours, not by a fixed position on the clock.

• Ends late - the employee works through and stays on to finish, so the last 2 hours are overtime and the premium lands on whatever they did last.
• Starts early - the employee comes in two hours before the shift to get ahead, so the first 2 hours are the overtime and the premium belongs to whatever they started on.
• An early job over-runs - a planned 6.5-hour day tips to 8.5 because the masonry over-ran, so a 30-minute check-in that was never meant to be overtime is the half-hour sitting past the threshold. The overtime was caused by the masonry, but it looks like it landed on the concrete.

In every version the work is identical; only the story differs - and a naive rule would charge a different activity and site each time. The insight is that there is no single correct answer, only a consistent one. Customers argue their own convention passionately - 'overtime is always the last hours', 'it's whatever ran over' - and none of them is wrong, which is exactly the point. The business does not need the one true method so much as one method applied the same way every pay run. If masonry looks cheap in March only because the overtime happened to be charged elsewhere, and expensive in April because the rule quietly changed, the job costs cannot be compared and the whole exercise is worthless.

Weekly overtime makes it harder still

Many businesses calculate overtime weekly rather than daily: all the hours worked across the week are added up, and only the hours beyond a weekly threshold (for example 45 hours - configurable per business) count as overtime. This breaks the intuition even further, because overtime no longer belongs to any particular day - it emerges partway through the week. An employee can work an 11-hour Monday with none of it overtime, because they have not yet crossed the weekly threshold; overtime only switches on later in the week, the moment cumulative hours pass the line, perhaps on Thursday afternoon. From that instant on, whatever activity and site the employee is working becomes the overtime work and carries the premium.

This is precisely why job costing has to be solved on the payroll side. Time and attendance can show that overtime occurred - it knows the hours. But it cannot correctly attribute the cost of that overtime to activities and sites, because whether an hour is overtime depends on the full week's running total and the pay rules, which live in payroll. Only once payroll has determined when in the week the employee crossed into overtime can the work from that point on be costed accordingly. AllWage already handles this on the payroll side.

How AllWage solves it: one rule, applied every pay run

AllWage keeps the costing calculation where it already works - in payroll, where the true cost of every hour is already known - and carries the site dimension all the way through to the report. Every clock already records which site and activity an employee worked. Payroll already knows the true cost of every hour, including the hard cases (overtime, whether daily or weekly, plus weekend and public-holiday rates). The costing report then breaks cost down not just per activity but per site, so per-site cost falls out of the same engine that already handles everything else. The rule is one consistent method, applied every pay run:

1. Capture - each block of clocked time carries the site and activity it was worked on.
2. Cost each hour - payroll classifies the day's hours as normal, overtime, weekend or public holiday according to the client's pay rules, and applies the matching rate.
3. Prorate across the day's work - the day's normal and premium hours are split across every activity-and-site combination worked that day, in proportion to the time spent on each. The system makes no attempt to guess which specific hour was overtime; it spreads the premium by time share.
4. Report per site - the cost report gains site and region columns and splits its rows one level finer, so cost rolls up per site and per region. The totals are unchanged - the split only subdivides existing rows.

The allocation rule in one line: take the day's normal and premium hours as payroll computed them, and divide each across the activity-site blocks worked that day in proportion to the hours spent on each. Two consequences make it the right rule. Premiums follow the work fairly - if an employee split a 10-hour day 6:4 across two sites, the 2 overtime hours split 1.2:0.8 the same way, so neither site is arbitrarily lumped with the whole premium. And the books always balance - because the split only subdivides, the total labour cost for the day, the employee and the pay run is identical to what it was before site costing existed. Nothing is created or lost; it is only attributed more finely.

Worked example: one employee, one week

This follows a single example employee on the Weekly Wages pay run for 07-13 May 2026. The figures are illustrative, chosen to show the mechanics clearly.

The hours worked

• Thu 07 May - Concrete at The Grove (Pretoria) 4h, then Masonry at Lintons Corner (Pretoria) 7h. An 11-hour day.
• Fri 08 May - Masonry at Lintons Corner (Pretoria) 10h.
• Sat 09 May - Concrete at Sandton (Johannesburg) 9h.
• Sun 10 May - Rubble Removal at Lintons Corner (Pretoria) 10h.
• Mon 11 May - Rubble Removal at Lintons Corner 6h, then Rubble Removal at The Grove 4h (both Pretoria).
• Tue 12 May - Masonry at Sandton (Johannesburg) 10h.
• Wed 13 May - Concrete at Sandton (Johannesburg) 8h, then Rubble Removal at Lintons Corner (Pretoria) 2h.

The rates and rules in play

• Normal - R30.23 per hour (base).
• Overtime - R45.34 per hour (1.5x normal).
• Sunday - R60.46 per hour (2x normal).
• A standard weekday is 8 ordinary hours; hours beyond 8 become overtime.
• A Saturday has a lower cap of 5 ordinary hours, so hours beyond 5 on a Saturday are overtime.
• Sundays are paid entirely at the Sunday rate.

How the split works, day by day

Thursday 07 May is the headline case - 11 hours across two sites, so 8 normal + 3 overtime. Rather than dump all 3 overtime hours on one site, the day's hours are prorated by time share: The Grove took 4/11 of the day, Lintons Corner 7/11.

• The Grove / Concrete / Normal - 2.91h x R30.23 = R87.94
• The Grove / Concrete / Overtime - 1.09h x R45.34 = R49.47
• Lintons Corner / Masonry / Normal - 5.09h x R30.23 = R153.90
• Lintons Corner / Masonry / Overtime - 1.91h x R45.34 = R86.57

The 3 overtime hours land as 1.09h on The Grove (4/11 x 3) and 1.91h on Lintons Corner (7/11 x 3) - neither site is arbitrarily lumped with the whole premium. Friday 08 May is a single site: 10h masonry at Lintons Corner, 8 normal + 2 overtime, nothing to split (8h x R30.23 = R241.84 normal, 2h x R45.34 = R90.69 overtime).

Saturday 09 May shows the cost side of the rules. 9 hours of concrete at Sandton, but Saturday's ordinary-hours cap is 5, so the day is 5 normal + 4 overtime - more of the day is overtime than the same 9 hours on a weekday would be. When an hour is worked, not just how many, decides what it costs.

• Sandton / Concrete / Normal - 5h x R30.23 = R151.15
• Sandton / Concrete / Overtime - 4h x R45.34 = R181.38

Sunday 10 May is paid entirely at the Sunday rate - the premium is driven by the day, not by exceeding a threshold, and attaches to whichever site was worked: 10h Rubble Removal at Lintons Corner, 10h x R60.46 = R604.60. Monday 11 May is the same activity across two sites (6h + 4h Rubble Removal, 8 normal + 2 overtime, prorated 6/10 and 4/10) - the cost still splits by site:

• Lintons Corner / Rubble Removal / Normal - 4.8h x R30.23 = R145.10
• Lintons Corner / Rubble Removal / Overtime - 1.2h x R45.34 = R54.41
• The Grove / Rubble Removal / Normal - 3.2h x R30.23 = R96.74
• The Grove / Rubble Removal / Overtime - 0.8h x R45.34 = R36.28

Tuesday 12 May is a single site again: 10h masonry at Sandton, 8 normal + 2 overtime (R241.84 + R90.69). Wednesday 13 May is the fullest case - two activities and two sites: 8h concrete at Sandton + 2h rubble at Lintons Corner, 8 normal + 2 overtime, prorated 8/10 and 2/10 across both:

• Sandton / Concrete / Normal - 6.4h x R30.23 = R193.47
• Sandton / Concrete / Overtime - 1.6h x R45.34 = R72.55
• Lintons Corner / Rubble Removal / Normal - 1.6h x R30.23 = R48.37
• Lintons Corner / Rubble Removal / Overtime - 0.4h x R45.34 = R18.14

The payoff - cost per site for the week

Rolling every row up by site gives the number the business actually wanted - what each job cost in direct labour, premiums and all:

• Lintons Corner (Pretoria) - 35 hours - R1 443.62
• The Grove (Pretoria) - 8 hours - R270.43
• Sandton (Johannesburg) - 27 hours - R931.08
• Pretoria region total - 43 hours - R1 714.05
• Johannesburg region total - 27 hours - R931.08
• Grand total - 70 hours - R2 645.13

Two things this makes concrete. Job costing works: Lintons Corner and The Grove are both in Pretoria, and Rubble Removal ran across both - yet the report cleanly separates R1 443.62 of labour on one job from R270.43 on the other. And time and premiums are attributed together: every one of the 70 hours resolves to a site, and each site carries its fair share of the week's overtime and Sunday premium, not just base hours. The cost per job is the true cost, not an hours count dressed up as one.

From report to books: getting the job cost into accounting

The cost report above is an operational document - a day-by-day, employee-by-employee breakdown a costing or payroll team inspects to check the numbers. But once the pay run is finalised, that cost has to go somewhere: into the customer's accounting software, as part of their books. Re-keying it by hand every pay period is exactly the manual job that job costing is meant to remove. The accounting journal is the handover - the payroll result turned into a balanced journal the customer can import into, or hand their bookkeeper for, any accounting package.

What a balanced journal is

A journal is a list of accounts, each carrying a debit or a credit, under one unbreakable rule of double-entry bookkeeping: total debits must equal total credits, always, to the cent. For payroll the shape is simple. Debits are what it cost the business - every wage line (normal, overtime, Sunday, allowances) and every employer contribution. Credits are who the business now owes - net pay to employees' bank accounts, PAYE, UIF and SDL to SARS, and any third parties. Gross wages get distributed on the credit side into net pay plus every deduction, and that is what makes the two sides balance.

The insight that connects job costing to the journal

Here is the structural point that ties the whole story together: only the debit (expense) side splits by job; the credit side stays whole. You still owe SARS one PAYE figure and your staff one net-pay figure no matter how the work is sliced, so the credit side never subdivides. But the expense lines - what did wages cost, and against which job? - are exactly what the costing engine answers. Because premiums are already attributed to the right site and activity by the costing engine (proportionally, consistently, weekly overtime and all), the journal inherits correct job costs for free. That is the differentiator: not 'export a journal', but 'export a journal already costed to the right jobs, premiums included' - which a competitor working only from a time-and-attendance view cannot do.

The week's journal

For the example week, the payslip has earnings of R2 645.13 gross (Normal Hours R1 360.35, Overtime R680.18, Sunday Hours R604.60), deductions of R159.87 (PAYE R133.42, employee UIF R26.45) and employer contributions of R52.90 (SDL R26.45, employer UIF R26.45). Net pay is R2 645.13 - R159.87 = R2 485.26. Turned into a balanced journal:

• Debit - Normal Hours - R1 360.35 (wage cost)
• Debit - Overtime - R680.18 (wage cost)
• Debit - Sunday Hours - R604.60 (wage cost)
• Debit - SDL (employer) - R26.45 (employer's own cost)
• Debit - UIF (employer) - R26.45 (employer's own cost)
• Total debits - R2 698.03

• Credit - Net Pay to bank - R2 485.26 (gross minus PAYE minus employee UIF)
• Credit - PAYE to SARS - R133.42 (employee deduction)
• Credit - UIF total to SARS - R52.90 (employee R26.45 + employer R26.45)
• Credit - SDL to SARS - R26.45 (employer contribution)
• Total credits - R2 698.03

Both sides land on R2 698.03 - the journal balances.

The depth dial - splitting the expense side by job

Only the debit side splits by job; the credit side stays whole. The journal above - normal time, overtime, Sunday hours and the statutory lines - is exactly what most payrolls export, and they stop there. Everything below - those same wage lines broken down by activity, by site, by region - is detail AllWage adds, and it is only possible because the costing engine already knows which job every hour and every premium belongs to. So the customer puts a depth dial on the wage-expense lines. Using the week's Overtime (R680.18) as the running example:

• By activity - Masonry R267.95, Concrete R303.40, Rubble Removal R108.83.
• By site - Lintons Corner (Pretoria) R249.81, The Grove (Pretoria) R85.75, Sandton (Johannesburg) R344.62.
• By region - Pretoria R335.56, Johannesburg R344.62.

Every one of these re-sums to R680.18 - the depth dial only ever subdivides a line, it never changes a total, so the journal still balances at every depth. The same applies to Normal Hours, Sunday Hours and every other expense line. Anything that carries no activity or site - a fixed amount like a bonus, or hours clocked without a site - cannot be split, so it lands on an explicit Unallocated line rather than being smeared across the jobs. In practice the customer picks a legal entity and a calendar month, chooses how deep to split the expense lines, and downloads one balanced, software-agnostic journal ready to capture or hand to a bookkeeper.

The full picture, end to end

One pipeline runs from a worker clocking in to a line in the customer's accounts: clock (site and activity) to time and attendance (hours and exceptions) to payroll (classify each day's hours as normal, overtime, weekend or public holiday, apply the rates, handle weekly overtime) to the cost report (prorate each day's cost across the activity-site blocks by time share) to the accounting journal (a depth dial on the wage-expense lines; one balanced journal) to the customer's accounting software. The through-line is a single idea: the genuinely hard problem - attributing premiums across a fluid, multi-site, multi-activity day, including weekly overtime that only switches on mid-week - is solved once, in payroll, with one consistent rule. Everything downstream inherits that answer, which is what makes job costs comparable month to month, trustworthy in the books, and defensible when a customer asks why a job cost what it did.

Common questions about job costing for labour

Why can't time and attendance alone do job costing?

Time and attendance knows the hours, so it can show that overtime happened - but it cannot correctly cost that overtime to a job, because whether an hour is overtime depends on the week's running total and the pay rules, which live in payroll. Costing has to be done where the true cost of every hour is already known.

How do you decide which hours are overtime when a day spans several jobs?

AllWage does not try to guess which specific hour was the overtime. It spreads the day's premium across every activity-and-site combination worked that day, in proportion to the time spent on each. It is a defensible rule applied identically every pay run - so job costs stay comparable month to month.

Does the cost that lands on each job include overtime and weekend premiums?

Yes. Each job carries its fair share of the day's overtime, Saturday, Sunday and public-holiday premiums, not just base hours. The cost per job is the true cost of the labour, not an hours count dressed up as one.

What happens to time not linked to a site, or fixed amounts like bonuses?

Anything that carries no site or activity - a bonus, or hours clocked without a site - cannot be attributed to a job, so it lands on an explicit Unallocated line rather than being smeared across the jobs. Nothing is invented and no total changes.

Which industries does this apply to?

Any business with a distributed, waged workforce - agriculture, construction, manufacturing, mining, security, cleaning, logistics, retail and hospitality all map onto the same site-and-activity model. Construction is used here because it shows the pattern in its most demanding form.

What this example does and doesn't claim

This is a worked example using an illustrative employee and figures, chosen to show the mechanics clearly. It does not guarantee a saving or productivity increase. The value of job costing depends on configuration, reliable data capture, accurate rates, and disciplined review before payroll is finalised.