Payments And Settlement

Payments & Settlement is where finance teams review payment transactions, maintain payout destinations, run payment batches, reconcile settlements, and handle payment exceptions.

Billing records what is owed. Payments records how money moves.

When To Use Payments & Settlement

Use this area when you need to:

• Review inbound or outbound payment transactions.
• Maintain verified payment instruments for parties.
• Create and execute a batch payout.
• Pay many beneficiaries in one controlled workflow.
• Review settlement batches from cash, bank, wallet, mobile money, card, or provider rails.
• Investigate failed, reversed, disputed, or unreconciled payments.
• Request or review wallet top-ups where wallet-funded payouts are used.

Workspaces

Payments & Settlement is split into setup and operations.

Workspace Reference

Workspace	How Users Reach It	What Users Usually Do There
Payment Channels	Payments & Settlement -> Setup -> Payment Channels	Enable tenant payment rails and review channel behavior, direction, currency, and settlement readiness.
Payment Instruments	Payments & Settlement -> Setup -> Payment Instruments	Create and verify party-owned payment destinations such as bank, mobile money, wallet, or cash payout allowance.
Payment Batch Types	Payments & Settlement -> Setup -> Payment Batch Types	Configure batch categories, direction, allowed sources, channels, currencies, and approval behavior.
Payment Batch Schedules	Payments & Settlement -> Setup -> Payment Batch Schedules	Configure recurring batch generation rules.
Payment Transactions	Payments & Settlement -> Operations -> Payment Transactions	Review inbound and outbound money movement, status, references, and settlement state.
Payment Batches	Payments & Settlement -> Operations -> Payment Batches	Create, validate, approve, execute, retry, cancel, and review payout batches.
Settlement Batches	Payments & Settlement -> Operations -> Settlement Batches	Group payment transactions for reconciliation against provider, bank, wallet, card, cash, or till evidence.
Settlement Disputes	Payments & Settlement -> Operations -> Settlement Disputes	Handle chargebacks, reversals, refund disputes, representments, and exception resolution.

Open Payments & Settlement > Setup to maintain:

• Payment Channels: tenant-enabled rails such as cash, bank, mobile money, wallet, card, cheque, or internal transfer.
• Payment Instruments: verified payout destinations attached to parties and derived from party-owned contacts, bank accounts, wallet records, or cash payout allowance.
• Payment Batch Types: configured batch categories, direction, source rules, channel rules, and approval behavior.
• Payment Batch Schedules: recurring rules that can generate batches from approved source obligations.

Open Payments & Settlement > Operations for:

• Payment Transactions: the payment ledger for inbound and outbound money movement.
• Payment Batches: batch payout preparation, validation, approval, execution, retry, cancellation, and posting follow-up.
• Settlement Batches: settlement review and reconciliation for transactions grouped by provider, channel, period, or finance process.
• Settlement Disputes: chargebacks, reversals, refund disputes, representments, and exception resolution.

Some service areas, such as POS, Billing, Agriculture, HR, or Shares, may link into these same payment workspaces. The payment workflow remains shared even when a user enters it from another module.

Shared Source-Obligation Pattern

Many payment runs begin outside Payments, but they should arrive inside Payments in the same controlled shape.

Typical pattern:

1. A service or shared module creates approved source evidence.
2. That evidence creates or supports an approved obligation.
3. Payments batches that obligation for execution.
4. Settlement, posting, and reconciliation remain inside the shared payment workflow.

Examples:

• Agriculture attendance or settlement creates a payable obligation.
• Projects & WBS fund control supplies project, WBS, and funding context.
• Billing or refund flows supply receivable or refund context.
• HR or payroll supplies employee payout obligations.

Payments should not require users to rebuild this context manually if the approved source already carries it.

Payment Channels

Payment channels describe the way money moves. Common examples include:

• Cash.
• Bank transfer.
• Mobile money.
• Wallet.
• Card.
• Cheque.
• Internal transfer.

Payment channels are activated in Payments & Settlement > Setup > Payment Channels. Individual modules should not create their own separate payment-channel lists.

Payment Instruments

A payment instrument is a verified destination or source attached to a party. The party record remains the source of truth for contact and bank data; the instrument controls whether that party-owned destination can be used for payments.

Examples:

• A mobile money number for a farmer, supplier, employee, agent, or member.
• A bank account for supplier payout.
• A wallet identifier.
• A cash payout allowance or cash pickup reference where cash payout is allowed.

Payment instruments should be reviewed before batch payout. A user should be able to tell:

• Who owns the instrument.
• Which payment channel it uses.
• Which currency it supports.
• Whether it is active.
• Whether it has been verified.
• Whether it is the default instrument for that party and channel.

