Frequently asked questions

Fundraising Commons is an open, vendor-neutral data standard for advancement and fundraising, plus free educational resources (a practical handbook and a business novel) that help any team trust its numbers and act on them, regardless of budget.

ACDM is an open, vendor-neutral data model for advancement data. It maps to and from major CRMs, so your data stays portable, comparable, and free of vendor lock-in. It extends the open Nonprofit Common Data Model.

Any organization that raises money and keeps relationship data. The beta cohort today is advancement shops, but the model already carries domains for congregations, programs, beneficiaries, and grants, with consent and privacy as first-class structures. If you want to map your vertical, join the beta and we are happy to discuss the possibilities.

Yes. The ACDM standard is open source, and the educational content is free to use. You can adopt and build on the model with attribution.

Advancement and fundraising teams, especially staff- and budget-constrained shops, along with the data, analytics, and leadership people who support them.

No. ACDM is vendor-neutral and maps to and from major CRMs, so you can adopt it alongside the system you already use.

It is an open commons funded by sponsors (currently Rigason LLC) who support it without controlling it. Anyone, including competing vendors, can build to the standard and be listed in the public registry.

AI agents are only as good as the data beneath them. An open, governed, portable foundation lets you adopt AI when you are ready and keep your data yours. You don’t have to bet the organization on one vendor’s roadmap, so a shift in the market won’t strand you.

No. Fundraising Commons is open, free to start, and vendor-neutral. You add the capabilities you need over time, instead of buying one big system you can’t get out of.

Yes. That’s exactly how it’s meant to work. Because everything sits on one shared, open standard, you can switch on the capability you’re missing without replacing what you have, and it works with the rest of your setup.

They’re safe when they act on clean, governed data. The foundation keeps your raw donor data yours and enforces consent and retention rules, so automation only works on records it’s actually allowed to use.

Comparison happens on aggregates, not records. Calculations run inside your own walls, and only summary parameters are ever shared. Raw donor data never leaves.

Usually because the definitions behind them were never written down, so each report quietly makes its own assumptions: different time windows, different gift types, even different dates. It’s rarely a data-quality problem; the fix is one written definition per metric that every report references, not a new reporting tool.

A constituent who gave before but not within an agreed recent window (for example, no gift in the last 12 months). “Lapsed” is a metric definition, not a flag: pin the window, decide which gift types count, and decide whether a pledge still being paid counts as active, then apply that rule the same way every time.

A pledge is a commitment, meaning a promise to give a set amount, often over time. A payment is a transaction, meaning the money arriving against that promise. One pledge is usually fulfilled by several payments. Collapsing them causes false lapses, missed recurring churn, and double-counted revenue, so the data model keeps them as separate, linked records.

Retention is the share of last period’s donors who gave again this period: donors retained divided by everyone who gave last period. The common error is dividing by this period’s donors instead, which is a moving number that makes the rate meaningless. Freeze the prior-period cohort, define “donor” once, and state which variant (overall, new-donor, or reactivated) you mean.

Gift date is when the donor gave; entry date is when staff keyed it; batch date is when it posted. All three are correct facts about the same gift. Attribute revenue and fiscal totals by gift date. Using entry or batch date is why year-end gifts appear to slip into January and why two reports won’t reconcile.

Hard credit is the legal donor of record, and there is one per gift. Soft credit recognizes someone else’s role in the same gift, such as a spouse, the person who closed it, or a matching employer. One gift, recorded once, can carry several soft credits. Revenue is always the sum of gifts, never the sum of credits, so soft credits recognize people without adding dollars.

The DAF sponsor (the community foundation or commercial sponsor) is the legal donor and receives the tax acknowledgment. The individual who recommended the grant gets soft credit, not a second tax receipt. Recording the individual as the legal donor causes improper acknowledgments and double-counted revenue.

A single, complete picture of a supporter: their gifts, relationships, and interactions over time. You build it by capturing engagement (especially the interactions that aren’t gifts) on clean, deduplicated data. It isn’t a dashboard you can just buy. A 360 view with no interaction data only re-shows the gifts you already knew about.

Agentic AI is software that takes actions on your behalf (drafting outreach, segmenting lists, queuing asks) rather than only answering questions. Because an agent acts, the data beneath it has to be clean, defined, and governed. That matters far more than it does for a report no one acts on directly.

With a short written policy, adopted before any AI touches donor records, that answers: what data AI may use, who approves donor-facing actions, what it must never do, how consent and retention apply, and how its actions are logged. Governance is policy written down. One enforceable page beats a framework you never finish.

Often, yes. These laws follow the donor, not your organization’s location, so if you hold data about EU or UK residents (GDPR) or California residents (CCPA), they likely reach that data. In practice that means having a lawful basis or opt-out, being able to find, produce, and delete one person’s data on request, and minimizing what you keep and share. This is general information, not legal advice.

ACDM is a neutral, advancement-focused layer: it extends the open Microsoft Nonprofit Common Data Model (NCDM) and maps to and from product data models like Salesforce NPSP and Nonprofit Cloud. It doesn’t replace your CRM’s model. It’s the vendor-neutral target they can all line up against, so your data stays portable and comparable. Product names are used for accuracy, not affiliation.

No. While open-source projects can sometimes carry a high Total Cost of Ownership (TCO) due to complex setup requirements, Fundraising Commons is built to avoid this. We provide pre-built ETL (Extract, Transform, Load) scripts, data crosswalks, and schema mappings for major CRMs like Salesforce NPSP and Microsoft Dynamics. This allows your existing database administrators or advancement services staff to map and standardize your data without needing a dedicated software engineer or expensive consulting contracts.

Take the free five-minute maturity self-assessment to see where your shop stands, then read the handbook chapters it points you to. The blog also has plain-language guides to the core ideas: definitions, the data model, portability, and adopting AI safely.