这是一个创建于 329 天前的主题，其中的信息可能已经有所发展或是发生改变。
36100 拿到手比 36000 少，请问大家真的是这样吗，上小学时的一道数学题成了现实了。
 |
101
nothingistrue 327 天前
@xmumiffy #70 所以你是并不理解，个税改成按年后，年终奖单独计税的优惠点在哪里了？啥都不懂在这里狂按键盘。
|
 |
102
gtx990 327 天前 via Android  1
楼里为这件事情辩解的人能不能别太离谱了
"因为这是一个优惠政策，所以怎么定都是对的" "制定政策的人不比你聪明" 很明显就是年度奖金计算逻辑引用的时候错误的引用了月薪的速算扣除数，导致“收入陷阱” 并且很明显是一个人为错误 因为就算这个陷阱是人造的，不如直接把公式里的速算扣除数删了 这样不仅能多收点钱，规则也简单一些，打工人到手也就差很小一部分钱 |
 |
103
chairuosen 327 天前
@gtx990 就是因为质疑的人少了，所以傻子都能留在上面
|
 |
104
xmumiffy 327 天前
@nothingistrue 你又在这里按什么呢?
|
 |
105
anzu 327 天前 4
这里先给出最新政策
https://www.gov.cn/zhengce/zhengceku/202308/content_6900595.htm 重点计算方式是： 以全年一次性奖金收入除以 12 个月得到的数额，按照本公告所附按月换算后的综合所得税率表，确定适用税率和速算扣除数，单独计算纳税。计算公式为： 应纳税额＝全年一次性奖金收入×适用税率－速算扣除数 现在开始解析公式的每个部分。 1. 全年一次性奖金收入 这个不用说，就是你的年终奖。没问题。 2. 适用税率 需要把年终奖按月换算后（除以 12 ），在税率表中确定适用税率，一共有 7 级。也没问题。 3. 速算扣除数 这里出问题了。税率表中给出的速算扣除数是月度的，而公式中只减了一次。 所以这个公式的问题在于 [一次性缴纳相当于 12 个月的税，但是速算扣除数只减了一次] 。（还有一个问题后面另谈） 例： 1. 年终奖 36000 应纳税额 适用 3%税率（ 36000 除以 12=3000 元档），速算扣除数 0 应纳税=36000×3%=1080 2.年终奖 36001 应纳税额 适用 10%税率（ 37000 除以 12=3000 ～ 12000 元档），速算扣除数 210 应纳税=36001×10%-210=3390.1 另谈： 年终奖的计算公式看似在模仿月收入计税的方式，实际上完全不同，只是借用了一些数字创造了一个新公式。 比如月收入 3001 元，那么 3000 元的部分会按%3 税率计算，而 1 剩下 1 元按照 10%税率计算，即超额累进。 而年终奖的计算方式完全没有体现超额累进这个过程。 明明是初中生就能理解的年终奖计算方式，我不知道为什么还需要解释……还有人说什么相信专业性之类的……还有好多人点赞……真是太草台了…… |
 |
107
mschultz 327 天前
@xmumiffy @snw 又思考了一下国税发〔 2005 〕 9 号的内容，揣测制定者的意思的话，我现在理解是这样的：
1. 旧税法按月计征。 2. 旧税法下，全年一次性奖金会导致某个月收入畸高，那个月的按月税率会畸高。 3. 因此，国税发〔 2005 〕 9 号给旧税法打了个「补丁」，把一次性奖金除以 12 后再按累进税率计税。但这个补丁算法是个缝合怪（金额按全年计算但只减一个月的超额累进税率扣除数），结果从数学意义上既不是超额累进税率也不是全额累进税率，但仍具有全额累进税率的跳变陷阱（无效纳税区间）特征。 4. Nonetheless ，国税发〔 2005 〕 9 号 这个补丁可以认为初步有了新税法「按年计算」的精神雏形。 5. 新税法开始全面按年度综合收入计算，不再以每月计算值为准。 6. 但是，对某些人来说，如果全部收入合并适用新税法，发现应缴税额比「一次性奖金用国税发〔 2005 〕 9 号补丁 + 其他收入用新税法」方案要多。 7. 国家考虑到这种情况，网开一面，允许这些人自行选择缝合怪方案少缴税。这种网开一面目前延续到 2027 年底。 本帖吐槽的是上述第 3 点。 我觉得吐槽是有道理的，国税发〔 2005 〕 9 号那个补丁在计算上就是个缝合怪，很奇怪，不太合理。虽然它比旧税法合理，比旧税法优惠，在某些情况下甚至也比新税法优惠。 但优惠归优惠，合理归合理，两码事，个人认为新税法还是更合理 😄 |
 |
108
corningsun 327 天前
新版 “皇帝的新装”
大家都明白，但仍然将错就错。 |
|
109
xmumiffy 327 天前
@mschultz 个税税法明面上就还有比例税率,不只是差额累进税率.
其实用类似算法的不止年终奖(全年一次性奖金).不少一次性收入都是按这个算法来的,你看到条款里面不写使用差额累进税率,而是指明算法的,十有八九是有坑.只不过年终奖最常遇到,影响的人数最多. |
 |
110
ygtq 327 天前
看了半天终于看懂了，但是这和我又有什么关系呢... T=T
|
 |
111
GuuJiang 327 天前 via iPhone 2
|
 |
112
manasheep 327 天前
所以说 7-9 万年终奖的话，二选一用哪种更省钱？
|
|
113
mschultz 327 天前 via iPhone 1
@manasheep #112 取决于你除了年终奖之外的其他应纳税所得额（即除了年终奖外的全年收入，减去 6 万的基本免税额、减去各种专项附加扣除）。
如果这个应纳税所得额是 33000 ，且年终奖在 7-9 万区间。那么你选择按新税法合并计税与年终奖单独计税方案是一样的。如果低于 33000 ，合并计税更好。如果高于 33000 ，年终奖单独计税更好。 我口算的不知对不对，你可以根据税率表格自己验算一下 |
|
116
nothingistrue 327 天前
@xmumiffy 林北这回有闲功夫，就给你说说年终奖单独计税的优惠点在哪里。https://www.v2ex.com/t/1014190
|
 |
117
unco020511 327 天前
@anzu #105 啊原来这么简单吗,怎么前面都说的这么复杂,你这么一说其实很简单啊,很明显就是有问题,如果税率递进,那应该是高于上一等级的收入才用高等级税率才对
|
 |
