Month-end close between HR and finance

Month-end close between HR operations and finance is a shared freeze calendar, not a second pay-run recipe and not a second people-ops loop. HR must freeze attendance and leave, payroll must calculate against those frozen inputs, and finance must receive a locked file they can post to books, fund, and use for whatever statutory filing they own outside the HRMS. The step list inside the calculation stays on the payroll-run checklist. The repeating people-ops order — attendance exceptions, leave decisions, then payroll inputs — stays on the monthly HR operating loop. This page is the seam between those two owners.

Different informal calendars produce the same failures: late punches after payroll has started, a draft net-pay file finance already funded, and a filing pack that no longer matches payslips. The fix is one published sequence with named owners.

Dayzen payroll calculates and issues payslips. It does not file government returns and it does not pay the bank. Finance must not treat an HRMS lock as a challan or a bank credit.

What “close” means when two functions share it

Inside HR, close means people inputs for the period stop moving. Inside finance, close means the numbers they post, fund, and (where they file) submit stop moving. Same event, two desks. If only HR freezes, finance still gets a moving spreadsheet. If only finance freezes, HR is still regularising yesterday’s punch while the ledger is booked.

Write the shared event as three named states:

1. Input freeze: attendance and leave queues for the period are closed except a named exception path.
2. Calculation lock: the pay run is calculated against those inputs and then locked so net pay does not silently change.
3. Finance consumption: a locked export or report becomes the file finance uses for books, funding, and filing they own.

Do not merge those three into “payroll is done.” A draft is not a lock. A lock is not a bank credit or a statutory return. Finance owns posting, funding, and filing on their tools and official portals. HR owns a people file finance can trust.

Publish one calendar both teams can see

The operating loop already orders attendance close, leave close, then payroll input freeze. The finance-facing calendar adds two dates HR often omits:

• When the locked payroll file will be handed to finance (not “when we hope to finish”).
• When finance will treat that file as the version for books and funding (so a later HR exception cannot be assumed into the same ledger period).

Put those dates next to payday and next to statutory due dates finance already tracks externally. Do not invent due dates here; verify them on official materials for the period. The HRMS calendar must be earlier and ordered so the locked file exists before funding and filing windows.

Owners, not departments-as-abstractions:

• Attendance owner declares the punch and regularisation queue closed for the period.
• Leave owner declares pending applications for the period decided or explicitly deferred.
• Payroll owner runs calculation and locks (or names a written hold).
• Finance owner accepts a file version (date, period, checksum or export name) for books and funding.

If the owner is “whoever is free that Friday,” you do not have a close. Chat confirmation is not acceptance of a file version.

Attendance and leave freeze is the HR half of the bargain

Finance cannot lock a file that still depends on open time and leave. That work is HR’s. Use attendance management and leave management as the queues, not as a substitute for a freeze date. Product capability does not freeze itself.

What must be true before HR tells finance “inputs are frozen”:

• Punches, regularisations, and shift exceptions you will still accept for this period are decided or parked for next cycle.
• Leave applications that change paid days or unpaid days for the period are approved, rejected, or explicitly held out of this run.
• Joiners and leavers in the period have the same last-working-day and start-date facts payroll and finance will both use.
• Unpaid absence is derived from those closed records, not typed from a hallway list after the export.

How you work those queues month after month is the operating loop article. How you click through a calculation once inputs exist is the payroll-run checklist. Here the only extra rule is: do not tell finance the file is coming while those queues are still open.

A freeze is a dated decision that late facts wait for the next cycle or a named exception. It is not “we will try to stop changing things.”

Calculate, then lock — finance consumes the lock, not the draft

After freeze, payroll calculates. Review exceptions, LOP amounts, one-off earnings, recoveries, and statutory calculation lines as your process requires. That review is inside the pay run. When the owners agree the calculation is the period’s result, lock it. Payslips should follow the locked result, not a later quiet edit.

Finance should consume:

• A period identifier (which month, which legal entity or pay group if you run more than one).
• Employee identity the ledger already knows (employee ID, not a nickname column).
• Gross, named deductions, net pay, and any cost-centre or department split you actually post.
• A lock timestamp or export version so two people cannot fund two drafts.

