Create control lever for revenue neutral carbon price and allocate to ISIC codes as flagged in input data

[robbieorvis]

Just following up on our discussion about creating the option of a revenue neutral carbon price in the model.

I’m thinking we can use a control lever to designate this (we could also eliminate some extra outputs and graphs this way) and then specify in an input file the share of the carbon revenue returned to different ISIC codes, including households.

This would provide us with some really great new abilities to estimate how different revenue return structures affect jobs and the economy.

Thinking really long term, if we ever add in spending based policies, this might also look at how reinvesting carbon tax revenue into specific deployment based policies would affect emissions.

My inclination would be to have the lever set to 1 by default.

All this is to help address some potential red flags with a significant fraction of new jobs being in the government and to mitigate some of the negative impact on industries and consumers from carbon pricing. Now that we have all the great I-O work you did, I think we can do this pretty seamlessly.

[jrissman]

In the case where the revenue neutral setting is enabled, and the policy package causes a reduction in carbon tax revenue, do you want the revenue neutral setting to be respected or disregarded? This would happen, for example, in a country or region with a BAU carbon tax rate (like the EU) and a policy package that consists solely of energy efficiency policies.

If the setting is respected, the user's specified carbon tax revenue recipients are passed negative dollars (i.e. they are taxed) to make the policy revenue neutral. Imagine government increasing payroll taxes, individual income taxes, or whatever other taxes the user envisioned the government reducing had there been increased carbon tax revenues.

If the setting is disregarded, then the carbon tax is not revenue-neutral, contrary to the plain meaning of the control setting the user has enabled. Government will make up the shortfall by reducing its spending.

[robbieorvis]

Good question. I think the revenue neutral setting should be respected. It's not that it's a tax, it's that it's a reduction in a government subsidy, which should be reflected in the data (and is also offset somewhat by lower spending on things like electricity. From a modeling perspective it's the same but qualitatively it's different than what you describe above.

[jrissman]

Okay, that makes sense to me.

One more question for you. As of 2.1.1, the "revenue-neutral" version of the direct policy package cost breakdown graph is calculated like this:

The green line represents a dollar-for-dollar rebate (no respending effects) of the total change in net tax revenue (taxes minus subsidies). This effectively says that any increase in tax revenue due to the policy package (such as from a carbon tax increase) would first be used to pay for any increase in subsidies that are part of the same policy package (like a new or increased feed-in tariff for wind power), and any remaining amount is refunded in a way that generates $1 of economic gain/output per $1 rebated. That gain is not assigned to any particular cash flow entity - it is just shown as the green line on the cost graph, which isn't broken out by entity.

Should we use the total change in net tax revenue for the new control setting you're requesting here? Or is it crucial to separate out the change in carbon tax revenue and make only that part revenue-neutral, while making other changes in tax revenue and subsidies caused by the policy package ignore the revenue-neutrality setting?

Here are some reasons we might want to treat the changes in taxes and subsidies consistently (e.g. the setting makes them all revenue-neutral, or none of them) rather than singling out the carbon tax:

• The net change in taxes and subsidies is already calculated
• Some countries for which withdrawing subsidies is the big deal and a carbon tax is not (e.g. Saudi Arabia) might want to be able to simulate a revenue-neutral subsidy withdrawal, rather than a revenue-neutral carbon tax.
• In the U.S., in policy packages with a significant carbon tax, the carbon tax is often responsible for a huge share (like 99%) of the net change in taxes and subsidies, so the two metrics are almost identical to each other in these cases
• In a policy package without a carbon tax, the revenue-neutrality toggle would allow us to answer a research question some folks might care about (what does it take to do this climate policy package without increasing or cutting taxes), but the toggle would serve no purpose if the setting's effect were limited to the carbon tax. I notice a de-emphasis of the carbon tax in more recent U.S. policy packages, and policymakers' interest in revenue-neutrality might not be limited to just how to make carbon taxes revenue-neutral, but how to make other policy packages revenue-neutral, in the U.S.

[robbieorvis]

I think we probably want to leave them lumped, because it provides the ability to test revenue neutral (or not) versions of other taxes. For example, a US state might consider raising the gas tax and then could look at redistribution effects (or not). I think preserving the ability to do this makes sense. I think the concern - that multiple taxes and subsidies might net out some share of the rebate is probably negligible given the size of the carbon revenues compared to other subsidies and taxes. So, IMO it's okay to keep them lumped. @ssonniaa - do you have thoughts, particularly as we think about how to share the new outputs of the modeling with folks on the Hill? Do you think it matters?

[jrissman]

This is done in 3b724e7. Please note the following:

• Rather than a Boolean, the new control has been implemented as a percentage slider, from 0% to 100%. This means that you can specify that a policy package may be 100% revenue-neutral, 75% revenue-neutral, 0% revenue-neutral, or any other percentage. This is necessary if we want the capability to evaluate proposed policies that rebate/offset some, but not all, of their revenues.

• The new policy is a policy lever, not a control setting. Remember that the key difference between policy levers and control settings is that control settings affect the BAU case and policy levers do not. The new feature alters the use of policy-driven changes in government revenue, which are zero by definition in the BAU case, so this lever cannot apply to or alter the BAU case. Also, remember that control levers cannot be visualized in the wedge diagram or cost curve, and they always report zero cost (because they don't create any difference between the BAU and Policy cases), which would prevent valuable types of analysis from being performed using this lever. We should almost always be making new things as policy levers, not control settings, with rare exceptions for things that are out of policymakers' hands - like the pandemic - or things that are pure modeling parameters - like a choice of whether to use 20-year or 100-year GWPs when reporting results in output graphs. Anything a policymaker might want to do, he/she might want to understand the costs and abatement implications, which means it generally should be a policy lever, even if its effect is to alter other policy levers.

• I've started off the policy with a default setting in io-model/AGFA of 25% of government tax revenues rebated to households (representing a climate dividend or a reduction in individual income taxes) and 75% of revenues rebated to industries, weighted by their total employee compensation (representing a reduction in social security taxes or other payroll taxes). I tilted it toward payroll tax reductions rather than direct payments to households because I think you likely derive greater economic benefits that way. But you may alter these default allocations in AGFA prior to the launch of EPS 3.0, if you wish. If you do so, please remember to also update the guidance text for the "Rebate Tax Revenues" policy in WebAppData, as the guidance text mentions what the default allocations are.