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.

Sign up for GitHub

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

Jump to bottom

Add switch for QBI deduction wage/capital limitations #2497

Merged
merged 4 commits into from Nov 30, 2020
Merged

Add switch for QBI deduction wage/capital limitations #2497

merged 4 commits into from Nov 30, 2020

Conversation

Peter-Metz
Copy link
Contributor

This PR adds a new parameter, PT_qbid_limit_switch, that turns on/off the QBI phaseout.

Above a certain taxable income threshold, the QBI deduction is subject to limitations based on wage expenses and capital income. Neither the PUF nor CPS contain the wage/capital data necessary to compute the limitations, so Tax-Calculator treats all taxpayers as having zero wage expenses and no capital income, and therefore fully subject to the phaseout. This issue has been identified in multiple places, including #2385 and PSLmodels/taxdata#319.

In #2453 (comment), @feenberg told us that TAXSIM makes a different assumption, that all taxpayers have sufficient wage expense/ capital income to avoid the limitation.

This PR will give Tax-Calculator users the option to choose between the two approaches. The revenue implications are fairly large:

With full wage/capital limitations:
Screen Shot 2020-10-07 at 9 17 10 AM

Without wage/capital limitations:
Screen Shot 2020-10-07 at 9 17 57 AM

@feenberg
Copy link
Contributor

feenberg commented Oct 7, 2020 via email

@codecov
Copy link

codecov bot commented Oct 7, 2020 •
edited

Codecov Report

Merging #2497 (365e1b1) into master (d3c7037) will decrease coverage by 0.00%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2497      +/-   ##
==========================================
- Coverage   99.92%   99.92%   -0.01%     
==========================================
  Files          13       13              
  Lines        2591     2567      -24     
==========================================
- Hits         2589     2565      -24     
  Misses          2        2
Impacted Files Coverage Δ
taxcalc/parameters.py 99.31% <0.00%> (-0.02%) ⬇️
taxcalc/data.py 100.00% <0.00%> (ø)
taxcalc/policy.py 100.00% <0.00%> (ø)
taxcalc/records.py 100.00% <0.00%> (ø)
taxcalc/growdiff.py 100.00% <0.00%> (ø)
taxcalc/taxcalcio.py 100.00% <0.00%> (ø)
taxcalc/calculator.py 100.00% <0.00%> (ø)
taxcalc/consumption.py 100.00% <0.00%> (ø)
taxcalc/growfactors.py 100.00% <0.00%> (ø)

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 d3c7037...5c869cd. Read the comment docs.

@MattHJensen MattHJensen changed the title Add switch for QBI deduction wage/capital limitations [WIP] Add switch for QBI deduction wage/capital limitations Nov 2, 2020
@MattHJensen
Copy link
Contributor

Background:

From a CBO modeler in response to a request from @feenberg, as reported in #2453 (comment).

I asked a couple of colleagues about the binary choice between
assuming 1) no taxpayer is subject to the wage/capital restriction or
whether 2) all taxpayers are fully subject to the limitations (i.e, treat
them as having zero wage expense and no capital). The consensus here is
that underestimate from option #2 would be larger than the overestimate
from option #1.

Discussion:

@Peter-Metz and I discussed these ideas in chat. Interested in others' feedback.

  1. This proposed tax law parameter is really filling in for a data limitation.
  2. Using a tax law parameter in this way would be somewhat confusing to users. They would be required set a tax law parameter to a value that is at odds with current law (i.e., PT_qbid_limit_switch = false) under both baseline and reform scenario in order to better approximate what we think is happening under current law, namely that the non-binding limits are more accurate than fully-binding limits.
  3. Instead of adding a tax law parameter, this issue could be resolved in TaxData, either by imputing PT_binc_w2_wages and PT_ubia_property that mean no taxpayer will be subject to the wage/property limitation by or imputing values that bring the deduction amounts in line with SOI statistics.
  4. In the meantime, Tax-Calculator, Tax-Brain, CCC, OG-USA could focus on documenting the data limitation. (cc @jdebacker, @rickecon, @andersonfrailey.)

