The Customer Reads Your Timesheets
Most labour records are built for the employer and the regulator. In export manufacturing a third party reads them — the customer — and they are not asking whether your numbers are correct. They are asking whether anyone but you could have produced them.
Attendance systems are almost always designed around two readers. The employer, who wants to know who was there, and the state, which wants to know that the law was followed. Both are demanding in their way and both share an assumption: that the records are yours, and that you are the one presenting them.
Export manufacturing adds a third reader with a completely different posture. Your customer audits you. The brand buying the output examines the working-hours and wage records of the factory producing it, and unlike a regulator, they are not weighing a penalty. They are deciding whether to keep buying. The leverage is commercial, the relationship is voluntary, and it can end.
That inversion changes which properties of a record matter. Accuracy is necessary and it is not the interesting part, because the auditor already assumes your numbers are internally consistent. What they are testing is something harder: whether the records could have been produced by anyone other than the person who benefits from what they say.
The property that is hard to fake and easy to demonstrate
The single most useful thing a system can do here is make it structurally awkward to reconcile hours after deciding what to pay. Not impossible — no software achieves that — but awkward, visible, and out of sequence.
Payroll here cannot be calculated against attendance that is still open. The timesheet period has to be locked first, and if it is not, the calculation refuses outright with a message naming the employee and the period rather than quietly falling back to whatever the live figures currently say. The reasoning is written into the code itself: a payroll figure computed against attendance that could still change defeats the entire point of locking.
The consequence is the useful one. Overtime on a payslip is derived from the locked snapshot, not typed into the payslip. The hours were frozen, and then the pay was computed from them, in that order — and the order is enforced rather than encouraged.
The mechanics of shifts and overtime in the ordinary case are set out in shifts and overtime management, and the payroll pillar in HR and payroll software. For an internal payroll process the locking is good hygiene. For a factory being audited by its customer it is considerably more than that: it is the difference between "these are our hours and this is our pay" and "the hours were closed on this date, and the pay was calculated from them afterwards".
What an attendance record actually carries
Three details on the attendance record are worth naming, because each answers a question an auditor asks and none is obvious from the outside.
- Where the record came from. Each row carries its source, so a clocked entry and a manually entered one are distinguishable. The proportion of manual entries is one of the first things a careful reader looks at, and it is answerable here rather than being a matter of assertion.
- Who touched it. Created-by and updated-by are on every row, with soft deletes, so an amended record has a person and a time against it rather than simply becoming a different number.
- Whether the shift crossed midnight. This is explicit rather than inferred, which means a night shift is a shift that ran past midnight instead of a negative duration that somebody had to correct.
There is also employee-side verification, which can be switched on per person: the worker confirms their own attendance. That is a different kind of evidence from anything the employer can generate alone, and it is the sort of thing worth enabling well before anybody asks whether it exists.
An auditor is not testing whether your numbers agree with each other. They are testing whether the sequence that produced them could have run in the other direction.
A workforce that is not all on your payroll
One structural point matters enormously at scale and is easy to miss: an employee is not a user account here. The link is optional. Someone who never logs into anything, who has no email address and no device, is still a complete employee record with attendance, a contract and payslips.
That sounds like a technical detail and it decides whether the system is usable at all at factory headcounts. Systems that model people as logins can only see the people who log in, and in a manufacturing workforce that is a small and unrepresentative fraction.
Where it stops is worth being equally direct about. Employment type is a closed set of four — permanent, contract, casual, intern — and there is no value in it for a worker supplied by a labour contractor and employed by somebody else. In a region where that arrangement is structurally normal rather than exceptional, the schema is describing a simpler workforce than the one on the floor. Such a worker can be recorded, but they will be recorded as one of the four things they are not.
And how they are paid
The compensation model is a monthly basic salary held on an employment contract, in a stated currency, with the payslip showing standard working days, unpaid leave days, overtime hours, basic pay and its prorated amount, gross, the statutory and voluntary deduction totals and net. The arithmetic from days to net is visible on the payslip rather than buried, which is itself worth something when somebody is checking it.
What is not there is piece rate. There is no per-unit pay, no production-linked compensation and no output-based component anywhere. Where pay is genuinely a function of units produced, that calculation happens outside and arrives as a figure — which means the one thing the audit most wants to see reconciled, hours against output against pay, is only partly reconcilable inside the system.
Overtime is a single number, too. One decimal figure of overtime hours per payslip, with no tiers, no premium multipliers and no distinction between ordinary, rest-day and holiday overtime. Where the applicable rules require those to be distinguished — and they very often do — the distinction has to be maintained outside and reconciled by hand.
What AWRA OpsHub does today
- Payroll that refuses to calculate against an unlocked timesheet, with an explicit error rather than a silent fallback to live figures.
- Overtime derived from the locked timesheet snapshot, so hours are frozen before pay is computed from them.
- Attendance with clock-in, clock-out, hours worked and an explicit midnight-crossing flag, so night shifts are represented rather than corrected.
- A source on every attendance record, distinguishing clocked entries from manually entered ones.
- Created-by, updated-by and soft deletes on attendance, so amendments have a person and a time against them.
- Employee-side attendance verification, switchable per person, producing evidence the employer cannot generate alone.
- Employee records independent of user accounts — a worker who never logs in is still a full record with contract, attendance and payslips.
- Unpaid leave resolved from approved leave requests rather than from a raw timesheet day count that cannot tell paid from unpaid.
- A payslip that shows its own arithmetic — working days, unpaid days, overtime, basic, prorated basic, gross, deduction totals and net.
What it does not do
- No employment type for contractor-supplied labour. The set is permanent, contract, casual or intern, and it is closed at the schema level.
- No piece rate or production-linked pay of any kind. Compensation is a basic salary on a contract; per-unit pay is calculated outside.
- No overtime tiers or premium rates. One overtime hours figure per payslip, with no weekday, rest-day or holiday distinction.
- No working-hours limits, alerts or thresholds. Nothing warns that recorded hours have passed any figure, because no such figure is configurable.
- No audit-pack export. There is no packaged set of hours and wage records assembled for an external reviewer; the underlying data is reportable and exportable, but the assembly is yours.
- No labour standards or code-of-conduct content. The system holds records; it makes no claim about what any standard requires or whether you meet it.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax authority pipeline, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax authority pipelines and reporting
Electronic invoicing or invoice registration against your authority's published interface, with retries, a failure queue and a daily report of sales that carry no reference. The regimes across this region differ enough that this is one build per country rather than one build for the region, and the local bench is deep in most of them — so the honest question is usually whether you need this from us at all, or whether you need the operations layer that feeds whatever you already file with.
Local payment rails and bank feeds
Real-time payment collection matched to the invoice, bulk payment files in your bank's format, and statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Statutory payroll and social security schedules computed on live records and produced in the layout each filing body expects. Per-state and per-province variation is the norm rather than the exception here, and it is what makes this a country build rather than a regional one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedWhat to get in place before you are asked
-
Lock timesheets on a schedule, and never after payroll
The system already refuses to calculate against an open period, so the sequence is enforced. What is not enforced is when locking happens, and a period locked days after everyone knows the pay figures is a weaker record than one locked on a fixed date. Put the lock date in the calendar and treat it as a deadline rather than a step.
-
Watch the proportion of manually entered attendance
Source is recorded per row, which makes this measurable rather than a matter of impression. A high manual share is not evidence of anything wrong, but it is the first thing a careful reader will ask about, and knowing the number before they do is worth more than explaining it afterwards.
-
Turn on employee verification well ahead of needing it
Verification enabled last month produces a month of evidence. Enabled the week an audit is announced, it produces a week of evidence and an obvious question. It costs nothing to have been running.
-
Decide where piece-rate and overtime-premium calculations live, and write it down
Since neither exists in the system, both happen somewhere else — usually a spreadsheet somebody maintains. That is workable, and it is only workable if the method is documented and the inputs tie back to employee numbers the records use. An undocumented spreadsheet is the weakest link in an otherwise strong chain.
-
Record contractor-supplied workers deliberately and consistently
The employment type field cannot describe them, so pick one value, use it for all of them without exception, and record the actual arrangement in a field that can hold it. Consistency is what makes the population countable later; the specific choice matters much less than everyone making the same one.
The summary is a narrow claim and a genuine one. The sequence — hours recorded, hours locked, pay calculated from the locked hours — is enforced by the system rather than left to discipline, and that sequence is the part of this that is hardest to establish after the fact and most valuable when a customer asks. The compensation model beneath it is simpler than a factory floor, and the places where it is simpler are precisely the places that need a documented process alongside. Knowing which is which is most of the work.
Frequently asked questions
Can payroll be run before attendance is finalised?
No. The timesheet period must be locked first, and payroll refuses with an explicit error naming the employee and period if it is not. It does not fall back to live figures. Overtime on the payslip is then derived from the locked snapshot rather than entered, so hours are frozen before pay is calculated from them.
Can we tell clocked attendance apart from manually entered attendance?
Yes. Every attendance record carries its source, along with created-by and updated-by, and deletions are soft. So the proportion of manually entered records is measurable, and an amended record has a person and a time against it rather than simply becoming a different number.
Does the system support piece-rate or production-linked pay?
No. Compensation is a basic salary held on an employment contract in a stated currency; there is no per-unit or output-based pay anywhere. Where pay depends on units produced, that calculation happens outside and arrives as a figure — so document the method and tie its inputs to the employee numbers the records use.
Can we distinguish rest-day or holiday overtime from ordinary overtime?
Not on the payslip. Overtime is a single hours figure with no tiers, premium multipliers or day-type distinction. Where the applicable rules require them to be separated, that separation has to be maintained outside the system and reconciled manually.
How do we record workers supplied by a labour contractor?
Employment type is a closed set — permanent, contract, casual or intern — with no value for a worker employed by someone else. They can be recorded as employees with full attendance and payslip records, but the employment type will describe them approximately. Choose one value, apply it consistently so the population stays countable, and record the actual arrangement in a field that can hold it.
Do workers need user accounts to have attendance records?
No, and this matters at scale. The link between an employee and a login is optional, so someone who never signs into anything is still a complete employee record with a contract, attendance and payslips. Systems that model people as logins can only see the fraction of a manufacturing workforce that logs in.
