A mobile attendance and employee self-service app built directly on ERPNext and Frappe HRMS.
The problem with attendance
Most companies in the Gulf run attendance one of three ways, and all three leak.
Biometric terminals at the door. Accurate at the point of scan, useless everywhere else. A fixed device only knows who walked past it. It cannot tell you whether the technician assigned to a customer site actually reached that site, whether the driver stayed there, or whether the storekeeper took a three-hour break. And the data lands in a proprietary database that someone has to export and reconcile against payroll every month.
Paper registers and supervisor WhatsApp messages. Zero infrastructure cost, zero reliability. Attendance becomes whatever the supervisor remembers or is willing to say. Overtime disputes become arguments about memory.
Generic attendance SaaS apps. Slick front end, sealed back end. You get check-in logs in someone else’s cloud, and then you export CSV files and hand-key them into your ERP. The moment attendance and payroll live in two systems, they disagree — and reconciling them becomes a monthly task nobody wants.
CheckIN was built to close that last gap specifically. It is not an attendance system with an ERP export. It is an attendance interface that writes into ERPNext directly, so the record the employee creates on their phone is the same record payroll reads.
What CheckIN is
CheckIN is a mobile application for employees, backed by your existing ERPNext / Frappe HRMS instance.
The employee opens the app, authenticates, and checks in. That action creates an Employee Checkin record in Frappe HRMS. When the shift is processed, HRMS’s auto-attendance engine converts those check-in and check-out logs into an Attendance document. Payroll reads Attendance. Nothing is imported, synced, or reconciled — there is only one database.
Because CheckIN sits on top of Frappe HRMS rather than beside it, everything HRMS already does is available: shift types, holiday lists, leave allocation, leave approvers, expense claim workflows, salary structures, and overtime calculation. CheckIN does not reimplement HR logic. It gives employees a phone-shaped door into the HR logic you have already configured.
Core attendance
Check-in and check-out
The primary screen is deliberately one button. The employee taps it. The app captures the timestamp, the device identity, and — where enabled — the location, and posts a log to the ERP.
Each log carries a type (IN or OUT), so shift processing can pair them correctly. Frappe HRMS supports both alternating entries and strictly based on log type pairing; CheckIN sets the log type explicitly, which is the more reliable mode and the one we recommend in every deployment where employees may take breaks or check in more than twice a day.
The employee sees their current state at all times: checked in since 07:12, on break, or checked out. There is no ambiguity about whether the tap registered.
Offline tolerance
Sites in the Gulf are not all covered by good mobile data. Basements, warehouses, remote plots, and industrial areas routinely drop signal. If CheckIN could only record attendance while online, it would fail exactly where it is needed most.
Logs are captured locally with their true timestamp and queued. When connectivity returns, the queue flushes to the ERP. The recorded time is the time the employee actually tapped, not the time the network recovered. Location, where captured, is stored with the log at capture time for the same reason.
Break tracking
A shift is not a solid block of work. Prayer breaks, meal breaks, and statutory rest periods all interrupt it, and in many contracts the treatment of paid versus unpaid break time directly affects payable hours.
CheckIN records break start and break end as their own events against the shift. The result is a shift with structure rather than a shift with two endpoints:
07:00 IN
12:15 BREAK START
13:00 BREAK END
15:40 BREAK START
15:55 BREAK END
18:30 OUT
From that log, gross duration, break duration, and net worked hours are all derivable — not estimated. When a payroll query arrives three months later asking why an employee was paid 9.5 hours instead of 11, the answer is in the record.
Break policy stays configurable on the ERP side: whether breaks are deducted from payable hours, whether a maximum break duration applies, and whether exceeding it flags the shift for supervisor review.
Multi-site work and geofencing
This is the feature that most distinguishes CheckIN from door-mounted biometric hardware, and the one most relevant to contracting, facilities management, security services, logistics, and field maintenance businesses.
Defining sites
Sites are master data in the ERP, not settings buried in a mobile app. Each site carries a name, a coordinate, and a radius that defines its permitted area. Larger compounds get a larger radius; a single retail unit gets a tight one.
Each employee is then assigned to one site or to several. A technician covering four buildings is assigned all four. A supervisor covering a region is assigned the whole set. A store cashier is assigned one.
Assignment is managed centrally by HR or operations. Employees cannot add sites for themselves, which is the entire point — the boundary has to be defined by someone other than the person being measured by it.
Check-in validation
When an employee checks in, the app compares the captured location against the sites assigned to them. Behaviour on a mismatch is a policy decision made per organisation:
Block — the check-in is refused outside a permitted site. Strict, appropriate for fixed-post roles.
Warn and record — the check-in proceeds but is flagged for review. Suitable where genuine exceptions occur regularly.
Record silently — the location is stored for reporting only, with no enforcement.
Most deployments start on warn and record and tighten later, once the data has shown where the real exceptions are. Enforcing a boundary before you know your own exception patterns generates a queue of angry supervisors on day one.
Where an employee is assigned multiple sites, the log captures which site they checked in at. That single field turns attendance data into deployment data: hours by site, coverage by site, cost by site. For contracting businesses billing clients per site, this is the difference between an estimate and an invoice you can defend.
Optional geofence exit detection
This feature is optional and off by default. That is a deliberate design decision, not a limitation.
When enabled, the app monitors whether the employee remains inside the geofence of the site they checked in at. If they leave the area and do not return within a configured grace period, the app can auto-record an OUT event at the time of departure.
The case for it: employees who leave a site without checking out — deliberately or through simple forgetfulness — otherwise accumulate hours they did not work. In roles where a physical presence is the deliverable, that is a real and recurring cost.
The case against it, which we raise with every client before enabling it: continuous location monitoring is intrusive, consumes battery, and legitimately unsettles employees. It also generates false positives — a technician who walks to a supplier for a part, a driver who leaves for a fifteen-minute errand, a GPS fix that drifts on a bad day.
So we build it as a switch you own, with a grace period you tune, and we recommend a rollout in three stages:
Enable in reporting-only mode. Auto-OUT events are logged as suggested, not applied.
Review a full month. Tune the grace period and site radii against the exceptions you find. The false-positive rate almost always comes from radii drawn too tight, not from employee behaviour.
Enable enforcement only for roles where it is genuinely warranted, and tell employees clearly that it is on.
An attendance system that employees believe is dishonest with them produces dishonest attendance. Transparency here is not a courtesy; it is what makes the data usable.
Employee self-service
The people who need to submit expenses and request leave are the same people opening the app twice a day. Putting those functions in the same app removes the excuse for paper.
Expense submission
Employees create an expense claim from the phone, with a photographed receipt attached. Claim type, amount, date, project or cost centre where relevant, and description.
The claim becomes a standard Expense Claim document in ERPNext and enters whatever approval workflow you have already configured. Approvers act in ERPNext or in their own app. Once approved, the claim flows to accounting and reimbursement exactly as an internally raised claim would.
There is no separate expenses inbox, no email chain, no reimbursement spreadsheet reconciled against receipts at month end. The receipt image is attached to the accounting document from the moment of capture — which is also the moment it is most likely to still exist.
Leave requests
The app shows current leave balances by leave type, drawn live from HRMS leave allocation, then lets the employee submit a request against them.
Because balances come from the ERP rather than from the employee’s memory, most invalid requests never get raised. HRMS validation still applies: allocation limits, holiday lists, blocked periods, and overlap checks. The approver is whoever the ERP says the approver is.
The employee sees the status of each request — pending, approved, rejected — without asking anyone.
Attendance history
Employees can see their own attendance logs: dates, check-in and check-out times, break durations, net hours, and status.
This does more work than it appears to. Most attendance disputes are not fraud; they are one party discovering, weeks later, that a record differs from their recollection, with no way to check anything at the time. When the employee can see their own log daily, discrepancies surface within a day of the event, while the facts are still recoverable. Payroll month-end gets quieter.
Authentication
Attendance data is only as trustworthy as the identity behind it. CheckIN supports several authentication methods so the level of assurance can match the role.
QR code
Fast onboarding and fast daily use. A QR code can carry an enrolment token — the employee scans, the device binds to their ERP employee record, and no credentials are typed. For daily use, site-posted QR codes can also serve as a physical presence factor: the employee has to be at the site to scan the code there.
Practical for large workforces where typing usernames on a phone keypad is a real friction point, and for workers who are not comfortable with text-heavy interfaces.
Username and password
The baseline. Credentials are the employee’s ERPNext user credentials, so account lifecycle stays in one place: an employee disabled in ERPNext cannot check in, immediately, without a second system to remember.
Multi-factor authentication
For roles where a shared or stolen password would be materially damaging — supervisors approving others’ attendance, payroll staff, administrators — MFA adds a second factor at login.
Device binding
A CheckIN installation can be bound to a specific device for a specific employee. Attendance from an unrecognised device is rejected or flagged, depending on policy. This closes the simplest and most common abuse: handing your credentials to a colleague so they can check you in from their phone.
Active biometric authentication
Passive face matching against a stored photograph is defeated by holding up a photograph. Active biometric authentication — liveness detection — requires the person in front of the camera to respond to a real-time prompt, proving a live human is present rather than a static image or replayed video.
CheckIN supports active biometric verification at check-in for roles where presence assurance genuinely matters. It answers a question a password cannot: not did someone with the right credentials check in, but was this specific person actually here.
Two points we are direct about with clients. First, biometrics are personal data and attract legal obligations that vary by jurisdiction; collection needs a stated purpose, retention limits, and employee notice. Second, biometrics should be one factor, not the only one — cameras fail, faces change, and lighting on a construction site at 05:30 is not lighting from a product demo. There must always be a supervised fallback path, or you have built a system that locks honest employees out of their own attendance.
Why building on ERPNext matters
It would be easier to build CheckIN as a standalone product with its own database and an ERPNext connector. We did not, for reasons that show up on month twelve rather than day one.
One source of truth. Attendance, leave, expenses, and payroll are the same dataset. There is no sync job to fail silently, no reconciliation report, no divergence to discover at year end.
Your configuration already applies. Shift types, holiday lists, leave policies, approval hierarchies, cost centres, and salary structures are already defined in your ERP. CheckIN uses them. You do not configure your HR policy twice in two dialects and then keep the two versions in agreement forever.
Your data stays yours. Self-hosted or on your own cloud tenancy, on infrastructure you control, in a database you can query. Attendance history does not become a hostage to a subscription.
Extensible, because it’s Frappe. Custom fields, custom validation, custom reports, and custom approval logic are ordinary Frappe development, not vendor feature requests. Every deployment we have done has needed at least one client-specific rule; on Frappe, those take days rather than release cycles.
Auditable. Frappe’s document versioning means every attendance record carries its own history. Who created it, who amended it, when, and from what. In a labour dispute or an audit, that trail is the whole case.
Architecture at a glance
Mobile app (employee)
│
│ authenticated API, offline queue
▼
Frappe / ERPNext instance
│
├── Employee Checkin ← raw IN / OUT / BREAK logs + location + site
├── Shift Type ← pairing rules, auto-attendance, thresholds
├── Attendance ← generated, consumed by payroll
├── Expense Claim ← employee submissions, existing approval flow
├── Leave Application ← employee submissions, existing approval flow
└── Site / assignment ← coordinates, radius, employee-to-site mapping
Logs are raw and immutable. Attendance is derived. Payroll consumes the derivation. If a shift rule changes, the raw logs remain intact and the derivation can be reprocessed — which is exactly the property you want the first time someone asks you to recalculate a month of overtime under a corrected policy.
Who this is for
Contracting and facilities management — workforces distributed across many client sites, where hours must be attributable per site to support billing.
Security and manpower supply — fixed posts where physical presence is the contracted deliverable and coverage gaps carry penalties.
Logistics and field service — mobile employees who never pass a fixed terminal, with break tracking that matters for driving-hours compliance.
Retail chains — multiple branches, shift-based staffing, employees who occasionally cover at another branch, and no appetite for biometric hardware in every unit.
Any ERPNext site already running HRMS — where the payroll logic exists and works, and the only missing piece is trustworthy attendance data feeding it.
Deployment
CheckIN installs as a Frappe app onto an existing bench. A typical rollout:
Install and configure. App installed on your bench; sites defined with coordinates and radii; employees mapped to sites.
Shift alignment. Shift types reviewed so auto-attendance produces correct results from CheckIN’s logs. This is where most of the real configuration effort sits, and where getting it wrong is expensive.
Pilot. One department or one site, geofence enforcement off, for two to four weeks. The pilot exists to find your exceptions, not to prove the software runs.
Tune. Radii, grace periods, break policy, and enforcement mode adjusted against what the pilot actually showed.
Rollout. Remaining workforce onboarded, with enrolment by QR to keep the friction low.
Payroll cutover. Attendance feeds payroll. Run one cycle in parallel with the old method before switching off the old method.
We recommend against enabling every feature on day one. Get clean check-in and check-out first. Add breaks, then geofencing, then biometrics, each once the previous layer is producing data you trust.
Talk to us
CheckIN is developed and supported by ERPGulf. We implement and support Frappe/ERPNext across the Gulf region, including ZATCA e-invoicing compliance, POS integrations, and custom HR and payroll development.
If you are already running ERPNext, CheckIN is an app install and a configuration exercise. If you are not, we can talk about both.
Contact: ERPGulf — support@erpgulf.com
