Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
HRMS modules checklist: what a custom HR system needs The modules a custom HRMS needs, what each one must handle beyond the obvious, and which belong in the first release versus later phases.
An HR team hands us a feature list for a new HR system. It says "leave", "attendance", "payroll" and "recruitment", one word each. Every one of those words hides a dozen decisions, and the ones nobody wrote down are usually the ones that cause trouble six months after launch.
The short answer: the HRMS modules a custom system needs are a foundation layer (employee master data, organisation structure, roles and an approvals engine), core operations (leave, attendance and shifts), payroll inputs or payroll itself, the employee lifecycle from hiring to exit, self-service, documents and reporting. Integrations with biometric devices, accounting and single sign-on tie it together.
Below is the checklist we work through with clients, module by module, with the details that tend to be missed. If you are still deciding whether to build at all, read our guide on whether to build or buy an HRMS first. This piece assumes some or all of the system will be custom.
Foundations: the modules every other module depends on These rarely appear on a requirements list, but if they are modelled badly, every later module inherits the problem.
Employee master record: one record per person for their whole history with you, including rehires. Personal details, job details, bank details and emergency contacts, each with effective dates so you can answer "what was true on 1 April?" Organisation structure: legal entities, locations, departments, designations, grades and cost centres. Model reporting lines separately from departments, because matrix reporting is common. Positions and job history: transfers, promotions and pay changes stored as dated events, not overwritten fields. Roles and permissions: employee, manager, HR, payroll, finance and auditor, with access scoped to an entity, location or department. Salary and medical data need tighter rules than the rest. Approvals engine: one configurable workflow component used by leave, expenses, requisitions and letters, rather than approval logic written separately into each module. Audit trail: who changed what, when and from where, especially on pay, bank details and leave balances. Notifications: email, SMS or chat messages from shared templates, with delivery logs. Effective dating is the decision that matters most here. Payroll, leave accrual and headcount reports all need to know what an employee's grade, location and salary were at a given date. Retrofitting that onto a model that only stores current values is painful.
Core operations: leave, attendance and shifts These are the modules employees touch every week, so they decide whether people trust the system.
Leave types and policies: accrual rules, carry-forward limits, encashment, probation restrictions, sandwich rules for weekends and holidays, half days and leave that needs documents. Holiday calendars: per location or entity, with optional and restricted holidays. Leave balances and ledger: every credit and debit stored as a transaction, so a balance can always be explained. Attendance capture: biometric devices, web or mobile check-in, geofencing for field staff where needed, and manual regularisation with approval. Shifts and rosters: fixed, rotating and night shifts, shifts that cross midnight, grace periods, overtime and compensatory off. Monthly attendance close: a clear cut-off after which attendance is locked and passed to payroll. We store leave and shift rules as configuration rather than code, so HR can change a policy without a release. A simplified example of how a leave policy might be held as data:
{
"leave_type": "earned",
"accrual": { "days_per_month": 1.5, "starts_after_days": 90 },
"carry_forward": { "max_days": 30 },
"encashable": true,
"counts_weekends_between": false,
"effective_from": "2026-04-01"
}The effective_from date matters. When the policy changes next year, the old version stays in place for any recalculation of past periods.
Payroll: build it, integrate it, or feed it Payroll is the module where we are most cautious. Statutory rules change, and in India that means keeping up with provident fund, ESI, professional tax that varies by state (and is not levied in every state), TDS under the income tax regime the employee chooses, and the wage definition in the labour codes, which came into force in November 2025. Whatever you decide, the HRMS needs these pieces:
Salary structures: components, formulas and which components count towards statutory wages. Payroll inputs: attendance, loss of pay, overtime, arrears, bonuses, reimbursements and one-off deductions for the period. Payroll run: calculation, review, lock and reversal, with a clear record of who approved each run. Payslips and tax declarations: investment proofs, regime choice and year-end forms. Statutory outputs: the challans and return files your payroll provider or accountant needs. Bank and accounting exports: salary transfer files and journal entries to the general ledger. Many organisations do best with a hybrid: the custom HRMS owns employee data, attendance and leave, and pushes clean inputs to a packaged payroll product that keeps up with rule changes. If you do build payroll, plan to run it in parallel with the old process for at least two or three months before switching over.
The employee lifecycle: hire to exit Manpower requisition: a manager requests a hire against an approved position and budget. Recruitment: job postings, an applicant portal, CV parsing if useful, interview scheduling, feedback forms and offer approval. Onboarding: pre-joining document collection, background verification status, asset allocation, accounts to create and a first-week checklist. Probation and confirmation: reminders before probation ends, manager assessment and confirmation letters. Transfers and promotions: dated changes that flow into payroll and reporting lines. Performance: goals, review cycles, self and manager ratings, and calibration if you use it. Keep the first version simple; review forms change often. Training: courses, attendance and certificates, often linked to performance goals. Exit: resignation, notice period calculation, clearance from each department, asset return, full and final settlement and experience letters. Exit is the most underestimated part of the lifecycle. Full and final settlement pulls from leave encashment, pending reimbursements, notice pay recovery, loans and gratuity where applicable. It touches nearly every other module, which is why it often reveals data problems that were hidden elsewhere.
Self-service, documents and reporting Employee self-service: profile updates with approval, leave and attendance, payslips, tax declarations, letters and policies on a mobile-friendly web portal. Manager self-service: team calendar, approvals in one inbox, team attendance and headcount. Letters and documents: templates for offer, appointment, confirmation, increment and relieving letters, generated as PDFs with a document register. Employee documents: secure storage for ID proofs and certificates, with expiry reminders for visas, licences or contracts. Helpdesk: a simple ticket queue for HR queries, which cuts down on email. Reports: headcount, attrition, leave liability, attendance exceptions, payroll cost by cost centre, plus exports HR can work with in a spreadsheet. Self-service is what reduces HR workload in practice. A system where employees still email HR to ask for their leave balance has not done its job.
Integrations, security and data protection Biometric and access devices: most expose an SDK or push logs to a server. Check the exact device models early, because this is a common source of delay. Single sign-on: Microsoft Entra ID or Google Workspace, so leavers lose access the day their account is disabled. Accounting and ERP: payroll journals, cost centres, and employee data shared with an existing ERP from one source of truth. Email, SMS and chat: for notifications and approvals. An API for other internal systems, so nobody needs direct database access. HR systems hold some of the most sensitive data an organisation keeps. Practices that help with data protection obligations, including India's DPDP Act, include collecting only the fields you need, encrypting backups, masking bank and ID numbers in the interface, logging access to sensitive records, setting retention periods for ex-employee and applicant data, and recording consent where an applicant shares data through a portal.
What to put in the first release Trying to launch everything at once is the most common reason HR system projects slip. The order we usually recommend:
Release 1: foundations, employee master data migrated and cleaned, leave, holidays, attendance and employee self-service. Release 2: payroll inputs and integration, or a payroll module run in parallel, plus letters and documents. Release 3: recruitment, onboarding and exit workflows. Release 4: performance, training, helpdesk and deeper reporting. Before you ask anyone for a quote, check your own list against these questions:
Do we have one clean list of employees, with entity, location, grade and manager for each? Are our leave and attendance policies written down, including the exceptions HR applies by habit? Which approval chains differ by entity, location or grade? Which device models, payroll product and accounting system must we integrate with? Who in HR will own the system, test each release and sign off policy changes? If you can answer those clearly, scoping a custom HRMS becomes a much shorter conversation, and the estimate you get back will be far more reliable.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789