Indian payroll with a global HCM or ERP: adding compliance and self-service on top
Indian payroll with a global HCM or ERP HR module: who owns which data, how self-service changes flow back, and how the salary journal posts to your ledger.
Last checked 6 min read
A pattern we see often in Indian subsidiaries of global groups, and in large Indian companies that standardised on an international ERP: the people data lives in a global HCM suite or the ERP's HR module, but nobody in India is happy with how payroll and attendance work. PF, ESI, professional tax, labour welfare fund, State-wise leave rules, biometric attendance on three shifts, and shop-floor workers who will never log in to a desktop portal. Indian payroll with global HCM works well when the boundary between the two systems is drawn carefully. It goes badly when nobody draws it.
This guide sets out the integration pattern, not a product pitch.
Why companies keep the ERP HR module
There are good reasons to keep the global system as the record:
- One organisation structure, job architecture and reporting line across countries.
- Group headcount, cost and talent reports that the parent company relies on.
- Finance already integrated with the ERP's ledger and cost centres.
- Audit and access controls the group has signed off.
Replacing it for India alone rarely makes sense. What the ERP HR module India teams need is a local layer that does the India-specific work and stays in step with the global record.
Indian payroll with global HCM: what the local layer does
| Area | India-specific work |
|---|---|
| Statutory payroll | PF ECR, ESI, professional tax by State, labour welfare fund, TDS and the quarterly Form 138 file |
| Labour Codes | Wage registers, wage slips, the annual return, Central vs State forms |
| Attendance | Biometric and face devices, rotating shifts, overtime, regularisation |
| Leave | Rules under each State's shops and establishments law, sandwich and comp-off rules |
| Self-service | Mobile app, local languages, kiosks and WhatsApp for workers without email |
| Year-end | Investment declarations, Form 130 distribution from TRACES files |
Most global suites can be configured to do some of this. The question is how much of it you want to configure, maintain and re-test every time an Indian rule changes.
HR master data ownership: decide per area
The single most important design decision is HR master data ownership. Make it per data area, and write it down:
| Data area | Usual owner |
|---|---|
| Organisation, legal entity, department, position, job | Global system |
| Reporting lines | Global system |
| Core personal and employment details | Global system, or split by field |
| Statutory identifiers (UAN, ESI number, PAN for TDS) | Indian layer |
| Attendance and time | Indian layer |
| Leave types and balances under Indian rules | Indian layer, or the ERP where it already runs leave |
| Compensation structure | Depends on whether India's salary structure is designed in the global tool |
| Payroll results | Indian layer |
For each area there are three workable modes:
- Global system is master. The Indian layer reads the data on each sync and shows it read-only.
- Indian layer is master. It owns the data and pushes it to the global system.
- Split by field. Some fields belong to each side, for example the global system owns name and job, India owns the local address and emergency contact.
Also decide what happens when both sides change the same record between syncs: the master wins, the latest change wins, or a person reviews it.
Employee self-service on ERP-owned data
Employee self-service on ERP data is where projects often go wrong. A worker in Sanand updates her address in the mobile app. If the Indian layer simply saves it, the next sync from the global system overwrites it, and she complains that the app "lost" her change.
The clean pattern: when the global system owns a field, a change made in Indian self-service becomes a change request in the global system's own workflow (its personnel action or approval process). Once HR approves it there, the new value comes back to India on the next sync. Leave applications can work the same way where the ERP runs leave approvals. The employee sees one app; the record stays in one place.
Payroll journal to ERP
Payroll stays with the Indian layer, so the money has to reach the ledger. The payroll journal to ERP usually includes:
- the salary journal: earnings by cost centre, deductions, net pay payable;
- statutory payables: PF, ESI, PT, LWF and TDS to the authority vendors;
- the payout entry, full and final settlements, and provisions such as gratuity and leave encashment.
Four controls are worth insisting on:
- Mapping to the ERP's own codes: ledger accounts, cost centres, dimensions, plants.
- Preview before posting, with any missing mapping shown as an error.
- Finance approval, by someone other than the person who sent it, where the company wants maker-checker.
- No double posting: each journal carries a unique reference, and the integration checks the ERP before posting again after a time-out.
Many finance teams prefer journals to arrive unposted, so the accountant reviews and posts them in the ERP.
Sync triggers and sensitive fields
A manual "send" button with a preview is the safest default for the first few months. Scheduled syncs, daily or monthly, and near-real-time updates from the ERP's change notices can follow once the mappings are stable.
Be deliberate about which fields cross the boundary. Bank details, PAN, Aadhaar, date of birth and home address are rarely needed in a global system. Leaving them out by default is the simplest way to apply the data minimisation the DPDP Act expects, which we discussed in the DPDP Act post for HR.
A worked example
A European-owned auto components group runs its HR on a global HCM suite and its finance on an international ERP. Its Indian subsidiary has 1,800 people across plants in Chakan and Sanand, two-thirds of them on the shop floor.
- From the global system: legal entities, departments, positions, jobs, reporting lines, and new hires once approved.
- Owned in India: UAN and ESI numbers, shifts and biometric attendance, leave balances under Maharashtra and Gujarat rules, the salary structure, and payroll.
- Back to the global system: address and contact changes as change requests, approved leave as absences, and payroll results summarised for headcount and cost reporting.
- To the ERP ledger: the monthly salary journal by plant cost centre and the statutory payables, sent for finance approval and posted unposted.
The plants got a mobile app in Marathi and Gujarati; the group kept one HR record. Our HRMS guide for manufacturing covers what the plant side needs in more detail.
Questions to ask in an evaluation
- Can ownership be set per data area and per field, and is it enforced?
- How do self-service changes reach the global system's workflow?
- What happens when a sync fails halfway, and how is it retried?
- Can journals be previewed, approved and checked against what the ERP holds?
- Which statutory files does the Indian layer produce, and how quickly are rule changes released? The Form 138 FVU file post is a good test case.
- Where is the data hosted, and which fields leave India?
Vatsin Payroll can work as this Indian layer, with each data area owned by the HRMS, the ERP, or split by field, and the payroll journal posted to the ERP after preview. Whichever tool you choose, settle the ownership table before the first sync.