20% QBI (Pass-through income) deduction revenue estimate

[kpomerleau]

Currently, the revenue effect of repealing the 20% qualified business income deduction raises about $16 billion each year. However, this is far lower than the revenue effect estimated by the Joint Committee on Taxation, which finds a revenue effect of about $50-$60 billion per year. Link to JCT estimate: https://www.cbo.gov/system/files/2018-06/51138-2018-04-revenueprojections.xlsx (tab 7).

My first hypothesis is that it may interact with the AMT, but it looks like this is not the case.

My second hypothesis is that there is an issue in how the deduction itself is being calculated. Given that tax brain does not have switches for the W-2 and K limits, it's hard to tell what's going on there and I am not sure what sort of data is driving that, so I don't have a suggestion there besides trying to run the model without the limitation code to see if the revenue effect is closer to other known estimates.

Another thought, based on experience: JCT likely assumed some amount of general avoidance in the pass-through sector in response to the deduction. It might be worth while to have some sort of parameter for general avoidance for this provision (which could simply be a factor increasing qualified pass-through income) to baseline the model to the revenue loss that the JCT thinks would occur.

[jdebacker]

@kpomerleau I'm not sure exactly how your are getting the revenue estimate form TC, but one thing to be wary of is comparing runs when there is a different stacking order when evaluating a several policy changes at once.

E.g., if you were to do a revenue estimate of repealing the 20% QBI deduction by itself (i.e., keeping the lower individual tax rates, etc from the TCJA), you'd get a smaller number than if you estimated the 20% QBI deduction after repealing the lower rates under TCJA (since the deduction would be worth more with the higher rates).

The CBO numbers your reference include the 20% QBI extension as part of a stack of policies. It looks like they come after the rate changes, but there are other important provisions that interact with the 20% QBI such as bonus deprecation, which appear to be stacked after the QBI extension.

But you are right that behavioral responses are important. I know the Behavioral Responses package will allow you to apply elasticities that can capture avoidance behavior. I'm not sure if you can specify separate elasticities for pass-through income, though. @martinholmer or @MattHJensen might be able to answer that.

[MattHJensen]

Thanks for opening this issue. I will start looking into this, and I very much appreciate any headway others make as well.

Note that we have a decent test of the tax logic, here, that shows we are at least doing the same basic computation as TPC for simple filers. Assuming our and TPC's computations are right, that leaves us to look into behavioral, stacking, and data issues.

[MattHJensen]

Also, cc @codykallen in case he is interested / has time to poke around.

[kpomerleau]

Thanks for the comments. I took a close look at the logic and I think the logic is okay.

Regarding stacking:

Besides tax rates, I don't see another major provision creating a potential interaction that explains the difference between CBO's estimate and taxcalc's estimate.

The only thing that comes after the QBI in CBO's numbers that could interact (although the interaction goes in the opposite direction and would make QBI even larger) is the limit on itemized deductions. However, for completeness, I ran QBI after repealing the itemized deduction limit and got a revenue estimate of $13.5 billion per year, which is nearly identical to a QBI-alone run. I then ran QBI after repealing the itemized deduction limit and the scaled-back AMT (the two largest differences between CBO's stacking and current law). Same deal: $11.3 billion.

Does taxcalc have the effect of bonus reducing AGI? My understanding is it did not. However, I don't think bonus would have a meaningful effect either way.

I kind of alluded to this in my previous comment, but in modeling this in the past, we found that simply following the logic of the code drastically understated the cost (relative to JCT). However the adjustments made to match the cost were very simple.

[MattHJensen]

@kpomerleau, thanks for looking into the stacking issues.

Does taxcalc have the effect of bonus reducing AGI? My understanding is it did not.

This is correct.

I kind of alluded to this in my previous comment, but in modeling this in the past, we found that simply following the logic of the code drastically understated the cost (relative to JCT). However the adjustments made to match the cost were very simple.

I would be happy to add a parameter in the Behavioral_Responses repo that allows users to assume a behavioral response to the deduction. It does not surprise me that JCT assumes one, and I found confirmation in this OTA working paper (" We note that the Joint Committee’s estimates include forecasts of behavioral responses to the deduction")

@kpomerleau do you have a preferred method for modeling the QBI adjustment factor?

[kpomerleau]

If we are sure about the code's logic, here are two concrete suggestions. One is pretty specific, but I am unsure how applicable it is after any Treasury Regs and how it may interact with the capital limitation. The second is a very rough adjustment to gross up the revenue effect of the provision to match that of the JCT.

First suggestion is based on the idea that high-income pass-through businesses that face the 50% wage limit have an incentive to increase wages to the point that your deduction is maximized.

