How to Determine Whether Donations to a Previously Revoked Nonprofit Are Deductible

Q: Which fields contain the contribution classification?

Use `organization_type`, `deductibility_limitation` and `deductibility_status_description` inside `organization_types`.

Q: Should I erase the revocation history after reinstatement?

No. Preserve `revocation_code`, `revocation_date` and `reinstatement_date` separately.

Direct answer

Do not determine deductibility from revocation history alone.

For a previously revoked nonprofit, review pub78_verified and the contribution fields inside organization_types: organization_type, deductibility_limitation and deductibility_status_description. Then review revocation_date and reinstatement_date separately so your application can distinguish contribution classification from revocation history.

Recommended verification flow

Normalize the EIN.
Send the EIN to the Nonprofit Check Plus API.
Confirm the organization.
Confirm Pub. 78 presence. Review pub78_verified.
Read contribution classification. Review organization_type, deductibility_limitation and deductibility_status_description.
Review revocation history. Check revocation_code and revocation_date.
Review reinstatement. Check reinstatement_date.
Review BMF context. Check bmf_status.
Check freshness. Review most_recent_pub78, most_recent_bmf and organization_info_last_modified.
Apply your contribution policy. Keep deductibility, revocation and reinstatement signals separate.

Example request(s)

curl --request GET \
  --url https://entities.pactman.org/api/entities/nonprofitcheck/v1/us/ein/YOUR_EIN \
  --header 'Authorization: Bearer YOUR_API_KEY'

Implementation note: The endpoint name above reflects the Pactman single-EIN Nonprofit Check endpoint used in Pactman's Production/Customer Environment.

curl --request POST \
  --url https://entities.pactman.org/api/entities/nonprofitcheckbulk/v1/us/eins \
  --header 'accept: application/json' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '[
    "YOUR_EIN_1",
    "YOUR_EIN_2",
    "YOUR_EIN_3",
    "YOUR_EIN_4",
    "YOUR_EIN_5"
  ]'

Implementation note: The endpoint name above reflects the Pactman bulk-EIN Nonprofit Check endpoint used in Pactman's Production/Customer Environment. You can have at most 50 EINs in a bulk-EIN Nonprofit Check endpoint request.

What your application should evaluate

Signal	Why it matters	Typical application decision
`pub78_verified`	Indicates presence in the most recent Pub. 78 data set used by Pactman.	Use as the Pub. 78 presence signal.
`organization_type`	Describes the organization type and intended use of contributions as listed in Pub. 78.	Preserve the contribution description.
`deductibility_limitation`	Provides the returned contribution limitation.	Keep the limitation separate from status codes.
`deductibility_status_description`	Provides the Pub. 78 deductibility-status code.	Preserve the returned code as a separate contribution-classification field.
`revocation_date` / `reinstatement_date`	Provides revocation and reinstatement history.	Do not let historical revocation overwrite current contribution data without explicit policy logic.
Source dates	`most_recent_pub78`, `most_recent_bmf` and `organization_info_last_modified` provide freshness context.	Use when deciding which returned data is current enough for the transaction.

Example decision logic

A post-revocation contribution workflow might:

confirm Pub. 78 presence;
read the contribution-classification fields;
preserve revocation and reinstatement history;
compare source freshness;
keep BMF presence separate; and
route ambiguous or conflicting cases for explicit review.

The supplied current examples have null revocation and reinstatement fields, so they do not provide a positive previously-revoked example.

Important: A past revocation event does not by itself supply the current deductibility answer.

Why use a consolidated nonprofit verification API?

Post-revocation deductibility decisions can require Pub. 78 contribution data, revocation history, reinstatement and source freshness.

Pactman Nonprofit Check Plus returns those signals together in one normalized response.

One normalized response

Evaluate contribution classification and revocation history without merging them into one opaque status.

Separate source signals

Preserve Pub. 78 contribution fields, revocation, reinstatement and BMF presence independently.

Reusable compliance rules

Apply one policy across donation, payroll-giving, DAF and grantmaking workflows.

Developer-friendly automation

Move post-revocation contribution review into application logic instead of manual record comparison.

Frequently asked questions

Is `pub78_verified` enough by itself to decide deductibility after a prior revocation?

No. Also review the contribution fields, revocation history, reinstatement and source freshness according to your policy.

Which fields contain the contribution classification?

Use organization_type, deductibility_limitation and deductibility_status_description inside organization_types.

Which field tells me whether there was a reinstatement?

Use reinstatement_date.

Should I erase the revocation history after reinstatement?

No. Preserve revocation_code, revocation_date and reinstatement_date separately.

Next step

Evaluate Pub. 78 contribution classification together with revocation and reinstatement history, then apply your application's explicit deductibility policy.

Ready to automate post-revocation deductibility checks?

Use Pactman Nonprofit Check Plus API to combine Pub. 78 contribution data with revocation and reinstatement history.

Get an API Key →