From the time clock to the payslip — one straight run +84 789 723 672 Thanhnp87@Gmail.com
Scarlet Sails HRM logo Scarlet SailsHRM Platform
Home/Insights/Multi-site attendance
Operations

Multi-site attendance: four approaches and their trade-offs

From the second location onward, the question stops being "which device is best" and becomes "how do we gather logs into one place without gaps, duplicates, or a security hole".

With one site, attendance is simple. From the second location onward the problem changes shape: how do you gather logs from every device into one place, on time, without gaps, without duplicates, and without turning your time clocks into a security hole?

Approach 1: collect by USB stick

Somebody walks to each device, plugs in a USB stick, downloads the log file, and imports it back at a computer.

Upside: no network needed, no additional investment.

Downside: it depends entirely on one person. When they take leave, the data stops. Remote sites end up emailing or messaging files, which invites sending the wrong period, missing a device, or sending twice and doubling the hours. By the time you notice a gap at month-end it is usually too late to recover it.

Approach 2: vendor software at each site

Each location installs the software bundled with the device, downloads its own logs, exports its own reports, and sends files to head office.

Upside: more automated than the USB route; each site is self-sufficient.

Downside: every site becomes a data island. Employee lists differ between devices, card numbers collide across locations, and anyone transferring between sites has to be re-enrolled from scratch. Answering "where did this person clock in" means opening several files and comparing by hand.

Approach 3: expose the time clocks to the internet

Configure port forwarding on the router so devices at each branch are reachable from outside, and have the central server connect straight into each one.

Upside: centralised data with nothing extra installed at the site.

Downside: this is the riskiest option by a wide margin. Time clocks are embedded devices, rarely patched, and many ship with default passwords and unencrypted protocols. Putting one on the public internet exposes your entire workforce's biometric data. On top of that, a flaky branch connection makes direct sessions drop mid-transfer.

Approach 4: an on-site agent

Each location has one always-on computer running a small service — the agent. It sits inside the internal network, talks to the time clocks, and initiates outbound calls to the central server.

Upside:

  • Time clocks never face the internet, and no inbound ports open into the site network.
  • If connectivity drops, the agent holds logs in a local queue and sends them when the link returns — nothing is lost.
  • One employee list at the centre, so card numbers stop colliding.
  • Logs carry device information, so every punch is traceable to a location.
  • The centre can push commands down: test the connection, sync now, read the device clock.

Downside: you need one always-on machine per location and a first-time install. The hardware requirement is modest.

Side by side

CriterionUSBVendor SWInternet-exposedAgent
AutomatedNoPartlyYesYes
Centralised dataNoNoYesYes
SecurityFairFairPoorGood
Survives connection lossPoorGood
Traceable to a siteHardHardYesYes
Operational effortHighMediumLowLow

Which one to pick

  • One site, under 50 people: USB still works. No investment needed.
  • Two sites or more: move to an agent. The added cost is one old computer left switched on per location.
  • Night shifts or heavy overtime: an agent becomes close to mandatory, because data has to arrive in time to process attendance daily rather than piling up until month-end.
  • Avoid entirely: exposing time clock ports to the internet, unless your IT team is equipped to place them behind a VPN and monitor them continuously.

Scarlet Sails HRM uses the on-site agent model: outbound only, with a local queue against data loss and deduplication by device, employee code and punch time. See Time clocks & synchronisation.

Want to test this on real data?

Send one month of your punch data. We will run it and point at exactly where it diverges from your policy.

Zalo