QBID income limit switch

[bodiyang]

This issue is for the QBID calculation.

Tax-Calculator adopts an income limit switch PT_qbid_limit_switch in QBID calculation. This is because both CPS & PUF lack the information on capital gains, which is required for the income limitation calculation for QBID form 8995. So we need to either apply or not apply the income limit on all records.

Right now, the switch is set as True by default, which means applying the income limit on all records.

However, would this actually be the better choice?

I tried to compare the QBID calculation when the switch is set as On versus Off.

For the year 2024:
qbided is 106.2 billion, when PT_qbid_limit_switch is set as True;
qbided is 296.5 billion, when PT_qbid_limit_switch is set as False;

[martinholmer]

In issue #2822, @bodiyang said:

Right now, the switch is set as True by default, which means applying the income limit on all records.

However, would this actually be the better choice?

The current value of this parameter is consistent with current-law policy, which is what is in the policy_current_law.json file. So why would we want to change the value of this parameter in the policy_current_law.json file?

If that is not what you're suggesting, then what are you suggesting in issue #2822?
You never said what you thought would be better.

[bodiyang]

@martinholmer

Choice of True or False value for PT_qbid_limit_switch should be decided by the accuracy of the calculated qbided value.

As an example, for year 2024:
if $106.2 billion is closer to the real world QBID value, then we keep PT_qbid_limit_switch as True, as it is in policy_current_law.json
if $296.5 billion is closer to the real world QBID value, then we should make a change ~ change PT_qbid_limit_switch to False in policy_current_law.json

I received other users feedback that the calculated qbided value is more accurate when the PT_qbid_limit_switch is set as False. ~ So I am trying to search evidence on that, and see if we should reconsider the value for PT_qbid_limit_switch.

Is there any CBO published QBID revenue estimation? (if you know, can share the source). We should compare that value to the Tax-Calc qbided calculation, and then decided if we want to set PT_qbid_limit_switch as True or False.

[martinholmer]

@bodiyang said in issue #2822:

Choice of True or False value for PT_qbid_limit_switch should be decided by the accuracy of the calculated qbided value.

I think you are dead wrong about that. The "accuracy of the calculated qbided value" under current-law policy is jointly determined by the quality of the input data and the logical accuracy to the Python tax code. It has been known for many years that the CPS and PUF data used with Tax-Calculator are deficient with respect to QBID calculations, and therefore, using those datasets leads to under-estimates of the QBID amount. See taxdata issue 319, which was the original issue on this topic.

As an example, for year 2024:
if $106.2 billion is closer to the real world QBID value, then we keep PT_qbid_limit_switch as True, as it is in policy_current_law.json
if $296.5 billion is closer to the real world QBID value, then we should make a change ~ change PT_qbid_limit_switch to False in policy_current_law.json

As I said above, this is completely wrong. The policy_current_law.json file contains the values of parameters under current law, and current-law policy requires PT_qbid_limit_switch to be True.

I received other users feedback that the calculated qbided value is more accurate when the PT_qbid_limit_switch is set as False. So I am trying to search evidence on that, and see if we should reconsider the value for PT_qbid_limit_switch.

You are barking up the wrong tree. Why not "reconsider" the use of the PUF input data generated in the taxdata repository? Why not use the more up-to-date PUF input data generated in the tax-microdata repository? These data are not only based on the 2015 IRS PUF (instead of the 2011 IRS PUF used in taxdata) but they include imputed values of the PT_binc_w2_wages variable so that the aggregate QBID amount is more sensible. More on that last point below.

Is there any CBO published QBID revenue estimation? (if you know, can share the source). We should compare that value to the Tax-Calc qbided calculation, and then decided if we want to set PT_qbid_limit_switch as True or False.

Again your notion that "we [might] want set PT_qbid_limit_switch as [...] False" is wrong.

The TMD input data for Tax-Calculator generate sensible aggregate QBID amounts as shown in the following table (which is generated using these methods):

For documentation about how to use the TMD data with Tax-Calculator, see the data section of the Tax-Calculator documentation.

So, in conclusion, this QBID problem is a tax data problem, not a tax logic problem.
The sensible way to solve the QBID problem is to use better data as Tax-Calculator input.

[bodiyang]

@martinholmer

Yes, I agree QBID is a taxdata problem not a tax logic problem

