Membership Data in Reports, Receipts, and Your CRM

If your school is launching a Membership Form, your gift processing team needs to know a few things before the first dues payment lands. Membership payments flow through the same gift pipeline as everything else in GC Online Giving, but they carry new fields, they use two familiar fields differently, and they do not flow into the Raiser's Edge NXT direct integration.

Share this with whoever reconciles your deposits and posts gifts to your CRM.

How a membership payment is stored

One membership payment equals one contribution record with donation_type = membership. Multi-year memberships create one record per annual charge, the same way recurring gifts do.

A 1-year annual membership is a single charge with no subscription behind it, so it looks like a one-time gift in your recurring reporting.

Only multi-year commitments create a subscription record.

New fields in reports

These columns are available in donation reports, the custom report builder, and scheduled or SFTP-delivered custom reports. They populate on membership rows and stay blank everywhere else.

Two dedicated reports also live under Reporting > Donations.

• Membership Payments gives you one row per processed payment, for reconciliation and CRM posting.
• Membership Commitments gives you one row per membership, so you can see who is committed to what and for how long. Both support filters and scheduled email delivery.

How existing fields shift

donation_type is your primary filter. membership is a new value alongside donation, general, match, challenge, installment, and pledge. If your import routines or CRM mappings work from an allowlist of donation types, add it to your integration flow.

Do not use tax_deductible_amount or fmv_of_incentive for memberships. These were built for gift incentives and do not read membership FMV.

• On a membership row, fmv_of_incentive comes through blank and tax_deductible_amount shows the full payment amount even when the level carries an FMV.
• To get the deductible portion, subtract membership_type_price_fmv from the payment amount. Donor receipts already do this math correctly for you.

The API

The API includes a membership object on contributions that represent membership payments. Use this data when posting payments into your CRM or reconciliation system.

How membership appears in the API

• Membership contributions have donation_type = membership. When a contribution is a membership payment, the API response includes a non-null membership object; for other gifts, it returns as null.
• Both initial charges and renewal installments include the membership object.

Membership object details

• id: The identifier for the membership record. Use this when linking the API row to the corresponding membership record.
• type: An object describing the selected membership level. It contains:
  • id: The stable identifier for the membership level (useful for mapping to CRM fund codes or tiers).
  • name: The display name of the selected level.
• price: Either an object containing details about the pricing variant or null if no price was chosen. When present, it includes:
  • id: A stable identifier for the selected pricing variant.
  • name: The label for the pricing variant (e.g. "Annual" or "Lifetime").
  • billing_cadence: The billing frequency, with possible values of "yearly" (annual memberships) or "lifetime" (lifetime memberships).
  • amount_at_payment: The charged amount at the time of payment.
  • fair_market_value_at_payment: The FMV recorded at payment time, which represents the non-deductible portion for tax purposes.

CRM mapping and deductible calculations

• Map membership.type.id or membership.type.name to your CRM’s membership level or fund code to maintain consistency even if names change.
• Map membership.price.id or membership.price.name to distinguish pricing variants in your CRM.
• To calculate the deductible portion, subtract membership.price.fair_market_value_at_payment from the payment amount. Do not use fmv_of_incentive or tax_deductible_amount for membership FMV.

Edge cases

• If a membership record exists but no specific price variant was selected, membership.price will be null while membership.type remains available. Your integration should account for this scenario.
• The type and price identifiers are stable and can be used as authoritative keys when synchronizing membership data with external systems.

Example mapping

• Paid amount → membership.price.amount_at_payment
• Membership level or tier → membership.type.id (or membership.type.name)
• Pricing variant → membership.price.id (or membership.price.name)
• Billing frequency → membership.price.billing_cadence
• Non-deductible FMV → membership.price.fair_market_value_at_payment

Using these fields helps ensure your CRM records and reconciliation processes accurately reflect the membership details and amounts.

Raiser's Edge NXT direct integration

Membership payments are deliberately excluded from the Raiser's Edge NXT direct integration.

Memberships behave differently enough from standard gifts, particularly around the FMV split and the two designation destinations, that we did not want to guess at the right gift-record mapping and push data your team would have to unwind.

For now, process membership payments to Raiser's Edge NXT using the Membership Payments report or a scheduled custom report.

We would like to fold memberships into the integration, and the right mapping depends on how your school treats dues in Raiser's Edge NXT. If you run memberships and use the NXT direct integration, reach out through your Partner Success Manager. Partners who join that conversation early will shape how it works.

FAQ

Why does tax_deductible_amount show the full payment on a membership?

That column reads gift-incentive FMV, which memberships do not use. Subtract membership_type_price_fmv from the payment amount instead. The donor's receipt shows the correct figure.

We edited a level's FMV. Do past receipts change?

No. Every payment stores the FMV that was current when it processed, so past receipts and report rows stay as issued. The new FMV applies to future charges.

Why is subscription_type blank on some membership payments?

Lifetime and 1-year annual memberships are single charges with no subscription behind them. Only multi-year memberships create one.