118
mrrobot97 327 天前
看了一些回复，有不少半瓶晃荡的，可能这些人没拿过比较高的年终奖吧
|
 |
119
snw 327 天前 via Android
@mschultz
我非常赞同你 #107 说的“缝合怪”一词。 是的，全年一次性奖金这个补丁就是个缝合怪，函数长相怪异，数学上也没严格意义，然而它就是长得像本质啊。而其他许多方案长得好看是好看（比如速算扣除数×12 ），但问题是长得很不像本质。 本质在 #46 楼已经提过了，摊到每月收入上再超额累进，然而最大的问题在于没有实操性。 我也赞同现在年度综合所得计算个税才是更合理的方案，但你不能拿现在的情况去评价 19 年前的补丁。综合所得的实施有太多的前置条件了，大部分条件在 2005 年根本不具备，所以不可能在 2005 年实施。而往后知道个税准备向年度综合所得方向改革，自然就没动力去修补那个缝合怪了（就像知道项目要重构，自然懒得去改还能跑的屎山）。 |
|
120
snw 327 天前 via Android
@anzu
很简单的道理：年终奖平摊到 12 个月的话，年终奖的个税应当是从月度工资之上继续超额累进，而非从零开始超额累进。由于每个人的月度工资不同，所以在此之上继续累进难以统一做出月度工资速算扣除这样的公式。 然后你是不是想说“那就在月度工资之上继续超额累进计算呗”？嗯，老人事/老会计们都会想打死你的。。。 |
|
121
mschultz 327 天前
@cmdOptionKana #98
「但我有没有说过，我这个函数，它的计算结果是首尾相连的？我没说过。」 「注意，首尾相连这个要求，是你希望，不是我的承诺。」 实际上你「几乎」承诺了。 首先，根据国税发〔 2005 〕 9 号文的一个链接，https://guangdong.chinatax.gov.cn/gdsw/zjfg/2011-02/23/content_739bbfc1f7364a4a9b6091fc025662a2.shtml 我们进而找到对应的政策解读： https://guangdong.chinatax.gov.cn/gdsw/wzjd/2009-05/07/content_f354ca0442354599a94fc028217ed3d6.shtml 其中有一句：「计算方法是：用全年一次性奖金总额除以 12 个月，按其商数对照工资、薪金所得项目税率表，确定适用税率和对应的速算扣除数，计算缴纳个人所得税。」而这里的「工资、薪金所得项目税率表」，明显是指当时个税法里面的税率表，而个税法明确写了工资薪金所得适用超额累进税率。 也就是说：你引用了超额累进税率表中的数据，还引用了在超额累进税率计算中有特定数学意义的词汇「速算扣除数」，眼看就让广大群众都「觉得」你就就要按照超额累进税率的明确规则计算了 …… 但是一转头，在计算过程中悄悄埋陷阱多收税，导致计算结果根本不是超额累进税率，反而接近全额累进税率。 这就好比你给我一个函数 continuous_function( )，然后说：“我这个函数起名叫 continuous function ，但这只是个惯用名字，我并不保证它在数学意义上是连续的，多想了是你的责任” 怎么说呢，也许这不违法，但在普罗大众眼里，肯定是耍赖了。被喷的话不冤枉。 @chairuosen #99 |
 |
122
cmdOptionKana 327 天前
@gtx990
@chairuosen @anzu @mschultz 为什么大家会认为不够优美的缝合怪就等于 bug ？ 这显然证据不足，因为还有一个重点：这个缝合怪能避免吗？ 如果这个缝合怪是必须存在的，不能避免的，也就是说，如果必须要做一个速算表/速算公式，那么关键就会变成：你能设计一个更优美的缝合怪吗？如果不能，那凭什么说缝合怪是 bug 呢？ |
 |
123
fzls 327 天前
@cmdOptionKana #122 扣除数*10 不就符合逻辑了吗，同样也是缝合怪
|
|
124
fzls 327 天前
@snw #120 很简单啊，年终奖单独适用一套累进计算额度不就好了- -现在这个不就是这样，每年其他部分累加计算，年终奖这部分可以选择使用这个方案单独计算，唯一奇葩的就是按照单独纳税额度来计算的扣税额使用的是 12 个月的，而速算扣除数却用了单个月的
|
|
125
mschultz 327 天前 1
@cmdOptionKana #122 如果要求只是让函数给人感觉「更优美简洁」、不考虑国家税收收入数额问题（我的权力地位还没到考虑这个问题的地步😂）的话 —— 方案微调一下就可以的。
1. 如果想多收税，那就直接明说一次性奖金适用全额累进税率，36000 以下全额 3%，36000 - 144000 全额 10%，依此类推，没有扣除数的概念。 2. 如果不想多收税，想给人民群众优惠，那就一次性奖金直接单独适用 3% - 45% 的超额累进税率。 不用搞弯弯绕的参数，计算也方便好理解，也不怎么缝合。 ==== 现行的缝合怪方案与上述方案 1 有多大区别呢？感觉就是做了一个「超额累进」的样子，让人民群众观感好一点？ 但实质上不是超额累进，然后就被看出端倪的群众骂。反正方案 1 也是挨骂，哈哈。可能骂的人会更多吧。 |
|
126
snw 327 天前 via Android
@fzls
要是速算扣除数乘以 12 ，曲线是顺眼了，但离业务逻辑差远了。 乘以 12 翻译成业务语言是：“把年终奖分成 12 个月，每个月重新从最低档税率开始重新累进个税”，相当于额外给了 12 个月给你分摊年终奖，而不是把年终奖摊到月度工资上面。 至于你说年终奖单独适用一套累进计算额度......个税的税率表是写进税法的，那得修改税法才行。 至于你说现在年度综合所得纳税+年终奖可以单独计算......我前面说过了，改成年度综合所得纳税之后，理论上就没必要继续给年终奖单独计算了，无非是现在经济不好，所以打着延续政策的名义给个税优惠罢了。这是暂时补丁，不是应该有的东西。 |
 |
