How to Check the Effective Date of a Nonprofit’s IRS Revocation

Recommended verification flow

1. Normalize the EIN.
2. Send the EIN to the Nonprofit Check Plus API.
3. Confirm the organization.
4. Check revocation_code.
5. Read revocation_date.
6. Preserve the returned date exactly.
7. Check reinstatement_date.
8. Review BMF and Pub. 78 separately. Use bmf_status and pub78_verified.
9. Check freshness. Review most_recent_bmf, most_recent_pub78 and organization_info_last_modified.
10. Apply your status policy. Distinguish the revocation-event date from current status.

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

Example decision logic

A revocation-date lookup might:

• confirm the organization identity;
• inspect revocation_code;
• read revocation_date;
• preserve that date as the revocation event;
• review reinstatement_date;
• keep BMF and Pub. 78 status separate; and
• use source freshness for broader current-status logic.

The supplied current examples return revocation_date: null, so they demonstrate the field's presence in the schema but do not provide a positive revocation-date example.

Important: Do not substitute report_date, most_recent_bmf or most_recent_pub78 for revocation_date. They describe different dates in the Pactman response model.

Why use a consolidated nonprofit verification API?

A revocation date is easier to use correctly when the application can also see revocation code, reinstatement, BMF, Pub. 78 and freshness signals.

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

One normalized response

Retrieve revocation date, revocation code, reinstatement and supporting IRS context together.

Separate source signals

Keep the revocation-event date distinct from source-refresh dates and current-status signals.

Reusable compliance rules

Apply one revocation-date interpretation layer across grants, donations, onboarding and recurring reviews.

Developer-friendly automation

Retrieve revocation dates programmatically from EINs instead of manually searching IRS records.

Frequently asked questions

Which Pactman field contains the revocation date?

Use revocation_date.

Is report_date the revocation date?

No. report_date is a different field in the API response. Use revocation_date for the revocation event.

What if revocation_date is null?

The response contains no revocation date in that field. Do not substitute another date field.

Why should I also check reinstatement_date?

Because a nonprofit can have historical revocation data and later reinstatement data. The revocation-event date alone should not be treated as the complete current-status answer.

Related Pactman artifacts

• How to Check if a Nonprofit Appears on the IRS Automatic Revocation List
• How to Verify Whether a Revoked Nonprofit Has Been Reinstated
• How to Check the Reinstatement Date of a Tax-Exempt Organization

Next step

Use revocation_date as the revocation-event date, retain revocation_code, and review reinstatement_date before applying a current-status rule.