How to Add IRS Revocation Screening to a Grantmaking Application

Q: Which fields should trigger the revocation-screening step?

Start with `revocation_code` and `revocation_date`, then review `reinstatement_date`.

Q: Should I also check Pub. 78?

If your grant policy requires Pub. 78 context, use `pub78_verified` and contribution fields separately.

Direct answer

Add IRS revocation screening at the point where your grantmaking application verifies a grantee EIN.

Evaluate revocation_code, revocation_date and reinstatement_date, then keep BMF, Pub. 78 and source-freshness signals separate. Your application should implement an explicit grant policy for stop, review or continue decisions rather than relying on a universal API pass/fail field.

Recommended verification flow

Normalize the grantee EIN.
Send the EIN to the Nonprofit Check Plus API.
Confirm organization identity.
Check revocation_code.
Check revocation_date.
Check reinstatement_date.
Review BMF status. Check bmf_status.
Review Pub. 78 status. Check pub78_verified and contribution fields when relevant.
Check source freshness.
Apply the grant policy. Continue, review or stop according to documented rules.

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` / `revocation_date`	Provides Automatic Revocation context and event date.	Trigger the grant application's revocation rule.
`reinstatement_date`	Can represent a later status event.	Prevent historical revocation from being treated automatically as unresolved.
`bmf_status`	Provides BMF presence.	Use as a separate IRS-status input.
`pub78_verified`	Provides Pub. 78 presence.	Use when the grant policy also requires contribution-eligibility context.
Source dates	`most_recent_bmf`, `most_recent_pub78` and `organization_info_last_modified` provide freshness context.	Route stale or ambiguous records through review.
Organization identity	`ein` and `organization_name` identify the grantee.	Ensure the compliance result is attached to the intended organization.

Example decision logic

A grantmaking workflow might:

review a record with populated revocation data according to policy;
check reinstatement_date before treating revocation as unresolved;
require the intended BMF and Pub. 78 signals for the grant program;
check freshness;
store returned source fields for audit; and
avoid converting one field into a hidden universal eligibility rule.

The supplied current examples have null revocation and reinstatement fields, so they represent the no-revocation-data path.

Important: The API returns source signals; your grantmaking application owns the final policy decision.

Why use a consolidated nonprofit verification API?

Grantmaking due diligence often needs revocation history, IRS-status context and source freshness in the same workflow.

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

One normalized response

Check revocation, reinstatement, BMF, Pub. 78 and organization identity together.

Separate source signals

Preserve the source fields that support the grant decision.

Reusable compliance rules

Apply the same grant policy across intake, approval and recurring grantee review.

Developer-friendly automation

Trigger review or workflow actions programmatically from returned fields.

Frequently asked questions

Which fields should trigger the revocation-screening step?

Start with revocation_code and revocation_date, then review reinstatement_date.

Should a past revocation always block a grant?

The supplied files do not define a universal grant policy.

Should I also check Pub. 78?

If your grant policy requires Pub. 78 context, use pub78_verified and contribution fields separately.

Can the same rule be used for bulk grantee screening?

The bulk endpoint returns the same organization-level field model, so the same field logic can be applied across returned organizations.

Next step

Add the revocation fields to your grantee decision layer, preserve BMF and Pub. 78 context, and make stop/review/continue behavior explicit in your grantmaking policy.

Ready to add revocation screening to grantmaking?

Use Pactman Nonprofit Check Plus API to bring IRS revocation and reinstatement checks into grantee workflows.

Get an API Key →