127
changnet 327 天前 1
@snw 我都不知道你们在争什么，我觉得 snw 说得很清楚了。
很久以前，年终奖是合并到当月工资里计算的。假设 12 月工资为 0 的情况下，年终奖要扣 4410 ，即到手 36000 - 4410 = 31590 于是大家觉得这计算方式不够好，改进一下，变成：应纳税额＝全年一次性奖金收入×适用税率－速算扣除数 12 ，即 36001 ，平均到 12 个月，税率 10%，速算 210 ，则税为 36001×10%-210=3390.1 ， 到手 32610.9 你看，改进后，工资是独立算的，年终奖 32610.9 也比原来的算法的 31590 多，这不是优惠了吗？ 没错，这算法是有问题，人家也没否认。至于为什么有问题也这样做 snw 不也解释了吗？但是比原来的算法有进度不是。而且现在不也有新的税法了吗？按年总收入来算。 然后一帮人在 2024 的角度对这算法口诛笔伐有什么意义？就好比大家都在说 md5 算法有问题，会出现冲突。人家是有问题，但是在当时简单够用。 |
|
128
snw 327 天前 via Android
@mschultz
见 126 楼，你提的方案相当于额外给了 12 个月用来分摊年终奖（即从 3%开始适用累进税率），这就是我说的看起来很好看但离本质差很远的东西。 |
|
129
mschultz 327 天前
@snw #119 你说问题的本质是「（应该）摊到每月收入上再超额累进」，我可不可以进一步解读为「月度收入高的人，其年终奖的税率应该更高一些；月度收入低的人年终奖税率也低一些」。也就是说，新税法的做法最接近问题本质。
只是 19 年前财税界电算水平不高，「最大的问题在于（每个人月度工资不同，所以在快捷计算上）没有实操性。」，所以才实行国税发〔 2005 〕 9 号补丁。 这个补丁其实做了一个隐含的、非常粗糙的假设：就是年终奖越高的人，他的平时工资大概也越高，如果将年终奖均摊到 12 个月（本质算法），均摊过来的这部分更可能直接适用高税率。 因此，年终奖直接适用「全额累进税率」更接近问题的本质。现行方案约等于在全额累进税率的基础上做了一定的「扣除数」补偿。 ==== 那么现在剩下的主要问题是：这个「扣除数」补偿的*数值选择* 和 *名词选择* 极具误导性，给补偿的解释也挺牵强的。不排除是官方刻意误导（？）。最后也免不了挨骂，这个帖子里那么多回复就是例子。 |
|
130
xmumiffy 327 天前 1
@changnet 有点小错误是, 国税发〔 2005 〕 9 号 之前用的是 国税发〔 1996 〕 206 号.
一次性奖金是单独作为一个月的工资计算纳税的,不需要假设 12 月的工资为 0. 这也可能是 国税发〔 2005 〕 9 号 算法中减除一个月的速算扣除额的隐藏原因,因为之前就另外给了一个月用于缴税. |
 |
131
liuweiqing 327 天前
持保留态度
|
|
132
snw 327 天前 via Android
|
|
133
chairuosen 327 天前
我本身也是开发，我非常讨厌开发在面对自己写出的 BUG 时，各种狡辩这不是 BUG 的行为。
在楼上我看到了： 1 ，历史继承的所以不是 BUG 2 ，占了便宜所以不是 BUG 3 ，人家专业的所以不是 BUG 4 ，需求就是人家出的所以不是 BUG 我是用户，我用着有问题，就是 BUG |
|
134
chairuosen 327 天前
@chairuosen #133 这个问题根本不需要从过程分析。只需要从结果分析：发的多，拿的多，发的少，拿的少。跟多劳多得一样，是理所应当的。 发的多拿的少，我付出多奖金高到手的反而少，我凭什么付出。违背历史发展规律，你不认为是 BUG 无所谓，历史会把你淘汰。
|
 |
135
skull 327 天前 via iPhone
36001~38566.67 是禁区，38566.67~41775 是低效区
|
|
136
snw 327 天前 via Android
@chairuosen
我是(半个)业务部门，我很讨厌开发用“代码优雅性”、“我觉得应该怎样怎样”来试图直接篡改业务逻辑。 由业务逻辑导致的意外结果，而且有 workaround 的情况下，应该先制定业务逻辑的改进方案，而不是想当然地直接改代码。 |
|
137
chairuosen 327 天前
@snw #136 有意外结果的业务逻辑不就是 BUG 么。业务逻辑的改进方案不就是改 BUG 么？
|
 |
138
kkbblzq 327 天前
@snw 这种所谓的唯权威论是不能让我信服的，这种无论从数学角度还是实际执行上都有明显问题的算法，单纯以有优惠就是对的来解释是很强行的；像极了那种"领导说的就是对的，错的也是对的"，我完全没有从你的说法中找到任何可以佐证的证据，而是直接以“官方给的算法一定是对的”的角度，然后自圆其说的拿一些所谓的背景来找补。
|
|
139
mschultz 327 天前 via iPhone
@changnet #127 至今还在讨论的原因是：1.新税法虽最合理，但新税法下很多人税负增加了，还不如用那个有问题的算法。
2.官方允许老算法继续应用到 2027 年。现行的政策就应该容许批评的声音。 3.这个补丁算法虽然是比更老的算法优惠，但人们永远希望它能更优惠。诶，它不是长得有点儿像超额累进税率吗？人们希望它真的是。毕竟那样又可以交更少的税咯。啊，仔细一看原来不是啊，遗憾，批判一下。 “如何让自己少交点钱” 这个话题别说 2024 年，4202 年也可以热烈讨论啊，如果那时候人类还没灭亡的话 |
 |
