Making the employee record payroll-ready at activation

A payroll-ready employee record is a data contract at activation: identity, joining date, pay structure, bank details you collect, work location (and entity if you use one), and the statutory calculation inputs your payroll method needs. Dayzen onboarding should land those facts on one person. Dayzen payroll calculates from that record — including configured EPF, ESI, professional tax, and TDS components. It does not file EPF or ESI returns, remit to government, pay the bank, or auto-enrol anyone in provident fund. Ongoing field hygiene after the first cycle sits on the employee information checklist. First-month money when they did not work the whole period sits on prorating salary for joiners and leavers. This page is not the payroll-run checklist. It is what must be true on the joiner before you include them in a run.

If activation is a welcome email and payroll is a spreadsheet with a first name, the first cycle will invent a second person or a guessed CTC. Ready-for-pay is a property of the employee record, not a mood in finance chat.

What “payroll-ready” means here

Payroll-ready means a calculator can produce a first-cycle result without inventing keys. It does not mean:

• Government portals have been filed.
• Salary has left the company bank account.
• PF Universal Account Number enrolment has been performed by Dayzen.
• Every future master-data field you might ever collect is already perfect.

Filing, remittance, and payout remain your statutory and treasury processes. Calculation versus filing is a distinction payroll teams already live with; do not collapse it because onboarding was in a hurry.

1. Identity the payslip and bank file will trust

Legal name as you will print it, employee ID, and the personal identifiers you actually use in pay operations (for example PAN where you collect it for TDS calculation). Spelling must match the bank account name you hold if your payout process cares about that match — Dayzen is not the payout processor, but a mismatch will still become your problem at the bank.

Date of birth and gender may be inputs to some statutory calculations depending on how you configure components. Collect what your method needs, for a stated purpose, on the record — not in a side sheet. Do not treat this page as a privacy-law packing list. Operationally: if payroll cannot find the person by employee ID, they are not ready.

Search before create so you do not pay a duplicate ID. Rehires keep history on the old identity when policy says so.

2. Joining date

The joining date on the employee record is the date payroll will use to decide whether this person is in the period and whether the month is partial. Offer-accept date is not a substitute. Laptop-issue date is not a substitute. A chat “they came last Tuesday” is not a substitute.

If they join mid-month, proration arithmetic is the sibling article. This page only requires that the date exists, is agreed, and will not be quietly edited after the run is locked. If the date is still TBD, they are not payroll-ready even if CTC is typed.

3. Pay structure as offered

Store the structure the offer committed: monthly heads (basic, HRA, allowances as you actually split them), and labels for variable or one-off amounts so a joining bonus is not treated as recurring. Cost centre or payroll grouping if you use one. Employee type as you classify it (full-time, intern, contract) because stipend versus salary is a structure choice on the record, not a surprise in the calculator.

Do not type a “round number for now” that finance will “true up.” The first cycle will ship that fiction. If a head is still unknown, name it as an open item with an owner — or delay inclusion in the run under a written rule — rather than inventing basic pay.

Dayzen payroll calculates from the structure on the employee. Onboarding’s job is that the structure matches the offer packet, not that onboarding runs payroll.

4. Bank details you collect

If your payout process needs account number, IFSC, and account-holder name, collect them on the employee (typically via pre-onboarding) and verify them with whatever check you actually run. Dayzen does not pay the bank. Ready-for-calculation and ready-for-payout can differ: you can calculate a net even if a bank row is still being corrected, but you should not pretend payout is complete. Write whether a missing bank row blocks activation, blocks inclusion in the run, or only blocks the treasury file. Those are three different gates. Mixing them produces either unpaid people who were “active” or paid people whose record was never activated.

5. Location and entity

Work location (and legal entity if you operate more than one) drives professional tax configuration, attendance calendars, and sometimes which payroll template applies. A remote person still needs a location rule you have written — “remote” with no state or entity is how PT and holiday calendars get guessed.

Do not copy the job-ad city if the offer named a different office. The offer and the employee record should agree.

6. Statutory calculation inputs — not enrolment, not filing

Configure the flags and identifiers your calculator needs for EPF, ESI, professional tax, and TDS as calculation components. Examples of operating inputs (not a legal list, not rates, not section numbers):

• Whether this person is included in a PF calculation method you have configured, and any member identifiers you store because you already have them — Dayzen does not auto-enrol PF with EPFO on your behalf.
• Whether ESI calculation applies under the method you configured for this period — verify applicability on official rules for that period; this page will not mint a wage-threshold law.
• Professional tax location mapping.
• Tax regime choice you collect for monthly TDS calculation, if you collect it, and PAN as you use it in that method.

Rates, slabs, and filing due dates are not published here. They change; use official sources for the period. Dayzen’s honest payroll scope is calculation, LOP sync, templates and adjustments, advances, and payslip PDFs — not returns, not remittance, not bank salary payout, not “we registered them for PF.”

If a statutory flag is blank, the calculator will either skip a line or apply a default you did not intend. Treat blanks as blockers for the first run unless you have a written default.

Activation versus first payroll cycle

Question	Activation cares	First cycle cares
One identity	Yes	Yes — paying the wrong ID is worse
Joining date	Usually yes	Always
Structure	Should be on the record	Must match offer
Bank details	If your gate says so	Needed for payout; calculation may still run
Statutory calc flags	Should not be left to “later”	Must be set before lock
Filing / remittance	No	Outside Dayzen; your compliance calendar

You can mark someone active so they can punch, then finish a bank correction before treasury. You should not mark them active with a blank joining date. You should not include them in a locked run with a CTC that is still a recruiter’s memory.

Sequence that avoids a side sheet

1. Packet accepted; search; one employee identity.
2. Pre-onboarding (or HR entry) fills bank, address, identity fields you collect.
3. Structure and location copied from the offer; statutory calculation flags set by someone who owns payroll config, not guessed by the buddy.
4. Joining date locked; activation when your gate passes.
5. First cycle: proration if partial month; LOP if attendance says so; lock; payslip. Payout and filing happen in your other processes.

If step 3 is still “finance will confirm” on the morning of cutoff, pull them from this run under a written exception or finish the confirmation — do not invent heads at 6 p.m.

Failure modes

• CTC on the offer ≠ structure on the record. Fix before lock; do not “adjust next month” as a habit for joiners.
• Two rows, one payment intent. Stop. Identity first.
• PF spoken of as “the software enrolled them.” It did not. Complete enrolment where you actually do that work.
• Blank location, guessed PT. Set location; do not patch the payslip by hand as the standing process.
• Joining date corrected after lock. That is a draft-versus-lock problem, not a new onboarding theory. Recalculate under exception or adjust next cycle; fix the master going forward.

Payroll-ready is fields a calculator can trust. It is not a government acknowledgement, a bank UTR, or a PF enrolment receipt.

What this page will not become

It will not list every master-data field you might collect in year two; that is the information checklist. It will not walk month-end close or the happy-path run. It will not explain proration divisors. It will not claim Dayzen files, remits, pays out, or auto-enrols PF. Keep those lines honest so onboarding and payroll can share one record without a legal or product overclaim.

---

At activation, the joiner needs identity, joining date, offer-true structure, bank details you collect, location, and statutory calculation inputs. Dayzen onboarding should put those on one employee. Dayzen payroll can calculate from them. Filing, remittance, bank payout, and PF enrolment stay outside that claim. Use the information checklist for ongoing hygiene and the proration article for a partial first month — not a second payroll-run guide.