Connecting charity finance and fundraising data makes reporting more dependable when both teams understand what the figures represent. A donation recorded in a supporter system, a payment received through a provider and income posted in the accounts can describe related events without being the same record or the same reporting total.

The challenge is often the handoff between those events. Staff export files, adjust spreadsheets and explain differences from memory. A dashboard can make the result attractive, but it cannot repair an undefined reconciliation or establish which team owns a disputed value.

This guide describes a practical operating model for shared definitions, matching and exception review. The worked figures are hypothetical. Accounting treatment, tax questions and fund classifications need approval from the charity's qualified advisers and responsible finance team.

Begin with the questions the report must answer

Ask each audience what decision they need to make. Fundraising may want to understand campaign response; finance may need to reconcile receipts; trustees may need an accurate account of resources and commitments. Those purposes can share data without requiring one universal number labelled “income” in every report.

Write the question next to the proposed measure. “What donations were confirmed during the appeal?” is different from “What cash reached the bank this month?” The first may use a transaction event, while the second uses settlement and bank records. A date filter alone cannot make them equivalent.

Identify the actions expected from the report. An unmatched receipt needs investigation. A campaign with many enquiries but few completed donations may need a journey review. A restricted-purpose question belongs with the person authorised to interpret the relevant arrangements, not with a dashboard developer guessing from a campaign name.

Limit the initial scope. One provider, one period and a defined campaign can reveal the key reconciliation issues without connecting every historical record at once. Document what remains outside the pilot so a convenient early report is not mistaken for the charity's complete financial position.

Create a shared dictionary for important terms

Define donation, pledge, settlement, refund, fee and adjustment in the context of your systems. Record which events each product uses and which records are authoritative for each purpose. A field called “paid” may refer to a successful supporter transaction in one system and a cleared bank receipt in another.

For every report measure, include its definition, source, date basis, currency and owner. Explain whether values are gross or net of fees and how refunds are represented. These details should be accessible beside the report rather than buried in an integration specification available only to technical staff.

  • Donation event: the approved transaction state used for the fundraising view.
  • Settlement: the provider's grouping or transfer of funds, using its documented reference.
  • Bank receipt: the amount and date visible in the relevant bank record.
  • Reconciliation difference: a specific unmatched amount requiring an explanation, rather than an assumed error.

These labels are illustrative. Your finance team should approve the actual definitions and treatment. If teams need different views, name them clearly. It is better to show two well-defined measures than to force them into one figure that requires a verbal explanation every month.

Map the records before building a connection

Draw the path from supporter action to transaction, provider settlement, bank receipt and accounting entry. Add any fundraising platform or intermediary that changes the reference or groups transactions. The map should show where information is created, combined and corrected.

Identify stable identifiers at each stage. An email address is a poor substitute for a transaction reference: people can share addresses, change them or donate anonymously. Match payments using suitable transaction and settlement evidence, with personal details used only where the approved process requires them.

Record which system owns supporter preferences separately from financial status. An unsubscribe request should not disappear when an accounting import updates the contact record. Equally, a suppressed marketing preference does not mean the charity should delete financial evidence it is required to retain.

Our guide to CRM and accounting integration explains broader record-ownership questions. In a charity setting, add the fund, campaign and supporter-relationship context explicitly instead of assuming a commercial sales template captures all the relevant distinctions.

Work through an illustrative reconciliation

Imagine a provider report showing hypothetical donations totalling £1,000, a £50 refund and £20 of provider fees, producing a £930 settlement. These are invented values for explaining the workflow, not typical costs or an accounting recommendation. The finance team confirms how the records should appear in its own accounts.

The fundraising view may need to show the original donations and refund separately. The bank view shows the £930 receipt. If a spreadsheet compares £1,000 directly with £930 without those intermediate records, it creates an unexplained £70 difference that staff must reconstruct.

Now suppose the settlement reaches the bank in the next reporting period. Both records may be correct, but a simple same-month comparison will not match them. The reconciliation needs the provider reference and the relevant timing explanation, with the outstanding settlement visible until it is confirmed.

Finally, imagine one refund relates to an earlier campaign. Assign it according to the charity's approved reporting rules, preserving the original link. Do not let an integration allocate it to the newest campaign merely because that is the current default in a form or spreadsheet.

Keep fund and campaign classifications distinct

A campaign label describes how a donation was attracted or grouped for analysis. It does not by itself establish the accounting classification or permitted use of funds. Keep those decisions with the responsible finance and governance roles and record the relevant evidence.

Where a fundraising form offers a purpose choice, define how that choice reaches the finance process and who reviews unusual cases. A free-text message from a supporter may require attention. The system should flag it rather than treating a model's interpretation as an authoritative fund decision.

Maintain a controlled mapping between approved campaign values and the relevant reporting dimensions. Version it when a campaign changes or a new programme begins. An old campaign code should not silently acquire a new meaning because somebody reused a convenient label in the website form.

For charities in England and Wales, the Charity Commission's financial-controls guidance is a useful starting point. Other jurisdictions have their own requirements. Use applicable professional guidance for classifications and disclosures rather than relying on an integration vendor's standard dashboard categories.

A volunteer packing a box of supplies
Illustrative stock photography. Gustavo Fring / Pexels · Licence

Design an exception queue for the two teams

Separate unmatched transactions, unmatched settlements, duplicate candidates and classification questions. Each type needs an owner and a next action. A single list of “data errors” makes it difficult to distinguish a timing difference from an incomplete provider import or an unresolved finance decision.