Payment Transactions

Payment Transactions is the shared ledger of money movement.

Use it to review:

• Direction: inbound or outbound.
• Channel: cash, bank, mobile money, wallet, card, cheque, or transfer.
• Amount and currency.
• Status.
• Provider or reference details where available.
• Settlement and reconciliation state.
• Related source document or business process.

Use Billing if you need to understand invoice balance. Use Payment Transactions if you need to understand the actual movement of money.

Payment Batches

A payment batch allows an organisation to pay many parties in one controlled run.

Typical examples:

• Farmer settlement payouts.
• Supplier payments.
• Payroll payments.
• Transporter payments.
• Agent commissions.
• Loan disbursements.
• Refund payouts.

Where the batch settles approved obligations, users should expect the line to inherit:

• beneficiary or payee
• source obligation reference
• project and WBS where present
• funding source where present
• cost category where present
• narration or source explanation

This matters in Agriculture, project-funded operations, payroll, refunds, commissions, and other controlled disbursement flows.

Batch Lifecycle

A typical batch moves through these steps:

1. Select the batch type.
2. Choose the payment channel and currency when they are not fixed by the batch type.
3. Add beneficiaries as batch lines.
4. Select the beneficiary from the party list.
5. Select an existing verified instrument for that party and channel.
6. Enter amount and narration.
7. Validate the batch.
8. Submit or approve, depending on the configured approval rule.
9. Execute the batch.
10. Review success, failure, pending, cancelled, or reversed lines.
11. Complete posting and reconciliation follow-up.

Batch Types

Batch types control how a payout is intended to be used.

A batch type can define:

• The purpose of the batch.
• Whether it is for direct disbursement or settlement of existing obligations.
• Whether approval is required.
• Which party profiles are allowed.
• Which source records are allowed.
• Which channels and currencies are allowed.
• Whether schedules can generate batches automatically.

For most users, the important decision is choosing the correct batch type before adding lines.

Batch Lines

Each line represents one beneficiary payment.

A good batch line should show:

• Beneficiary name.
• Payment instrument.
• Channel.
• Amount.
• Currency.
• Narration.
• Validation status.
• Payment status.
• Provider feedback or failure reason.

If a line fails, review the line feedback before retrying. Common reasons include missing wallet balance, invalid provider credentials, unavailable provider, unverified instrument, or provider rejection.

Settlement Batches

Settlement batches are different from payout batches.

A payout batch sends money out to beneficiaries. A settlement batch helps finance reconcile payment transactions after money has moved or been reported by a provider, bank, card processor, wallet rail, or merchant account.

Use settlement batches to:

• Group payment transactions for reconciliation.
• Compare expected and actual settlement amounts.
• Review provider references and settlement dates.
• Track fees, exclusions, rejected items, and exceptions.
• Confirm that finance has reviewed the settlement outcome.

Settlement Disputes

Use Settlement Disputes when a payment outcome is contested or needs formal exception handling.

Examples:

• Chargebacks.
• Refund disputes.
• Provider reversals.
• Amount mismatches.
• Representment follow-up.
• Manual exception resolution.

Disputes should be handled in the shared payment workspace so POS, Billing, Wallet, and other domains do not each create separate dispute ledgers.

Wallet Top-Ups

Some outbound payment flows use tenant wallets or provider float. If a wallet-funded payout is used, the wallet must have sufficient available balance before execution.

A typical wallet top-up flow is:

1. The tenant deposits funds through the agreed channel.
2. A top-up request is created with amount, currency, reference, and evidence.
3. An authorised admin reviews the request.
4. The request is approved or rejected.
5. If approved, the wallet balance becomes available for eligible payout workflows.

Wallet top-ups should be controlled by approval permissions and supporting evidence.

User Checks Before Executing A Batch

Before executing a payment batch, confirm:

• The batch type matches the business purpose.
• The payment channel is correct.
• The currency is correct.
• Every beneficiary has the correct verified instrument.
• Amounts and narrations are clear.
• Wallet or funding balance is sufficient where required.
• The approval state is complete.
• There are no invalid lines.

Common Mistakes To Avoid

• Do not use Billing to run payout batches.
• Do not create ad hoc beneficiary numbers inside a batch if the party already has managed payment instruments.
• Do not mix payment channels unless the selected batch type explicitly allows it.
• Do not retry a failed line before reading the provider or system feedback.
• Do not post or reconcile a batch without understanding cancelled, failed, and successful line totals.
• Do not treat settlement batches as payout batches. They serve different purposes.

Related Guides

• Billing And Invoicing
• Project Fund Control
• Payment Channels
• Navigation & Permissions