Faith organisation (delivered via Fiverr)
Donation & Withdrawal Ledger
An internal ledger for a faith organisation: per-member donation and withdrawal entries, a running balance, and reports that can be sliced by year, month, member and type.
- Status
- Completed
- Industry
- Non-profit & Community
- Year
- 2021
- Categories
- Web Applications, Business Systems
A small internal tool, built to the shape the client described
A custom PHP donation and withdrawal ledger with per-member balances and a flexible report builder, built to a client-specified layout for internal use by a faith organisation.
Our earliest engagement in this portfolio, and a useful one to keep visible: a custom PHP application built for one of the executives of a church, to manage the donations and withdrawals the congregation's fund handles.
It is an internal tool. There is no public side, no marketing surface, and no ambition beyond being correct and quick to operate — which is exactly what the client asked for.
What it does
An operator picks a member or guest from the register, or creates a new one, and records a donation or a withdrawal against them. The header carries the day's running totals — donated, withdrawn, balance — and each member's record shows their last transaction in plain language.
The reporting side is the part that earns the tool. Any combination of year, month, member or guest, and entry type can be reported as a summary or in detail, displayed as a table or exported, with per-member totals, maxima, minima and averages.
Administrators are managed in the application with roles, so the executive controls who can see the ledger.
- Balances
- Computed from entries
- Reporting
- Period, member and type
- Access
- Permission levels
The problem
The fund's records were manual, and manual records of money have a predictable set of problems: a balance nobody can state with confidence, no way to answer "what did this member give last year" without paging through a book, and no separation between who may record an entry and who may read the whole ledger.
The client came to us having already thought it through. He described the problems he was facing and how he intended them to be solved, including how the screens should be laid out.
Requirements
- Register members and guests, capturing name, date of birth and phone number
- Record donations and withdrawals against a member or guest
- Show a running balance per member and a running total for the day
- Report across year, month, member or guest, and entry type
- Offer summary and detailed report modes
- Display reports as a table or export them
- Manage administrators with permission levels
- Follow the client's own layout and workflow
The solution
The entry workflow was built around a single screen, because the work happens in a queue of people. The member register sits on the left, the entry form on the right, and the day's totals stay pinned above both. Selecting a member loads their record in place; creating a new one happens in the same panel. Nobody navigates away mid-queue.
Each member's record states its last transaction as a sentence — Last transaction was on July 29th, 2021 12:39 PM, $21.00 was Deposited — rather than as a row in a grid. When an operator is confirming something with the person standing in front of them, a sentence is faster to read aloud than a table.
Reporting is a small query builder rather than a fixed set of reports. Six selectors — year, month, member or guest, type, summary or detail, table or export — cover the questions the executive actually asks, and the summary mode computes totals, maxima, minima and averages per member so that comparison is possible without exporting anything.
Administrators are records in the system with a permission level, which is what makes the ledger delegable at all.
Architecture
A custom PHP application on MySQL — no framework, which was appropriate to the size, the budget and the year.
The interface is server-rendered with jQuery handling the in-page interactions: the member list, the inline forms, the report tables with their search, pagination, column visibility and export.
Entries are stored as individual immutable transactions against a member rather than as a mutable balance field. The balance is computed, so the history is the record and a correction is a new entry.
Implementation
The layout was the client's. He described how he wanted each screen to work, and we built to that description — the colour scheme, the entry-and-report tab split, the pinned daily totals.
That is a legitimate way to work, and it is worth being explicit about: the design credit here is his. What we brought was the judgement underneath it — computing balances from immutable entries rather than storing a mutable total, separating administrator permission levels, validating and parameterising every input, and making the report builder general enough to answer questions he had not asked yet.
All the data visible in these screenshots is demonstration data.
Results
Delivered and put into internal use by the organisation. The fund's donations and withdrawals are recorded per member with a computed balance, and the executive can report across any combination of period, member and entry type.
No public figures exist for this one — it is an internal tool for a private organisation, and its transaction volumes are not ours to publish.
What we learned
A client who has thought carefully about their own workflow is an asset, not an obstacle. The job here was to implement his design well and to apply the engineering judgement he was not in a position to supply — not to redesign what he had already worked out.
Storing transactions and computing balances, rather than storing a balance, is the decision that keeps a small ledger honest. It costs nothing at this size and it makes every figure reconstructible.
Building the report as a small query builder rather than as three fixed reports meant the tool kept answering new questions without us.
Gallery
