Salary payment batches

A salary payment batch is the record that pays one payroll run's net salaries, together with the expense claims the run reimburses. It is one bank payment that settles every employee's Payroll Payable open items in a single journal: debit Payroll Payable, credit the bank. It comes after the run is posted, because posting is what raises the net-pay open items. A posted full and final settlement is paid the same way, through a batch of its own. When the batch is paid, the run is finished, and you make the actual transfer through your bank. The batch is built for you from the run; you check it and click Pay.

Overview

A batch has a header and one line per employee:

• The header names the payroll run (blank on a full-and-final batch), the company (Partner Account), the bank GL account the salary is paid from, the Payment Date and the Total Net Pay.
• Each line is everything still open for one employee: on a run batch, their net salary plus the expense claims the run carries; on a full-and-final batch, the settlement's open net amount. The bank account number and IFSC are copied from that person's Resource record.

A batch has two statuses in practice:

The Status list also offers Approved and File Generated. Nothing in xMatix sets them, and nothing reads them.

When to use it

Use a batch once a month for each payroll run, after the run is posted (directly or through approval) and before you transfer the money. Its payment journal lands in the period of the batch's Payment Date. That date is separate from the payroll period's pay date, which dates the accrual journal.

A run's batch pays the run's net-pay open items and the Payroll-Payable open items of the expense claims the run carries. A settlement's batch pays only that settlement's open net amount. A run's batch never pays a full and final settlement, a settlement's batch never pays salary, and no batch pays a loan or a claim reimbursed by finance.

How xMatix handles it

Generating. Generate payment batch on a posted run builds the batch in one step:

• One line for each employee with something open on the run. The line amount is everything still open for them: net salary plus the expense claims the run carries, rounded to two decimals. The line also copies the person's Bank Account Number and IFSC Code from their Resource. Employees with nothing open, or a total of zero or less, get no line. Because of the claims, the batch total can be higher than the run's posted net salary.
• Name is PPB- followed by the run's number. Partner Account is copied from the run. Payment Date is today. Status is Draft. Total Net Pay and Item Count are the sum and the number of lines.
• Bank GL account is the company's default bank (Set default bank under Org Settings → Companies). If the company has no default, xMatix uses its only GL account with Control Type Bank. With several bank accounts and no default, generation stops and names them, because xMatix will not guess which account to pay salary from.
• The run's Status becomes PaymentGenerated.

Nothing is posted at this point. You can delete a Draft batch and generate it again.

Paying. Pay on the batch works from the run's open items, not from the line amounts:

1. For each line that names an employee, xMatix finds that employee's open Payroll Payable items that are not yet settled or reversed: on a run batch, their net-pay item and the items of the claims the run carries; on a full-and-final batch, their settlement's item. A line with no open item left is skipped.
2. It posts one journal of type Payroll, dated the batch's Payment Date, with the narration Salary payment (or Full-and-final payment) followed by the batch name. The journal has one debit line ("Payroll payable settled") per Payroll Payable account and branch, and one credit line ("Salary paid" or "Full-and-final paid") for the total on the batch's bank GL account. The branch comes from the open items, or from the run if they have none.
3. Each settled open item drops to zero and becomes Settled. A claim whose item is settled becomes Payment Status Paid and Status Settled; a settlement becomes Status Paid. Each line's Payment Status becomes Paid and its Net Pay Amount is rewritten to the amount actually paid.
4. The batch's GL link is filled and its Status becomes Paid. Total Net Pay and Item Count are rewritten to the amount and number actually settled.
5. On a run batch, the run's Status becomes Paid, and its Payment Batch field names this batch.

The journal is listed on the batch's Related tab.

What the batch does not do. xMatix does not produce a bank transfer file, and it does not read a bank acknowledgement. Payment File Format, Payment Reference and each line's UTR number (the UTR, on salary and full-and-final lines alike) are there for you to record things by hand. Nothing fills or reads them.

Prerequisites

• A payroll run whose Payroll Posting Status is Posted, with at least one employee who has something open to pay — or a posted full and final settlement with an open net amount.
• A GL account with Control Type Bank for the run's company. If the company has more than one, set its default bank (see Configuration).
• Bank Account Number and IFSC Code on each employee's Resource, filled in before you generate, if you want them on the lines (see Resources).
• An open fiscal period for the payment date.
• A security profile that can run Generate payment batch on the run and Pay on the batch (see Permissions).

Procedure

Step 1 — Generate the batch from the run

Open the posted payroll run and click Generate payment batch once. A Draft batch named PPB- plus the run number is created, and the run's Status shows PaymentGenerated.

The run's page does not list its batches, and Payment Batch on the run is filled only after payment. Go on to Step 2 to find the batch.

For a leaver, click Generate payment batch on the posted full and final settlement instead. It creates a Draft batch named PPB-FNF- plus the settlement number, with Payroll Run blank, the label "Full-and-final payment" and one line for the person. The bank GL is derived the same way as for salary. See Full and final settlement.

Step 2 — Open the batch

Open Payroll → Pay and comply → Salary payment batches.

The list shows Name, Payment Date, Partner Account, Total Net Pay, Payment Reference, Status, Created By, Created and Modified Date. Click the batch's name to open it.

The batch page has:

• a header showing the Name, Partner Account, Payroll Run, Status and Total Net Pay, with the Pay, Edit and Delete buttons;
• a Payment Batch Line tab listing the lines;
• a Related tab listing the batch's journals (empty until it is paid);
• a Details tab with a Key Information section (Partner Account, Bank GL Account, Payroll Run, GL) and a Payment Information section (Payment Date, Payment File Format, Payment Reference, Total Net Pay, Item Count).

Step 3 — Check the batch

On the Details tab, check:

• Bank GL account is the account you are paying from;
• Payment Date is the date the payment should be posted on. It is the date you generated the batch, so change it if you will pay later;
• Total Net Pay and Item Count match what you expect to pay: the run's net salary plus the claims it reimburses, and the number of employees.

To change a field, click it on the record page, change the value and save. Edit opens a smaller form (Name, Partner Account, Payment Date, Payment Reference, Payment File Format, Total Net Pay, Item Count) that does not include the bank account.

The Bank GL account picker lists every GL account, not only bank accounts. Choose a Control Type Bank account of the run's company. Pay does not check the account's type.

On the Payment Batch Line tab, check each line's Net Pay Amount, Employee Bank Account, IFSC and Payment Status (Pending). Each line has a generated number rather than the employee's name, and the seeded list has no employee column. Add Resource through the list's column controls (see Personalizing lists and views), or ask your administrator to add it to the view.

If a bank account or IFSC is missing or wrong, correct it on the person's Resource, delete the Draft batch, and generate it again. Lines copy the bank details only when they are generated.

Don't edit line amounts to change what is paid. Pay settles the employees' open items (net pay and claims) in full, whatever the lines say. To pay a different amount, correct the run's inputs before posting, or record the difference as a payroll adjustment next month.

Step 4 — Pay the batch

Click Pay. The dialog asks Are you sure? with the text "Pay the salary batch (Dr Payroll Payable / Cr Bank)." Click Yes. A full-and-final batch is paid the same way.

When it finishes:

• the batch's Status is Paid, and GL links to the payment journal, which the Related tab also lists;
• every line whose employee had an open item shows Payment Status Paid and the amount actually paid;
• Total Net Pay and Item Count show what was actually settled;
• the expense claims the batch paid show Payment Status Paid and Status Settled;
• for a run batch, the payroll run's Status is Paid and its Payment Batch names this batch; for a full-and-final batch, the settlement's Status is Paid.

Pay works once. A second click is refused with "Payment batch is already paid."

Step 5 — Transfer the money and record the reference

Make the salary transfer through your bank, using the lines (account number, IFSC and amount) as the instruction. If you want the bank's reference on record, type it into Payment Reference on the batch, and each employee's transaction reference into UTR number on their line. These are notes only.

Step 6 — Remove a batch you don't need

On a Draft batch, click Delete and confirm. Nothing was posted, so nothing else changes. You can then click Generate payment batch on the run again.

Don't delete a Paid batch. Nothing stops you, but deleting it doesn't reverse the payment journal or reopen the open items. The run keeps its Paid status and its link to the deleted batch.

On mobile

The batch has no place in the field app. Generate and pay it on the web.

Fields

Batch

Line

Business rules

