Propensity Score Matching in Stata: psmatch2 vs. teffects psmatch

psmatch2 and teffects psmatch both perform propensity score matching in Stata, but they are not interchangeable: psmatch2 is a user-written command by Edwin Leuven and Barbara Sianesi, installed from the Boston College SSC archive (ssc install psmatch2), while teffects psmatch is an official, built-in Stata command shipped since Stata 13. The method they both implement — matching treated and untreated units on their estimated probability of treatment — is the same. The reproducibility, citation, standard-error, and diagnostic behaviour around that method is not. This page covers the Stata implementation specifically; for the underlying method itself — what propensity score matching does, its conditional-ignorability assumption, and what it cannot fix — see Propensity Score Matching: How It Works and What It Cannot Fix.

Two commands, not two names for the same command

psmatch2 predates teffects by roughly a decade and was, for a long time, the de facto standard — most published PSM studies using Stata before 2013 used it, and a large share still do out of habit or because a paper they are replicating used it. It supports nearest-neighbour, radius, kernel, and Mahalanobis matching, reports the average treatment effect on the treated (ATT) by default, and pairs with a companion command, pstest, for balance diagnostics — also written by Leuven and Sianesi and installed alongside it.

teffects psmatch arrived in Stata 13 (2013) as part of the official teffects treatment-effects suite, which also includes inverse-probability weighting (teffects ipw), regression adjustment (teffects ra), doubly robust estimators (teffects aipw, teffects ipwra), and nearest-neighbour matching on covariates directly (teffects nnmatch). Because it ships with Stata itself, it requires no separate install, is documented in StataCorp’s own Treatment-Effects Reference Manual, and behaves identically across every installation of the same Stata release.

Why the distinction matters for reproducibility and citation

This is the part a purely conceptual PSM explainer will not tell you, and it is the actual reason to write down which command a paper used, not just that “propensity score matching” was performed:

• Version drift. psmatch2 is user-maintained software with its own revision history on SSC. A study run in 2014 and a replication attempt in 2026 may be running different versions of the same nominal command unless the author records (and the replicator installs) the exact version — SSC does not silently notify you of this, and ssc install psmatch2 always pulls the current release unless you specify otherwise. teffects psmatch has no separate version to track; it is versioned with Stata itself, so citing “Stata 18, teffects psmatch” is a complete, checkable statement.
• Citation obligations differ. User-written commands are, by the norms of the Stata user community and of most journals’ statistical-software disclosure requirements, cited as software in their own right — author, year, and the SSC/Statistical Software Components archive entry — separately from the citation to Stata itself. Citing only “Stata was used to perform propensity score matching” when psmatch2 did the work omits the actual authorship of the algorithm implementation used. teffects psmatch, by contrast, is covered by the standard StataCorp citation already in the paper’s methods section; no separate software citation is owed beyond crediting the command in-text.
• Replicability of results, not just of intent. Because psmatch2 and teffects psmatch use different default matching algorithms, different default standard-error treatments (below), and in some configurations different handling of ties, they will not always reproduce each other’s point estimates on the same data even when both are told to do “1:1 nearest-neighbour ATT matching.” A reviewer or replicator who does not know which command a study used cannot fully reproduce it from the phrase “propensity score matching in Stata” alone.

Basic syntax, side by side

Both commands take an outcome, a treatment indicator, and a set of covariates the propensity score is estimated from. The syntax shape differs:

* psmatch2 (user-written, install first: ssc install psmatch2)
psmatch2 treated x1 x2 x3, outcome(y) neighbor(1) common

* teffects psmatch (official, built in)
teffects psmatch (y) (treated x1 x2 x3), atet nneighbor(1)

psmatch2 puts the treatment variable first and names the outcome inside outcome(); teffects psmatch uses the treatment-effects family’s shared syntax, with the outcome equation and the treatment equation each in their own parentheses. By default teffects psmatch without atet estimates the average treatment effect (ATE) across the whole sample rather than the ATT — the two commands’ un-modified defaults answer subtly different questions, which is itself a reason to state explicitly, in a paper’s methods section, which estimand was requested and not just which command was run.

The standard-error problem psmatch2 does not solve

