What NGO finance finds wrong before the donor audit

In plain terms: an NGO audit fails in the software when commitment, cash received, and spend do not come from one chain, and when “approved” is allowed to mean “in the books.” On an international NGO with European funding and East African operations, those two rules explained most of the month-end reconstruction.

One receipt, two ledgers

Grant cash has a legal path and, in many systems, a second internal path.

• The legal path is the funding agreement: how much the donor committed, which disbursements were received, which published expenses consumed that agreement.
• The internal path is a fund bucket with its own movements, the sort of restricted and unrestricted pool some policies want.

If a disbursement already posts debit bank, credit grant income, a second “fund receipt” for the same cash doubles the income. Dashboards that read the fund buckets then disagree with the funding statement that reads the agreements. Staff enter the next grant in whichever menu they saw first.

The rule we put in place: donor funding is the source of truth for commitment, cash, and spend. The internal fund ledger stays installed for history and is visible only to an administrator. Empty fund lists are expected. Finance is not asked to maintain both unless the board has written down that it wants two books, and even then the second posting needs a documented split so the same bank line is not income twice.

Questions the screen has to answer without a spreadsheet:

• How much did the donor promise? The commitment on the funding agreement.
• How much hit the bank? Disbursements marked received, and the project’s total disbursed.
• How much can we still spend? Available amount, when cash control is on.
• How much did this grant consume? Spent on that funding agreement, not a second fund balance.
• Which bank? The payout bank on the disbursement or the voucher, under the same rules.

Approved is not spent

Budget versus actual stays stale for a boring reason: actuals count published vouchers only. A voucher that has been approved by the manager and not published has not hit the ledger and has not hit the budget. Refreshing the report will not invent the number.

The same gate shows up as these errors:

• “Budget line is not active.” A draft or merely approved line cannot take an expense. Someone has to activate it. Bulk activate exists so a new budget is not clicked line by line.
• “Allocation exceeds remaining balance.” The system is right. Reduce the split, pick another line, or raise the planned amount if someone with authority does that. Forcing the post is how a grant is overspent quietly.
• Project “total spent” does not move. The voucher is not published, or the allocation is not linked to that project.
• The voucher is published and there is still no journal. It has no allocation, or the budget line has no general-ledger account. The project screen and the ledger have come apart.
• A disbursement is marked received and there is still no journal. The received flag and the status do not match, or the bank account the entry needs does not exist.

Publish is the accounting moment. Approval is the management moment. They are different buttons on purpose.

A published voucher is not edited

Once a voucher is published, the fields lock. That feels hostile the first week. It is the audit trail. A correction is a reversal and a new voucher, or a reversing journal that points at the original. Editing the published row is how a donor pack changes under the reviewer between draft and final.

Projects that already have budgets or expenses are not deleted. Donors that already have agreements are not deleted. They are cancelled, inactivated, or archived. The history is the compliance file.

Co-financing on one expense

One workshop, two donors, a cost share. Each allocation row has to name the funding agreement it consumes. If the tag is missing, the project total moves and the funding statement does not, or the whole cost lands on the donor who happened to be the default. The donor report then has to be rebuilt by hand, which is the work the system was bought to stop.

Hierarchical budget lines matter here. A cap on the parent and a cap on the line are different promises. The line that staff can pick must be the line that still has room, and it must point at the account finance will defend.

Currency and the field payment

The donor reports in one currency. The field spends in another. The rate on the disbursement and the rate on the voucher have to be rates that were stored for that date, and the rate used has to stay on the entry. A “latest rate” lookup that changes next month rewrites history. Differences between the rate at receipt and the rate at payment are a real result. They need an account and a report, not a plug figure.

Mobile-money payouts to field staff fail reconciliation when the payout journal is not the account the statement import uses. The voucher can be perfect and the bank screen will still show the cash as outstanding. Payout bank on the voucher and the statement format are one setup, done before the first live payment, not during the audit.

What “grant-ready” means on the books

• Funding agreement, then disbursement, then journal. One chain.
• Voucher states that finance can explain: draft, approved, published, reversed.
• Budget lines with a cap, a general-ledger account, and a state. Inactive lines cannot be charged.
• A funding statement: committed, received, spent, available, by agreement and by currency.
• Exchange rates by date, kept on the entry that used them.
• Bank reconciliation against the same journals the vouchers pay from.
• A closed period that refuses new postings. Adjustments go in an open period and point back.

Standard nonprofit settings on Odoo cover a chart and a few analytic tags. They do not cover this chain. That gap is why the quarter still ends in Excel.