140
KgM4gLtF0shViDH3 327 天前
没有年终奖就没有烦恼了
|
|
141
nothingistrue 327 天前
@mschultz 哥们看一下我单独发的主题，虽然现在这种算法问题很大，但你希望那种方式是不可能存在的。
|
|
142
GuuJiang 327 天前
@changnet 那为什么不能是 36001x10%-2520=1080.1 呢？这难道不是更优惠？说白了，在正确的版本中(比如月薪)，法律文本明确写了，3000 以下税率为 3%，**3000-12000 的部分**按 10%，基于这个前提才算出了速算扣除数为 210 这个数字，所以可以明确地回答以下问题
1. 我国的征税税率是多少？ 答：超额累进税率，3000 以下 3%，3000-12000 的部分 10%，等等 2. 计算公式 3001*10% - 210 中的-210 的含义是什么？ 答：是对上述的超额累进税率进行计算的过程中产生的一个中间结果，相当于把超额累进当成全额累进计算后多出的部分，减去以后就能还原为超额累进 而在 36001x10%-210 这个公式里，能回答上述两个问题吗？根本就不能，假如把物理公式中的量纲的概念进行一个广义的推广的话，可以说这个公式连量纲都不对 问题的真正本质是，对于一个税收策略的制定者，可供他调整的参数包括： 1. 全额累进还是超额累进 2. 各档次的区间以及税率 至于速算扣除数，压根就不是一个自由的参数，是在当选择了超额累进策略以及确定了区间和税率后自然就确定了的一个值，它的值完全由区间和税率来决定，拿 excel 举例的话，前两个参数是用户可以自由输入的值，而速算扣除数那里放的应该是一个公式，根本就不应该由用户去输入 而由于“减去速算扣除数”那个版本的公式太过于深入人心，导致了很多人，包括年终奖政策制定者，实际操作的人员，以及这个帖子里的一部分人，都把它当成了原始的公式，误以为速算扣除数是一个可以根据各种理由去自由调整的参数，于是把讨论的方向歪到了“速算扣除数应该选多少才合适”上去 政策制定者真正应该去操作的是选择全额还是超额，以及确定区间和税率，如果选择了全额，那么自然就不存在速算扣除数，也就是你们所说的不减或者减 0 的情况，如果选择了超额，那么就应该在确定完区间和税率后重新计算出新的速算扣除数，也就是说对于全额/超额，以及区间和税率的选择，才具备讨论的基础，区间合不合理，税率高了还是低了，在这类问题上才值得各方根据自己的观点进行辩论，而对于一个原本是由其他的参数间接确定的值去讨论取多少合适，以及取值的理由，只能说 not even wrong |
|
143
GuuJiang 327 天前
https://docs.google.com/spreadsheets/d/1smAmln56i3CJyh4vrFQWMzuvIsZlBks7i9Z78E1zfXc/edit?usp=sharing
做了一个表格，如果结合这个表格都还看不懂问题出在哪里那就确实没有讨论的必要了 其中 A 列指定各区间起点，B 列指定各区间税率，C 列中使用公式通过 AB 两列的数据计算出了速算扣除数，是不是和官方文件中正确版本的取值完全一样？然后把 A 列和 B 列换成历史上曾经推出过的文件中的区间和税率，是不是发现 C 列的结果仍然和文件里是吻合的？ F 列是通过超额累进的原始定义的公式来计算税，而 G 列是使用了速算扣除数版本的公式，可以看到二者计算结果完全相同，但是 G 列的公式更简洁，这才是速算扣除数的本质含义 @snw 你一直在强调本质，那请问下，在 3001*10%-210 和 36001*10%-2520 这两个公式里，我可以回答出-210 和-2520 的本质是什么，而在 36001*10%-210 这个公式里，你能说出这个-210 的本质吗？难道就是个为了达到“优惠但又不完全优惠”这个目的而随意添加的一个任意的值吗？你一直强调相比起不减速算扣除数(其实也就是选择了全额累进)来说“优惠”了，如果不想给优惠，那就直接选择全额累进，如果想要给优惠，那就老老实实提供正确版本的超额累进，如果觉得照搬月薪的区间优惠力度太大了，那完全可以根据实际情况去调整区间和税率(也就是表格里的 AB 列)，并且计算出新的 C 列，而不是现在这个结果 政策制定者的真正想法确实是一出罗生门，我们所有人能做的只有分析和猜测，但是从一般人的常理出发，你觉得是 A：原本想要制定一个超额累进的策略，但是没有真正理解超额累进的公式含义，把一个化简后的公式当成了原始公式，搬错了参数 还是 B：出于某些我等 P 民无法理解的苦心，去精心设计了一个形式上长得像超额累进的简化版公式，同时照搬了另一个已有的超额累进公式里的一组参数，然后事后声称这个既不是全额累进，也不是超额累进，而是为了给优惠而精心设计的第三种世界上还不存在的税收算法，所有不理解背后的良苦用心的人都是哗众取宠的小丑 这两种哪种的概率更大？ |
|
144
snw 327 天前 via Android
@chairuosen
首先，上面提出的那些简单的改 bug 方案是违背业务逻辑的，这比一个有部分意外结果的不优雅的业务逻辑更糟糕。 其次，这个问题已经被“年度综合所得”方案彻底解决了，所以剩下的问题只是什么时候把过时补丁删掉罢了，不需要再修改补丁。 最后，老用户也是用户，所以政策变动一般会考虑延续性。 @kkbblzq 并不是唯权威论。我已经介绍了前因后果，也没有认为这个方案没问题。我想说的是，你们能想到的“正确方案”要么错得更大，要么不具可操作性。另外，彻底的修正已经上线了，没必要再改这个临时的补丁。 |
|
145
snw 327 天前 via Android
@GuuJiang
你会提出全额累进，以及你提出的参数建议，说明你压根没理解业务逻辑。 请理解(1)“把年终奖摊到 12 个月的月度收入之上继续适用超额累进税率”与(2)“把年终奖摊到额外的 12 个月，每个月单独适用超额累进税率”这两种业务逻辑的区别。 对于第 1 种，实操中还需要由人事/会计给每个人添加每个人月度收入的参数，并且这个参数每月是不同的，并且如果一次性奖金不是在最后一个月发你都没法确定这个参数。 对于第 2 种，从业务逻辑上就不是这样设计的。 |
|
146
GuuJiang 327 天前 via iPhone
@snw 无论是上述两种中的哪一种，最终都不可能推得出 36001*10%-210 这个公式，请正面回答下，这个公式里的-210 这个数值的本质含义是什么？
|
 |
147
zizon 326 天前
大家着重看下 120L 再吵
|
 |
