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.

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:

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.

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.

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:

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.

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.

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 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.

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:

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:

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

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.

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.

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:

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:

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.

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.

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.

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.

How AllWage represents operational locations.

How clocking data is processed before reporting and payroll.

How managers can inspect captured workforce information.

The checks used before payroll is completed.

A detailed worked example of job costing for direct labour: attributing base pay and premiums to the correct site and activity, then into a balanced accounting journal.

Most payrolls can export a journal. Ours exports a journal already costed to the right jobs, premiums included - something you can't get from a view of the hours alone.

Our worked example follows a construction company that runs crews across several building sites in Pretoria and Johannesburg, paying an hourly, weekly-waged workforce. We track one of its employees through a single week to show how AllWage attributes every hour of labour cost - base pay and premiums like overtime and Sunday - to the exact site and activity it was worked on, and carries that into a balanced accounting journal.

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

Invision Turn Point Industries has more than 25 years of experience designing, manufacturing, and installing glass and aluminium shopfronts, doors, and windows. Its projects range from residential properties to office blocks and large commercial spaces.

The business operates across construction and manufacturing and manages weekly, casual, and permanent employees with different attendance and pay structures.

Each payroll week, the bookkeeper had to assemble paper timesheets and manually enter records for every employee type. The process consumed days, created pressure around the payroll cycle, and introduced avoidable opportunities for data-entry errors.

Invision introduced AllWage during the financial year and connected its time and attendance records to payroll. The team received training and implementation support while moving away from the existing paper process.

This reflects the documented AllWage workflow in which processed clocking data forms the foundation of payroll calculations and is reviewed before a pay run is finalised.

The Invision team reported that payroll work which previously took days could be completed in hours. They also described fewer manual entry problems, easier day-to-day use, and responsive onboarding support.

The change gave the team a more repeatable process for managing different employment and pay structures without assembling payroll from disconnected paper records. Invision subsequently planned to expand the workflow to other business units.

A South African glass and aluminium design, manufacturing, and installation business serving construction projects.

Invision Turn Point Industries

How processed clocking records support payroll preparation.

The checks used before a recurring pay run is completed.

We didn't know how much we were missing until we saw what was possible.

How Invision Turn Point Industries replaced manual timesheet entry with connected time, attendance, and payroll workflows.

Turning paper timesheets into a faster payroll process

Rheeders Boerdery is a diversified farming operation near Brits in South Africa's North West province. It grows fourteen products throughout the year and supplies major food retailers across South Africa.

The operation manages between 300 and 500 permanent and piecework employees. With labour spread across crops, activities, and harvesting blocks, understanding how working time was used was central to protecting productivity.

Harvesting teams clocked at the packhouse before travelling to their assigned blocks and clocked out only after returning. The recorded working day therefore included transport time and did not show managers how much time was spent productively in the harvest blocks.

Rheeders moved clocking closer to the work by associating employee records with harvesting blocks and activities. This separated productive harvesting time from the travel between the packhouse and the fields.

The workflow aligns with AllWage's documented ability to capture employee activities and associate operational work with configured areas or blocks, giving managers records they could review by place and activity.

Rheeders Boerdery reported that productive time increased by 10%, which it estimated as 7,000 additional productive hours per month. These are customer-reported results from the original engagement and are not a general performance guarantee.

The business moved from assumptions about workforce productivity to a process it could measure, review, and improve.

A diversified farming operation near Brits in South Africa's North West province.

Rheeders Boerdery

How operational locations are represented in AllWage.

How clocking records can include the work employees perform.

Once you have started measuring a process, you can quantify standards for those processes.

How Rheeders Boerdery used activity and location-aware clocking to identify lost production time across its harvesting operation.

Measuring where productive farm time was being lost

Saronsberg Vineyard is a wine and hospitality operation in the Tulbagh Valley of the Western Cape. Its teams work across the vineyard, accommodation, and venue areas rather than in one central workplace.

Worker hours were recorded with pen and paper. Transferring and checking the records for payroll took approximately half a day every fortnight.

After evaluating the workflow with its wider team, Saronsberg introduced RFID wristbands and mobile capture devices so employees could record attendance and activities where work happened.

The resulting records gave the vineyard, accommodation, and venue teams a shared source of workforce information that could then be used during payroll preparation.

Saronsberg reported reducing the time required to finalise fortnightly wages from roughly half a day to 15 minutes. The team also gained more immediate access to workforce data across its different operating areas.

The new workflow reduced repeated paper handling while giving the vineyard a common record for attendance, activities, and payroll preparation.

A vineyard and hospitality operation in Tulbagh, Western Cape.

Saronsberg Vineyard

How RFID identifiers are assigned for employee clocking.

How clocking records move through the attendance workflow.

The documented workflow for checking payroll inputs.

What used to take half a day for payroll now takes just 15 minutes.

How Saronsberg Vineyard connected RFID activity clocking with payroll preparation across a distributed farm and hospitality workforce.

See AllWage at work.

See the work behind the results.

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

Find case studies that fit your operation.

More case studies.

Turning paper timesheets into a faster payroll process

Measuring where productive farm time was being lost

Reducing fortnightly payroll preparation to 15 minutes