Tithes, pledges, and three databases: mapping church giving to a common model

A large church typically runs at least three systems: a membership platform for people and households, a giving platform for online donations, and something else — spreadsheets, a groups tool, a legacy database — for everything in between. None of them agree on who a “member” is, and when the church switches giving platforms, years of history arrive as a CSV nobody fully trusts. The fix is the same one advancement shops use: map your data to a neutral shape that no vendor owns. Church giving maps cleanly, because underneath the vocabulary it’s the same six objects every fundraising database keeps.

Does a common data model work for churches?

Yes — and more naturally than you might expect, because the Advancement Common Data Model carries a dedicated congregation domain for faith communities: congregations, members, and their life events. That’s alongside the universal spine of constituents, gifts, commitments, designations, and campaigns. The current shape lives in the open acdm repository; the standard overview has the plain-English version.

Here’s the crosswalk from church vocabulary to the neutral objects:

| What your church calls it | Neutral object | The distinction that matters | |---|---|---| | Member, regular attender, visitor | Constituent | One person, one record — across the membership system and the giving platform | | Household, family unit | Relationship | Joint giving statements depend on modeling this, not guessing it | | Tithe, offering, online gift | Gift (transaction) | Money that actually arrived | | Building-campaign pledge, faith promise | Commitment | A promise of future giving — not a transaction | | Building fund, missions, benevolence | Designation / Fund | What a gift was for | | Capital campaign, year-end appeal, special offering | Campaign / Appeal | What asked for the gift | | Baptism, membership class, serving team | Life events & engagement | Contacts that aren’t gifts — the congregation domain’s home turf |

The distinction that breaks capital campaigns

The single most valuable line in that table is commitment versus transaction. A three-year building-campaign pledge is a promise; the monthly gifts that fulfill it are transactions. Blur the two — and most giving-platform exports do — and you get the same wrong numbers that plague universities: campaign totals that double-count, “lapsed” families who are actually current on their pledge, and year-end statements that don’t reconcile with the finance office. The full treatment is in a pledge is not a payment, and every word of it applies to a faith-promise campaign.

Two more church-specific traps the neutral shape forces you to decide on purpose:

• Household versus individual giving. Joint statements require knowing which spouse gave and how the household connects — that’s relationship modeling, the same soft-credit question advancement shops argue about.
• The calendar-year statement. Churches live on calendar-year giving statements while budgets may not; which date a December-31st online gift belongs to is a real decision, not a default.

What a church gets out of mapping

Three durable outcomes. Portability: when you outgrow a giving platform or a ChMS, your history moves with you, because it’s described in terms no vendor owns. Statements that reconcile: the finance office and the giving platform finally count from the same definitions. A foundation for later: benchmarking, analytics, and eventually AI all require exactly this kind of clean, well-defined data — the same readiness any organization needs.

Where this sits in the bigger picture

This post is part of a series on the model beyond advancement — the umbrella view is who is the Advancement Common Data Model for? For the universal objects underneath the crosswalk above, see the six objects every advancement CRM has.

For the standard itself, see The Standard (ACDM).

ACDM is open and early; treat current releases as drafts. Examples use synthetic data.