Add switch for QBI deduction wage/capital limitations

[Peter-Metz]

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:

Without wage/capital limitations:

[feenberg]

Does Matt or anyone else have a contact at JCT, OTA or CBO that can tell us what they are doing about the QBI wage and capital features? Dan

…

On Wed, 7 Oct 2020, Peter Metz wrote: 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 ________________________________________________________________________________________________________________________ You can view, comment on, or merge this pull request online at:   #2497 Commit Summary * add switch for qbi limitations * add test for qbi limitation switch File Changes * M taxcalc/calcfunctions.py (13) * M taxcalc/policy_current_law.json (26) * M taxcalc/tests/test_calculator.py (36) Patch Links: * https://github.com/PSLmodels/Tax-Calculator/pull/2497.patch * https://github.com/PSLmodels/Tax-Calculator/pull/2497.diff ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.[AB55AVMSDN3AIFIN6BJ3VUTSJRTUTA5CNFSM4SHMSCU2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4KVVKWYQ.gif]

[codecov]

Codecov Report

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

@@            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]

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]

@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]

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.

[donboyd5]

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]

@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]

@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]

Great! Thanks. That would really help in what we're doing re NY.

…

On Wed, Nov 25, 2020 at 3:41 PM Matt Jensen ***@***.***> wrote: @Peter-Metz <https://github.com/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? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2497 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABR4JGCGIKC76TQOER4OIOLSRVTYLANCNFSM4SHMSCUQ> .

[MattHJensen]

@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

[Peter-Metz]

@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]

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]

@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]

@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.

[donboyd5]

Perfect, thanks! Don

…

On Wed, Nov 25, 2020 at 6:43 PM Peter Metz ***@***.***> wrote: @MattHJensen <https://github.com/MattHJensen> You're totally right. I'm using a new computer and didn't have things set up properly. I think #2498 <#2498> fixes that MTR test. @donboyd5 <https://github.com/donboyd5> Now that I actually have things set up, here is the difference table (in $b), grouped by expanded income. Note the $24B tax cut for millionaires. [image: Screen Shot 2020-11-25 at 6 37 18 PM] <https://user-images.githubusercontent.com/43755005/100291988-4154dd00-2f4d-11eb-873a-9abdf1eed3af.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2497 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABR4JGEAKR5CWYTU7NMBRFDSRWJAJANCNFSM4SHMSCUQ> .

[MattHJensen]

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]

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

[MattHJensen]

Thanks very much @Peter-Metz. Merging now.