This is the single most consequential technical difference, and it is frequently missed. psmatch2‘s reported standard errors, by default, treat the estimated propensity score as if it were known with certainty — they do not account for the fact that the propensity score itself was estimated in a first stage. Abadie and Imbens’ methodological work on matching estimators showed this understates the true sampling variability of the treatment-effect estimate, sometimes substantially. psmatch2 offers a bootstrap option as a partial workaround, but bootstrapping matching estimators has its own known problems (Abadie and Imbens separately showed the standard nonparametric bootstrap is not generally valid for nearest-neighbour matching with a fixed number of matches).

teffects psmatch‘s reported standard errors, by contrast, are computed analytically using the moment-based approach built into the whole teffects family, which does account for first-stage estimation of the propensity score. This is one of the concrete reasons StataCorp built teffects in the first place, rather than leaving matching estimation to user-written commands indefinitely. A paper reporting psmatch2‘s default standard errors without addressing this is reporting standard errors that are, by the method’s own developers’ later published work, too small.

Checking match quality: balance tables and common support

Neither command’s point estimate is trustworthy without checking that matching actually balanced the covariates — a good propensity score model does not guarantee a good match in any given sample.

• pstest (for psmatch2 users, same authors, installed alongside it) produces a balance table: the standardised percentage bias in each covariate before and after matching, and the percentage reduction in bias achieved. A common informal threshold, following Rosenbaum and Rubin’s original guidance, treats a standardised bias under roughly 10% after matching as acceptable; there is no universally agreed cutoff, and it should be reported as a diagnostic alongside the estimate, not as a pass/fail gate that justifies skipping sensitivity checks.
• tebalance summarize (the official postestimation command after teffects) reports the analogous standardised differences and variance ratios for the covariates used in the treatment model, run immediately after teffects psmatch in the same way estat commands follow other Stata estimation commands.
• Common support matters regardless of which command is used: matching treated units to untreated units whose propensity scores fall outside the range actually observed in the comparison group extrapolates the model rather than comparing genuinely similar cases. psmatch2‘s common option restricts matching to the region of overlapping propensity scores; graphing the propensity-score distributions of the treated and untreated groups (a simple two-group histogram or kernel density plot) before committing to either command is the fastest way to see whether common support is a real constraint in a given dataset or a non-issue.

When propensity score matching is the wrong tool

Both commands only ever balance the covariates you give them. If treatment assignment depends on something unmeasured — motivation, unobserved severity, an omitted variable correlated with both treatment and outcome — matching on measured covariates cannot address it, and a balance table that looks clean on the measured variables says nothing about the unmeasured ones. This is the same conditional-ignorability assumption covered in full on the main propensity score matching guide, and it is also why PSM is not a general-purpose fix for endogeneity: endogeneity from an unobserved confounder is exactly the case matching on observed covariates cannot resolve, however good the observed-covariate balance table looks. Where the actual concern is an unmeasured confounder, a design that does not rely on ignorability — an instrumental-variable approach, a difference-in-differences design with a credible parallel-trends case, or a regression-discontinuity design where one exists — is the more defensible choice; where selection into treatment is on unobserved factors specifically, PSM is not the right starting point at all. See the broader causal inference guide for how these designs relate to one another and when each is identified.

Frequently asked questions

Is psmatch2 deprecated in favour of teffects psmatch?

No. psmatch2 is still maintained on SSC and still widely used, particularly by researchers replicating or extending older studies that used it, or who need matching variants (Mahalanobis, radius, kernel) that teffects psmatch does not offer in exactly the same form. “Official” does not mean “the newer command supersedes the older one” — it means one ships with Stata and one does not, with the citation and version-tracking consequences described above.

Do psmatch2 and teffects psmatch give the same treatment-effect estimate on the same data?

Not necessarily. Even with matching options set as similarly as possible, differences in default estimand (ATT vs. ATE), tie-handling, and the underlying matching algorithm can produce different point estimates, and will produce different standard errors for the reasons above. Do not treat one as a robustness check on the other without accounting for those default differences first.

Which command should I use for a new study?

For a new analysis with no prior-version constraint, teffects psmatch‘s built-in status, correctly-computed standard errors, and StataCorp-maintained documentation make it the more defensible default. Use psmatch2 where you specifically need a matching variant it offers that teffects does not, or where you are replicating or directly extending a study that used it.

Do I need to report which command I used, not just that I did “propensity score matching in Stata”?

Yes. Given the standard-error and default-estimand differences above, “propensity score matching in Stata” alone is not a complete enough methods statement for another researcher to reproduce the analysis. Report the command, the Stata version (or the psmatch2 release, if used), the matching option (neighbours, caliper, or radius), and the estimand (ATT or ATE).