Biometric and Access Attendance Connector

The problem with monthly attendance uploads

Factories, clinics, warehouses, security firms and retail chains already have attendance hardware on the wall — fingerprint and face terminals, RFID readers, turnstiles, access-control panels. That hardware records punches perfectly well. What it does not do is speak Zoho.

So the process becomes: an HR administrator exports a device log at the end of the month, opens it in a spreadsheet, reconciles duplicated punches, guesses which of four punches was the real clock-out, applies grace periods and overtime rules by hand, splits the night shift that crosses midnight into two days, and then bulk-imports a summary into Zoho People. Payroll is calculated from that summary. Errors surface as pay disputes, and by then the raw device log has usually rolled over.

The underlying issues are structural, not clerical. Shift awareness: a raw punch means nothing until it is assigned to the correct shift, and a night shift starting 22:00 belongs to the previous calendar day. Multiple devices: an employee badges in at the gate turnstile and out at the shop-floor terminal, and no single device holds the full picture. Timing: managers cannot see today's absences until next month's upload. Traceability: once the summary is imported, the link back to the individual punch is gone.

ECOSIRE builds a connector that removes the spreadsheet from the middle of that chain.

What ECOSIRE builds

Device collection

We build a collection layer suited to how your terminals actually expose data: a scheduled pull from the device or controller SDK or HTTP endpoint on your network, an inbound push endpoint the device or middleware posts to, or a watched drop folder or SFTP location where the terminal writes its log file. Where the vendor exposes only a database, we read it directly on a schedule. Collection is incremental with a stored high-water mark, plus a periodic backfill sweep, so a terminal that loses network for a day catches up automatically rather than leaving a silent gap.

Each raw punch is stored verbatim — device ID, employee device code, timestamp, direction if the device reports one, verification mode — before any interpretation happens. That raw log is what you go back to when a pay dispute lands.

Employee identity mapping

Device enrolment numbers rarely match Zoho People employee IDs. We build a mapping table linking each device code, card number and biometric enrolment ID to the corresponding Zoho People employee record, supporting employees enrolled on several devices across sites. Unmapped codes are quarantined and surfaced for HR to resolve rather than being silently discarded — an unmapped punch is a person who worked and might not get paid.

Shift-aware punch interpretation

This is the substance of the build. A Deluge processing engine converts raw punches into attendance entries against the employee's assigned shift in Zoho People:

• pairs the first-in and last-out of a shift window, collapsing duplicate punches inside a configurable de-bounce interval
• assigns punches that cross midnight to the correct shift date for night and rotating shifts
• applies grace periods, late-arrival and early-departure rules, and minimum-hours thresholds as you define them
• computes break deductions, either from actual break punches or as a fixed policy deduction
• calculates overtime by your policy — daily threshold, weekly threshold, rest-day and public-holiday multipliers — and flags whether it was pre-approved
• handles employees who work across two sites in one day by merging device streams into a single timeline
• flags missing punches, impossible sequences and out-of-shift attendance as exceptions instead of writing a guess

Writing into Zoho People and Payroll

Processed entries post into Zoho People attendance through the People API, respecting the employee's shift and roster assignment. Leave and holiday records already in Zoho People are read first, so an approved absence is not reported as a missing punch. Exceptions raise a regularisation request routed to the employee's reporting manager through the People approval flow, so corrections happen in Zoho with an approval trail rather than in a spreadsheet.

At period close, we build the payroll handoff: approved attendance, overtime hours by category, late deductions and unpaid-absence days are compiled into the input format your Zoho Payroll organization consumes, or written directly through the Payroll API where your edition supports it. Nothing reaches payroll until the period is locked and approved by the role you nominate.

Rosters, dashboards and alerts

Where shift rosters are currently maintained on paper or in spreadsheets, we build roster management as a Zoho Creator application that publishes assignments into Zoho People, including rotation patterns, swaps and coverage checks. Supervisors get a live view of who has clocked in, who is late, and which shifts are short-staffed. Zoho Flow automations send alerts — device offline for longer than a threshold, unmapped enrolment codes accumulating, a site under minimum coverage, an employee approaching an overtime cap.

Who this is for

Manufacturing plants and warehouses running multi-shift operations with terminals at several gates; clinics and hospitals with rotating rosters and night duty; retail and hospitality chains with many small sites and part-time staff; security, facilities and contracting firms deploying staff across client locations; and any organisation on Zoho People where attendance still arrives as a monthly spreadsheet.

How delivery works

1. Scoping call. We inventory your terminals, models and how each exposes data; your sites, shift patterns and overtime policy; your Zoho People and Payroll editions; and how attendance currently reaches payroll. Network access and enrolment data samples are agreed here.

2. Fixed quote. A written scope covering devices, sites, shift rules, exception handling and the payroll handoff, with a fixed price and delivery date. Work starts only on your approval.

3. Build. We develop the collection layer, mapping tables, Deluge processing engine, People and Payroll integration and any Creator roster app, testing against exported logs from your actual terminals.

4. Install in test. Deployed to a test People environment and run in parallel against a historical period, comparing our computed attendance line by line with your existing manual result until the differences are explained and the rules agreed.

5. Production. Installed in your live Zoho org, devices connected, employees mapped, and the first live payroll period run alongside your HR team with manual verification as a safety net.

6. Support. A defined support window for defect fixes, rule adjustments and device changes, extendable as your estate grows.

Typical lead time is one working week from approved quote, depending on device count, site count and shift-rule complexity.