148
jobscolin 326 天前
一群“数学家”再争吵
|
|
149
GuuJiang 326 天前
@snw
> 我是(半个)业务部门，我很讨厌开发用“代码优雅性”、“我觉得应该怎样怎样”来试图直接篡改业务逻辑。 由业务逻辑导致的意外结果，而且有 workaround 的情况下，应该先制定业务逻辑的改进方案，而不是想当然地直接改代码。 引用你自己说的这段话，什么叫作业务逻辑？“3000 以下税率为 3%，3000-12000 的部分税率为 10%”，这种才叫业务逻辑，因为它是用自然语言描述，并且也白纸黑字地写在了官方的文件里，任何一个读懂了这段文字的人都能够计算自己应该交的税，比如我工资 5000 ，交税 290 ，我能对照着官方文档中的业务逻辑清楚地知道每一分钱的来龙去脉，5000 当中的 3000 按 3%应交 90 ，另外 2000 按 10%应交 200 ，合起来一共 290 。这个过程中是不是完全没有用到 210 这个数字？因为“3000 以下税率为 3%，3000-12000 的部分税率为 10%”这段文字已经使用描述一个税收政策所使用的通用语言给出了这个政策的全部信息，至于 5000*10%-210 ，反而不属于业务逻辑，而是实现层面的其中一种选择，实现者可以选择用这个公式，也可以选择不用，总之只要从原始的业务逻辑出发，一定能够得到正确的结果，而过去的文件把某一种具体实现中推导出来的一个常数也写在了业务逻辑里，本身就是不合理的，也为后面的事件埋下了伏笔，因为把 210 写到文件中，首先就在业务逻辑中干涉了具体的实现方式，其次这个 210 和前面的税率其实是在使用两种不同的方法描述了同一个业务逻辑，那就给制定业务逻辑的人增加了额外的风险，就是必须要维护这两个数字之间的一致性，比如已经说了“3000 以下税率为 3%，3000-12000 的部分税率为 10%”，那后面对应的速算扣除数就只能是 210 ，根本没有别的选择，一旦变成了其他的数字，就会和前面的描述自相矛盾，并且每次调整了区间和税率时，扣除数必须得要跟着一起变 而后面的年终奖恰恰就踩中了前面埋的这个坑，在 36001*10%-210 这个例子中，根本就做不到像上面一样使用自然语言描述出 36001 中哪一部分的税率是多少，别说 210 了，连 10%都变得无法解释，因为你根本就没法说清楚 10%到底表示哪一部分的税率，这难道不属于业务逻辑有 bug ？ 只要是人都会犯错，权威也不例外，一个有错误的文件已经正式发布了，那么在被修改或者废止之前就只能照着执行，这个大家都可以理解，哪怕去论述为什么不能修改，也勉强可以接受，但是非要去说“原本就是故意这样设计的”、“这是更优的选择”，那就简直是在把大家当傻子了，原本这个错误知道的人也不多，从这个帖子的讨论就可以看出很多人也是第一次才知道的，哪怕知道也并不一定完全清楚细节，你非要坚持不余遗力地去为之辩解，导致更多的人了解到这个错误是多么的低级，税务部门内心表示听我说谢谢你 |
|
150
snw 326 天前 via Android
@GuuJiang
我 145 楼、120 楼等已经重复解释过很多遍业务逻辑了，如果你思路还转不过弯来那我真没办法教会你。 最后实现的公式不需要你所谓的一一对应的“意义”，你讨论一大通公式哪一部分具体对应什么东西是没意义的。 |
|
151
GuuJiang 326 天前
@snw 是你一直思路转不过弯来，一直没有明白“速算扣除数”不是一个可以由制定业务逻辑的人指定的值，他能够指定的只有区间和税率，速算扣除数是实现层面的产物，所以“速算扣除数取多少值合理”这个问题从根上就不应该拿来讨论，如果你想要反驳这一点，请正面回答我前面提出的几条疑问，而不是用一句“不需要意义”搪塞过去，如果你所认为的业务逻辑居然连“用普通人能理解的自然语言描述”这一条都满足不了，而是要借助另一个业务在实现过程中产生的公式来描述，你觉得那可以称为一个业务逻辑吗？连描述里面涉及到的每一个常数的意义都解释不出来，还能称之为一个业务逻辑吗？
如果这还是理解不了，不妨来做个思想实验，假设在另一个平行宇宙里，最开始的月收入那个版本给出的值不是一个“速算扣除数”，而是一个“速算增添数”，取值如下表： (0, 3000): 0 (3000, 12000): 90 (12000, 25000): 990 并且把计算公式修改为(x - 所属档次的起点)*所属档次税率 + 速算增添数，比如 12002 的所得税=(12002-12000)*20%+990=990.4 这个“速算增添数”是不是比“速算扣除数”更优秀？ 第一，速算增添数的计算变得更简单了，下一行的速算增添数可以在上一行的基础上递推 第二，最终的公式变得更好理解了，更加直观地体现出了超额累进的过程 那么假如把现行的月收入的政策中的“速算扣除数”替换为“速算增添数”的版本，相信你不会有意见吧？因为这样的修改对最终税收的计算不会有任何影响，和“速算扣除数”的版本原本就是完全等价的 好了，接下来在这个平行宇宙里，接着重演年终奖的故事，那么最终的版本就会变为 年终奖 36000 的人，税为 36000*0.3=1080 而年终奖 36001 的人，则变成了 (36001-36000)*10%+90=90.1 于是网上讨论的标题不再是《年终奖多发一元，到手少千元》，而是变成了《年终奖多发一元，到手多千元》，那你觉得在这种情况下，从有人指出有问题到税务部门修改算法，需要经历几天？ 月收入明明采用了两种完全等价的方法去定义，但是相对应的年终奖却产生了两种截然不同的结果，你觉得问题出在哪呢？仔细想清楚这些问题，再决定要不要继续坚持你的观点吧 |
 |
152
Padawan 326 天前
@snw 你还是太年轻。这个事情就是一开始就搞错了但修正对于政策制定者来说很麻烦，不修正也影响不到他们的利益，就劳烦全国劳动人民一起将错就错。
部委的这些政策都是基层小职员拟一个初稿然后层层审批，负责审批的上级根本懒得管这些细节。等公布出去发现有问题时，那么多章都敲过了，认错重来要追责的。不认错也没（上面的人）管 |
|
153
snw 326 天前 via Android
@GuuJiang
再读读 120, 145, 150 楼吧，你仍然没有理解我重复了很多遍的业务逻辑。 速算算法本来就是怎么简单怎么来，而不是什么好理解。你给出的月收入“速算添加”算法并不比速算扣除有什么优势，甚至实操上更麻烦（多一个参数），2005 年仍有不少企业的工资表是手动算的（纸+笔+计算器），多减一个数就多一分工作量。 顺便说一句，如果平行宇宙的税务局把“速算扣除”算法套用到全年一次性奖金计算上，那么减的边界数也会是按月度表来的，结果仍是跳增而非跳减🐶 36000*3%=1080 (36001-3000)*10%+90=3390.1 |
 |
