Measured 2026-08-25

How does our matching work, and what is the best it could be?

When a foundation files its taxes, it lists who it gave money to. Some filers include the recipient’s ID number. Most don’t; they just write a name, like “BOYS + GIRLS CLUB OF TAMPA”. Our job is to work out which real organization that is, and to admit it when we can’t.

It sounds useful to say how many grants we can match, but that’s not a great question. A lot of grants can’t be matched by anyone. Some filings name no recipient at all. Some are cheques to individuals. Some are gifts to charities abroad, which have no US ID number to find.

Here's a better approach: first, which grants could never be matched? Then: of the ones that could, how many did we get?

Which grants could never be matched to a US charity?

Anything foreign (obviously), anything with no name at all, something with a name that's so short it's unusable, or a grant to an individual. Here's the breakdown:

That’s 1.2% of grants, but 6.1% of the money, because the grants involved tend to be big ones. For international grants, we treat them slightly differently on the international pages.

What’s left, and how we did

Take those out and you’re left with the grants that could actually be matched. Switch between grants and money below. They give quite different answers.

We’ve matched 76.0% of the grants and 80.7% of the money. But that's 76.9% of the grants that could be matched and 85.9% of the $. It's higher for money because a handful of enormous grants name no recipient, e.g. acompany foundation booking a whole patient-assistance program on a single line.

How we actually match them

There's a simple approach to start with: match based on the name of the organization. It's cheap and easy, but sometimes organizations share names, and sometimes we can't find that exact name in a file anywhere. So we restrict this matching to only within organizations in the same state, and we normalize the names to remove minor variations like "Inc." and "LLC".

There's a few refinements to name matching, like using the address to help, or the ZIP code, dealing with typos etc.

But the most interesting part is working with the entire dataset. Every filer who states a recipient’s EIN directly is handing us a (name, EIN) pair we didn’t have to work out. Collapse those pairs to distinct organizations, and that same 31.5% of grant rows becomes a registry of who those organizations actually are, including some the IRS itself has never registered:

That same directly-stated EIN is also the answer key the precision figure further down is graded against: masked, then guessed at, with the caveat that comes with grading yourself on the easy cases.

Impact

Here’s the full breakdown of how we match, and how much we match, as a flow or as a table. Same numbers either way.

Comparing with other funders

This is the single most important part of matching.

There's 2 ways this works: 1) If 2 other funders have matched the same organization name to an EIN, and no other funders have matched the same name to a different EIN, then we can be confident that the organization is the same. This is the easy option, and shows up in the API as the "registry" field.

But sometimes, there are a few different EINs for the same organization name. In that case, if over 90% of grants go to one of these, we map grants to that EIN. If it's not that obvious, we fall through to the model.

The technical part: what the model does

The rules and funder matching are simple to understand, but the model is a bit more complex, and more expensive to run.

Essentially, it combines a lot of sensible flags and features into a single score, and then uses that score to rank the potential matches.

The score comes from gradient-boosted trees. We chose trees because the useful questions are conditional: a distant name is fine when only one organization sits at that address, and a problem when forty do. Adding those signals together misses that; a split catches it. Trees also treat a missing revenue figure as unknown rather than as small, and they score millions of pairs on the CPUs the job already runs on.

What does work is asking a different question. Instead of “how similar are these two names?”, we pull up every organization it could plausibly be, score them all, and take the best one only if we’re confident enough. We can check whether this works because some filers do give the ID number: hide their answer, make the model guess, compare.

The useful part is what turned out to matter most, and it isn’t how alike the names look. It’s whether other foundations, filing separately, have used that same name for that same organization, and how many of them agree. Essentially: ask around. How similar the text is comes second. Knowing they disagree, and have named someone else, is sharper than knowing they agree.

scikit-learn’s HistGradientBoostingClassifier, with the scores isotonic-calibrated so that “90% sure” is right about nine times in ten.

How often we’re right, and what that number leaves out

On its own that figure is easy to fake: a system that almost never guesses can be right nearly always. So it only means something next to how much we actually match, which is the 76.9% further up.

Ground truth comes from 990 Schedule I, whose recipients skew larger and more formally registered than the 990-PF recipients the resolver actually runs on. Treat this as an estimate on a related population; the true figure on 990-PF names is likely lower.

The ones that got away

These are grants that could potentially be matched and haven’t been. Over time, we hope to reduce this list, but need to do so carefully to maintain accuracy in the matches we do make.

And then... sometimes the answer key is wrong

31.5% of grants have an EIN. But what if the EIN is wrong? What if the grantmaker just made a typo?

They do! Quite a lot!

Here’s how we found out

Typos are predictable. They are usually a single digit off, they swap a two digits, or they add or remove a leading zero. They are not random. So we can check for them, and see how often they happen.

Three things have to be true. The recipient name points at exactly one organization in that state. The EIN they typed is not anyone’s real number. And that fake number is one of those four shapes away from the named organization’s real EIN. If the name could be two organizations, we leave it.

A nine-digit number has 81one-digit cousins, so sitting next to somebody’s real EIN happens by luck. The checklist only counts a hit when it is the EIN of the organization the name already points at.

We ran the first two checks on 1,200,000 grants where the name and the EIN already agree, so we know they are not typos. The checklist should never call those typos. It never did. Then we used it.

The last two both look like the digits slid along by one place. The first two digits of an EIN are the IRS office that issued it, and a person typing usually leaves them alone: 484 times out of 487. The other group kept those digits only 3 times in 533, because the digit that vanished was the first one. Those numbers started with a zero, got stored as a number in a spreadsheet, lost the zero, and then had one stuck on the wrong end to make the length right. That is why they are two rows: one is a typist, the other is software.

If you want to know who has the fattest fingers, it's in our API. But also, this also means we needed to re-do all of the work above, because we were training the model on answers that were often wrong.

EINs have no check digit

NHS numbers, ISBN-10, and many VAT registration numbers all carry one. Modulus-11 is the usual scheme: it blocks a substituted digit or a swapped pair at the point of entry, so the wrong number never files.

An EIN is an IRS office prefix plus a sequential counter. There is nothing to catch a mistype. The slip goes onto the return, into every dataset built from the return, and stays there. Years later it has to be reconstructed from the name, which is the work above.

Check it yourself

Every figure here comes from one artifact, computed against the same published data the API serves, and regenerated whenever the corpus is rebuilt. The per-figure detail, coverage by year, the provenance ledger and the raw JSON, is on the data quality page, and the underlying grants are queryable through the API.

Measured 2026-08-25. Filings lag twelve to twenty-four months after the activity they describe, so the most recent fiscal years are floors that rise with each monthly IRS release rather than final totals.