Maybe I can further narrow down this issue: the PT_qbid_limit_switch is not a tax law / tax logic. This is because the switch is not in QBID tax form 8995. ~~~ We are supposed to follow the tax logic of line 15 to check the income limitation. However, this is not possible because of the PUF/CPS data constraint.

So, we are assuming that either we apply the income limitation upon all tax units or not. PT_qbid_limit_switch is essentially an assumption we made, and this assumption is that all of the tax units are under the income limit (when the switch is turning true). We replaced line 15 tax logic with this assumption.

So strictly speaking, PT_qbid_limit_switch should not hosted be in policy_current_law.json file. What PT_qbid_limit_switch does is actually a matter of taxdata's.

---

It is helpful to see the CY 2023 QBID tax expenditure you shared.

I will try to do more calculation based on this table.

[martinholmer]

Among other things @bodiyang said in issue #2822:

So strictly speaking, PT_qbid_limit_switch should not hosted be in policy_current_law.json file.
What PT_qbid_limit_switch does is actually a matter of taxdata's.

I agree completely. Not only is the logic of PT_qbid_limit_switch not part of current law, but that logic has never been proposed as part of any tax reform that I'm aware of.

I think Tax-Calculator PR #2497 was a big mistake. My main take-away from this discussion (here in issue #2822), is that the PT_qbid_limit_switch parameter should be removed from the policy_current_law.json file.

@MattHJensen and @jdebacker, do you have any concerns about removing the PT_qbid_limit_switch parameter?

[jdebacker]

@martinholmer @bodiyang Is the suggestion to remove the PT_qbid_limit_switch from the policy_current_law.json file or to also remove the conditional statements in calcfunctions.ItemDedCap?

I think having this flag can be useful for some use-cases.

And we need to make a default assumption for all parameters. And those defaults are set in the baseline JSON file.

So should we really be thinking about changing the default value?

[martinholmer]

@jdebacker said in issue #2822:

Is the suggestion to remove the PT_qbid_limit_switch from the ``policy_current_law.json file or to also remove the conditional statements in calcfunctions.ItemDedCap?

The suggestion is to remove both the parameter and its associated logic.

@jdebacker also said:

I think having this [PT_qbid_limit_switch parameter] can be useful for some use-cases.

What would those use cases be? Can you give some examples?
The discussion in issue #2822 indicates that this parameter causes plenty of confusion.

[martinholmer]

@jdebacker, Let me clarify. The logic in calcfunctions.py would be the same as the default True logic (which is current law). What would be removed is the parameter and its associated False logic.

[jdebacker]

What would those use cases be? Can you give some examples?

You want a QBID with no wage or capital limitations, right? Is there a better way to model that?

[martinholmer]

@jdebacker said:

You want a QBID with no wage or capital limitations, right? Is there a better way to model that?

But who wants that kind of policy reform? Has such a reform ever been proposed in the serious tax analysis community?

[martinholmer]

@jdebacker said in issue #2822:

You want a QBID with no wage or capital limitations, right?
Is there a better way to model that?

This kind of reform can be modeled without the PT_qbid_limit_switch parameter (more below). There is a cost to keeping the PT_qbid_limit_switch parameter in Tax-Calculator because it causes confusion, and therefore, requires developer time to explain things to confused people.

If you look at the current QBID code, you can see that setting the PT_qbid_limit_switch parameter to False produces the same results at setting the PT_qbid_taxinc_thd parameter values to infinity. So, the PT_qbid_limit_switch adds nothing except confusion.

[martinholmer]

@bodiyang added this comment in issue #2822.

When I click on your screenshot link, I get this:

@bodiyang, Can you please explain what you did to generate your results?
Include the Python script (as text) that generated your numbers.

[martinholmer]

@bodiyang, I ask you to post the Python script as TEXT. Please do that instead of posting it as binary information.

[martinholmer]

@bodiyang said in issue #2822:

A follow up regarding to the calculated qbided table you shared (For the year 2023)

That table had been posted earlier in the #2822 discussion in this comment.

@bodiyang, I don't understand what your "calculated qbided table" has to do with the tax-microdata tax expenditure table that I posted. Do you realize there is a difference between the amount of tax deduction and the tax expenditure associated with that tax deduction?

[bodiyang]

@martinholmer

Ok, my misunderstanding of the table of tax expenditure.

I will delete the previous comment above in case of confusion