Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix AGI concept used in EITC phase-out logic #1907

Merged
merged 1 commit into from
Mar 8, 2018
Merged

Fix AGI concept used in EITC phase-out logic #1907

merged 1 commit into from
Mar 8, 2018

Conversation

martinholmer
Copy link
Collaborator

@martinholmer martinholmer commented Mar 8, 2018

This pull request fixes a bug in EITC phase-out logic. This issue was raised by @MaxGhenis in #1904. Thanks, Max, for pointing this out. Prior to this pull request the EITC amount was phased out using the maximum of earnings and a concept called eitc_agi, which was defined as the sum of AGI (c00100) and non-taxable interest income (e00400). As Max pointed out e00400 is included in the investment income EITC eligibility test, but he couldn't find an mention of it being added to AGI and used in the phase-out formula. After an extensive Google search, I found an IRS document that said in a discussion of the EITC that the AGI concept used was from line 38 of Form 1040, which is standard AGI (c00100). My search also found an online EITC calculator that implied the AGI concept used in EITC calculation was standard (that is, does not include non-taxable interest income).

The results of fixing this bug are quite small. In some years, total refundable credits (in which the EITC is included) changes by $0.1 billion and in other years it is unchanged. When it does change, the aggregate individual income tax total and the combined tax total also changes by $0.1 billion.

It appears that this bug went undetected in our validation efforts because Internet TAXSIM does not have non-taxable interest income as one of its input variables, and because our efforts to validate Tax-Calculator against other tax calculators were never completed.

@MaxGhenis, thanks again for raising and pressing this issue.

A diligent reader of the changes in this pull request might wonder why the aggregate EITC payments changed slightly when using the CPS input data but did not change enough to cause different aggregate EITC payments (rounded to the nearest $0.1 billion) when using the PUF input data. The likely answer to that question is that the distribution of non-taxable interest income in the PUF data is realistic while the distribution in the CPS data is known to be unrealistic. Even before the EITC logic bug was reported, work had begun on trying to impute a more realistic CPS distribution as part of taxdata pull request 165. A more realistic distribution (with most of the non-taxable interest being received by high-income filing units) would probably have produced no aggregate EITC changes as big as $0.1 billion in the CPS data (which is what happened in the PUF data).

@codecov-io
Copy link

codecov-io commented Mar 8, 2018

Codecov Report

Merging #1907 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #1907   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files          37      37           
  Lines        3316    3316           
======================================
  Hits         3316    3316

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 13a9a33...26936fc. Read the comment docs.

@martinholmer martinholmer merged commit f3ca68a into PSLmodels:master Mar 8, 2018
@@ -1123,14 +1123,14 @@ def F2441(MARS, earned_p, earned_s, f2441, CDCC_c, e32800,

@jit(nopython=True)
def EITCamount(phasein_rate, earnings, max_amount,
phaseout_start, eitc_agi, phaseout_rate):
phaseout_start, agi, phaseout_rate):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be clearer to use c00100 here instead of introducing a new variable name of agi, which might be interpreted as a different concept? functions.py currently only uses the name c00100 to refer to AGI in code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants