Payment Batches

Payment batches let users pay many beneficiaries in one controlled run. They are used for outbound payments where the organisation sends money to parties.

Open Payments & Settlement -> Operations -> Payment Batches.

Workspace Reference

Area	What The User Does
Main table	Reviews batch number, batch type, channel, currency, line count, total, validation status, approval status, execution status, and posting status.
New Batch	Opens the batch form.
Validate	Checks whether the batch is safe to approve or execute.
Submit or Approve	Moves the batch through the configured approval workflow.
Execute	Sends eligible lines to the selected payment channel or payout process.
Retry	Attempts failed lines again after the issue is corrected.
Cancel	Stops a batch or line from further execution.
Post	Sends eligible successful results to accounting where posting is enabled.
View Detail	Reviews lines, instruments, totals, validation messages, execution results, fees, and posting state.

When To Use A Batch

Use a payment batch for:

• supplier payouts
• farmer settlements
• payroll runs
• transporter payments
• agent commissions
• refunds
• bulk loan disbursements
• other outbound party payments

Use a single payment transaction only when there is one payment and no batch review is needed.

Shared Obligation Flows

Payment batches are shared execution workspaces. Service modules may send users here, but should not create parallel payout engines.

Typical upstream owners include:

• Projects & WBS fund control for project-funded obligations
• Agriculture source workflows for farmer, worker, supplier, or settlement payables
• Billing for refunds or outbound adjustments
• HR or payroll for employee payouts

The execution rule is the same: upstream modules approve the source and obligation, while Payments owns the batch, provider outcome, retry, cancellation, posting follow-up, and settlement review.

Setup Versus Operations

Payment batch setup and execution should be separated.

Area	Workspace	Purpose
Batch types	Payments & Settlement -> Setup -> Payment Batch Types	Defines reusable batch categories, approval behavior, channel rules, direction, and accounting behavior.
Instruments	Payments & Settlement -> Setup -> Payment Instruments	Defines verified party payout destinations.
Schedules	Payments & Settlement -> Setup -> Payment Batch Schedules	Defines recurring or generated batch rules where enabled.
Batch execution	Payments & Settlement -> Operations -> Payment Batches	Creates, validates, approves, executes, retries, cancels, posts, and reviews actual batches.

Creating A Batch

1. Click New Batch.
2. Select the batch type.
3. Confirm the payment channel and currency if the batch type does not fix them.
4. Enter requested execution date and description.
5. Add payment lines. If the batch settles approved obligations, prefer selecting approved sources so the line is prefilled instead of typed from scratch.
6. Validate the batch.
7. Submit or approve depending on configuration.
8. Execute when ready.
9. Review line outcomes and reconciliation status.
10. Post to GL only when the batch is eligible.

Batch Header Fields

Important batch header fields:

Field	Required	Meaning
Batch Type	Yes	Controls direction, source rules, channel rules, approval behavior, and accounting behavior.
Payment Channel	Required unless fixed by the type	Cash, bank, mobile money, wallet, cheque, card, internal transfer, or another configured rail.
Currency	Required unless fixed by the type	Currency used by all batch lines where the type enforces one currency.
Requested Execution Date	Recommended	Date the payout should run or be reviewed for execution.
Description	Recommended	Purpose of the batch, such as farmer settlement, supplier payment, payroll, refund, or commission run.

Choose the batch type before adding lines. The selected type can lock or filter channels, currencies, sources, approvals, and posting behavior.

Batch Type Attributes

Batch type details guide what users can do in the batch.

Important attributes include:

Attribute	User Meaning
Direction	Outbound batches send money. Inbound activity normally belongs to Billing, POS, Wallet, or settlement workflows.
Batch mode	Whether the batch pays direct destinations or settles existing obligations.
Required channel	Whether the batch is fixed to cash, bank, mobile money, wallet, cheque, or another channel.
Required currency	Whether the batch must use one currency.
Mixed-channel setting	Whether all lines must use the same channel. Most payout batches should not mix channels.
Approval behavior	Whether validation is enough or a second user must approve before execution.
Auto-approval behavior	Whether the batch can proceed without manual approval where policy allows it.
Schedule behavior	Whether the type can be used by recurring batch schedules.

The batch detail dialog should be reviewed when users are unsure why a field is locked, required, or filtered.

Adding Lines

Each line should include:

• beneficiary party
• existing verified instrument for that party
• amount
• currency
• narration
• source obligation where the batch settles existing obligations

The instrument list should be filtered by:

• selected party
• selected payment channel
• selected currency
• active status
• approval status
• verification status

Users should not type new phone numbers or bank accounts directly on batch lines. If the destination is missing, update the party contact or bank account and create or verify the corresponding instrument first.

