Ask a finance lead at a $3M nonprofit what takes the longest each month and the answer is rarely a hard question. It is a matching exercise: a list of gifts on one screen, a bank statement on another, and a spreadsheet in between reconciling numbers that were never designed to agree.
This is not a discipline problem or a software-selection mistake. It is the predictable result of how the two dominant categories were built.
Donation platforms are built around the donor's moment
A checkout tool optimises the seconds between intent and confirmation: a fast form, a wallet button, an instant receipt. Its data model reflects that. It holds a transaction, an amount, an email address and a campaign, and it considers its job finished when the confirmation renders.
What happens afterwards — the processor batching that transaction into a payout two days later, deducting fees, netting a refund from last week — is settlement. Settlement is the processor's world, not the form's. Most platforms surface it as a report you can export, not as objects you can reconcile against.
Donor CRMs are built around the relationship
A CRM's centre of gravity is the constituent: their history, their household, their moves-management stage, their next ask. Gifts exist inside the CRM as attributes of a relationship, which is exactly right for fundraising and exactly insufficient for finance.
A gift row in a CRM typically carries a gross amount and a date. It rarely carries the fee the processor took, the payout it settled in, the deposit that landed in your bank, or the accounting period it belongs to. When finance asks the CRM to explain a $18,412.66 deposit, the CRM has no object that represents it.
The seam nobody owns
So one system owns the gift and another owns the money, and the join between them is a human with two exports. That human has to reconstruct, by hand, a chain the software already knew about and simply did not store:
- Which transactions did this payout contain?
- What fee was deducted from each, and what platform-level fees came off the batch?
- Which refunds and disputes reduced this payout rather than a prior one?
- Which of these gifts were restricted, and to which fund?
- Which of them are already receipted, and at which amount?
Why integrations do not close it
The usual answer is a connector between the payment tool and the CRM. This helps with data entry and does almost nothing for reconciliation, because the connector typically syncs the gift, not the settlement chain. You end up with the same gross amount in a second place, still with no payout object beneath it.
A bi-directional sync makes it worse in one specific way: two systems now both believe they own the gift record, and disagreements between them become a third reconciliation task.
“If the payout is not a first-class object in your system, your reconciliation process is a person.”
What a system that owns the seam looks like
- The gift stores gross, fee and net, not a single amount.
- A payout object sits between transactions and the bank deposit, with its own date, fees and adjustments.
- Refunds and disputes are events with their own settlement timing, not negative gifts.
- Fund restriction is recorded on the gift at the moment of intent, so allocation is not reconstructed later.
- The receipt references the gift, and its amount is derived rather than typed.
- Every unmatched item is an exception with an owner and a reason, not a highlighted spreadsheet row.
What this means when you evaluate software
The useful question in a demo is not 'do you integrate with QuickBooks'. It is: show me a bank deposit, and click through to every gift inside it, including the ones that were refunded.
If that path exists, reconciliation is a review. If it does not, reconciliation is your month-end, whatever the integrations page says.
Where Beneora is on this
This model is the reason Beneora exists, and the reconciliation workspace is built around it. We are in active build with design partners and do not process live donations for any organisation today — so read this as our design position, verified in a working prototype, not as a production claim.