How Frappe HR runs payroll from payroll entry to bank payout
Frappe HR creates salary slips from a Payroll Entry, and the same chain feeds ERPNext accounting and bank entries. A payroll administrator selects a company, a period and the employees to include, and the Payroll Entry generates one salary slip per employee from the salary structure assignments in force for that period. The slips then become the source for the accounting postings in ERPNext and for the bank payment file or bank entry. Because every later step depends on the Payroll Entry, the filters you choose at creation decide which employees are paid, which accounts are hit and which bank entry is produced, so they deserve the same review as the payroll itself. The feature ships in the Frappe HR app (HRMS), which runs on ERPNext and is licensed separately from ERPNext core. Hosting cost is the only pricing fact this page can give: self-hosting ERPNext is free, and the ERPNext pricing page lists Frappe Cloud hosting from 5 US dollars per month for shared site hosting. Implementation effort is quoted separately from scope.
A single-branch company with one payroll calendar can usually run one Payroll Entry per month. Multi-branch or department-based organizations need several runs, typically one per branch, business unit or pay group, because each run can carry different cost centers, salary components and bank accounts. Splitting runs keeps errors contained, lets each approver sign off on their own population and makes reversals smaller. The cost is more coordination, since the team must confirm that no employee falls between two runs or appears in both. Before go-live, confirm with your payroll lead how many runs you need, which filters separate them and how cost centers and default accounts are mapped to each branch or department. Ask your implementation partner to test one run per filter combination on a copy of your data, not just the largest population.
Between salary slip generation and bank payout, the reviewer should check the slips for missing attendance or leave effects, unexpected overtime, and components that changed since the last run. Corrections should go through a Payroll Correction document rather than edits to submitted slips, so the adjustment remains traceable to the original period. Once the accounting entries are posted and the payroll is approved, the bank entry is created from the Payroll Entry, and that bank entry is what your bank file or payment process consumes. Confirm with your bank which file format and account details it accepts, and confirm with your auditors how Payroll Correction and bank entries should be evidenced, since DeployOpen prepares controls and records but does not issue audit opinions. The ERPNext role and permission setup for payroll approvers is covered in the roles section of this series.
Which payroll run structure fits your organization
A single company run creates one Payroll Entry that covers every employee in one company and one payroll frequency. It suits organizations with a single legal entity, one bank account for salaries, and a small number of pay structures. The Payroll Entry filters on company, payroll frequency, the posting date and the pay period, so every eligible employee with an active salary structure assignment for that period is pulled into the run.
- Filter scope: Confirm that company, frequency and period alone select the right population, since leavers and new joiners are picked up only through their dates.
- Slip grouping: All salary slips sit under one Payroll Entry, which makes review and submission a single pass.
- Accounting dimensions: Decide whether cost center or project must be set on each salary component, because a single run posts every slip to the same default accounts.
- Approval routing: Confirm who reviews the slips before submission and whether a second approver is required.
- Bank file: Check whether one bank payment file covers all employees or whether a separate file is needed for each bank.
Before go-live, run a test Payroll Entry on a copy of real data and compare the totals against your last payroll.
Running payroll by branch splits the population by a branch-level attribute on the employee record, so each branch can be reviewed and paid on its own schedule. This fits organizations where branch managers approve time, or where branches have separate bank accounts or cost centers. The Payroll Entry filters on the branch in addition to company and period, which means employees without a branch value are not selected and must be handled in a separate run.
- Filter completeness: Check that every active employee has a branch value, because blank values drop people silently from branch runs.
- Slip grouping: Each branch produces its own Payroll Entry and its own set of salary slips and journal entries.
- Accounting dimensions: Map the branch to a cost center or accounting dimension so that expense postings follow the branch.
- Approval routing: Decide whether branch leads approve their run or whether a central payroll team does, and record that in your approval process.
- Reconciliation: Plan how branch totals add up to the company total for the month.
Ask your implementation partner to show the branch filter results for each active branch before the first live run.
Runs by department select employees by their department on the employee record. This structure is useful where departments carry their own cost centers, approval chains, or pay calendars, for example when operations staff are paid weekly and head office staff monthly within the same company. The department filter is applied alongside company and frequency, so the department value must be consistent across all employee records.
- Filter consistency: Department names should follow one master list, since spelling variants create runs that miss people.
- Slip grouping: Slips group under the department's Payroll Entry, so payroll reviewers can work through one department at a time.
- Accounting dimensions: Confirm whether the department maps to a cost center, and whether the salary expense and payable accounts change by department.
- Approval routing: Check whether department heads approve their slips or whether one payroll owner signs off every run.
- Mid-month transfers: Agree how employees who move departments during the period are paid, since their slip reflects the department at the time the run is created.
Also confirm how department changes made after a run is created will affect that run.
Runs that span several companies or currencies create one Payroll Entry per company, because each company has its own ledger, bank accounts and tax obligations. Where employees are paid in a currency other than the company currency, the salary slip and the bank entry must carry exchange rate treatment that your finance team has agreed. This structure needs more setup than the others and should be tested with at least one employee from each entity.
- Company boundaries: Each company must be run separately, so consolidated totals are a reporting step, not a payroll step.
- Currency handling: Confirm the payment currency, the exchange rate source and the rounding rule before the first run.
- Accounting dimensions: Set company-specific default accounts for salary expense, payable and bank accounts so that postings land in the right ledger.
- Approval routing: Confirm which entity's finance lead approves each run and whether cross-entity approvals are needed.
- Tax and statutory rules: Check with local advisers which deductions and statutory forms apply in each jurisdiction, since these are configured per company.
Ask for a written list of company, currency and account mappings before the build starts.
Payroll entry settings and when each fits
This table compares the main Payroll Entry settings in Frappe HR and when each one fits a monthly run. Read each row as a decision: what the setting filters or posts, the situation where it helps, and the point to verify in your version before the first live run.
| Option | What it controls | When it fits | What to confirm |
|---|---|---|---|
| Company | Which company's employees, salary structures and ledgers the run covers | Single-entity payroll, or one run per legal entity in a group | Confirm that each entity has its own payable and bank accounts set up |
| Payroll frequency | How often the run generates salary slips and the period dates it uses | Monthly salaries are the common case; other frequencies suit hourly or weekly staff | Check the exact label and options in your version's Payroll Entry form |
| Branch | Limits the run to employees assigned to one branch | Branch-level cost centers or separate pay runs by site | Confirm employees carry the branch value on their records before filtering |
| Department | Limits the run to employees in selected departments | Staggered runs by function, or departments approved by different managers | Check that department values match the employee master exactly |
| Designation and employee filters | Narrows the run to specific roles or named employees | Excluding a group on hold, or running a small correction batch | Confirm how excluded employees are handled in the next regular run |
| Salary slip posting | Whether generated slips are posted to accounts when submitted | Use posting when the ledger should update at slip submission | Verify the posting behavior and date rules in your version's documentation |
| Payable account | The ledger account credited for net pay owed to employees | Payroll accrued before payment, with a bank entry made later | Confirm the account type and that it is configured on the company |
| Bank or payment account | The account used when the bank entry records the payout | Matching the bank account from which salaries are paid | Check that the account matches the bank feed or statement used for reconciliation |
Setting up a monthly payroll cycle step by step
This sequence takes a monthly pay run from approved salary setup to a reconciled bank payout, with a check at each stage so that slip totals, ledger postings and bank amounts agree before the period is closed. Each step names the record it produces so reviewers can trace every rupee or dollar from the structure to the bank.
Confirm salary structures and assignments
Before any payroll run, the payroll administrator confirms that every employee in scope has an active Salary Structure Assignment with the correct structure, base pay and effective date. Check that bank account details and the employee's company, branch and department are filled in, because the Payroll Entry filters and the bank file depend on them. Done means a filtered list of employees for the cycle matches the headcount HR expects, with no one missing a structure or showing a start date after the pay period. Changes such as mid-month joiners or revisions should be resolved here, not on the slips.
Create the payroll entry with filters
The payroll administrator creates a Payroll Entry for the company and pay period, then sets filters such as branch, department, designation or employee group so that each run covers a defined population. Running separate entries by branch or department can make review and approval easier, but the groupings must cover every employee exactly once. The entry is saved, and the employee count shown on it should be compared with the list from the previous step. Any difference is investigated before slips are generated.
Generate and review salary slips
Generate the salary slips from the Payroll Entry, then have a reviewer, usually a payroll lead or HR partner, check a sample and every exception. Exceptions include zero net pay, large changes from the prior month, unexpected deductions, attendance or overtime inputs that look wrong, and tax lines that do not match the current slab. Corrections to slips are made on the source data and the slips are regenerated, so the slips and the records behind them stay consistent. The step is complete when the reviewer signs off the exception list and the slip total is recorded for the next check.
Submit slips and check the ledger
Submit the Payroll Entry so that salary slips are finalized and the accounting entries are created in ERPNext. The accountant then compares the total gross pay, deductions and net pay on the submitted slips with the totals in the generated journal entry and the payable accounts that hold salary and statutory liabilities. The two figures must reconcile to the currency unit. If they do not, the entry is investigated before any payment is made, because a mismatch here usually points to a wrong account mapping in the salary component setup.
Create the bank entry from the payroll entry
From the submitted Payroll Entry, the accountant creates a bank entry, which Frappe HR supports directly, so that the net pay to be paid is carried into a payment record against the bank account. Confirm the paying bank account, the posting date and the reference before saving. The bank entry total should equal the net pay total from the payroll ledger check in the previous step. Any difference, such as a deduction that should not be paid out or an employee excluded from the file, must be resolved before the bank file is produced.
Export the bank file or record payment
Produce the payment instruction in the format your bank requires, or record the payment against the bank entry if payouts are made through a manual or portal process. Frappe HR does not replace your bank's file specification, so confirm the required layout, field lengths and account validation rules with your bank before the first run. Check the file's record count and total amount against the bank entry. Once the bank confirms receipt and the payouts are completed, the bank reconciliation should show the same amounts cleared.
Record corrections and close the period
If a payment or slip was wrong after release, record the fix through a Payroll Correction rather than editing a submitted slip, so the adjustment is itself auditable and flows into the correct period. Then confirm that the bank reconciliation, the payroll ledger and the slip totals agree, and lock the period according to your own month-end process. The period is closed when the payroll lead signs off the reconciliation pack and the open correction list is empty or has a named owner and date.
How to review salary slips before anything posts
The review pass is where a payroll run is either caught or shipped. Before anything posts to accounts, spot-check the earnings and deductions on each generated salary slip against the approved salary structure and the salary structure assignment for that employee. Confirm that each component (basic, allowances, overtime, statutory deductions) carries the amount and effective date the approved offer or revision says it should. Then check the exceptions that generate most errors: new joiners whose first slip should be prorated, leavers whose final slip should stop at the relevant date, and employees with unpaid leave whose deductions should match the leave records for the month. Compare the run's total gross, total deductions and net pay with the prior month and investigate any movement that does not have a named cause, such as a hire, exit, revision or leave pattern.
Assign the review to people who own different inputs. A payroll administrator should check the run mechanics and component totals, an HR business partner or compensation owner should confirm that every change traces to an approved revision, and a finance reviewer should check the expected payout total and the accounts it will hit. Keep these sign-offs separate from the person who created the payroll entry where your controls allow. Record who approved each stage, because that trail is what your auditors will ask for.
The quality of this review depends on what reaches it. Attendance and leave errors surface here as wrong deductions, so confirm that check-ins, shift data and leave applications were settled before the run was generated. Salary revisions approved late also need to be in place, or the slips will carry stale amounts. Treat missing or late inputs as a reason to hold the run, not to correct the slip by hand. Confirm with your own team which cut-off dates apply to each input module and how your process handles revisions that arrive after the cut-off.
When and how to use Payroll Correction
Payroll Correction handles errors found after a payroll run is posted. The five situations below are the ones teams commonly meet in a monthly cycle, and each one needs a check of the accounting and bank effects before anyone is paid.
Wrong component amount
A salary component can post the wrong value when a formula, base salary or supplementary input is off for one employee. Confirm where the figure came from before you correct it, so the same error does not return next month. Then check how the corrected earning or deduction changes the salary slip and the accounting entries already linked to the payroll run, since those changes can move expense and payable balances. Keep the original and corrected figures side by side for the payroll file.
Missed employee
An employee who joined, returned or had a structure assigned after the Payroll Entry was created may not appear in the run. Check the employee's status, salary structure assignment and the branch or department filters used on the Payroll Entry. Read the Payroll Correction documentation to confirm whether it adds a slip for the missed person or whether a separate entry is needed. Review the effect on totals and the bank file before payment is released.
Duplicate salary slip
Two slips for one employee and one period inflate expense, tax and net pay totals at the same time. Find the duplicate by filtering salary slips for that employee and period, then identify which slip is linked to the bank entry and which accounting entries it generated. Follow the correction process documented by Frappe HR and avoid deleting records by hand, because a removed slip can leave journal or bank entries pointing to nothing.
Tax or deduction error
Income tax, provident fund and other statutory deductions depend on slabs, exemptions and effective dates, so one wrong input can misstate several months. Identify whether the fault sits in the component, the tax slab, the exemption declaration or the structure assignment. Correct only the period that is wrong, then review how the deduction liability accounts and remittance amounts change, because statutory payments to authorities rely on those figures.
Bank detail error
A correct salary slip still causes a payout problem if the money goes to an outdated account. Verify each employee's bank details against a source the employee has confirmed before the bank entry is generated or the file is sent. If the error is found after the bank entry exists, check the linked payment records and confirm whether the correction reaches the bank file, the bank account ledger and the employee record. Confirm the exact steps in the bank entry documentation.
Questions buyers ask before running Frappe HR payroll
What drives the implementation effort and cost of Frappe HR payroll?
The biggest drivers are the number of salary structures, how many statutory rules apply in each country or state, how many bank files must be produced, how much historical data must move across, and how many approval steps the business requires. Each salary structure with its own components, formulas and effective dates adds design and testing work. Statutory deductions, tax slabs and reporting formats differ by jurisdiction and are often the largest source of rework when they are not captured early. Bank integration depends on the format each bank accepts and on how many accounts you pay from. Data migration of employee master data, opening leave balances and prior-year figures adds validation time. Approvals that span HR, finance and branch managers add test cycles. Ask any provider for a quote that lists each of these items separately, with the assumptions behind each one.
Can our team run Frappe HR payroll without an implementation partner?
Yes, a capable internal team can install and run Frappe HR on ERPNext, and the software itself is free to self-host. The question is whether your team has the time and skills for the parts that carry risk. Those include configuring salary components and structures, validating statutory logic against current rules, setting up bank entries, testing a full dry run before the first live cycle, and maintaining the system through Frappe and ERPNext version changes. Frappe's supported versions page lists which major versions are supported and when they end, so your team must plan upgrades on that schedule. A partner is most useful when the scope is wide, the deadline is fixed, or no one internally has run payroll on this platform before. Many teams split the work, keeping day-to-day operation in-house and bringing in outside help for design and testing.
What does the payroll work need from HR and finance?
HR must provide a clean employee master, confirmed salary figures for every employee, approved salary revisions with effective dates, the attendance and leave data that feeds each run, and a decision on which exceptions are paid through payroll and which through separate entries. Finance must confirm the chart of accounts for salary expense, payables, tax liabilities and bank accounts, decide how cost centers or branches map to accounting dimensions, and agree who approves the bank payment file. Both teams need to sign off on the salary slip review checklist and on the process for corrections after approval. Expect the first cycles to surface gaps in these inputs. Agree on owners and a sign-off calendar before build starts, because the most common delay is waiting for confirmed data rather than for software configuration.
How long does it take to prepare the first payroll cycle?
The duration depends on the scope and on how quickly your HR and finance teams confirm their inputs, so treat any single number with caution. Preparation usually covers configuration of salary components and structures, loading or validating employee data, a test payroll entry for one branch or department, a review of generated salary slips, a trial of the accounting and bank entries, and at least one full dry run. Confirm the timeline with the provider against your written scope, and ask which steps depend on your data owners. If the first live cycle falls near a payment deadline, plan a parallel run against your current payroll so that differences are caught before employees are paid.
Does self-hosting Frappe HR and ERPNext cost anything in licenses?
No license fee applies to self-hosting. ERPNext is free and open source, and the ERPNext pricing page states that self-hosting ERPNext is free. ERPNext is licensed under GPL-3.0 and the Frappe Framework under MIT. Your costs are the infrastructure you run, the people who operate and update it, and any implementation or support services you buy. If you choose Frappe Cloud instead, its published starting prices are 5 US dollars per month for shared site hosting, 20 US dollars per month for shared server instances and 125 US dollars per month for dedicated servers, and those figures may change, so confirm them on the pricing page before budgeting. Support warranty coverage from Frappe depends on running a listed version with a matching Frappe Cloud support plan, which is a separate decision from hosting.
How do payroll corrections affect the accounts in ERPNext?
Corrections should be posted as documented adjustments, not by editing submitted records, so the audit trail stays intact. Frappe HR provides a Payroll Correction document for this purpose. Confirm how it creates or reverses accounting entries in your version, and check that the related bank entry and accrual match the corrected amounts. Agree a rule for which corrections are made in the current cycle and which carry into the next salary slip, and make sure the approver for each correction is recorded. Test one correction of each common type during the dry run, such as an overpayment, a missed deduction and a wrong bank account, and reconcile the ledger after each test. Your auditors will expect to trace every correction back to an approved request.
What a DeployOpen payroll implementation covers
A DeployOpen payroll implementation is a fixed-scope engagement with written deliverables agreed before work starts. The core deliverable is configuration of the Payroll Entry flow for your branches and departments, so that each run selects the right employees, salary structure assignments and payroll period, and so that the resulting salary slips, accounting entries and bank entries map to the cost centers, payables and bank accounts your finance team uses. We also set up the roles that control who creates, submits and cancels Payroll Entries, and we document which of those actions require a second approver in your process.
The other deliverables are the parts that keep a monthly run predictable. We produce a month-end runbook that walks your payroll team through each step, from pulling attendance and leave into the period to reviewing salary slips, generating the bank entry and handling corrections. We run test payrolls on sample or anonymized employee data so the team can see what a full cycle looks like before the first live run. We also document the Payroll Correction procedure and the bank entry procedure, and we hand the runbook, configuration records and test evidence over to your staff in a closing session. Confirm with us in writing which environments, data sets and number of test cycles are included in your scope.
DeployOpen does not issue payroll compliance attestations, audit reports or certifications. We configure the system to reflect the pay rules you give us, and we document how those rules are applied, but whether the calculations meet your statutory obligations is confirmed by your own payroll advisers, tax advisers and external auditors. Before scope is signed, ask us to list which statutory components are in scope and which are your responsibility. Ask your advisers to review the salary components, formulas and tax settings against your current rules, since that review is what supports your compliance position.