@Peter-Metz, I'm interested in whether you still agree with these points. In the meantime, I've added a WIP tag here.

@Peter-Metz
Copy link
Contributor Author

@MattHJensen I agree that it would be conceptually nicer to handle this in taxdata, although it seems that it would be functionally the same. Two outstanding questions on my end:

  1. Do we impute any other parameters in taxdata (cc @andersonfrailey)? We might want to have a separate conversation in taxdata regarding what the process would look like and any other considerations.
  2. Regarding your second point, if we stick with a policy parameter switch, couldn't we make the default such that taxpayers are not subject to the limitations? If users wanted to fully impose wage/capital restrictions in their analysis, they could use the Python API to implement the restrictions in both the base and reform calculators.

@MattHJensen
Copy link
Contributor

Do we impute any other parameters in taxdata (cc @andersonfrailey)? We might want to have a separate conversation in taxdata regarding what the process would look like and any other considerations.

See, e.g., impute_itemxp.py, impute_pencon.py, and a smaller imputations in finalprep.py. https://github.com/PSLmodels/taxdata/tree/master/puf_data.

Regarding your second point, if we stick with a policy parameter switch, couldn't we make the default such that taxpayers are not subject to the limitations? If users wanted to fully impose wage/capital restrictions in their analysis, they could use the Python API to implement the restrictions in both the base and reform calculators.

This is true, we could set the default under baseline so that taxpayers aren't subject to the limitations. And that does seem like the natural solution if we want to solve this issue in Tax-Calculator. But I am quite hesitant because it means purposefully changing baseline to be out of step with tax law. Any downstream users that do have better data, are willing to do their own imputations, or rely on their users for data (like Tax-Cruncher) would be disadvantaged. Short version: I'm concerned about introducing an intentional error in Tax-Calculator's representation of tax law to support puf.csv users at the expense of other users.

@MattHJensen MattHJensen mentioned this pull request Nov 25, 2020
Closed
@donboyd5
Copy link
Contributor

The QBI deduction wage/capital limitations issue has come up in #2513 as a possible explanation for why puf.csv shows net TCJA tax increases for AGI millionaires. In rough terms, I'm guessing I'm finding $12b more TCJA tax for agi millionaires than it looks like JCT has: I find a $3.8b net increase vs. very-very rough not-quite comparable JCT estimate of -$8b, or about a $12b difference. Of course JCT could be wrong, the numbers could be not comparable enough, data could have changed, etc. (And for reasons mentioned in #2513 related to SALT, the non-SALT related difference might be larger than $12b.)

@Peter-Metz (cc @MattHJensen, @feenberg, @andersonfrailey), as I read your tables above, it looks like the PT_qbid_limit_switch approach results in a tax change of about $35b ($1,557b - $1,522b) which seems consistent with the implied $34-44b JCT estimate mentioned in #2385. And a $35b difference across all taxpayers certainly seems like it could be large enough to help explain a $12b+ difference in tax for agi millionaires.

I'm wondering if your $35b falls in the right income ranges to help explain this. Is there any chance that you have, or could run at some point, your PT_qbid_limit_switch approach by agi range or some reasonably close approximation to agi? It would be nice to see how much of the difference is for agi millionaires. If so, that would be really great. Additional comments below.

@donboyd5
Copy link
Contributor

@Peter-Metz @MattHJensen, @feenberg, @andersonfrailey,

My own thoughts on what would be useful is to have the issue well documented and leave placeholders or something like that in taxdata for variables needed to compute the limitation:

  • specialized service business indicator (PT_SSTB_income)
  • W-2 wages the business pays (PT_binc_w2_wages), and
  • filer's share of qualified properties (PT_ubia_property)

and to have tax-calculator implement that logic (which I understand that it does, I think).

