BUG: Approximation of last year's tax in ALG 1 calculation

[paulinaschroeder]

Bug description

To approximate last years income for unemployment benefit arbeitsl_geld_eink_vorj_proxy calculates taxes the following way:

# Relevant wage is capped at the contribution thresholds
max_wage = min(bruttolohn_vorj_m, _ges_rentenv_beitr_bemess_grenze_m)

# Fictive taxes (Lohnsteuer) are approximated by applying the wage to the tax tariff
prox_tax = _eink_st_tarif(
   12 * max_wage - eink_st_abzuege_params["werbungskostenpauschale"],
   eink_st_params,
)

Problem description

These Lohnsteuer estimates are too high since 12 * max_wage - eink_st_abzuege_params["werbungskostenpauschale"] is not the same as taxable income of last year, e.g. a person with bruttolohn_vorj_m of 1000€ currently has to pay Lohnsteuer with this calculation. This leads to lower arbeitsl_geld_m outputs (compare test data with the results of this calculator for ALG 1 from the Bundesagentur für Arbeit).

Problem solution

150 currently implements Lohnsteuer. After that PR is merged this problem can be fixed by using that instead of _eink_st_tarif.

[hmgaudecker]

Yes, that will be the way to go. @JakobWegmann told me that he can reproduce the exact values found in the IAB data with (a Stata version of) that code.

This said, I think we should just get rid of that proxy in favor of an example how to calculate net income in the previous year (people would have to call GETTSIM twice, but I'd think that'll be fine to ask).

[JakobWegmann]

This said, I think we should just get rid of that proxy in favor of an example how to calculate net income in the previous year (people would have to call GETTSIM twice, but I'd think that'll be fine to ask).

I'm not sure that the proxy is much better, as ALGI depends strongly on the Steuerklasse.

[ChristianZimpelmann]

Since arbeitsl_geld_m is an input to several transfers (Unterhaltsvorschuss, Wohngeld, ALG 2), I don't think we should require calling GETTSIM twice to calculate any of those. Or did I misunderstand your suggestion?

[hmgaudecker]

We just want an input variable arbeitsl_geld_bezugsgröße (not sure whether that is the right term) rather than calculating some proxy for it ourselves. For example, the latter only works if the system does not change (much) from one year to another.

And yes, @JakobWegmann, Steuerklasse will be a required input then. As usual, users may input whatever assumption they like in case they do not have data. It should not be GETTSIM (quietly) making that assumption.

[ChristianZimpelmann]

For example, the latter only works if the system does not change (much) from one year to another.

That's something we could handle by just using last-year's policy parameters/functions (we implemented the access_different_date-key for this use case).

The bigger problem would indeed be to handle changes of the Steuerklasse.

I think this is a bigger discussion as we need proxies of last year's net income or Lohnsteuer for a few transfers.

[hmgaudecker]

Fair enough, I did not even remember that one. I am just afraid that we will quietly be assuming persistence in lots of relevant state variables. But let's see about that once #150 is merged.