• Generate needs a posted run. The run's Payroll Posting Status must be Posted, and at least one employee must have a positive amount open on the run (net pay plus claims).
• Full-and-final batches. Generate payment batch on a settlement needs it posted with an open net amount, and refuses while the person is on another unpaid full-and-final batch. See Full and final settlement.
• The bank is never guessed. The company's default bank must be an active Bank account of that company. Without a default, the company must have exactly one Bank account. Otherwise generation stops with a message that names the fix.
• One batch per run at a time. Name is unique and every batch of a run gets the same name, so a second Generate payment batch is refused while the first batch exists. Delete the Draft batch first if you need to rebuild it.
• Lines are a snapshot. Amounts and bank details are copied when the batch is generated. Later changes to a Resource or to the run's rows are not picked up; delete and regenerate a Draft batch to refresh it.
• Pay settles open items, not lines. Pay looks up each line's employee's open Payroll Payable items — the run's net pay and its claims, or the settlement's net — and settles all of them. Line amounts are not used. A line whose employee has nothing open stays Pending, and no error is shown for it.
• Pay refuses a batch that is already paid ("Payment batch is already paid."), a batch with no bank GL account, and a batch where nothing is left open to settle ("Batch has no open net-pay items to settle.").
• Payroll Payable nets to zero. A run accrues salary once and each claim once; the paid batch pays each once, so the run's employees owe nothing on Payroll Payable afterwards.
• Normal posting checks apply. The journal must balance, every GL account must be active, the Payroll Payable and bank accounts must not have Is Control Account ticked (that flag demands a customer or supplier on every line), and the payment date's fiscal period and financial year must be open.
• No lock and no undo. A Paid batch can still be edited and deleted, and it has no reverse action. Reversing the payment journal from Journals doesn't change the batch, the lines, the open items or the run.
• Payslips are untouched. Generating or paying the batch doesn't change any payslip.

Example

A payroll officer pays the June salaries of a 12-person company.

1. The June run (PR-06-2026) is approved and posted on 28 June. It has 12 employees; one, on unpaid leave all month, has net pay 0.
2. On 30 June the officer clicks Generate payment batch. Batch PPB-PR-06-2026 is created in Draft with 11 lines totalling 5,42,800 and the company's default bank, which is its salary account.
3. One line shows no IFSC. The officer adds the IFSC Code to that person's Resource, deletes the Draft batch and clicks Generate payment batch again. The new batch has the code.
4. The bank transfer will go out on 1 July, so the officer changes Payment Date to 1 July.
5. The officer clicks Pay and confirms. The batch shows Paid, Item Count 11 and Total Net Pay 5,42,800. The Related tab lists one journal dated 1 July: debit Payroll Payable 5,42,800, credit the salary bank account 5,42,800. All 11 lines are Paid, and the run shows Paid.
6. The officer uploads the transfer through the bank's own portal and types the bank's batch reference into Payment Reference.

Training

Practice exercise

In a sandbox with a posted payroll run:

1. On the run, click Generate payment batch. Find the batch under Payroll → Pay and comply → Salary payment batches.
2. Compare the batch's Total Net Pay with the run's total net pay (which includes any expense claims the run carries), and its Item Count with the number of employees with something to pay.
3. Click Generate payment batch on the run again and read the message.
4. On the batch, set Payment Date to today and click Pay.

Expected result: Step 3 is refused because a batch of that name already exists. After Step 4 the batch is Paid, its Related tab lists one Payroll journal, all lines are Paid, and the run's Status is Paid with Payment Batch filled.

Quick reference

• Generate on the run; pay on the batch.
• Find the batch under Payroll → Pay and comply → Salary payment batches.
• The batch pays net salary plus the run's expense claims; a leaver's net goes on a separate PPB-FNF- batch.
• One batch per run at a time; delete a Draft batch to rebuild it.
• Fix bank details on the Resource, then regenerate. Lines don't refresh.
• Set Payment Date to the real payment day before you click Pay.
• Editing line amounts changes nothing; Pay settles the open items in full.
• A line still Pending after Pay means that employee had nothing open.
• xMatix makes no bank file. Transfer through your bank.
• Don't delete a Paid batch; nothing is undone.

Permissions

Access is set in each security profile under Setup → Access Control → Profiles (see Security profiles). A user needs:

• entity permissions on Salary Payment Batch and Payment Batch Line (Entity Permissions tab) to open, edit and delete batches and lines. New, Edit and Delete follow these permissions;
• a grant for Generate payment batch on Payroll Run (Actions tab) to create a run batch, or on Full & Final Settlement for a full-and-final batch;
• a grant for Pay on Salary Payment Batch (Actions tab) to pay it. A user without the grant cannot run Pay.

In the seeded profiles:

• SystemAdmin and StandardUser have full entity access and both actions.
• SalesExecutive has full entity access to batches and lines but neither action, so it can open, edit and delete batches but not generate or pay them.

The seeded access is broad. Before you go live, limit both entities and both actions to your payroll team, because Pay posts to the bank account and a batch's fields can be edited after it is paid.

Configuration

Common problems

"Payroll run must be posted before a payment batch can be generated."

Post the run first, directly or through approval, then click Generate payment batch again.

"Run has no positive net pay to disburse."

Nothing is open on the run for any employee, or every employee's open total is zero or negative. Review the run's register; negative net pay usually means a deduction or loan installment larger than the month's earnings.

