Skip to content

Create and approve a payment batch

How to take a payment cycle from an empty batch through to a bank-ready instruction file. The MIS deliberately splits this into two stages — generate then approve — with two different officers signing off before any money moves.

You need: Create batch (pym:ls:crt) to generate, and one of the two approval permissions (pym:bc:ap:fr, pym:bc:ap:sd) to sign off.

The approval snapshot is final

When a batch finishes generating, the amounts and bank-account details are frozen. Approval pays exactly that snapshot. Check accounts and apply exclusions before you approve — afterwards the batch is locked.

Stage 1 — Generate the batch

1. Create it

Go to Payments → Payment Batches and click Create Batch. In the modal, choose:

  • Province (or All Provinces)
  • Payment cycle — the start and end month/year

Click submit. You'll see "Payment batch created". The batch can't be created twice for the same location and cycle — the system blocks a duplicate.

2. Watch it build

The batch works through these statuses in the list:

Status Meaning
Queued Created, waiting for a worker to pick it up
Processing Calculating who's paid and how much, building the report
Complete Ready to review — the name becomes a clickable link
Failed Generation failed; the batch is archived automatically

During processing the system pulls each beneficiary's outstanding ledger balance, freezes their account details, and produces a PDF report. Only beneficiaries with a payable amount and a valid account are included.

3. Check the accounts

Open the completed batch. Use Validate All to queue a bank-account check for every member, or Validate on a single row. Results show in the Validation Result column:

Result Meaning
Valid Account and name match the bank
Name mismatch Account exists but the name differs — review before paying
Invalid The bank rejected the account
Validating… / Never validated Check running, or not yet run

4. Exclude anyone who shouldn't be paid

To hold a beneficiary out of this run only, click Exclude on their row. A reason is mandatory:

  • Fraud Investigation
  • Data Discrepancy
  • Administrative Hold
  • Account Re-verification
  • Other

Add the required details and click Confirm Exclusion. The row is struck through and marked EXCLUDED — they stay in the batch record but are dropped from the instruction file.

Exclusions only work before approval

The Exclude button disappears once a batch is approved or archived. If you spot a problem after approval, you cannot exclude — the payment is already committed to the snapshot.

Stage 2 — Approve the batch (two officers)

Approval takes two separate sign-offs, by two different officers.

flowchart LR
    C[Complete] --> V1{First approval}
    V1 -->|Approve| V2{Second approval}
    V1 -->|Reject| X[Halted]
    V2 -->|Approve| A[Approved 2/2]
    V2 -->|Reject| C
    A --> F[Instruction file + ledger entries]
    style A fill:#f1f5f2,stroke:#657e6b
    style F fill:#eef0f7,stroke:#3d4479
  1. First approval — the first officer opens the batch, reviews it, and clicks Approve (or Reject). The Review column shows Awaiting 0/2 until this happens.
  2. Second approval — a second officer with the second-stage permission does the same. On the second Approve, the batch becomes Approved 2/2, the bank instruction file is queued, and the disbursement is recorded on the ledger.

A Reject at the first stage halts the batch; a reject at the second stage sends it back to the first stage.

Stage 3 — Send to the bank and reconcile

  1. Generate Instruction File (pym:ins:gn) — builds the CSV the bank expects, containing every non-excluded member at the frozen amount.
  2. Download it (pym:ins:dl) and deliver it to the bank.
  3. When the bank replies, go to Reconciliation and Upload Response (pym:rcn:imp). The MIS marks each beneficiary paid or failed, records any difference on the ledger, and lets you export the failed rows (pym:rcn:exp) to follow up.