Payroll problems cluster by stage: calculation, posting, payment, statutory, payslips. Find the symptom below; each entry states the cause the platform actually acts on and the fix. A useful general rule first: while a run is unposted and its payslips unpublished, recalculation is free — it replaces the previous pass completely (loan recoveries restored and re-taken included), so "fix the input, calculate again" is the answer more often than not.
Setup records
A PF, ESI, LWF or PT rule will not save
The rule masters refuse values payroll cannot use, naming the field. PF rule: the wage ceiling (and EPS ceiling) must be above zero, every rate between 0 and 100, and Effective to not before Effective from. ESI rule: the wage threshold above zero and both rates between 0 and 10. LWF rule and professional tax slab: no negative amounts, and a slab's upper bound not below its lower. Inactive rules are not checked, so retiring a wrong rule always works. See Statutory deductions.
"PF rule … is already active for this company"
Only one active PF rule may apply to a company on any date, and an empty Effective to means "forever". To move to a new ceiling, set the old rule's Effective to to the day before the new rule's Effective from (or make the old rule inactive), then save the new one. ESI rules have no end date, so two active ESI rules of a company may not start on the same date.
A payroll period will not save
A period needs a start and an end date, the end on or after the start, and no other period of the same company and pay frequency may cover any of its dates — the message names the period that already does. Use that period, or change the dates. A Locked period accepts no edit except a change of its Status: unlock it first.
A tax declaration or declaration line will not save
The declaration's financial year must be one that has an income-tax rule pack (for example 2026-27). Each line must belong to a declaration and name a section from the tax deduction section catalogue that is allowed in the declaration's regime — an 80C line on a New-regime declaration is refused, and so is switching a declaration with such a line to the new regime. See Income tax on salary.
Calculation
Employees are missing from the run
The run header's skipped count tells you it happened; the causes are exact. An employee is excluded when their employment status is Exited, and skipped when no active compensation record with a salary structure exists for them, or the structure has no active lines. Fix the employee's compensation or structure and recalculate. Also check the employee's payroll company — a run only picks up the employees of its own company.
Calculate is refused
Three deliberate blocks. "Payroll can't compute salary TDS for tax year …": the year has no income-tax rule pack (Tax Regime Rule, slabs and surcharge slabs) for one or both regimes for the run's company — add it (see Income tax on salary) and calculate again. "Payroll run is posted": the ledger already reflects the old figures, and the run stays locked for good. Reversing the accrual journal in Finance does not reopen it, so correct the difference with an adjustment in the next period. "Payslips are published": employees have seen those documents; recalculating would contradict them. Correct forward with an adjustment next period instead.
Project TDS, Calculate or Post is missing or refused
Each run action applies only up to a stage. Project TDS and Calculate stop once the run is posted; Post stops once a payment batch has been generated. On a Paid, Closed or Reversed run none of them applies, and the buttons are hidden. Calling them anyway (an API call, a flow) is refused with the run's status in the message. Nothing runs in a Locked or Closed payroll period, and no new run can be added to one — reopen the period first.
An adjustment or loan recovery didn't apply
An adjustment must be on the run's period and employee, with approval status approved or empty — pending and rejected adjustments are excluded by design. A loan recovers only once it has been Disbursed (it then reads Active) with a positive outstanding balance and a positive installment amount; a Requested loan was never disbursed, and typing Active into its status does not make it recoverable. A recovery entered by hand on a loan that has not been disbursed is refused. Outstanding amount is computed — blank before disbursement, then principal less recoveries. Fix and recalculate.
An expense claim reimbursed through payroll is not on the run
Calculate pulls a claim only when it is posted and not yet paid, has Reimbursement Mode Payroll, has the employee's Resource as claimant, belongs to the run's company and is not already in another run (Included In Payroll Run blank or this run). Employees the run skips or excludes are not pulled, and nothing is pulled when the company has no Payroll Payable control account. Fix the claim and recalculate. See Expense claims through payroll.
TDS is zero for everyone
The TDS component reads the month's persisted projection. A missing rule pack no longer gets this far — Calculate refuses the run (above). If the run calculated and TDS is still zero for everyone, check that the structure's TDS line has Statutory Type TDS and that each employee's taxable income is not simply within the rebate; the employee's TDS Calculation Sheet tab shows the figures line by line. For a single employee at zero, check their TDS-applicability flag and whether their projected annual income simply falls below tax.
TDS is zero for one employee whose declarations were "submitted"
Only proof-checked declarations count, at their verified amounts. A declaration in Draft or Submitted contributes nothing — verify it and recalculate. Also confirm the claimed sections are allowed under the employee's elected regime.
Posting
Post fails naming a component line
The named line's payroll component lacks a GL mapping: earnings and reimbursements need an expense account, deductions a payable account, employer contributions both. Map the account on the component master and post again — nothing posted partially.
Post fails on the control account
"No Payroll Payable control account is configured": the company has no GL account with the Payroll Payable control type. Configure it (see Payroll configuration) and post again. The same pattern applies to challans and settlements — each names the missing control type.
The run was approved but never posted
Final approval posts the accrual, but a posting failure does not undo the approval. The failure is logged, not shown; the request stays Approved while the run's Status and Approval Status don't change. The usual causes are a run approved before it was calculated, a component line with no GL account, or no Payroll Payable control account. Calculate the run if it has no lines, fix the mapping, then click Post on the run, which shows the reason if it still fails. See Payroll run approval.
Payment
Generate Payment is refused
In order of likelihood: the run is not posted yet (posting is the prerequisite); no employee has a positive amount open on the run (net salary plus claims); or the bank cannot be derived — the error spells out which: the company has no bank control account, the configured default bank is not an active bank account of this company, or several banks exist with no default. Set the company profile's default bank GL and retry.
Pay reports no open items to settle
"Batch has no open net-pay items to settle." The batch settles the run's per-employee payroll-payable open items (net pay and the claims the run carries) — or, on a full-and-final batch, the settlement's — and they are already settled: typically the batch was paid once already (a second Pay is refused with "Payment batch is already paid."), or the items were settled by a manual payment. Check the open items on the Payroll Payable control for the run before assuming money is unpaid.
The batch total is higher than the run's posted net salary
Expected when the run carries expense claims. Each employee's line is net salary plus their claims; the claims reached Payroll Payable when they were handed over, not through the run's posting journal.
Generate Payment on a full and final settlement is refused
The settlement must be posted, must have an open net amount, and must not already be on an unpaid full-and-final batch — the message names the batch to pay or delete. See Full and final settlement.
Pay is refused: no bank account number or IFSC
"Payment batch … cannot be paid: no bank account number or IFSC for …". Salary is paid into a bank account, so every line needs both. A line generated before the employee's bank details were entered picks them up from the employee's record when you click Pay — add the bank account number and IFSC on the employee and click Pay again. To pay the others now, take the line off the batch.
Where the UTR goes
Fill UTR Number on each batch line when the bank confirms the transfer. An API or flow can pass them with Pay as utrNumbers, keyed by line or employee. Pay is hidden once the batch is Paid.
The period still reads Open after the run was paid
A period's status follows its runs: when every run of the period is posted it becomes Approved, all paid → Paid, all closed → Closed. It moves only forward, never out of Locked, and ignores reversed runs. A second run of the same period that is still a draft holds the period back. Periods left Open by older runs move the next time one of their runs changes status.
Full and final: Approve is refused, or Net settlement changed
The net is computed from the settlement's lines (payables less deductions) every time the settlement or a line is saved, so a typed net does not survive. A settlement with no line carrying an amount cannot be approved or posted — add the lines first. See Full and final settlement.
Statutory and payslips
Post Challan is refused or hidden
A challan posts only with its challan number (the TRRN, CIN or bank receipt number), the deposit (paid) date and the bank account it was paid from — fill them on the challan and post again. The statutory payable account defaults to the company's control account for that statute. Post challan is hidden once the challan is Paid.
Prepare TDS Challan finds nothing
The challan sums TDS from posted run details of the period — an unposted run contributes nothing. Post the run first. If the period's challan is already Paid and a correction run posts later, the difference is reported on the challan result rather than edited into the paid challan; deposit it separately.
Employees cannot see their payslips
Payslips reach employees when you click Publish payslips on the posted run: each slip gets its PDF and the employee is notified by push and email. Typing Published into a slip's Publish Status by hand does not send anything. An employee is notified only if their Resource has a linked user, and opens the PDF from the payslip if their profile can read payslips. See Payslips.
Payslip year-to-date looks wrong
YTD sums the fiscal year containing the run's period — the company's fiscal calendar, or April-to-March absent one. A figure that seems to include "last year" usually means the fiscal calendar is missing or its dates are wrong; fix the calendar, delete the affected slips and click Generate payslips on the run again. Generating never updates a slip that already exists. YTD also counts every run in the year, posted or not, so an extra run for the same period inflates it.
A posted figure needs correcting
A posted run cannot be edited or recalculated, and reversing its journal does not reopen it. Correct forward with an adjustment in the next period, which also keeps the closed period's statutory challans untouched. Do not create a second run for the same period to correct it: every run calculates each employee's full salary again. If the accrual landed in a closed accounting period, see Closing a period for reopening rules.