Where the batch is obligation-backed, users should also avoid manually retyping:

• project
• WBS or work package
• funding source
• source reference
• source amount basis

That context should come from the approved obligation payload where the tenant workflow supports it.

Important line fields:

Field	Required	Meaning
Beneficiary party	Yes	Person or organisation being paid.
Payment instrument	Yes	Approved destination for the party, channel, and currency.
Amount	Yes	Amount to pay.
Currency	Required where lines can vary	Currency for the line.
Narration	Recommended	Explanation that appears in review, audit, provider, or statement context.
Source obligation	Required for settlement batches where configured	Approved payable, settlement statement, invoice refund, commission, payroll line, or other source being settled.
Validation message	Review before approval	Explains why the line can or cannot proceed.

Validation

Validation checks that the batch is safe to approve or execute.

Typical checks include:

• batch type is active and allowed
• direction and channel are valid
• all lines have valid parties
• all lines use eligible instruments
• currency is consistent
• mixed channels are blocked where not allowed
• amount is positive
• duplicate or suspicious lines are identified
• funding or wallet prerequisites are met where required
• source obligation is approved where required
• amount does not exceed remaining obligation amount
• inherited project or funding context is still valid

Do not execute a batch that has validation warnings you do not understand.

Approval

Some tenants require maker-checker approval. Others allow auto-approval for selected batch types.

If approval is required:

• the creator may not be allowed to approve the same batch
• approvers should review batch type, channel, currency, line count, total amount, payees, instruments, and narration
• returned batches should be corrected and resubmitted

Execution

Execution submits eligible lines to the selected payment channel or payout process.

Before execution, confirm:

• batch is valid
• approval is complete
• funding is available
• line instruments are verified
• requested execution date is correct
• payment channel is operational

Line Outcomes

Outcome	Meaning
Successful	The payment completed.
Pending	Provider, bank, wallet, or settlement confirmation is still pending.
Failed	The line did not complete. Review feedback before retrying.
Cancelled	The line was intentionally stopped from further payout follow-up.
Reversed	A completed payment was reversed.

The batch total may include lines that were later cancelled or failed. Always review paid amount, cancelled amount, failed amount, and line outcomes.

Retry And Cancellation

Retry a failed line only when the failure is temporary or setup has been corrected.

Cancel a line when:

• the destination is wrong
• the party should not be paid in this run
• maximum retries are exhausted
• the obligation will be handled separately

Cancelled lines should remain visible for audit.

GL Posting

Post to GL only when the batch is financially clear enough to account for.

For project-funded or Agriculture-backed payouts, the batch posting should preserve the inherited project, WBS, funding source, source document, and narration context so Reporting and reconciliation can trace the payout back to the approved obligation.

Normal expectation:

• successful lines can be posted
• cancelled lines should not be treated as paid
• failed or pending lines should be resolved before posting unless policy explicitly allows partial posting
• fee lines should be reviewed before posting

Accounting Tags

Payment batch posting uses administrator-configured accounting tags and posting rules. These tags do not come from the payment instrument; they come from the payment batch/channel accounting setup.

Accounting Tag	User Meaning
Payment Batch Disbursement	Selects the accounting rule for outbound batch payouts.
Debit Clearing / Payable	Debits the payable or payment-clearing account for successfully paid amounts.
Debit Fees	Debits provider, wallet, bank, or platform fee expense where fees exist.
Credit Funds Out	Credits the funding account, such as wallet float, cash on hand, till, bank, cheque clearing, or provider float.

Funding normally resolves by channel:

Channel	Normal Funding Account Concept
Mobile money	Tenant wallet or provider float for the selected rail.
Wallet	Internal wallet or service wallet.
Cash	Cash on hand or till.
Bank	Configured bank account.
Cheque	Cheque clearing or bank suspense.
Card refund	Card processor clearing or refund clearing.
Internal transfer	Internal wallet, bank, or clearing account.

If the funding account is a control account, the setup must also resolve the correct detailed tracking reference.

Common Mistakes

Mistake	Better Practice
Mixing channels in one payout batch without a clear reason.	Use one channel per batch unless the batch type explicitly allows mixed channels.
Adding unverified instruments.	Verify and approve instruments first.
Posting GL while lines are still failed or pending.	Resolve line outcomes before posting.
Treating batch total as paid amount.	Review paid, failed, cancelled, and pending amounts separately.
Retrying provider failures blindly.	Correct credentials, wallet funding, provider setup, or destination data first.

Related Guides

• Project Fund Control
• Payment Instruments
• Payment Channels
• Settlement And Reconciliation
• Wallet Top-Ups