154
wupher 326 天前
明明是 bug ，非要硬洗。对，砖家不会错。千万不要智疑，你说的都对。
|
|
155
GuuJiang 326 天前 via iPhone
@snw 我完全充分理解你想要表达的所有观点，但是反过来你却并没有理解或者说尝试去理解我的观点
我来从头理一遍你的逻辑，然后一一指出你的逻辑里有哪些陷阱 1. 如果把年终奖并入当月工资计税，会导致税收太高，对劳动者不公平，在这个背景下税务部门开始制定新的税法，这点我完全同意 2. 接下来有 4 种备选方案，按缴税额从高到低依次称为 ABCD 下面我来逐个分析 3. 方案 A：也就是你说的本质，即把年终奖分摊到 12 个月中去合并计税，并且以原本的月收入为起点继续超额累进，我完全同意你说的这个才是年终奖税本来应该有的样子，这个方案对国家来说是最公平的，但是**直接计算年终奖的税**实操较困难，这点我也同意，但是实际也没有那么的困难，只要抛开直接计算这个固有观念，先把分摊后的部分累加以后整体算一个税，再减掉之前月收入已经交过的税，是不是就解决了？实际也没增加多少困难 4. 方案 B：36001*10%，不减速算扣除数，用业务语言描述，相当于把年终奖分摊到凭空多出来的 12 个月上，然后进行全额累进 5. 方案 C：36001*10%-210 ，也就是现行方案，用业务语言根本无法描述 6. 方案 D：36001*10%-2520 ，用业务语言描述，相当于把年终奖分摊到凭空多出来的 12 个月上，然后进行全额累进 7. 约定完上述记号后，我们来一起逐条分析你的逻辑，首先，你说方案 D 的问题是“210*12 后导致了实际上相当于分摊到了凭空多出来的 12 个月，偏离了本质（其实就是说离方案 A 更远了）”，但是你发现没，这个问题在方案 BCD 中都同样存在，造成这个问题的根本原因是重新以 0 为起点计算税率，只要选择了以 0 为起点计算，自然就已经造成了这个结果了，和 210 乘不乘 12 根本没关系，也就是说在“偏离本质”这个缺点上，BCD 之间只有量变没有质变，大家都是 50 步笑百步而已 8. 其次，你说方案 C 比方案 B 更优惠，从结果来看确实没错，但是和上面类似，要说优惠的话 BCD 都比 A 要优惠，并且带来优惠的大头贡献仍然是“重新以 0 计算起点”，和这个相比，后面的速算扣除数减多少对于大多数人来说已经无关痛痒了，C 相比 B 带来的仍然只是量变而非质变 9. 所以你的所有逻辑无非就是，C 比 D 更“接近本质”，比 B 更“优惠”，所以 C 是最优的选择，我没有总结错吧？这里就体现出你的一个陷阱了，要寻找一个平衡的方案这点本身没有错，但是应该是在 A 到 D 这个范围中寻找，而不是在 B 到 D 这个范围，碰巧 B 和 D 的公式长得只相差后面的速算扣除数，于是造成了“减去一个介于 210 和 2520 中间的数是一个更合理的方案”这样的假象，并且夸大了方案 C 对于两种优势的贡献程度，成功把部分人带进了沟里，得出了“虽然方案 C 不合理，但是方案 D 更不合理，并且方案 C 比方案 B 更优惠”这样一个很具有迷惑性的结论 10. 而我的观点是，我完全同意应该综合考虑公平性和易操作性，去寻找一个介于 A 和 D 之间的方案，这个目的应该通过制定一组新的区间和税率来完成，而不是去修改公式里的速算扣除数，虽然说从业务出发-2520 似乎离 A 更远，但是从数学角度出发却是“选定了 36000 和 10%”这个前提下的唯一解，你说的“把-210 改成-2520 只会造成更大的不平衡”这个观点看起来好像很有道理，问题是造成这个不平衡的是从数学角度出发支持把-210 改成-2520 的那些人吗？不是，而是选择了 36000 和 10%的那个人，从它选择了这组数那一刻起，就已经决定了后面只可能是-2520 ，你为什么不去抨击选择了 36000 和 10%的人而要反过来抨击指出数学不合理性的人呢，为什么仅仅因为-210 看起来更平衡而宁愿选择放弃数学合理性，而不是去选择真正合理的方案：即调整 36000 和 10%这两个数呢？ 11. 方案 ABD 都值得拿来讨论和对比，因为他们各自都具备明确的业务含义，而方案 C 连参加这场对比的入场资格都不具备，因为他是一个不自洽的，无法用业务语言来描述的畸形方案，你比起直接认为应该无脑改 D 的人来说确实看得远了一步，但也正是这种自信蒙蔽了你的双眼，拒绝去思考方案 C 的天生缺陷，我从头到尾都没有去讨论过 C 和 D 哪个更优的问题，一直都只是在论述为什么 C 不具备成为备选项的资格，包括我举的那个思想实验的例子，也是换一种角度指出滥用量纲不正确的公式会造成多么荒谬的结果，如果你无法理解这个实验和现实情况之间的联系，以及为什么应该-36000 而不是-3000 ，真心建议你好好补习下数学中的抽象思维能力 12. 然后就是最后一个问题，为什么有那么多的人指出-210 应该是原本-2520 的误用，因为这个错误首先太明显，其次里面有太多的巧合，“工作人员充分地思考了各种方案的利弊，为了寻找一个合理的平衡方案，哪怕明知将来要被骂，也要自己默默承担一切，坚持为广大劳动人民谋福利”这种可能性的说服力远远比不上“当初可能根本就没想那么多，本来就是想直接设计出方案 D ，并且懒得再单独给出一组分界点为 36000 ，扣除数为 2520 的表格，而是让实操人员除以 12 后去查 3000 的那个表，结果无意中搞错了 210 的倍数”这种可能性，只不过在被爆出问题后，事后诸葛地发现了“方案 D 同样也不合理”这一理由 |
 |
