Count the ways money reached your organization last month: the donate page, a campaign link shared by email, the kiosk in the lobby, a handheld reader at the spring event, a staff phone running the Mobile App, and the envelope of checks that arrived anyway. Six channels, six chances for the books to disagree with the bank.
This guide is for the person who has to make them agree. It covers what a channel-tagged ledger actually changes, how per-campaign accounting coding removes the re-keying, and what a defensible month-end close looks like when giving is multichannel.
The patchwork is the problem
Most nonprofits never chose a fragmented giving stack. They accumulated one: a donate button from one vendor, a card reader from another, a spreadsheet for cash, each adopted in the year it solved a problem.
Each piece produces its own report, on its own schedule, with its own donor list. One tool batches deposits daily and nets out fees before payout. Another deposits at the gross amount and bills fees separately, and the spreadsheet deposits whenever someone drives to the bank.
So month-end becomes translation work. You download exports in different formats, match deposits that were batched under different rules, and re-key summaries into the accounting system. The books end up describing deposits rather than gifts: a single bank line says nothing about which appeal earned it or which donors gave it.
That monthly translation cost rarely makes the list when a team weighs one fundraising platform versus a patchwork of tools, yet it is the cost the treasurer pays every month.
What a unified ledger changes
Donatefy writes every gift, from every channel, into one ledger with the same fields. Each record carries the donor, the campaign, the channel and device it came through, the payment method, the gross amount, the fees, whether the donor chose to cover them, the current status, and its sync state with your accounting and donor systems.
That tagging is what makes the close mechanical instead of forensic. Filter by channel to match a payout, by campaign to answer the board, by status to find the gifts that are still pending or were refunded.
It also collapses the donor lists. The supporter who gave online in March and tapped the kiosk in April is one record with one history, not two names on two exports. The full reporting surface is covered on the reporting page.
Code the campaign once, not the gift a thousand times
In most stacks, accounting coding lives in the bookkeeper's head. Every gift gets classified at month-end, by hand, from memory of which appeal maps to which fund.
Donatefy moves that mapping onto the campaign itself. When you build a campaign, you assign where its gifts should land: the QuickBooks account, class, and department; the Blackbaud fund; the Bloomerang fund and appeal. The mechanics live in campaign setup and the accounting and donor system connections.
From then on, every gift to that campaign arrives pre-coded, automatically, after each successful donation. A kiosk tap and an online recurring charge against the same campaign post to the same account and class. The bookkeeper reviews; the bookkeeper does not re-key.
Sync is visible per donation. Each record shows whether it reached QuickBooks or the donor system, and when a push fails, the reason sits on the record so you can correct the mapping and move on.
One more structural tool for fund accounting: different campaigns can settle to different bank accounts. The building campaign can pay out to the building account while general giving pays out to operating, which keeps restricted money physically separated instead of separated only on paper.
Fees you can see, coverage you can book
Fee opacity is what makes multichannel books drift. If one channel deposits net and another deposits gross, your revenue figure depends on which vendor's habit you happened to inherit.
In Donatefy, every donation record carries its gross amount and its fees, and reporting toggles between gross and net views. The platform's per-transaction fee is line-itemed in your organization's own Stripe dashboard, so the processor's numbers and the ledger's numbers are the same numbers.
Donor fee coverage adds one accounting wrinkle worth deciding on once. When a donor chooses to cover the fees, the charge is larger than the intended gift; many finance teams book the full amount as contribution revenue and the fees as expense, though your accountant may prefer a different treatment. The ledger shows the covered portion explicitly on each gift, so whichever policy you adopt, you can apply it consistently instead of reverse-engineering it from deposit totals.
Refunds that do not scar the ledger
Refunds are routine: a duplicated gift, a donor who typed an extra zero, an event payment that should have been a registration. What matters at month-end is whether the refund left a clean trail.
Staff issue full or partial refunds from the dashboard, with a reason captured on the record. The original gift is never deleted; its status moves to refunded or partially refunded, and the refund stays attached to the donation it reverses.
That linkage is the whole game for reconciliation. A refund issued this month against last month's gift traces to both the original record and the bank movement it caused, so you can post it in the correct period without archaeology.
Partial refunds behave the same way. The gift remains on the books at its original amount with the refunded portion recorded against it, and cash or check entries can be marked refunded too, so a hand-returned gift never silently overstates the month.
Cash and checks belong in the same ledger
The envelope of checks is still giving, and it deserves the same record. Back-office entry adds a cash or check gift in a few fields: pick or create the donor, choose the campaign, enter the amount and date, and attach a photo of the check or the count sheet as proof.
The gift then behaves like every other gift. The donor receives the same branded, tax-ready email receipt, the entry syncs to QuickBooks under the campaign's mapping, and it appears in totals tagged as an offline gift so nobody mistakes it for card volume.
This is the quiet end of the shadow spreadsheet. When cash lives in the ledger, it is counted once, receipted once, and reconciled against the physical deposit like everything else. For food banks and human-services nonprofits, where checks still arrive by mail alongside drive-day and online gifts, it is often the step that decides whether the books close on time.
The treasurer's month-end checklist
Here is a close that a channel-tagged ledger makes realistic. Adapt the order to your own controls.
- Reconcile deposits. Match each Stripe payout to its bank deposit, then to the ledger filtered by date and channel. Match physical deposits against the offline entries and their proof photos.
- Review exceptions. Filter for failed and pending gifts. Bank-transfer gifts sit in a processing state while the transfer clears, so separate still-settling from actually-failed before you chase anything.
- Check sync status. Filter for donations that did not reach QuickBooks or the donor system, read the failure reason on each, correct the mapping, and confirm per-campaign totals in QuickBooks match the ledger.
- Verify refunds. Pull the refunded view. Confirm every refund carries a reason, ties to its original gift, and matches a bank movement.
- Sweep for duplicates. Run duplicate detection and resolve the flags before reports go out, not after.
- Report gross and net. Give the board the campaign view at gross, give the accountant the net view, and let both come from the same records.
None of this requires heroics. It requires that every gift, from every channel, was written into one ledger with its coding, its fees, and its status at the moment it happened.
If your close still starts with downloads and ends with a spreadsheet named final-v3, bring it with you. Walk through your channels, your chart of accounts, and your last messy month, and see what the same close looks like when the ledger does the translation for you.