Biometric Device Not Syncing Punches
The device status reads offline, or it reads online but no attendance appears against your employees.
There are two different faults here and they need different fixes. If the device shows offline, it is not reaching NepalHRM at all, which is a network or a device-configuration problem. If the device shows online but attendance is empty, the punches are arriving and sitting unattributed, which is almost always because device user IDs are not mapped to employees. Check which of the two you have before changing anything, because the fixes do not overlap.
Work through these in order
Cheapest first. Each step says what you should see if it worked, so you can stop as soon as it does.
Read the device status first
Open the biometric devices screen and look at the status against the device. Offline and online lead to completely different fixes, and guessing wrong costs an afternoon.
You know which half of this guide applies.
Offline: confirm the device can reach the server
On the device, check the server address and port your IT team configured. Then confirm the firewall on the NepalHRM side accepts the connection. A device with a green network icon can still be blocked one hop later.
The status flips to online within about a minute of a device reboot.
Offline but the device says connected: check the server mode
A ZKTeco unit set to plain web-server mode connects to the network happily and never pushes attendance. It has to be in the push mode your installer configured. Change it and reboot the device.
Punches start appearing as raw device logs.
Online with no attendance: map device users to employees
Open the device and go to its user mapping. Every device user ID has to point at an employee record. Unmapped IDs are stored as raw logs and never become attendance. You can upload the mapping as a CSV rather than clicking through it.
New punches turn into attendance the same day.
Recompute the dates you just fixed
Mapping is not retroactive by itself. Open the device, choose Recompute, and give it the date range you want reprocessed. Historical raw logs are then attributed to the right people.
The missing days fill in for the range you chose.
Check for a duplicate serial number
If punches from one machine land against the wrong site, look for a second device record carrying the same serial. This has happened in production. Retire the stale record rather than editing the live one.
Punches land on one device record only.
Check the device timezone
Timestamps a day out, or every punch an hour early, is a timezone mismatch between the device and the workspace. Nepal does not observe daylight saving, so a device set to a zone that does will drift twice a year.
Punch times match the wall clock, and a recompute fixes the affected history.
What the system does
- Supported vendors
- ZKTeco and Hikvisionother makes are not supported today
- Nightly reprocess
- 1:30 AMreruns the previous day for every device
- On-demand recompute
- any date rangefor that device's mapped employees only
- Serial numbers
- unique per companya duplicate serial sends punches to the wrong device record
Still stuck? Send us this
Include all of it in the first message and the first reply back is usually a fix rather than a question.
- The device make and model, and its serial number.
- A photo of the device's communication settings screen.
- Whether the status reads online or offline in NepalHRM.
- One employee's name and device user ID whose punch is missing, plus the date.
Asked most often
ZKTeco and Hikvision. Those are the two vendors the application accepts today. If you have another make, ask support before buying more of them, and plan on the attendance import route instead.
The punches are arriving and being stored, but the device user IDs are not linked to employee records, so there is nobody to attribute them to. Map the users, then recompute the dates you care about.
No. A nightly job reprocesses the previous day for every device at 1:30 AM. Recompute by hand only after you change something historical, such as a user mapping, a shift assignment or the device timezone.
It overwrites anything that was typed directly over a day. Corrections made through the regularisation flow survive a recompute, which is the reason to use that flow rather than editing the day directly.
Not on one company. Active devices are held unique on their serial, because a duplicate quietly routes punches to the wrong device record and the attendance looks plausible while being wrong.
Screens, labels and limits change between releases. If something here does not match what you see, tell us and we will correct the page.
Support you can actually reach. From Kathmandu.
Email, phone and WhatsApp, answered in English and Nepali by people who know the product. Most questions are closed on the first reply.
- No minimum commitment
- Nepal IRD compliant
- Free onboarding
- Cancel anytime