157
Hozoy 326 天前
竟然没进水深火热🤔
|
|
158
GuuJiang 326 天前 via iPhone
@snw 本来我还觉得你前面说的从业务逻辑角度出发的分析还体现出了你比其他人更理性的一面，别人喷你喷得有点冤，但是从这里的回复看你已经开始逐渐往为杠而杠的方向上发展了，好吧，我继续回应
你要说“速算增添数”不比“速算扣除数”优秀，OK ，我同意，因为这本来就不是这个类比的重点，这个类比是想要说明，无论“速算扣除数”还是“速算增添数”，在计算上都是完全等价的，因为它们分别都是从超额累进的原始定义出发推导出的两种中间结果，这两种中间结果在正确使用的前提下都没有问题，但是一旦忽略了适用条件产生了误用，就会形成完全相反的结果 你说的应该是-3000 而不是-36000 ，这个错误简直比起“-210 还是-2520”那个错误还要离谱，但是好处是足够明显，所以也许可以作为一个很好的切入点来帮你理解-210 到底错在哪里，先叠个甲，接下来我会使用一些需要具备一定的抽象思维能力才能理解的不严谨的设定，如果你理解有困难，请自行去咨询学数学和学物理的朋友，让他们给你解释，如果我们给前面出现过的所有公式里的一些数字添加上量纲，年终奖的数字量纲为“元”，12 的量纲为“月”，那么元除以月得到了“元/月”，“元/月”乘以月得到元，于是你就会发现 36001 这个和 3000 这两个数字的量纲都不一样，而量纲不一样的数字之间根本就不可能执行加减运算，其实原本的那个错误里之所以-210 应该变成-2520 ，根本原因绝不是像你想的那样“一群数学家为了让数字变得好看而强心凑上去的一个值”，而是乘以 12 后把量纲从元/月变成了元，这样才能和元进行加减运算，“速算扣除数”和“速算增添数”的两个例子里，都是减去或者加上了一个量纲不正确的量，而一旦把量纲修正了，二者都能同时得到正确的结果 1800.1 ，这从另一种角度揭示了原本那个错误的本质 |
 |
160
silerLee 325 天前
很多满减不也是这样么.外面 30-5 .你买了 28 了.多两块钱.没觉得有多逆天不影响事物本质啊
|
 |
161
jose13 325 天前
看了以上的讨论，又搜到这篇文章，感觉还是比较靠谱的，各位可以看一下 https://www.shui5.cn/article/f1/51015.html
四、全年一次性奖金征收个人所得税的历程 这个政策是以前奖金合并当月计征个人所得税导致税负过重的打的一个补丁，确实为纳税人减轻了税收负担，扣除一次速算扣除数，主要是控制减税的幅度。 |
 |
162
hahajing2019 324 天前
此贴非常棒，弄明白了很多问题，感谢
|
 |
163
ArianX 324 天前
整个社会计算年终时都因为一个简单的错误而产生多少误解、额外的消耗，而政策制定者却死性不开，真是叹息
|
|
164
snw 324 天前
@GuuJiang
我已经反复解释业务逻辑了，而你压根一点都没理解或者尝试理解。 你说方案 A“也没有那么的困难”、“实际也没增加多少困难”？真是随口就来。你知道 19 年前在实操中这个方案会导致多少麻烦和障碍吗？ 在“年度综合所得”这个改革之前，个税一直是单月计算的。这是什么概念？就是说计算当月个税只需要当月数据就可以确定，不需要其他月份数据，请记住这点。 2005 年那时大部分公司的人事工资数据没数据库，一个月工资表就是一个或几个 Excel 文件（甚至纸质计算表），年终奖可能是另一个 Excel 文件。现在你要分摊奖金到每个月，那么意味着你要给每个人每个月重算一遍个税，要从一堆文件夹里找到打开一堆文件，找出以前每人每月应税收入多少、实缴多少税，然后还要汇总起来（复制值或用 Excel 公式外部链接）；要是想检查一下又得打开这一堆文件。这是增加了 n 倍工作量！而且由于算法不同，还要另做 Excel 公式，但当年就连会计普遍水平都一般，更别提许多企业是人事算工资，计算能力只会更差。 另一方面当年税务局系统也是按单月计算设计，你想取以前月份的数据？不好意思系统不支持，先申请个系统大变更吧，在系统支持之前税务局想核查申报数据都难。 你觉得这些不是大事？那么好，年度奖金不一定在 12 月发，有些企业是年头或年中发，发放当月只有以前几个月的实际数字，请问你怎样分摊计算缴纳奖金个税？你想说先按摊给后面几个月算一次税（即基数为零，税偏低），等后面几个月发工资了再合并重算？那后面几个月的工资表也得一直带着这个分摊数，麻烦事。 你如果觉得还不难，那么好，现在员工跳槽换了家公司，请问下家怎样拿到这人前几个月应税收入和已交个税数据？员工不知道，上家懒得给，税务局也不好查。 等你把这项那项困难都解决了，仔细一看，这不就是现在的“年度综合所得”吗？但你站在 2005 年，你能说先等你花 15 年把一切准备妥当了再出政策吗？ 接下去，你对方案 B,C,D 的业务语言描述完全就是错的。 方案 B 的业务描述是：把年终奖分摊到*实际*的 12 个月，与月度工资合在一起适用差额累进。但由于方案 A 实操困难，所以做了假设和简化，例如假设年终奖除以 12 适用的税率与月度工资达到的边际税率基本相仿或更低，例如由于不知道工资边际税率那档还剩多少才达到下一档所以后面就不再累进，最终结果就是按照年终奖除以 12 查到适用税率计算。 方案 C 的业务描述是：在方案 B 的基础上再适当减一个不大的数。虽然看起来不如方案 B ，但至少大致保留了方案 B 的逻辑，并且实操中公式形式与月度收入个税一致，也不需要多一个查询表。 方案 D 的业务描述是：把年终奖分摊到*凭空多出*的 12 个月，从零开始使用差额累进。这完全就是另一套错误的业务逻辑，是最没资格参与对比的！ 如果你稍有税务实践经验就知道，凭空给从零基累进是非常大的优惠，根本不是你以为的减除数多一点而已。你还不明白的话，你看看你自己的例子： * 方案 B 税款 3600.1 元。 * 方案 C 税款 3390.1 元，比方案 B 少 6%。 * 方案 D 税款 1080.1 元，比方案 B 少 70%！ 另外你就别瞎扯量纲概念了，量纲分析适用于大部分理工学科，但这里讨论的是经管学科明白吗？这里的公式是人为定义出来的，公式中的数字就是纯数字，压根不鸟量纲明白吗？ 比方说签一份合同，合同中规定如果逾期违约，那么违约金 = 拖欠金额*(拖欠月数)^0.5 ，你难道跳出来说"不对，这公式左边单位是元、右边单位是 元·月^0.5 ，量纲不对所以显然是错的” ？？？ P.S.，“月”是单位，不是量纲，谢谢。 |
|
165
GuuJiang 324 天前 via iPhone 1
@snw 醉了，没想到你的理解能力低下到这种程度，反正这个帖子肯定也已经沉了，就不要在这里继续浪费公共空间了，如果你还想要继续讨论，就去知乎上开个提问，让更多各行各业的人都参与进来，只想友情提醒你一句，V 站一般情况下无法删帖，希望你若干年后回想起来不要后悔在这里留下的黑历史，最后回复一条，此后不会再在这个帖子里回复，大过年的，你自便
你一直扯业务逻辑业务逻辑，什么叫做业务逻辑，以月收入为例“月收入实行超额累进制，3000 以下税率为 5%，3000 至 12000 部分税率为 10%”，这就叫业逻辑，并且白纸黑字地写在了法律条文里，有了这个业务逻辑，在使用速算扣除数计算时，这个速算扣除数就只能是 210 ，不可能是其它任何一个值，否则就违背了前面的业务逻辑，所以 210 不是人为定的！不是人为定的！不是人为定的！是根据“月收入实行超额累进制，3000 以下税率为 5%，3000 至 12000 部分税率为 10%”这个业务逻辑推导出来的，这点都理解不了还讨论个屁的业务逻辑，要是月收入那里敢以任何的理由在 5%、3000 和 10%这几个数字不变的前提下把 210 改动任意一点，你猜会不会被喷出翔，年终奖那里吃亏就吃亏在没有把“超额累进”这四个字明确写出来，所以给你们这种人留下了一点诡辩的空间 至于方案 B ，只要是只以年终奖除以 12 的结果去月收入表里查税率，那就跟方案 D 一样都是分摊到额外的 12 个月，这点都理解不了，确实没有任何讨论的必要了，祝大家春节快乐 |
|
166
snw 324 天前
@GuuJiang
你的话就原封不动地送还给你： 没想到你的理解能力低下到这种程度，就不要在这里继续浪费公共空间了。 友情提醒你一句，V 站一般情况下无法删帖，希望你若干年后回想起来不要后悔在这里留下的黑历史。 你一大堆废话我都不厌其烦地看完，耐心地逐一给你指出你错在哪里，给你解释什么叫业务逻辑，你倒是连看都不看，自始至终只是复读自己的错误认知。 带你到这个程度你都理解不了，确实没有任何讨论的必要了，祝你春节快乐算了 |
 |
