An attendance system that cannot talk to your other systems creates a new job: someone downloads a spreadsheet every month and retypes it into payroll. That person becomes a permanent integration layer, and they make mistakes, because everyone does. This guide covers the three ways attendance data normally leaves the system, how to choose between them, and the questions to ask before you assume an integration will be straightforward.
Three levels of integration
1. File exports
The system generates a payroll-ready file — commonly CSV or Excel — which someone imports into payroll. Simple, universally supported, and entirely adequate for many organisations, particularly under a few hundred employees with a monthly cycle.
Its weakness is that it is a manual step with a human in the middle, and it is one-directional: payroll learns about hours, but the attendance system never learns that someone left the company.
2. Native connectors
Purpose-built links to specific accounting or payroll products. Where one exists for your stack, it is the least effort — mapping is pre-built and the vendor maintains it. NCheck provides exports for Tally ERP and QuickBooks, which between them cover a large share of small and mid-market finance stacks.
The limitation is obvious: connectors exist for popular systems, not yours specifically. Check before assuming.
3. REST API
The general-purpose answer. A documented API lets your systems read attendance events and reports, create and update employees, manage groups and devices, and drive synchronisation in both directions. This is what you need for anything beyond periodic payroll: real-time dashboards, HR system as the source of truth, or attendance feeding an ERP.
The integration that matters most: joiners and leavers
If you build only one integration, build this one. Your HR system knows when someone is hired and when they leave. Your attendance system needs to know both — the first so they can clock in on day one, the second so their template is deleted and they cannot clock in on day after.
Manual offboarding is where two separate problems meet. Operationally, ex-employees linger in the system. Legally, retention obligations are breached quietly and continuously — the exact failure our compliance hub warns about. Automating leaver-triggered deletion is the highest-value integration in the whole project, and it is usually a small piece of work.
Designing the data flow
Decide which system is authoritative for what, and write it down before anyone starts building:
- HR system owns the employee record: identity, employment status, department, cost centre.
- Attendance system owns the biometric template and the verified check-in events.
- Payroll owns the calculation and the payment.
Trouble almost always comes from ambiguity here — two systems both believing they own shift patterns, and overwriting each other nightly. One authoritative source per data type, synchronised one way, avoids an entire category of support tickets.
Practical API questions to ask
- Is the API included in the licence, or priced separately?
- Is documentation public, so our developers can scope the work before we buy?
- What authentication is used, and how are credentials rotated?
- Are there rate limits, and what are they?
- Can we read raw check-in events, or only computed reports? Raw events matter if you want to build your own logic.
- Are there webhooks for real-time events, or must we poll?
- Can employees be created, updated and deleted through the API — including template deletion?
- Is the API identical in cloud and on-premise deployments?
Question five separates systems you can build on from systems you can only report from. Question seven determines whether your leaver automation is possible at all.
Common integration patterns
Nightly HR sync
A scheduled job reads joiners and leavers from HR and applies them to attendance. Low complexity, handles the most important case, and is usually a day or two of work. Start here.
Payroll period export
At period close, pull approved hours, overtime and absence via the API and post them to payroll. Automating what someone was doing by hand, with the same figures and no retyping.
Live operations dashboard
Poll or subscribe to check-in events to show who is on site now. In manufacturing, construction and healthcare this frequently becomes the most-used output of the whole system — an evacuation muster list that is always current. See construction.
Access control coupling
If attendance and door access share one enrolment, you avoid a second identity database entirely. Where separate systems must coexist, the API is how they stay aligned — see access control.
Things that quietly break integrations
- Time zones. Storing local wall-clock times without offsets is the classic failure; shifts crossing midnight expose it immediately. Confirm the API returns unambiguous timestamps.
- Identifier mismatch. Decide the shared key between HR and attendance early — an employee number, not a name or email, both of which change.
- Silent success. An API that returns success while discarding a field is worse than one that errors. Always read back what you wrote during development.
- Retroactive edits. A supervisor corrects a missed clock-out after payroll ran. Decide how corrections propagate before it happens, not after.
Frequently asked questions
Do we need a developer?
For file exports and native connectors, no. For API integration, yes — typically a few days for HR sync and payroll export combined.
Does the API work with on-premise deployments?
It should be the same API in both modes. Confirm this, because it determines whether integrations survive a future migration — see on-premise attendance software.
Can we push data in, not just read it out?
You should be able to create and update employees, groups and schedules. That is what makes HR the source of truth rather than a parallel spreadsheet.
What about biometric templates over the API?
Templates are normally created at enrolment on a device, not pushed through an API — but deletion should absolutely be available programmatically. See how it works.
A phased integration roadmap
Trying to build every integration before go-live delays the rollout and front-loads work you may later discover you do not need. A three-phase sequence delivers value earlier.
Phase 1 — go live on exports. Launch with file exports into payroll. It works from day one, requires no development, and lets you learn what the data actually looks like in production before you automate anything. Many organisations under a few hundred employees never leave this phase, and that is a legitimate outcome rather than a failure.
Phase 2 — automate joiners and leavers. Once the system is stable, build the HR sync. This is where the compliance and operational benefit lives: no orphaned accounts, no manual offboarding, automatic template deletion on the correct day. Typically a few days of work and the highest return of any integration.
Phase 3 — automate the payroll cycle and add real-time views. With identity synchronisation solid, automate the period export and, if useful, build the live on-site view. Attempting this before phase 2 tends to produce dashboards populated with people who left months ago.
Testing an integration properly
Integrations fail quietly, which is what makes them dangerous — the symptom is usually a wrong number in payroll weeks later rather than an error message.
- Always read back what you wrote. A success response is not proof the value was stored. Write, then fetch, then compare. This one habit catches a whole class of silent failures.
- Test the edges deliberately. An employee who clocks in but never out. A shift crossing midnight. A correction applied after the period closed. Someone rehired after leaving. Each of these breaks naive integrations.
- Test with production-scale data. Behaviour with fifty records differs from behaviour with fifty thousand, particularly around pagination and rate limits.
- Check time zones explicitly. Confirm timestamps carry unambiguous offsets and that a shift starting at 22:00 local appears correctly after transfer.
- Run parallel for one full cycle. Compare automated output against the manual process before switching off the manual process.
Budget for maintenance as well as build. HR systems change fields, payroll providers change formats, and an integration nobody owns is an integration that breaks silently at the worst moment. Name an owner at handover.
NCheck is a biometric attendance system by Neurotechnology that runs on-premises or in the cloud, supports face, fingerprint and iris recognition, and works on phones, tablets, IP cameras and biometric terminals. Free forever for up to 5 employees.
