Implementation
HR and payroll projects rarely fail on features. They fail in the changeover — a migration that quietly drops arrears, a first payroll no one reconciled against the old one, a rollout the shop floor was never trained for. Our implementation method is built to eliminate each of those, and it is the same method on every engagement.
We sit with whoever actually runs payroll and attendance, and map what really happens: your shift patterns, your weekly-off and overtime rules, your leave policy and its exceptions, how many entities and branches, which states you're liable in, and what your attendance hardware is. If your process has a quirk that no textbook approves of, we want to hear it now — that quirk is usually load-bearing.
Implementation is scoped to your estate and quoted in advance — entities and branches, attendance hardware, the data to be migrated, the parallel payroll you want run. The monthly rate is unaffected by it, and nothing on your invoice is a surprise. See pricing →
Shifts, weekly offs, holiday calendars, leave types and accrual, salary structures, statutory profile per state, approval chains, roles and who may see what. This is configuration, not custom code — which matters, because custom code is what makes upgrades frightening. Your rules live as settings, so they can be changed later without a developer and without a release.
Employees, salary structures, opening leave balances, loans and advances, and attendance history come across from whatever you're on now — spreadsheets included.
Every sheet is reconciled against its own totals row before a single record is written. If your register says a figure and the sum of the rows disagrees, the load stops and we come back to you. A migration that "succeeded" but is wrong by a few thousand rupees is worse than one that refused to run, because you find out at month-end.
Before you cut over, we process a payroll in Garuda alongside your existing process, for the same month, and compare it line by line — gross, each allowance, PF, ESI, PT, TDS, net. You sign off on the differences (there usually are some, and they're usually your old process rounding somewhere) before anything becomes the system of record.
You are never asked to trust a first payroll you haven't seen proven against a month you already know the answer to.
Cutover, then employee and manager onboarding — the app, punching, leave requests, approvals. The first month-end is the one that matters, and we're on it with you rather than waiting for a ticket.
Every release we deploy keeps a tagged rollback image of the version you were running, so a bad upgrade is a revert rather than an incident. Schema changes are rehearsed against a copy of your own database before they ever touch it.
If you have a specific security or data-residency requirement — an auditor's questionnaire, a customer contract clause — ask us directly and we'll answer it in writing rather than pointing at a badge.
A clean go-live is a joint effort. So you can resource it properly:
Your implementation has a named owner from the discovery call through your first month-end, and that person remains your point of contact afterwards. When something needs attention at month-end you reach the engineers who build and operate the platform and know your configuration — not a first-line queue in another timezone reading from a script.
Escalation is a phone call, not a portal.
We map your process, confirm the fit, and set out the implementation and its cost in writing before you commit to anything.