How to Check if a Nonprofit Has Lost Its Tax-Exempt Status

Q: Which Pactman fields show IRS revocation information?

Use `revocation_code` and `revocation_date` together.

Direct answer

To check whether a nonprofit has lost tax-exempt status, evaluate revocation_code, revocation_date and reinstatement_date in the Pactman response.

The supplied mapping identifies revocation_code as the code provided by the IRS Automatic Revocation file, revocation_date as the date of revocation, and reinstatement_date as the date of reinstatement, if any. Use those fields together, then review bmf_status, pub78_verified and source dates separately before making a current-status decision.

Recommended verification flow

Normalize the EIN.
Send the EIN to the Nonprofit Check Plus API.
Confirm the organization. Match ein and organization_name.
Check for revocation data. Review revocation_code.
Check the revocation date. Review revocation_date.
Check for reinstatement. Review reinstatement_date.
Review BMF presence. Evaluate bmf_status.
Review Pub. 78 presence. Evaluate pub78_verified.
Check source freshness. Review most_recent_bmf, most_recent_pub78 and organization_info_last_modified.
Apply your current-status rule. Keep revocation, reinstatement, BMF and Pub. 78 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
`revocation_code`	The mapping says this is the code provided by the IRS Automatic Revocation file.	Treat a populated value as revocation-list-derived data requiring interpretation.
`revocation_date`	The mapping defines this as the date of revocation, if any.	Use to establish when the revocation event occurred in the returned data.
`reinstatement_date`	The mapping defines this as the date of reinstatement, if any.	Determine whether a later reinstatement is represented in the response.
`bmf_status`	Indicates BMF presence.	Keep BMF presence separate from revocation history.
`pub78_verified`	Indicates Pub. 78 presence.	Keep Pub. 78 presence separate from revocation history.
Source dates	`most_recent_bmf`, `most_recent_pub78` and `organization_info_last_modified` provide freshness context.	Use before treating the combined result as current enough for the workflow.

Example decision logic

A practical current-status rule might:

treat a populated revocation_date as evidence of a revocation event in the returned IRS data;
review reinstatement_date before concluding that revocation is the latest status event;
preserve revocation_code as Automatic Revocation file context;
keep bmf_status and pub78_verified separate; and
use source dates to understand freshness.

The supplied current single and bulk examples return revocation_code, revocation_date and reinstatement_date as null. The supplied examples therefore do not provide a positive revoked-or-reinstated test case.

Important: Do not turn null revocation fields into a universal guarantee that the organization is currently tax exempt.

Why use a consolidated nonprofit verification API?

A current-status decision can require revocation history, reinstatement, BMF presence, Pub. 78 presence and source freshness.

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

One normalized response

Evaluate revocation, reinstatement, BMF, Pub. 78 and freshness signals together.

Separate source signals

Keep revocation history, reinstatement, BMF presence and Pub. 78 presence distinct.

Reusable compliance rules

Apply one status-evaluation layer across donations, grants, onboarding and recurring reviews.

Developer-friendly automation

Move tax-exempt-status checks into application logic instead of relying on manual IRS searches.

Frequently asked questions

Which Pactman fields show IRS revocation information?

Use revocation_code and revocation_date together.

How do I know whether a revoked nonprofit was later reinstated?

Review reinstatement_date.

Does `bmf_status: true` mean the organization has not been revoked?

Not by itself. BMF presence and revocation history are separate signals.

Do null revocation fields prove the nonprofit is currently tax exempt?

No. Null values mean no values are returned in those revocation/reinstatement fields for that response.

Next step

Evaluate revocation_code, revocation_date and reinstatement_date together, then incorporate BMF, Pub. 78 and freshness signals according to your current-status policy.

Ready to automate tax-exempt-status checks?

Use Pactman Nonprofit Check Plus API to evaluate revocation, reinstatement and supporting IRS status signals in one response.

Get an API Key →