Governing Adapt Timesheets, the workforce management system (“the System”) used to record time and attendance and produce timesheets.
This policy explains how Adaptare handles personal information. It is written for the employers who use the System, the workers whose information it holds, and anyone else who deals with us. It is published on our website and within the System. Capitalised terms are defined in section 1.5.
Adaptare Intelligence Pty Ltd (ACN 701 658 022, ABN 53 701 658 022) is an Australian software business. It builds and operates the System, which it offers under the name Adapt Timesheets.
Employers subscribe to the System to record time and attendance for their own workforce. We do not employ or engage the Workers whose information it holds.
Where the System stops matters, because it shapes this whole policy. The System records work, turns it into hours, and produces an approved timesheet. That timesheet is passed to the Employer’s Payroll Software, where the pay run is lodged, tax is withheld, superannuation is paid and wages are transferred. We are responsible for the timesheet. We are not a payroll system, and the information a payroll system needs to pay someone is not held here.
In practice the System lets an Employer record sign-ins and sign-outs and turn them into shifts and paid hours; record leave and stand-down days; flag problems such as a missing sign-out, a duplicate entry or an unusually short shift; approve a timesheet for a pay period; and pass it to Xero or MYOB.
Levels of access.
A Foreman can therefore change the attendance record a Worker’s pay is calculated from. Section 7 explains where those changes are reviewed.
The Employee Portal appears in the System as “My Pay”. It shows a Worker their own days and times signed in and out, the hours those total, their site, leave submitted or approved, and any allowances recorded. It shows no pay figure and nothing about anyone else, and it is optional for an Employer to switch on. The System does not produce pay slips; those are issued by the Employer from its Payroll Software. The Portal exists so a Worker can check their hours and leave were recorded correctly, ideally before the timesheet is approved. Through it a Worker can submit a leave request, ask for an amendment to a record, submit a photograph of a receipt, and clock in and out from their own phone at the sites they are assigned to.
Our own technical access. Separately from those three levels, the technical access needed to operate the System — control of the hosting environment, custody of the encryption key, and the ability to revoke sessions, rotate credentials and retrieve audit records — is held by Benjamin Kumaru, who built and maintains it. It is held by him alone until we engage a second person in a technical role.
It covers personal information we handle in operating the System and running our business: information about Workers whose records an Employer holds in the System, about the Administrators and Foremen who use it, and about people who visit our website or contact us.
It does not cover an Employer’s own privacy practices, which are their responsibility; third-party services such as Xero, MYOB, superannuation funds and the ATO, which operate under their own terms; information that is never in the System, such as bank account details; or reports an Administrator downloads from the System, once they are outside it (see section 8).
One document sits alongside this one: our Terms of Service, which set out the contractual privacy and data-handling terms between us and each Employer. This policy is the document we make available to Workers; we do not issue a separate Worker-facing notice.
Where this policy and another document cover the same ground: this policy is our general statement and applies to everyone; a written agreement with an Employer prevails over it as between us and that Employer, but cannot reduce the protections described here for a Worker’s information; an Employer’s own notice describes their practices, not ours; and nothing displaces an obligation we have at law.
On our own account, we handle the account details of Administrators, our subscription and billing records, website enquiries, support requests, and the security and audit records that protect the System. We decide what we collect and why, and we are answerable for it.
On an Employer’s instruction, we hold most of what is in the System — Worker names, hours, pay rates, leave and sign-in records — because an Employer put it there. They decide what is collected and why. We hold and process it to provide the System, and not for our own purposes.
Three things follow. A Worker wanting to see or correct information should go to their Employer first; section 12 explains what happens if that is not resolved. The Employer, not Adaptare, is the legal record-keeper: under the Fair Work Act 2009 (Cth) an employer must keep employee records for seven years and issue pay slips. And when an Employer leaves, we export their data back to them before deleting our copy, as section 11 sets out.
We avoid the terms “controller” and “processor”. They come from European law and do not appear in the Privacy Act 1988 (Cth), which imposes obligations on anyone holding personal information rather than dividing responsibility between two defined roles.
Adaptare is bound by the Privacy Act 1988 (Cth) and handles personal information in accordance with the Australian Privacy Principles. We do not rely on the small business operator exemption in section 6D of that Act, and nothing in this policy should be read as claiming it. The Notifiable Data Breaches scheme applies to us in full, and our Data Breach Response Plan is written on that basis.
| Term | Meaning |
|---|---|
| Adaptare, we, us, our | Adaptare Intelligence Pty Ltd (ACN 701 658 022, ABN 53 701 658 022), the business that builds and operates the System. |
| The System | Adapt Timesheets, the workforce management software built by Adaptare, in all its forms: the web application, the mobile app, the sign-in interface on a shared device at a workplace, and the Employee Portal. |
| Employer | The business that subscribes to the System and uses it to manage its own workforce. Also called our client. The Employer decides who is given access, what is entered, and for what purpose, and it is the Employer, not Adaptare, that employs the Workers. |
| Worker | A person employed or engaged by an Employer whose information is held in the System. A Worker may do any job — labourer, tradesperson, supervisor or foreman. The term describes whose information it is, not what work the person does. |
| Administrator | A person the Employer has given full access. Administrators add and edit Worker records, grant Foreman access, review and approve timesheets, download reports, and change settings. The System requires no particular qualification; the Employer chooses who to appoint and is responsible for what they enter and how they use it. |
| Foreman | A person given a limited additional level of access, usually a site supervisor, with the functions described in section 1.1. A Foreman is usually also a Worker, and their own information is held on the same basis as anyone else’s. |
| Employee Portal | The optional part of the System a Worker signs in to, shown as “My Pay”, described in section 1.1. |
| Stand-down | A day on which a Worker could not work, because of weather, a site closure or similar. A Foreman or Administrator can record one for a single Worker, several, or a whole site. |
| Payroll Software | The third-party accounting and payroll platform an Employer connects to the System — Xero or MYOB — where wages, tax, superannuation and pay slips are processed. Bank account details are held there, not here. |
| Personal information | Has the meaning given in section 6(1) of the Privacy Act 1988 (Cth): information or an opinion about an identified individual, or an individual who is reasonably identifiable, whether or not true and whether or not recorded in a material form. |
Most of what the System holds is not collected by us — it is entered by an Employer’s Administrators and Foremen, or recorded when a Worker signs in and out. Some of it is not collected at all but calculated. We treat calculated information as personal information too.
For each Worker the System may hold their name, email address, trade, the site or crew they are assigned to, employment start date and type, and whether they are currently employed; their base rate, the award code and classification an Administrator records against them, overtime and penalty multipliers and allowances, held with effective dates so previous rates are retained; the times they sign in and out, the site, how the record was made, whether someone entered it on their behalf, and any note typed at sign-in; the coordinates recorded at sign-in, their accuracy and the address they resolve to; overtime and who approved it; leave dates and type, any note recorded with a request, who submitted it and its status, and stand-down days; hours worked and paid and the gross figure those produce; any receipt a Worker photographs and submits for an expense or allowance claim, together with the date and amount they enter with it; and, for Portal users, their login email, whether it is verified, a one-way hash of their password, and a hash of any single-use reset or verification link issued with its expiry and whether it has been used.
Two further items may be held. If one has been recorded, a Worker’s QLeave worker number. And the name of a Worker’s superannuation fund, which the System stores but does not display or use for any purpose. Neither is shown to Foremen or Workers.
The System works out a great deal of this rather than receiving it: the shifts it builds by pairing sign-ins with sign-outs, rounded start and finish times, the paid hours that follow, the gross figure, and warnings that a Worker has a shift that looks incomplete, short, late or duplicated, or a base rate below the minimum rate an Administrator has entered (section 7.1). It also records who reviewed, overrode or resolved each of those and any reason given. These are our calculations and can be wrong; section 12 explains how to have a record corrected.
What we can see in Payroll Software but do not use. The connection to Xero or MYOB requires read access to employee records, which can contain a home address, phone number, bank account details and the tax and superannuation details that software holds. Our software requests only a Worker’s identifier and name, their ordinary pay item and hourly rate, and whether their pay period lines up with the Employer’s pay periods in the System. This is enough to match them to the roster and carry their rate across. No other field is transmitted to us: the unused information stays in the Payroll Software and never reaches our server, so there is nothing for us to read, store, display or log. The technical reach exists because the connection requires it, but the information does not travel.
For each person given access we may hold their name, email address, role and whether their access is active; a one-way hash of their password and whether they must change it; for a Foreman, their assigned sites; whether they have set up multi-factor authentication and, if so, an encrypted authenticator secret; hashes of password reset, verification and invitation links with their expiry and use; records of sessions and sign-in attempts including time, IP address and browser or device; and their name against actions they take.
The audit record. The System logs actions taken in it: who acted, what they did, which record it affected, when, from which IP address, and for changes the values before and after. Passwords and other secrets are stripped before anything is written. If you use the System as an Administrator or Foreman, what you do is recorded, including network and device details. That is how an Employer can show a timesheet was properly reviewed, how a change to someone’s hours can be traced, and how we can establish what happened after a security incident. Because the log keeps values from before a change, older information — such as a previous pay rate, or an attendance record — continues to exist after the record itself is updated.
We hold each Employer’s legal name, trading name, ABN and business address, a contact email address and phone number, their subscription status and the identifiers our payment provider uses. Most of this is business rather than personal information, but for a sole trader it can be both, and where it is we treat it as personal information. Where an Employer connects Payroll Software we hold the credentials for that connection in encrypted form.
If you contact us, we hold what you send: your name, email address or phone number, the content of your message and our reply.
Our website sets out our pricing and lets a business sign up. Signing up creates an account and collects the name of the person signing up, their company name, their email address and a password they choose. No payment details are needed to sign up. If a business chooses to subscribe to a paid plan, payment details are entered directly with our payment provider and never reach our server. There is no chat widget, no newsletter and no contact form. The only ways to reach us are in section 14.
We do not advertise or sell advertising. We use no analytics or tracking tools on our website or in the System, place no tracking cookies, build no profiles and track nobody across other sites. Our network provider records standard request information including IP addresses, which is necessary to route traffic and protect the service; that is not analytics. We look at error reports, alerts and support requests for two purposes only: fixing faults, and improving the interface. If we introduce analytics, advertising or marketing, we will update this policy first.
Sensitive information is a defined category under the Privacy Act 1988 (Cth) including health information, trade union membership, religious or political beliefs and criminal history. It attracts stronger protection and generally should not be collected without consent. The System is not designed to collect it and has no field that asks for any, but it can arrive two ways.
The first is the type of leave taken: recording sick, carer’s or compassionate leave says something about a person’s circumstances and may amount to health information even without detail. The second is free text. Several places accept typed text: a note a Worker types at sign-in, a note attached to a leave request, the reason given with an amendment request or a request to delete an account, the description entered with a receipt, notes an Administrator keeps against a Worker’s profile or pay profile, and the reason given when someone reviews, overrides or resolves a record. There is no restriction on what can be typed, so the protection is not a technical limit but knowing who will read it.
All free text is visible only to Administrators, and to Foremen within their assigned sites. No Worker can see anything another Worker has written, anywhere in the System. A photographed receipt is free text of a different kind. We do not control what appears in the frame, and a receipt can show what was bought and where. Receipts are visible to Administrators; a Foreman sees only the receipts they submitted themselves. We ask Employers to tell their people to submit only what a claim needs.
When an Administrator invites a Worker to the Portal, the invitation explains that anything typed into a note, or told to a Foreman to record, may be read by their Foreman and their Employer’s Administrators, and that other Workers cannot see it. This matters more once Workers submit their own leave: a Foreman writing “off sick” on someone’s behalf records less than a Worker typing into a box on their own phone, who may explain the reason in full.
Where sensitive information does end up in the System it is held under the same access controls as everything else and we do not use it for any purpose of our own. We ask Employers to tell their people to record only what is needed. A leave request needs a date and a leave type, not a diagnosis.
We do not sell, rent or trade personal information, and we do not use a Worker’s information to market anything to them.
From a business signing up. Signing up collects the signatory’s name, company name and email address and a password they choose. Subscribing to a paid plan, which is optional, adds payment details entered directly with our payment provider.
From an Employer. Most of a Worker’s record is entered by Administrators: name, email address, trade, site, employment type and start date, pay rates and allowances.
From a Worker. When they sign in or out on the shared device or from their phone (through the Employee Portal, at a site they are assigned to), the System records which name was selected, whether it was a sign-in or sign-out, the time, the site, any note typed, and a location reading. Where there is no signal, on either the shared device or a phone, the record is held on the device and sent when the connection returns, and both times are kept. The System also records how long the form took to complete and whether hidden fields were filled — a standard way of telling a person from a script. If a Worker has Portal access we hold their login email, verification status and a hash of their password. A Worker with Portal access can also submit a leave request, ask for an amendment to a record, and photograph and submit a receipt for an expense or allowance claim, entering the date and amount alongside it.
From a Foreman or Administrator, about a Worker. They can add a missed sign-in or sign-out, approve overtime, submit leave or a receipt on a Worker’s behalf, record a stand-down, or correct an attendance record and give a reason. Information about a Worker can therefore enter the System from someone else, and the Worker may not know a particular record was made. It is how a supervised worksite must operate. Someone who forgets to sign out still needs to be paid, but the System records who made each entry, and section 12 explains how to have a record corrected.
From Payroll Software, a Worker’s identifier, name, ordinary pay item and hourly rate, and pay period alignment, as section 2.1 explains.
From a sign-in provider. An Employer can let Administrators and Foremen sign in with a Google or Microsoft account. Where that is switched on we receive the email address and name held by that provider, and nothing else. It never applies to Workers.
From using the System. Ordinary technical records such as IP address, browser details and times of sign-in attempts are created whenever anyone connects, and a substantial part of what we hold is calculated rather than collected, as section 2.1 sets out.
Personal information about someone should be collected from that person unless it is unreasonable or impracticable. We have no relationship with a Worker: we do not employ them, set their pay or agree their conditions. Their Employer does all of those, already holds the information, and is the one that decides to use the System. So the information comes to us from the Employer, and we hold it because it is reasonably necessary for them to run their payroll and meet their obligations. We do not ask Workers for consent and this policy does not rely on it. The duty to tell Workers what is collected therefore sits largely with the Employer.
An Employer can send a Worker an invitation to the Employee Portal from within the System: an Administrator ticks a box in the Worker’s profile and presses a button, which emails the invitation. It explains what is recorded, who can see it, and that other Workers cannot. It is optional and not automatic, so a Worker who is not invited will not receive it, and it is their employer who must tell them what is being recorded.
We ask every Employer to tell its Workers that it uses the System and what it records, including that a location reading is taken at sign-in; to give them its own privacy notice; to tell them who to approach with a question or correction; and to give access only to people who need it and remove it when they do not. We can build a notice into the System and write a template, but we cannot stand in an Employer’s workplace and explain it.
Information sometimes arrives that we never sought, usually through a free-text field. We do not read those fields as a matter of course and do not monitor what Employers record, so in the ordinary case we will not know. Where we do become aware, what we can do depends on whose record it is: if it is information we hold on our own account and could not properly have collected, we destroy or de-identify it; if it sits inside an Employer’s record, we raise it with them rather than delete it, because their seven-year record-keeping obligation is theirs to meet.
You can ask us a general question about the System, this policy, or how we handle information without telling us who you are. Beyond that, anonymity is not available. A Worker cannot be recorded in the System anonymously or under a pseudonym, because paying someone correctly requires knowing who they are. If you have a concern about being identified in the System, raise it with your employer, since it is your employer that decides to record you in it.
An Employer uses the System to turn work into pay: knowing who worked where and when; turning sign-ins and sign-outs into shifts and paid hours; recording leave and stand-downs; applying the rates, allowances and penalties the Employer has entered; finding and fixing problems in the record before pay is calculated from it; approving a timesheet; passing it to Payroll Software; and keeping records of hours, pay and leave.
Much of that exists because the law requires it. An employer must keep records of its employees’ pay, hours and leave for seven years, must issue pay slips, must withhold tax and report it, and must pay its people at least the applicable award rate. The obligations the System does not help with — withholding tax, paying superannuation and making the payment — are met in the Employer’s Payroll Software, which is why the System holds nothing it would need for them.
Location has one purpose: confirming a sign-in happened at the site it was recorded against. It is not there to follow anyone, is not recorded between sign-ins, and does not run in the background. Section 6 sets this out in full.
Our own purposes are narrower. We hold and use personal information to provide the System and keep it available; to keep it secure, control who can reach what, detect and block attacks and keep a record of what was done in it; to support the people who use it and put things right when it gets something wrong; to run our business, manage subscriptions and keep our accounts; to meet our own legal obligations; and to fix faults and improve the interface, in the bounded sense described in section 2.4. What is absent from that list matters as much as what is on it: we have no commercial use for a Worker’s information beyond providing the System to their Employer.
We may also produce aggregated, de-identified statistics about how the System is used — for example, the average time taken to approve a pay period — to operate and improve it. These statistics do not identify any Employer or individual and cannot be used to re-identify them, so they are not personal information.
We would use information for something other than the purpose it was collected for in a few situations: to investigate a security incident or misuse of the System; where required or authorised by law, or for a court or tribunal proceeding; to establish, exercise or defend a legal claim; where an Employer instructs us within the scope of what we have agreed; and where the individual has consented.
One example comes up in practice. The audit record exists so we can tell what happened after a security incident. It is also how an Employer answers “who changed this person’s hours, and when?” — usually a payroll question rather than a security one. We treat that as a closely related use anyone would expect. What we would not do is hand an audit record to someone who is not the Employer, or use it to build a picture of how an individual works.
These are commitments, not descriptions that might quietly change. We do not sell, rent or trade personal information. We do not use a Worker’s information to market to them or advertise to anyone whose records the System holds. We do not use anything held in the System to train or improve an artificial intelligence model; if that ever changes it will require an Employer’s explicit agreement, be off by default, and be stated here first. We do not build profiles of Workers, score them, or produce any assessment beyond the calculations and record-keeping described in this policy. And we do not give information about a Worker to anyone but their own Employer, except as sections 8 and 9 set out.
The System flags things about individuals so timesheets come out right: that someone signed in late, that a shift was unusually short, that a sign-out is missing. Those flags exist to protect the accuracy of a timesheet, and that is the only reason we produce them. But an Administrator can see them, and an Employer may take them into account for other things — a conversation about lateness, a rostering decision, a disciplinary process. That is the Employer’s decision. We do not make it, are not told about it, and do not advise on it. A Worker reading this should understand that a record of when they arrived exists, that their employer can see it, and that its use is a matter between them and their employer. If you think something in the record is wrong, section 12 explains how to have it corrected.
A payroll-adjacent system would normally hold both. Ours holds neither.
Tax file numbers. The System has no field for one. We do not ask for one, do not record one, and there is nowhere for one to be stored. A Worker’s tax file number is given to their employer, normally on the Australian Taxation Office declaration form, and stays in the Employer’s Payroll Software. The one qualification is in section 2.1: the connection to Payroll Software can technically reach an employee record containing one, and our software is written so it never reads that part of the record.
Superannuation details. We do not hold a Worker’s USI or member number, do not calculate contributions and do not make them. Superannuation is worked out and paid through the Employer’s Payroll Software. The System stores the name of a Worker’s fund, as section 2.1 explains, but does not display or use it, and a fund name alone cannot be used to access or move anyone’s superannuation.
Neither omission is a gap we intend to close. The System records work; withholding tax and paying superannuation happen in the Employer’s Payroll Software, and the information those tasks need belongs there.
Why it matters. A tax file number is issued to a person once and stays with them for life, which is why Australian law regulates it more tightly than almost any other personal information. Had we chosen to hold them, three sets of obligations would apply: the Privacy (Tax File Number) Rule 2015, a legally binding rule issued under section 17 of the Privacy Act 1988 (Cth); sections 8WA and 8WB of the Taxation Administration Act 1953 (Cth), which make unauthorised requesting, recording, use or disclosure a criminal offence; and the Notifiable Data Breaches scheme, which applies to anyone holding tax file number information whatever their size.
The rule permitting a service provider engaged by an employer to hold tax file number information turns on whether access is reasonably necessary to provide the service. Ours is not. The System does not calculate tax, produce pay slips or pay anyone. A tax file number would sit in our database serving no function, carrying real risk to the Worker it belongs to. The honest answer is that we do not hold them because we do not need them.
For a Worker, the most sensitive number attached to your working life is not in our system and cannot be exposed by anything that happens to it. For an Employer, using the System does not put your workers’ tax file numbers into an additional set of hands. If we ever needed to hold this information, we would update this policy before doing so, and the obligations above would then apply to us in full.
When a Worker signs in or out on the shared device at their site, or from their own phone through the Employee Portal, the System records the coordinates the device reports, how accurate that reading was, and the street address they correspond to. Location capture is on by default; whether a reading is taken at all depends on the location settings the Employer has chosen, and the record notes which way the sign-in was made.
That is the whole of it. There is no collection between sign-ins. The System does not run in the background, does not follow a device through the day, and does not build a trail of anyone’s movements. On a normal day a Worker generates two location records. Between them the System has no idea where anyone is and no way of finding out.
To confirm a sign-in happened at the site it was recorded against. That matters because hours are calculated from these records and site-based allowances depend on which site someone was at, so an attendance record that cannot be checked is one a dispute has no way of resolving. An Employer also has a safety interest in an accurate record of who was on a site and when, which becomes important after an incident.
This is verification, not monitoring, and the distinction is real rather than a comfortable choice of word. Verification answers “was this sign-in made at this site?” Monitoring answers “where is this person?” The System is built to answer the first and cannot answer the second.
It never drives an automated decision about pay: nothing about a Worker’s pay, hours or entitlements is decided on the basis of where they were, and section 7 lists what the System does decide automatically.
By default a location reading never blocks a sign-in either. A reading that fails, arrives inaccurate, or places someone outside the expected area does not reject them and does not stop the sign-in being recorded.
One exception, chosen by the Employer. An Employer can switch on a setting that requires a Worker clocking in from their own phone to be within a set distance of the site — 500 metres unless the Employer changes it. The setting works only while location capture is switched on. Where it is switched on, a clock-in from outside that distance is refused and the Worker is told the distance and asked to move closer or contact their supervisor, who can record the shift by hand. The setting is off unless an Employer turns it on, it applies only to the Employee Portal on a personal phone and never to the shared device at a site, and a Worker who declines location permission is asked for it rather than being locked out of a day’s pay. An Employer turning it on is carrying out workplace surveillance and must tell its Workers first — see sections 3.3 and 6.7.
Where the setting is off, providing a location is not compulsory in order to be paid. If a Worker declines location permission on the device the sign-in still works and their hours are still recorded. An Employer can switch location collection off entirely, in which case nothing is recorded for anyone in that business. One qualification: declining is possible but not invisible. An Administrator can see that no location was captured against a sign-in. The System does not penalise it, flag it as a problem, or treat it as a reason to question anyone.
An Employer’s Administrators can see location records for their own workforce, and a Foreman for their assigned sites. No Worker can see another Worker’s location record, and the shared device shows only who has signed in that day, with no location detail beside a name. We can reach location data in the course of operating and supporting the System, under the controls in section 10.
To turn coordinates into a street address they are sent to a geocoding service run by the OpenStreetMap Foundation, which operates in Europe, so a set of coordinates and the address they resolve to leave Australia at that point. It is a free, community-operated resource rather than a commercial provider we hold a contract with, which means there is no processing agreement behind it and no service commitment. If it is unavailable the step simply fails and the sign-in proceeds without an address attached.
Twelve months after a sign-in or sign-out is recorded, its location is permanently deleted. An automated job runs every night and, for any event older than 365 days, overwrites all four location fields — the latitude, the longitude, the accuracy reading and the reverse-geocoded street address — and sets them to empty. The timesheet itself remains intact: the record that someone worked a shift survives, but where they were when they signed in or out is gone from the live system and cannot be recovered from it. Older copies remain in backups only until the backup window described in section 11 passes.
There is no single Australian law governing workplace location tracking, and where an Employer operates changes what applies to them. In Queensland there is no dedicated workplace surveillance legislation. In New South Wales and the Australian Capital Territory the position is different: the Workplace Surveillance Act 2005 (NSW) and the Workplace Privacy Act 2011 (ACT) specifically regulate tracking surveillance of employees and impose notice requirements before it begins. An Employer operating in those jurisdictions has obligations a Queensland employer does not and should take its own advice. Other states rely on general surveillance devices legislation, which varies.
We cannot discharge those obligations for an Employer and do not attempt to. Section 3.3 sets out what we ask every Employer to tell its workforce, and the location reading is the item we would most want a Worker to have heard about beforehand rather than afterwards.
If you are uncomfortable with a location being recorded when you sign in, the conversation to have is with your employer, since it is their decision whether to use the feature. Section 12 explains how to have a record corrected and section 13 how to complain.
There is no artificial intelligence in the System. It contains no artificial intelligence or machine learning component, calls no such service, and nothing held in it trains any model. What follows is ordinary software applying fixed rules.
The System pairs sign-ins with sign-outs to build shifts; rounds start and finish times using rules set for each site — when the day starts, how long the grace period runs, what interval times round to, when an early finish counts as one — and produces paid hours; works out a gross figure from those hours and the rates, multipliers and allowances an Administrator has entered; and flags problems such as a missing sign-out, an unusually short or late shift, duplicate entries, or hours that look like overtime.
Where an Administrator has recorded an award code and a classification for a Worker, and has entered a minimum rate for that classification, the System also compares that Worker’s base rate against the minimum rate entered when the pay period is sent to Payroll Software, flags the Worker to an Administrator where the base rate is lower, and holds the transfer until an Administrator corrects the rate or records a reason for proceeding. It is one number compared against a figure the Employer typed in. We supply no award rates. It does not check penalty rates, loadings, allowances, overtime or apprentice progression, it does nothing at all where no minimum rate has been entered or where the award code or classification is blank or does not match, and it is not a determination that pay is lawful.
These are fixed rules, not learned behaviour. The same inputs give the same result every time and the calculation can be re-run and checked. Where a shift cannot be worked out safely — a sign-in with no matching sign-out — the System leaves the hours blank rather than guessing, forcing a person to resolve it.
Nothing the System calculates takes effect on its own. A timesheet moves from draft to reviewed to approved one step at a time and the review step cannot be skipped. Approval is restricted to an Administrator and recorded against their name. Nothing reaches Payroll Software until unmatched employees, unapproved shifts and unresolved alerts are cleared, and until any Worker flagged below an entered minimum rate has been corrected or an Administrator has recorded a reason for proceeding. And a shift an Administrator or Foreman has manually corrected is not overwritten when the calculation is re-run.
Time rounding adjusts paid hours up or down automatically. A person approves the timesheet as a whole but not each rounded shift unless something is flagged. The rules are fixed and documented, the rounded times are visible on the timesheet, and any shift can be overridden by hand.
Account lockout. Five failed sign-in attempts within fifteen minutes lock an account, and unusually heavy request volume from one address is throttled. This affects access rather than pay and expires on its own.
From 10 December 2026, Australian Privacy Principles 1.7 to 1.9 require an entity to set out in its privacy policy where it has arranged for a computer program to use personal information to make, or do something substantially and directly related to making, a decision that could reasonably be expected to significantly affect a person’s rights or interests. The requirement captures rule-based software as well as artificial intelligence, and is a transparency measure rather than a right to contest a decision.
This applies to us. The rounding rules are the clearest example in scope: they determine paid hours, and paid hours determine what a Worker is paid. Section 7.1 sets out the information those rules use — recorded sign-in and sign-out times and the rounding configuration for the site. Section 7.3 identifies the automated steps that are not individually reviewed. Where an Employer has switched on the geofence described in section 6.3, that check also runs without individual review: it decides whether a clock-in from a personal phone is accepted at that moment, and a refusal is resolved by a supervisor recording the shift by hand.
Within an Employer’s business, information is visible according to the levels of access in section 1.1: Administrators across the workforce, Foremen for their assigned sites, Workers for their own record. On the shared device at a site, a Worker can see who else has signed in that day.
Receipts are an exception: they are visible to Administrators, and a Foreman sees only the receipts they submitted themselves.
Reports an Administrator downloads. An Administrator can download a payroll summary (one row per Worker per pay period, showing gross pay, overtime, allowances and leave days taken) and a wage register (the same, with pay-run totals and a list of leave). Nothing is emailed or sent automatically. The Employer decides who receives these files, for example its accountant. Once downloaded, a file is outside the System and outside our controls, and how it is stored and shared is the Employer’s responsibility.
To the services the System runs on. Operating the System requires a small number of external services, each handling a defined part of the information:
Section 9 identifies where each operates. We give none of them information beyond what the function requires.
Where the law requires it, we may disclose personal information to a court, tribunal, regulator or law enforcement agency, and to our professional advisers, who are bound by their own obligations of confidence.
If our business changes hands, information may transfer as part of a sale, merger or restructure. Any acquirer would be bound by this policy or one no less protective, and we would tell every Employer before it happened.
We do not sell, rent or trade personal information. We do not disclose one Employer’s information to another. We do not give information about a Worker to their employer’s clients, insurers, industry bodies or anyone else, except on that Employer’s instruction or where the law requires it.
The System and its database are hosted in Australia, in Microsoft Azure’s Australia East region in Sydney. Backups are held in the same region. Archived audit records are also copied to storage replicated between Sydney and Melbourne. The full dataset — every Worker record, timesheet, pay figure and audit entry — stays in Australia.
Where an Employer connects MYOB rather than Xero, the timesheet information sent to it is hosted in Australia and does not leave the country. Connecting MYOB instead of Xero therefore removes the Xero transfer described below.
Three things leave Australia for every Employer:
Three more depend on choices an Employer makes:
Taken together, personal information may be handled in the United States, New Zealand and Europe.
The three levels of access in section 1.1 are enforced on the server for every request, not merely hidden in the interface. A Foreman is restricted to their assigned sites and a Worker to their own record, and the System resolves who owns a record before allowing access. An attempt to reach someone else’s record is refused and logged. Each Employer’s information sits in its own isolated schema within the database, separate from every other Employer’s, and no account anywhere can see across Employers.
Sign-in is protected by a minimum password length of eight characters, a blocklist of common passwords, and one-way hashing so stored passwords cannot be read or recovered. Repeated failed attempts lock an account. A session expires twenty-four hours after sign-in. Multi-factor authentication using an authenticator app is available to Administrators and Foremen. It is off unless an Employer switches it on; it is not available to Workers.
Where someone forgets a password, the System emails a single-use link rather than a password. The link expires, cannot be reused, and what we store is a hash of it rather than the link itself, so a reset cannot be replayed from our records. A password is never sent by email. The same mechanism issues verification and Portal invitations.
Everything travels over encrypted connections, and the database is encrypted at rest by the hosting platform. The most sensitive stored values — such as authenticator secrets and the credentials for an Employer’s Payroll Software connection — carry a second layer of encryption applied before they are written, with the key held outside the database. Secrets are stripped before anything reaches a log. Every meaningful action is recorded in an audit log the application can only add to, and the most significant actions raise an alert visible to Administrators within the System.
We maintain an automated security test suite and run it in full before each release, against a test copy of the System rather than the live service. It checks specific failure modes rather than general behaviour: whether a user can reach a record outside their permitted scope, whether authentication and lockout hold up, whether input can be used to inject code, whether rate limiting works, whether sensitive fields leak through any interface or log, whether the audit trail records what it should, and whether one Employer’s data can reach another’s. A release does not go ahead unless the suite passes. Credentials are scanned for and blocked before code can be committed. This testing is carried out by us rather than by an outside party.
No system is completely secure, and we would rather name our limits than imply we have none.
Payroll and employment records — hours, pay figures, leave and the records behind them — are kept for seven years while an Employer subscribes, matching the period an employer must keep employee records. The most recent twelve months are displayed in the System; older records are retained but not shown, and an Employer can ask us for a copy of them at any time while they subscribe.
Receipts submitted for an expense or allowance claim are kept for seven years on the same basis as the records they support.
Location coordinates are permanently deleted after twelve months, as section 6.6 explains, leaving the timesheet intact but removing where a Worker was. Audit records stay readily searchable for two years, are then archived, and are kept for seven years in total. Account details for Administrators and Foremen are kept while their access is active and for as long as the audit record requires afterwards.
When a Worker leaves an Employer, they are normally marked inactive, which keeps the record intact for the Employer’s own obligations. Where an Employer purges a Worker entirely, all of that Worker’s records are deleted from the live system. The most sensitive values — a QLeave worker number and any authenticator secret — are first overwritten with random data; everything else is removed by ordinary database deletion. Deleted information remains in backups until the backup window described below passes.
When an Employer stops using the System we export their data and provide it back to them, so they continue to hold the records they must keep. Access is then disabled immediately, which blocks everyone in that business from signing in but deletes nothing. After a thirty-day grace period the Employer’s entire schema, and everything in it, is deleted. The seven-year retention above applies only while an Employer subscribes; once they leave, meeting their own record-keeping obligation depends on the export they take.
Backups, stated accurately. Backups are continuous and support restoring the System to any point within a retention window of thirty-five days. A backup cannot have one Employer’s data surgically removed from it — a property of how point-in-time backups work rather than a choice we have made. So when information is deleted from the live system it continues to exist inside older restore points until the retention window passes the deletion date. The accurate statement about any deletion is that the information was removed from the live system on a given date, and was no longer present in any backup after that date plus thirty-five days.
Asking for your account to be deleted. A Worker can request deletion of their account from the Employee Portal, including in the mobile app, using Delete my account at the foot of the portal. Pressing it does not delete anything immediately. The request is recorded and emailed to your employer’s Administrators rather than left to a conversation, and you can keep using the portal until your login is closed. It is your employer who acts on it, because they control the record and hold the relationship with you.
What that removes is your access. It does not erase your time and pay records, and no request to us or to your employer can, because those are your employer’s employment records and the Fair Work Act obliges them to keep them for seven years — see the retention periods above. This is the same position section 12 describes for corrections: the record must stay reliable as evidence of what was worked. If you want a copy of what is held about you before your access closes, ask your employer for the per-person export described in section 12. An Administrator wanting to close their own business’s account should follow the offboarding paragraph above rather than this path.
What is not yet automated. There is no single-action export covering an entire Employer; offboarding is assembled from several separate exports. The final deletion of an Employer’s schema is performed manually rather than by a command that checks the grace period and records itself, so the thirty-day period is our documented practice rather than something the software enforces. And archived audit records sit on the application server rather than in the database, so they are not covered by the database backups; each archive is instead copied to the separate storage described in section 10.4.
If you are a Worker, start with your employer. They hold the relationship with you, control what is in the System about you, and an Administrator can correct a record immediately. Asking us first will slow you down, because we would refer you back to them in almost every case. If your employer cannot resolve it, or you believe they have refused without good reason, contact us using the details in section 14.
An Administrator can generate a complete record of everything the System holds about one person in a single action, covering their profile and its history, sign-in events, shifts, leave and the figures calculated from them. Every export is written to the audit log.
Corrections are made by an Administrator on the Worker’s behalf. A Worker cannot amend their own record directly, because the record must stay reliable as evidence of what was worked. A Worker can ask for an amendment through the Employee Portal, which records and tracks the request rather than leaving it to a conversation. The change itself is still made by an Administrator. Changes to key fields are recorded with the values before and after and the name of the person who made them, and pay profiles are effective dated so historical records are not silently rewritten.
We acknowledge a request promptly and respond within thirty days. There is no charge for correcting information. If a correction is refused the reason will be given in writing, along with how to complain about that decision. One qualification: the System provides the tools to answer these requests quickly but does not enforce a deadline or a reminder, so the timeframe is a commitment we make and ask Employers to make rather than something the software imposes.
If you are a Worker and your concern is about information your employer holds or how they use it, raise it with your employer first.
If your concern is about something we have done, contact us using the details in section 14. Tell us what happened and what you would like done about it. We will acknowledge your complaint within five business days and give you a written response within thirty days. If we need longer, we will tell you why and when to expect an answer.
If you are not satisfied with our response you can complain to the Office of the Australian Information Commissioner at oaic.gov.au or on 1300 363 992. You do not need our permission, and you can approach them at any point. Depending on the circumstances, other avenues may also be open to you.
For any question about this policy, about information we hold, or to make a request or a complaint:
| Contact | Details |
|---|---|
| Entity | Adaptare Intelligence Pty Ltd — ACN 701 658 022, ABN 53 701 658 022 |
| Privacy contact | Darcy Johnston |
| [email protected] | |
| Registered office and postal address | 10/262 Leitches Road, Brendale QLD 4500 |
We aim to answer straightforward questions within five business days, and requests to see or correct information within thirty days.
We will update this policy as the System changes and as our obligations change. The current version is always available on our website and within the System, and the version number and date at the front tell you which version you are reading.
Where a change is material — a new category of information, a new disclosure, a new overseas recipient, or a change to how long we keep something — we will tell Employers before it takes effect and say plainly what changed.