Then, in the short term users can add these variables to puf.csv if they believe they have a way to impute them, and tax-calculator can use them if available. Over the longer term, perhaps taxdata could impute them.

@MattHJensen
Copy link
Contributor

@Peter-Metz, I've overlooked the elegance of this approach -- sorry about that. I plan to merge this PR soon, pending a request below.

The capability to turn off the limitation is a reasonable policy parameter to add in its own right, to help people designing and conducting policy reforms. If some users want to update the parameter in the baseline to accommodate data limitations, that's fine too.

When I run the full test suite, I see new MTR results. Would you mind doing the same to confirm?

@donboyd5
Copy link
Contributor

donboyd5 commented Nov 25, 2020 via email

@MattHJensen
Copy link
Contributor

@donboyd5 It has certainly helped to clarify my thinking!

By the way, do you know that you can check out this branch locally?

git fetch upstream pull/2497/head:pr-2497

or

image

@Peter-Metz
Copy link
Contributor Author

Peter-Metz commented Nov 25, 2020 •
edited

@MattHJensen said:

When I run the full test suite, I see new MTR results. Would you mind doing the same to confirm?

Hmm are you referring to the errors that say IndexError: too many indices for array? At the moment I'm hitting a few of those errors with the full test suite. These same errors also occur on the master branch, so it's not an issue with this PR per say. My only guess at the moment is that it has something to do with #2460

@donboyd5 Normally I'd be happy to paste a distribution table, but I'm currently hitting the error I mentioned above. I'll check back in with this.

@donboyd5
Copy link
Contributor

Thanks @MattHJensen and @Peter-Metz.

Now that I know I can check it out from GH (something I've never done), after you resolve issues to your satisfaction, I'll do that and run it locally and do distribution tables.

If there are any pointers you can give after you've resolved issues - for example, showing how to incorporate the new parameters into a json file, or really just a bit of guidance on what the values should be - that would be great.

Thanks!

@MattHJensen
Copy link
Contributor

@Peter-Metz, I'm just getting this:

E           ValueError: PUFCSV MTR RESULTS DIFFER
E           -------------------------------------------------
E           --- NEW RESULTS IN pufcsv_mtr_actual.txt FILE ---
E           --- if new OK, copy pufcsv_mtr_actual.txt to  ---
E           ---                 pufcsv_mtr_expect.txt     ---
E           ---            and rerun test.                ---
E           -------------------------------------------------

tests/test_pufcsv.py:273: ValueError

@Peter-Metz
Copy link
Contributor Author

Peter-Metz commented Nov 25, 2020 •
edited

@MattHJensen You're totally right. I'm using a new computer and didn't have things set up properly. I think #2498 fixes that MTR test.

@donboyd5 Now that I actually have things set up, here is the difference table (in $b), grouped by expanded income. Note the $24B difference for millionaires.

Screen Shot 2020-11-25 at 6 37 18 PM

@donboyd5
Copy link
Contributor

donboyd5 commented Nov 25, 2020 via email

@MattHJensen
Copy link
Contributor

I think #2498 fixes that MTR test.

@Peter-Metz, I may be missing something -- could you expand? Shouldn't the test pass here since #2498 is already merged and this PR doesn't influence MTRs?

@Peter-Metz
Copy link
Contributor Author

@MattHJensen I hadn't merged in those changes to this branch yet. Test passes now

@MattHJensen
Copy link
Contributor

Thanks very much @Peter-Metz. Merging now.

@MattHJensen MattHJensen merged commit da900b1 into PSLmodels:master Nov 30, 2020
@MattHJensen MattHJensen changed the title [WIP] Add switch for QBI deduction wage/capital limitations Add switch for QBI deduction wage/capital limitations Nov 30, 2020
@Peter-Metz Peter-Metz mentioned this pull request Jun 4, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@Peter-Metz @feenberg @MattHJensen @donboyd5