Grant payment processing — the step that turns an approved grant into actual money in the grantee's bank account — is a critical operational function that sits at the intersection of grants administration and financial management. It needs to be fast enough to meet grantees' cash flow needs, accurate enough to prevent errors, and controlled enough to prevent fraud.
This guide covers how to design efficient, secure grant payment processes and what software features support them.
Grant payments typically go through several stages:
Payment authorisation. Before any payment is made, it must be authorised — by someone with the appropriate approval authority, against a properly executed grant agreement. Payment authorisation is a key internal control: no grant funds should leave the organisation without an authorised approval trail.
Payment preparation. The payment details — payee name, bank account, amount, reference — are compiled, usually from the grants management system or grant agreement.
Payment verification. Before initiating payment, verify the bank account details against the grant agreement or an independent source. Bank account fraud — where payment details are changed by fraudsters — is a real risk in grants management.
Payment initiation. The actual payment instruction is sent to the bank or payment processor — via online banking, bank file upload, or payment API.
Payment confirmation. Confirmation that the payment was processed successfully. This may come from the bank immediately (for bank transfers) or with a short delay.
Grant record update. The payment is recorded against the grant record — amount paid, date, payment reference — and the grant status is updated.
Grantee notification. The grantee is notified that payment has been made — with the date, amount, and reference so they can match the payment when it arrives.
Accounting entry. The payment is recorded in the accounting system — as a reduction in grants payable and a cash outflow.
How grants are paid varies by programme design:
Single upfront payment. The full grant amount is paid when the grant agreement is executed. Simple and fast, but highest financial risk for the funder — all money is paid before any delivery is verified.
Advance with acquittal. An advance is paid at the start, and a final acquittal confirms how the funds were used. Any unspent balance is returned. Balances grantee cash flow needs with funder financial control.
Milestone-based payments. Payments are made when specific milestones are reached — and verified by the funder. Requires active milestone tracking and creates potential cash flow delays if milestone verification takes time.
Reimbursement. Grantees incur costs and submit receipts for reimbursement. Maximum financial control for the funder, but requires grantees to have the cash flow to fund activities in advance. Can be burdensome for smaller organisations.
Equal instalments over time. Annual or quarterly payments over a multi-year grant, with reporting requirements at each instalment. Common for operational and capacity-building grants.
50-50 split. 50% on execution, 50% on completion or final report. Simple two-payment structure that works well for project grants.
Grant payment is a high-risk financial function. Key controls:
Segregation of duties. The person who approves a grant should not be the same person who initiates and confirms the payment. Requiring different people for approval and payment reduces fraud risk.
Two-authoriser payment initiation. For payments above a threshold, requiring two authorised people to approve before payment is initiated — one to prepare, one to confirm — provides an additional check.
Bank account verification. Never pay to a bank account that hasn't been verified against the grant agreement or an independent source. When a grantee requests a bank account change, verify the new account with a callback to a known contact before updating.
Payment limit thresholds. Payments above a certain size should require additional approval — from a senior manager, finance committee, or board, depending on the threshold. Thresholds should be set in the organisation's financial delegation policy.
Payment reconciliation. At the end of each payment cycle, reconcile the payments made against the grants management system records — confirming that every payment made has a corresponding authorised grant record.
Two main payment execution approaches:
Manual online banking. Each payment is manually entered into the online banking system by a staff member. Simple but time-consuming for high volumes, and creates manual re-entry risk.
Bank file upload. A file of payment instructions (ABA format in Australia, CSV or bank-specific format in NZ) is generated from the grants management or accounting system and uploaded to the bank's online payment system in one batch. Faster, more accurate, and better suited to high-volume payment runs.
For programmes making more than 10-20 payments per cycle, bank file processing is significantly more efficient than manual entry.
Payment scheduling. Automatic scheduling of payment dates based on milestone completion, agreement execution, or calendar triggers. Staff are notified when payments are due for initiation.
Payment status tracking. Each grant payment has a clear status — scheduled, initiated, confirmed, failed — visible in the grant record.
Bank file generation. Export of payment instructions in bank-compatible formats (ABA, CSV), reducing manual re-entry and errors.
Payment authorisation workflow. Digital approval workflow — preparing officer flags payment for authorisation, authorising officer approves within the system, creating an audit trail of who approved what payment.
Bank account change alerts. Flagging when bank account details are updated for a grantee, for manual verification before the changed details are used in a payment.
Payment reconciliation reporting. Reports showing all payments made in a period, with status and grant reference — supporting reconciliation with the accounting system.
Grantee notification. Automatic email notification to grantees when payment is processed — with amount, date, and reference.
Paying before the agreement is executed. Payment should only follow a properly executed grant agreement. Payments made informally before the agreement is signed leave the funder without legal protection.
Not verifying changed bank accounts. One of the most common fraud vectors in grants management. Always verify bank account changes independently before paying to a new account.
Payments not matched to grants. When payments are made outside the grants management system — directly through online banking without a corresponding record — the grant file is incomplete and reconciliation fails.
Late payment. Grantees who've been notified of a successful grant and then wait weeks or months for payment are frustrated, and late payment affects their ability to deliver programmes. Build payment processes that are fast enough to meet reasonable grantee expectations.
Tahua's payment management module supports payment scheduling, bank file generation, authorisation workflows, and automatic grantee notifications — integrating grant payment with the full grants management workflow.