167
whirlp00l 324 天前
其实对比一下类似的股权激励单独计税规定。。。那个里面是没有问题的 是直接把 RSU 和期权类的收入单开了一个池子来做分段：
七、[条款废止] 员工以在一个公历月份中取得的股票期权形式工资薪金所得为一次。员工在一个纳税年度中多次取得股票期权形式工资薪金所得的，其在该纳税年度内首次取得股票期权形式的工资薪金所得应按财税[2005]35 号文件第四条第(一)项规定的公式计算应纳税款;本年度内以后每次取得股票期权形式的工资薪金所得，应按以下公式计算应纳税款： 应纳税款=(本纳税年度内取得的股票期权形式工资薪金所得累计应纳税所得额÷规定月份数×适用税率-速算扣除数)×规定月份数-本纳税年度内股票期权形式的工资薪金所得累计已纳税款 上款公式中的本纳税年度内取得的股票期权形式工资薪金所得累计应纳税所得额，包括本次及本次以前各次取得的股票期权形式工资薪金所得应纳税所得额;上款公式中的规定月份数，是指员工取得来源于中国境内的股票期权形式工资薪金所得的境内工作期间月份数，长于 12 个月的，按 12 个月计算;上款公式中的适用税率和速算扣除数，以本纳税年度内取得的股票期权形式工资薪金所得累计应纳税所得额除以规定月份数后的商数，对照《国家税务总局关于印发〈征收个人所得税若干问题的规定〉的通知》(国税发[1994]89 号)所附税率表确定;上款公式中的本纳税年度内股票期权形式的工资薪金所得累计已纳税款，不含本次股票期权形式的工资薪金所得应纳税款。 八、[条款废止] 员工多次取得或者一次取得多项来源于中国境内的股票期权形式工资薪金所得，而且各次或各项股票期权形式工资薪金所得的境内工作期间月份数不相同的，以境内工作期间月份数的加权平均数为财税[2005]35 号文件第四条第(一)项规定公式和本通知第七条规定公式中的规定月份数，但最长不超过 12 个月，计算公式如下： 而为什么年终奖的计算公式里面速算扣除数没有乘以 12 ，明显是税务局既要想多收税，又想弄个减税的名声，就捣鼓出这么个四不像。毕竟给这个优惠之前，你如果 3 万 6 年终奖是直接落到 30%税率的档的。 |
|
168
snw 323 天前 via Android
@whirlp00l
如果只看公式就容易陷入困惑迷茫。股权激励与全年一次性奖金的业务实质有一些区别。 全年一次性奖金基本上只是对于当年工作的奖励，所以摊在当年月度工资上是合适的。而且年度奖金金额与当年的月度工资一般是相称的，所以要实现“在实际月度工资边际税率上累进”时使用奖金/12 查表作为近似税率一般只低不高。 股权激励实质则是对于过去若干年的工作奖励，如果要摊的话照理应该摊到整个限制期间，短则 12 个月、长则 60 个月，差别较大。同时由于跨越时间较长，且行权方式不同（一次性、多次），难以用本次行权所得去估计被摊月份的边际税率。所以套用全年一次性奖金的思路不太行，才改用“分摊到凭空多出来的月份，但不超过 12 个月”这种妥协的设计。 顺带一提，现在个税改革为年度综合所得，其实只解决了月与月之间收入分布不均匀（比如全年一次性奖金），但并不能解决年与年之间收入分布不均匀（比如股权激励，比如离职一次性补偿）。再拓展一下，即使解决了时间分布不均匀，总还有其他维度的问题，例如家庭成员之间收入不均匀（比如一方高收入、另一方无收入），这些都是要不断改进的。 |
Select Language