How to Verify a Nonprofit Before Awarding a Grant

Q: What if the organization appears in revocation data?

Review `revocation_code`, `revocation_date` and `reinstatement_date` together. Revocation history should not automatically be treated as current disqualification without considering reinstatement information.

Direct answer

Before awarding a grant, use the prospective recipient's EIN with Pactman Nonprofit Check Plus API and evaluate the returned IRS, revocation and sanctions signals as separate parts of your due-diligence workflow.

Confirm the organization identity, review bmf_status, bmf_subsection, subsection_description and exempt_status_code, evaluate public-charity or private-foundation classification, check pub78_verified when Pub. 78 eligibility matters, review revocation and reinstatement history, inspect ofac_status, and account for irs_bmf_pub78_conflict and source freshness before applying the grantmaker's final eligibility rules.

Recommended verification flow

Normalize the EIN. Remove spaces or dashes so 12-3456789 becomes 123456789.
Send the EIN to the Nonprofit Check Plus API. Use the single-EIN nonprofitcheck endpoint when evaluating one prospective grantee.
Confirm the recipient. Match ein and organization_name to the nonprofit named in the grant application.
Review IRS BMF status. Evaluate bmf_ein, bmf_status, bmf_subsection, subsection_description and exempt_status_code.
Determine foundation classification. Review foundation_code, foundation_code_description, foundation_509a_status, foundation_type_code and foundation_type_description so public-charity and private-foundation records are not treated as interchangeable.
Review Pub. 78 when relevant to eligibility. Check pub78_ein, pub78_verified and the organization_types information.
Check revocation and reinstatement. Review revocation_code, revocation_date and reinstatement_date before treating historical revocation information as the organization's current status.
Review OFAC screening. Evaluate ofac_status separately from IRS tax-exempt classification.
Check conflicts and freshness. Review irs_bmf_pub78_conflict, most_recent_bmf, most_recent_pub78 and organization_info_last_modified.
Handle group and religious-organization cases explicitly. When relevant, review group_exemption, pub78_church_message and bmf_church_message rather than treating ordinary source absence as an automatic failure.

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 single-EIN Nonprofit Check endpoint used in Pactman's Production/Customer Environment.

What your application should evaluate

Signal	Why it matters	Typical application decision
`ein` / `organization_name`	Confirms that the API result belongs to the organization applying for the grant.	Continue only when the EIN and organization identity match the intended grantee.
`bmf_status` and IRS classification	`bmf_status` indicates whether the organization appears in the IRS Business Master File data used by Pactman, while `bmf_subsection`, `subsection_description` and `exempt_status_code` describe exemption and classification.	Use these as core IRS-status inputs to the grant eligibility rule.
Foundation classification fields	`foundation_code`, `foundation_code_description`, `foundation_509a_status`, `foundation_type_code` and `foundation_type_description` preserve public-charity/private-foundation context.	Apply the grantmaker's rules to the returned organization type rather than assuming every tax-exempt organization has the same classification.
`pub78_verified`	Indicates whether the organization is included in the most recent Publication 78 data used by Pactman.	Use when Pub. 78 inclusion or deductible-contribution eligibility is part of the grant policy.
`organization_types`	Contains Pub. 78 contribution information including `organization_type`, `deductibility_limitation` and `deductibility_status_description`.	Preserve the returned contribution classification as a separate eligibility or audit input when relevant.
Revocation fields	`revocation_code`, `revocation_date` and `reinstatement_date` expose revocation-related history.	Review reinstatement before treating a historical revocation record as current disqualification.
`ofac_status`	Indicates whether the organization is included on the OFAC SDN list according to the Pactman response.	Route sanctions-related results through the grantmaker's compliance policy separately from IRS status.
`irs_bmf_pub78_conflict`	Indicates whether BMF and Pub. 78 differ on the organization's private-foundation classification.	Route conflicts through source-aware review instead of silently selecting one classification.
Source dates	`most_recent_bmf`, `most_recent_pub78` and `organization_info_last_modified` provide freshness context.	Use them to determine whether the result is sufficiently current for the grant review.