Generate Payment says the company has no bank, several banks, or an invalid default bank

The bank is chosen from the run's company. If the run has no company, set its Partner Account. If the company has no Bank account, give a GL account Control Type Bank. If it has several, use Set default bank under Org Settings → Companies. If the default is no longer an active Bank account of that company, choose another.

"Name 'PPB-…' already exists"

The run already has a batch. Open Salary Payment Batches and use that batch. If it is Draft and you want to rebuild it, delete it and generate again. If it is Paid, the run is already paid.

"Payment batch is already paid."

The batch already has a payment journal. Check its Related tab. There is nothing left to pay.

"Payment batch needs a bank GL account."

The batch was created with New, or a field was cleared. Batches are meant to be generated from the run or the settlement: delete this one and click Generate payment batch again. To keep a generated batch, set Bank GL account on its Details tab.

"Batch has no open net-pay items to settle."

Nothing the batch links is still open: none of the employees on the lines has an open Payroll Payable item from this run (or, on a full-and-final batch, from a settlement). Usually it was already paid, or the batch was created by hand and has no lines. Check the run's Related tab: open items already Settled mean the salary is paid.

"Fiscal period '…' is Closed — posting is not allowed."

The batch's Payment Date falls in a closed or locked period. Change Payment Date to a date in an open period, or ask your finance team to reopen the period, then click Pay again.

"Party Account is required on lines posting to a control account."

The Payroll Payable or bank GL account has Is Control Account ticked. That flag is for customer and supplier accounts only. Untick it on the GL account and click Pay again (see GL accounts).

An employee's line is still Pending after Pay

That employee had no open Payroll Payable item (net pay or claim) from the run when the batch was paid, so nothing was paid to them through the batch. Check the run's Related tab for their open item. No error is recorded for the line.

The bank account or IFSC on a line is wrong

Lines copy bank details when the batch is generated. On a Draft batch, correct the Resource, delete the batch and generate it again. On a Paid batch, correct the line's fields by hand for your records. The journal is not affected.

The batch was paid from the wrong bank account or on the wrong date

The batch can't be paid again, and it has no reverse. In Finance, reverse the payment journal (see Journals) and post a manual journal that debits Payroll Payable and credits the right bank account on the right date. The batch, its lines and the employees' open items stay as they are.

Common questions

Does xMatix send the salary to the bank?

No. Pay records the payment in your ledger and settles the employees' open items, but it doesn't transfer money or produce a bank file. Use the lines' account numbers, IFSC codes and amounts to make the transfer through your bank, and record the bank's reference in Payment Reference if you want it on the batch. Payment File Format and the Approved and File Generated statuses are not used.

Can I pay only some employees?

No. Pay settles the open items of every employee on the batch's lines, all in one journal, and the batch has no way to hold one person back. Because a run can have only one batch at a time, you also can't pay the rest in a second batch later. If one employee's salary must wait, pay the whole batch and handle that person's transfer separately at your bank. Their open item still shows as settled in xMatix.

Why is Total Net Pay different after paying?

At generation it is the sum of the lines. Pay replaces it with what was actually settled from the employees' open items, which is also the amount of the bank credit. A lower figure means some employees had nothing left open. Their lines stay Pending, and Item Count drops by the same number.

Why is the batch more than the run's posted net salary?

The batch also pays the expense claims the run carries. Their amounts reached Payroll Payable when they were handed to payroll, so the run's posting journal does not include them, but each employee's batch line does. After the batch is paid, Payroll Payable for the run's employees is back to zero. See Expense claims through payroll.

Can one batch pay several runs?

No. Each run batch belongs to one payroll run and settles only that run's open items, including the claims it carries. Pay each run, for example each company, with its own batch. Full and final settlements are paid by their own PPB-FNF- batches.

Is the payment dated on the payroll period's pay date?

No. The payment journal uses the batch's Payment Date, which is the day you generated the batch. The payroll period's pay date dates the run's accrual journal instead. Change Payment Date on the batch before clicking Pay if the transfer happens on another day.

Related topics

• Running payroll — the full monthly cycle up to Generate Payment.
• Full and final settlement — paying a leaver through a PPB-FNF- batch.
• Expense claims through payroll — claims paid with the salary.
• Payroll configuration — control accounts and the default bank.
• AR and AP subledgers — how open items, including the employees' Payroll Payable items, are kept.
• Journals — reading and reversing the payment journal.
• Bank accounts — the default bank for disbursements.
• Salary Payment Batch reference and Payment Batch Line reference.
• Payment Batch — entity reference
• Payment — entity reference