How to Handle a Nonprofit That Appears in Both IRS Pub. 78 and the Automatic Revocation List

Q: Which fields represent the Automatic Revocation side?

Use `revocation_code`, `revocation_date` and `reinstatement_date`.

Q: Which fields represent the Pub. 78 side?

Use `pub78_verified` and the contribution fields inside `organization_types`.

Q: Should I compare source dates?

Yes. `most_recent_pub78`, `most_recent_bmf` and `organization_info_last_modified` provide freshness context.

Direct answer

If a nonprofit has both Pub. 78 and Automatic Revocation signals, preserve both instead of forcing one source into the other.

Use pub78_verified and the contribution fields in organization_types for the Pub. 78 side. Use revocation_code, revocation_date and reinstatement_date for the Automatic Revocation side. Then compare source freshness and apply an explicit policy for the workflow.

Recommended verification flow

Normalize the EIN.
Send the EIN to the Nonprofit Check Plus API.
Confirm the organization.
Review Pub. 78 presence. Check pub78_verified.
Review contribution classification. Check organization_type, deductibility_limitation and deductibility_status_description.
Review Automatic Revocation data. Check revocation_code and revocation_date.
Check reinstatement. Review reinstatement_date.
Review BMF context. Check bmf_status.
Compare source freshness. Review most_recent_pub78, most_recent_bmf and organization_info_last_modified.
Apply explicit conflict handling. Do not silently discard either source.

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`	Represents Pub. 78 presence.	Preserve the Pub. 78 side of the record.
`organization_types`	Carries contribution classification.	Retain contribution details separately from revocation history.
`revocation_code` / `revocation_date`	Represents Automatic Revocation file context and date.	Preserve the revocation side of the record.
`reinstatement_date`	Can represent a later reinstatement event.	Use to distinguish historical revocation from later status changes.
`bmf_status`	Provides separate BMF context.	Do not use BMF presence to erase either source.
Source dates	`most_recent_pub78`, `most_recent_bmf` and `organization_info_last_modified` provide freshness context.	Use source-aware logic rather than a blanket precedence rule.

Example decision logic

A cross-source workflow might:

retain Pub. 78 presence and contribution classification;
retain revocation code and revocation date;
check reinstatement;
preserve BMF context separately;
compare source dates; and
route unresolved combinations through review or a documented application rule.

The supplied current examples do not show a positive revocation record, so they do not demonstrate this exact dual-source condition.

Important: Do not automatically treat one source as universally overriding the other.

Why use a consolidated nonprofit verification API?

Cross-source cases are easier to handle when Pub. 78, revocation, reinstatement, BMF and freshness data arrive in one response.

Pactman Nonprofit Check Plus preserves those source signals separately.

One normalized response

Bring Pub. 78 and Automatic Revocation information into one application response.

Separate source signals

Keep contribution classification and revocation history distinct.

Reusable compliance rules

Apply consistent conflict-handling rules across donations, grants and onboarding.

Developer-friendly automation

Avoid manual cross-checking of separate IRS data files for each EIN.

Frequently asked questions

Should Pub. 78 presence override Automatic Revocation data?

The supplied files do not establish a universal override rule. Preserve both source signals and apply source-aware logic.

Which fields represent the Automatic Revocation side?

Use revocation_code, revocation_date and reinstatement_date.

Which fields represent the Pub. 78 side?

Use pub78_verified and the contribution fields inside organization_types.

Should I compare source dates?

Yes. most_recent_pub78, most_recent_bmf and organization_info_last_modified provide freshness context.

Next step

Preserve both Pub. 78 and Automatic Revocation signals, compare chronology and freshness, and apply an explicit conflict policy.

Ready to automate cross-source revocation review?

Use Pactman Nonprofit Check Plus API to preserve Pub. 78 and Automatic Revocation signals in one workflow.

Get an API Key →