Example decision logic

A practical grantmaking workflow might allow an applicant to proceed only after the application has:

matched ein and organization_name to the intended grantee;
evaluated the required BMF status, subsection and exemption signals;
identified the organization's public-charity or private-foundation classification;
reviewed pub78_verified and organization_types when those signals are required by the grant policy;
evaluated revocation and reinstatement information;
evaluated ofac_status under the grantmaker's sanctions policy;
handled any irs_bmf_pub78_conflict; and
considered source freshness before treating the result as current.

The supplied bulk sample provides a concrete example. For EIN "680343125", Pactman returns bmf_status: true, bmf_subsection: "03", subsection_description: "501(c)(3) Public Charity", pub78_verified: true, foundation_type_code: "pc" and foundation_type_description: "Public charity described in section 509(a)(1) or (2)". The same response has revocation_code, revocation_date and reinstatement_date as null, while ofac_status states that the organization was not included in the OFAC SDN list.

Important: Do not hard-code a universal definition of "grant eligible." A private foundation, corporate giving program, government grant program, donor-advised fund, community foundation or grant-management platform may apply different policies to the same underlying nonprofit-verification signals.

Why use a consolidated nonprofit verification API?

Pre-grant due diligence often requires several questions to be answered together: Is this the intended organization? What IRS exemption and subsection does it have? Is it a public charity or private foundation? Does Pub. 78 contain the organization? Is there revocation history? Does the OFAC result require review? Are the IRS sources in conflict, and how fresh are they?

Pactman Nonprofit Check Plus returns those signals in one normalized response. The supplied single-EIN and bulk samples use the same current 43 organization-level fields, so the same grant-recipient verification logic can be reused for individual applications and higher-volume grantmaking workflows.

One normalized response

Evaluate organization identity, IRS BMF, Pub. 78, foundation classification, revocation and OFAC screening from one Pactman response model.

Separate source signals

Keep bmf_status, pub78_verified, foundation fields, revocation fields, ofac_status and irs_bmf_pub78_conflict separate so the application retains the meaning of each source.

Reusable compliance rules

Apply the same nonprofit due-diligence framework across grant applications, grant renewals and recurring recipient reviews while allowing each grant program to define its own eligibility criteria.

Developer-friendly automation

Move pre-award verification into the grantmaking application instead of requiring staff to manually compare IRS, revocation and sanctions information for every prospective grantee.

Frequently asked questions

Is a valid EIN enough to approve a nonprofit for a grant?

No. The EIN identifies the entity. A grant workflow should also evaluate the returned BMF classification, foundation type, Pub. 78 information when relevant, revocation history, OFAC result and source freshness according to the grantmaker's rules.

Why does public-charity versus private-foundation status matter in a grant workflow?

Pactman exposes foundation classification separately through fields such as foundation_code, foundation_509a_status, foundation_type_code and foundation_type_description. This lets a grantmaker preserve the organization's actual classification and apply its own eligibility policy instead of treating all tax-exempt entities identically.

What if the organization appears in revocation data?

Review revocation_code, revocation_date and reinstatement_date together. Revocation history should not automatically be treated as current disqualification without considering reinstatement information.

Should OFAC screening be included before awarding a grant?

When sanctions screening is part of the grantmaker's compliance program, evaluate ofac_status as a separate decision signal. IRS tax-exempt status and OFAC screening answer different questions.

Next step

Use the Pactman API response to confirm the prospective grantee, evaluate IRS classification and foundation type, then explicitly handle Pub. 78, revocation, OFAC, source conflicts and freshness before applying the grant program's final eligibility rule.

Ready to automate grant-recipient verification?

Use Pactman Nonprofit Check Plus API to connect nonprofit verification directly to your grantmaking workflow.

Get an API Key →