Here is an example:

Let's say you earn $150 in business income and $50 wage income. Since 20% of your business income ($30) is in excess of 50% of wages ($25), your deduction is limited to $25. However, if you pay yourself more in wages, you can, counter-intuitively, increase your deduction value. If you re-categorize $7.14 away from business income to wages, your 50% wage limit is now equal to $28.57. In addition, 20% of your pass-through income (now $142.85) is also equal to $28.57. As a result, you have increased your deduction by $3.57.

Another method, which is admittedly much more blunt, is to simply multiply pass-through business income by (1+X%) to match the JCT score on the provision (~$50 billion in 2020).

I am also going to review the OTA paper. It seems like their static costs are much higher than TaxCalc, which may imply a logic error somewhere.

[MattHJensen]

Thanks a lot for these suggestions, Kyle. I'll be able to explore strategies that allow users to adopt assumptions like these next week.

[MattHJensen]

Another method, which is admittedly much more blunt, is to simply multiply pass-through business income by (1+X%) to match the JCT score on the provision (~$50 billion in 2020).

The easiest way to implement this crude adjustment for now may be with Tax-Calculator's built-in Growdiff parameters. These allow you to make additive changes to the baseline growth rates for schedule c business net profit/loss, among other growth rates.

@Peter-Metz, could you post an example showing how a one-time growdiff adjustment can cause a level change in the baseline?

@kpomerleau, once you see that, I'll be interested to know your feedback on whether this looks like what you need for making the blunt adjustments, at least in the short term?

If this ends up working as a long-term solution, we can expose these parameters via Tax-Brain. In any case, the documentation needs some work.

[Peter-Metz]

Hi @kpomerleau, the code snippet below should give you a sense of how to adjust an extrapolated parameter like e00900 with the GrowDiff class. Let me know if anything is unclear.

from taxcalc import GrowDiff
from taxcalc import *

# Base Calculator with no GrowDiff
pol = Policy()
recs = Records()
calc = Calculator(policy=pol, records=recs)

# Print e00900 for each year 2017-2028 (no grow diffs)
for y in range(2017,2029):
    calc.advance_to_year(y)
    calc.calc_all()
    e00900 = (calc.weighted_total('e00900') / 1e9).round(2)
    print(f'e00900 in {y} $B: {e00900}')

# Create GrowDiff and GrowFactors objects
gdiff = GrowDiff()
gfactors = GrowFactors()

# Specify one-time e00900 increase of 500%
diffs = {'ASCHCI': {2020: 5, 2021: 0}}
gdiff.update_growdiff(diffs)

# Apply grow diffs to grow factors
gdiff.apply_to(gfactors)

# Calculator that incorporates grow diffs 
recs_diff = Records(gfactors=gfactors)
pol_diff = Policy(gfactors)
calc_diff = Calculator(policy=pol_diff, records=recs_diff)

# Print e00900 for each year 2017-2028 (with grow diffs)
for y in range(2017,2029):
    calc_diff.advance_to_year(y)
    calc_diff.calc_all()
    e00900 = (calc_diff.weighted_total('e00900') / 1e9).round(2)
    print(f'e00900 in {y} $B (with GrowDiff): {e00900}')

[kpomerleau]

Thanks! I will take a look at this and report back.

[erinmelly]

Opening the thread back up on this, @kpomerleau and I found the source of this issue. The problem lies in the variables used for the capital/wage/SSTB limitation (as used in lines 808-833 of calcfunctions.py). The values for PT_SSTB, PT_binc_w2_wages, and PT_ubia_property are all zeros. This information is not reported on taxpayers' 1040s and instead requires some sort of imputation.

Until that imputation is done, we recommend turning off these limits so that users do not think that they are being employed when they are not.

[kpomerleau]

To add to @erinmelly's comment: The code works, but since W2 wages and capital are all zero in the PUF, the limits claw back almost all of the deduction for very high-income tax filers.

[MattHJensen]

@erinmelly and @kpomerleau, I'm happy you found the source of the issue here. I should have noticed this before, either by looking at the data myself or by checking the compatible_data field in /policy_current_law.json for "PT_qbid_w2_wages_rt", PT_qbid_alt_w2_wages_rt", and "PT_qbid_alt_property_rt".

Have you given any thought to where we should turn off the limits and where best to document that they've been turned off?

Separately, I'd be interested to know if you've given any thought to the imputations.

[jdebacker]

@Peter-Metz Given your work on the QBI deduction, is this issue resolved?

[Peter-Metz]

@jdebacker yeah, I think this issue is resolved. The parameters added in #2497 should bring the QBID-related revenue estimates more in line with JCT.