Show the relevant references, amounts and dates with links to controlled source evidence. Avoid placing full supporter details in every exception alert. Staff should have enough context to investigate within their permissions without exporting another copy of the entire donor list.

Give cross-team queries a clear handoff. Fundraising may confirm the appeal source while finance confirms the settlement treatment. Keep one working record with assigned actions so neither team assumes the other has resolved the whole issue after answering only its part.

Review ageing exceptions before the reporting deadline. Some differences can remain open with a documented explanation; others may block a report or require escalation. The finance owner should set that decision. A technical system should not mark a discrepancy resolved simply because it has been present for several days.

Make corrections traceable

Keep the source record and the reason for a correction. If a campaign attribution changes, record who approved it and whether it affects previously issued reports. If an import was duplicated, identify the affected batch and the reviewed correction instead of deleting rows without an explanation.

Separate data corrections from changes in reporting definitions. Correcting a mistyped reference and changing whether a report includes pending transactions have different consequences. A reader needs to know when figures changed because evidence improved and when the method itself changed.

Use stable reporting cut-offs and retain the version used for an important decision. Live dashboards can change as new data arrives. A trustee pack may need an identifiable dated snapshot with the associated definitions and known exceptions so later readers can understand what was available at the time.

Decide how backdated adjustments are communicated. If a material correction affects an earlier period, the responsible team needs an agreed review route. Avoid allowing a scheduled refresh to rewrite historical totals silently while the narrative in an already distributed report remains unchanged.

Protect supporter information through the connection

Map the personal information transferred and explain why each field is needed. A finance reconciliation may require transaction references without the complete supporter profile. Reporting generally benefits from aggregated information, with detailed records accessible only to people whose roles require them.

Use appropriate access controls and review the supplier arrangements for each connected service. Document where records and logs are stored, who can support the connection and how access is removed when staff or contractors leave. Test those controls rather than assuming a private-looking dashboard is adequately restricted.

Keep supporter preferences authoritative in the designated system. An integration must not reactivate a suppressed contact because an old import contains a positive marketing flag. Define how conflicts are resolved and retain the history needed to understand a preference change.

The ICO's guidance on business-to-business marketing describes relevant UK distinctions, but charity audiences and communication purposes vary. Review the actual activity with the responsible person rather than assuming every supporter or organisational contact can receive the same promotional messages.

Build reports that explain their limits

Show the reporting period, refresh time and important exclusions. If a provider feed is delayed, make the affected data visible as incomplete. A blank chart should not imply there were no donations when the source has not updated successfully.

Include a concise reconciliation view alongside the fundraising analysis. Staff should be able to see whether a difference is explained by fees, refunds, timing or an unresolved item. Keep the detail available without making every manager read transaction-level records before understanding the main report.

Give each chart a useful question and an appropriate comparison. A campaign total may need context about audience, duration and channel. Comparing two appeals solely by gross receipts can be misleading if one ran for months and the other for a week or targeted a very different supporter group.

A reporting and analytics assessment can help establish shared definitions and the handoff before building dashboards. The useful deliverable is a report people can trace and maintain, with the unresolved decisions clearly assigned rather than hidden behind an attractive presentation.

Test the connection with awkward records

Use a controlled sample containing refunds, repeated imports, multiple currencies if relevant, anonymous donations and settlements crossing a month end. Include a supporter who changes their details and a transaction whose campaign reference is missing. These cases test the real operating model beyond a straightforward successful import.

Simulate an interrupted import and a retry. Confirm that completed records are not duplicated and that unfinished work remains visible. Check whether the team can reconcile the batch using stable references rather than manually comparing names and amounts across several files.

Ask finance and fundraising to sign off their own questions. Technical success confirms that data moved; operational acceptance confirms it moved with the right meaning and controls. Record any remaining limitations so users understand which decisions the initial report can support.

Provide a fallback for essential reporting if the connection is unavailable. Identify the source exports, responsible person and reconciliation steps. Keep the process proportionate, but practise enough to establish that a reporting deadline will not depend entirely on one integration or one employee's memory.

Give a new colleague a reproducible check

Before accepting the report, ask a colleague who did not build it to trace one selected total back to the source records. Provide the dictionary and ordinary permissions, then observe where explanation is still needed. This tests whether the reporting method belongs to the organisation or remains dependent on one person's memory.

Repeat the exercise with an explained difference, such as a settlement crossing the reporting cut-off. The colleague should be able to locate the evidence, understand the treatment and identify the responsible owner without editing the underlying data. Any missing instruction becomes a concrete handover improvement.

Establish a sustainable monthly review

Schedule a short joint review of unresolved differences, definition changes and source reliability. The purpose is to maintain trust in the records and remove recurring rework. A regular conversation around a small exception list is often more effective than an occasional attempt to reconcile several months at once.

Keep a record of repeated causes. Missing campaign references may require a form change; unmatched settlements may require a better provider import; late approvals may need an ownership decision. Each issue should lead to an appropriate operational improvement rather than another permanent spreadsheet adjustment.

For broader context, the guide to charity administration automation looks at releasing capacity across the organisation. Finance and fundraising connections are one part of that work, with their own definitions and controls that deserve careful attention.

Begin with a report both teams can explain using a small reviewed dataset. Extend the connection when the evidence, exceptions and responsibilities are clear. That foundation makes later dashboards and campaign analysis more useful because the charity understands where the numbers came from and what they can safely tell it.

Checked sources

A CONSIDERED NEXT STEP

Good questions.
Better operations.

A useful conversation begins with the work you want to improve. Tell us where the friction is; we can establish an appropriate assessment scope.

Explore relevant support ↗