They should not consume a live worksheet. After lock, corrections are a named path: hold funding and recalculate this cycle under exception, or post a next-cycle adjustment — not a silent reopen of a file finance already booked. Draft-versus-lock mechanics stay with payroll operations; the cross-function rule is that finance’s copy is the locked one.

Dayzen payroll can calculate components, sync attendance and LOP as configured, produce payslip PDFs, and support templates, adjustments, and reports. That is not a bank file and not a government return. Finance generates or receives bank uploads in the payment process they own, and files returns on official channels from numbers reconciled to the locked calculation.

What finance does with the locked file (and what they do not ask HR to pretend)

Three finance jobs attach to the same file. Keep them named so HR is not blamed for all three.

Books

Salary expense, recoveries, and liability lines need a stable source. The locked payroll result is that source. If finance posts from a parallel spreadsheet HR did not lock, ledger and payslip diverge by construction.

Funding

Net pay that leaves the company bank must match locked net. Funding from an earlier draft, then discovering LOP changes, is a cash scramble. HR’s freeze exists so that total is trusted on the published funding date.

Filing that finance owns

Statutory deposits and returns (EPF, ESI, professional tax, TDS, or others that apply) are not HRMS close. They are finance or consultant work on official due dates verified outside this article. The locked calculation is an input, not the filing. Do not write that Dayzen files or that payroll lock equals a challan. Rates, slabs, and due dates are omitted here; use official portals for the period.

Artifact	Owner	What “done” means
Attendance and leave freeze	HR ops	Period queues closed or exceptions named
Payroll calculation and lock	Payroll / HR	Payslip numbers will not silently change
Locked file accepted	Finance	Version used for books and funding
Bank payment	Finance / treasury	Cash left the account; not an HRMS claim
Statutory filing	Finance / consultant	Submitted on official channels they own

Exceptions that still need both signatures

Write the exceptions you will still allow, with both HR and finance on the path:

• Late regularisation after freeze: default is next cycle. Same-cycle only if payroll has not locked, or if both owners agree to unlock/hold funding under a written exception.
• Missed joiner or missed leaver: identity and dates must match the employee record before anyone recalculates. Do not patch net pay in the bank file alone.
• Wrong cost centre: may be a books correction without changing net pay. Say so, so HR is not asked to rerun payroll for a posting string.
• Off-cycle payment: a separate locked mini-run or a next-cycle line, labelled so finance does not mix it into the original period’s funding total.

Do not leave “we will adjust in the sheet” as the exception process. That recreates two sources of truth: HRMS payslips and workbook books.

A working sequence you can pin without copying the checklist

Use this as the cross-function spine. Queue work stays in the monthly loop; in-product clicks stay in the payroll-run checklist.

1. Publish the freeze, lock, file-handover, funding, and payday dates for the period.
2. HR closes attendance and leave for the period (loop work).
3. HR or payroll calculates, reviews, and locks (checklist work).
4. HR issues payslips from the locked result (Dayzen can generate those PDFs; employees may see them in self-service where you enable it).
5. Finance accepts the locked export as the version for books and funding.
6. Finance pays the bank and files what they own, on their calendars.

If step 5 happens before step 3, you are funding a draft. If step 6 is assumed to be “the HRMS,” you have confused calculation with filing and bank pay.

Signals the shared close is working

A short internal list, not invented industry statistics:

• Finance can name the export version they posted, and it matches the locked pay run.
• Payslip disputes after payday are policy or data exceptions, not “the file kept changing.”
• Late attendance or leave after freeze has a written next-cycle or exception ticket, not an unofficial second payroll.
• Statutory work starts from the locked calculation, not from a parallel people list in a workbook.

When those fail, print the calendar, name the four owners, and stop handing finance a live sheet. Do not buy a new module first.

Month-end is one freeze, one calculation lock, and one file finance will book. Dayzen can calculate that lock and issue payslips; books, bank, and filing stay with the owners who already have them. Keep the people-ops loop and the pay-run checklist as the detailed maps. Use this page when the argument is who may still change the numbers.