今天才知道年终奖一次性计税的惊天 bug

[unt]

36100 拿到手比 36000 少，请问大家真的是这样吗，上小学时的一道数学题成了现实了。

[bailliesun]

其实可以合理避税，挪一部分到工资里

[abc500]

最近那个单人中奖 1000 注头等奖 具体多少忘记了还没教会你吗 千万税变成 20 万

[unt]

@bailliesun 我知道，我避了，只不过今天才知道，我一直以为一次性也是按梯度算

[ZRS]

一个比较 sb 的速算扣除数的问题，只要速算扣除数乘以 12 就可以了，死撑着不改才有了现在这个 Bug

[deanguqiang]

我知道这个 bug 后开始相信“世界是一个草台班子”这句话

[Akagi201]

有趣, 其实同理可以应用到很多事情上面. 权威不一定就是对的.

[salor]

这个应该由公司的 HR 负责来规避，以前给 9 档的税率表写过规则用来在算工资时提醒这个问题。

[unt]

@salor 嗯，我们 HR 对超过档位的人一个个打电话通知商量的，人还怪好的

[c5QzzesMys8FudxI]

没理解。。。

[unt]

@4rat 年终 36001 ，到手 32610 。年终 36000 ，到手 34920 。离谱不

[mschultz]

@ZRS #4 我没理解错的话，现在情况就是

「一个全国范围的政策，其计算某个关键数值时，并非按照汉字字面定义，而是全国规定统一使用一个推导出来的快速口算算法；而这个算法中用到的常数参数，从小学数学意义上讲跟本就推导错了」？

离谱

[FlytoSirius]

目前的税务制度 "发展中" 的离谱 ... 本应该是一个年度整体统计, 多退少补的过程, 但由于社会中"黑灰资金"比例太大, 与其多退少补, 不如有一笔扣一笔来的"简单粗暴又直接".

但是当然, 这套税务制度也不是多么的"税务", 本身也不是建立在 "义务"与"权力"之上的, 所以只会让人觉着自己失去了一部分资产, 却又没换来什么"权力", 所以有种相当的"损失"感.

[littlecreek]

哈哈哈太荒谬了，这么多律师会计师各种大佬小佬们，就没人对此提出异议吗？就这么逆来顺受这么多年……

[rainbowmolly]

@littlecreek 据我所知是最近几年才特意改成这样的，并没有很多年

[GuuJiang]

本质原因参见我在 https://v2ex.com/t/856447#reply18 里的回答，其实类似这样的例子在生活中并不少见，比如上学时背的各种口诀、编程里的 async/await 语法、do notation 等等，都相当于一种降低学习和记忆成本的二级结论，但是如果跳过本质而直接记二级结论，一旦超出了适用范围就抓瞎了，从而闹出这样的笑话

[ladypxy]

这就是税务耍流氓，被人吐槽了无数年，就是死活不改

[zenfsharp]

年终的奖励可以平摊到 12 个月中计算个税.

[godloveplay]

两种方式：

单独计算法：居民个人取得全年一次性奖金，可以选择不并入当年综合所得，以全年一次性奖金收入除以 12 个月得到的数额，按照按月换算后的综合所得税率表，
确定适用税率和速算扣除数，单独计算纳税。计算公式为：应纳税额＝全年一次性奖金收入×适用税率－速算扣除数 12 。

并入综合所得计算法：居民个人取得全年一次性奖金，也可以选择并入当年综合所得计算纳税 12 。

需要注意的是，由于税率是阶梯式的，因此在某些临界点，如果年终奖金额稍有增加，可能会导致实际到手的金额反而减少 14 。
例如，年终奖为 3.6 万元时，如果多发 1 元，也就是发放 36001 元年终奖，个税需要缴纳 36001×10%-210=3390.1 元，到手 32610.9 元。相比之下，多发 1 元年终奖，到手收入反而少了 2309.1 元 1 。

[godloveplay]

@unt #10 年终奖如果是 36001 ，单独纳税税率阶梯变高了。 这种情况，拆成 12 个月 会少纳税一些吗？

[0TSH60F7J2rVkg8t]

有没有可能，它这样设计就是这个目的啊？人家是收税的人，它要考虑的是，它收到的税多不多，而不是你缴的税合不合理。

[unt]

@godloveplay 应该是也要看你平时的薪资的，如果平时薪资也高，那这钱算到全年里也会全部按 20%计算甚至 25%

[bkmi]

这种计税方式还能实施，想想都难受，都是什么样的人在推。

[hefish]

你们财务在故意误导吧。 按照税务局的公式来计算，好像不是 OP 说的那么回事。

[opengps]

有没有可能公司为了多交税？？？

[unt]

@hefish 你可以搜一搜或者以你自己的为例

[unt]

@opengps 如果公司为了多交税为什么又主动协助我们避税呢

[julyclyde]

@opengps 公司犯不着多缴税啊
尤其是并非在公司名下而是员工名下的税

[xmumiffy]

用一句老话：不是 bug 是 feature 。

[StephenHe]

看了下个税 app ，年终加 1 月份工资分了两次扣税，36000 扣一部分，另扣一部分。想问下综合年度汇算的时候，还重新计算不。

[bkmi]

@hefish 难以置信吧，但是这是真的

[ETiV]

@ahhui
> 它要考虑的是，它收到的税多不多，而不是你缴的税合不合理。

换我肯定 120% 的税率，疯狂榨取人矿😂

[snw]

@rainbowmolly
法律依据是国税发〔 2005 〕 9 号 ，已经实行 19 年了

[awsx]

@unt 这个还能个人操作去避吗？

[NoOneNoBody]

记得当年足球甲级联赛转超级联赛时，还出现过“输球才能晋级”的事
不是打假球啊，就是分数计算的 BUG ，当年足协为了平衡各方利益，不是按名次而是另外定了一套计分标准，结果最后一轮出现这样的状况（输了不一定就能晋级，但胜了铁定降级）
这事被球迷当笑料笑了好多年

其实，很容易理解，就是权重是否合理的问题，程序员也常遇到权重系数没定好，导致计算结果不合理的情况。只不过权重系数是可以改的，俗语叫“调参”，现实中的一些规则没有测试和模拟就实行了，就变成 BUG 了

[iVeego]

税务黑洞，可以合法规避的

[alfchin]

@hefish 这是财税界公认的 bug 。。。

[matolv]

现在个税都是按年算，根本不可能出现楼主的问题，所以问出这种问题只能是小学数学不及格。退一步说，即便算错了，也有年度退税/补税可以办理，一切有法可依。

政策：国家税务总局公告 2024 年第 2 号 https://guangdong.chinatax.gov.cn/gdsw/zjfg/2024-02/02/content_ae1d585f72b747db91063d00ecfa4965.shtml

税率表： https://guangdong.chinatax.gov.cn/gdsw/zjfg/2024-02/02/ae1d585f72b747db91063d00ecfa4965/files/15504c33c3bd4235bb86246c5c5a4f95.pdf

[snw]

我来解释一下背景吧。

很久以前大部分人拿固定工资的时候，按月计发工资、按月计缴个税很合理也很容易。速算扣除表在大部分人事和会计手动算账的年代是自然而然的产物，老会计很熟悉这个表。
后来一些企业开始搞绩效制度，年终奖金额比例很高，如果按以前那样在当月计缴个税，就会导致当月个税非常高，所以个税制度跟不上社会发展需求了。

为了缓解这种矛盾，税务局研究后出了一个红头文件给“全年一次性奖金”单独搞个暂时性的优惠算法，思路是把奖金摊到 12 个月。如果完全按照这思路，应该把奖金平摊到 12 个月加到月度工资上，即适用月度工资的边际税率（超出档次部分还要上更高的税率），压根不该减速算扣除数。但这样实操太麻烦了，所以税务局才选了个容易理解和操作的简易算法（老人事和老会计很熟悉），而这个简易算法在正常情况下都是优惠的
——是的你没看错，哪怕在踩坑情况下都是*优惠*的，请尤其注意这一点！

楼上有些人拍脑袋说什么把速算扣除数乘以 12 云云，压根没理解该算法的本质。
如果要简单粗暴地修正 bug ，那么应该直接不扣速算扣除数才对。之所以宁可造成 bug 也要给个速算扣除数，无非是考虑到有少数人年终奖比例畸高，除以 12 的税率档次仍高于月度收入的边际税率，所以象征性地减个速算扣除数平衡一下。
至于更复杂的算法，请考虑到 2005 年时全国税务数据还没打通，人事财务电算化水平也不高（不少是手工计算，就连 Excel 2003 单元格公式也有 1024 个字符限制），复杂算法实操不可行。

现在个税改成年度综合收入纳税之后，理论上“全年一次性奖金”单独处理的理由已经不复存在了，现在无非是经济不好，所以打折“延续”的名头行税收优惠之实罢了。等哪天经济好了，这个优惠就该取消了。

最后再说一句，不要质疑国税总局在制定税收政策的专业程度，尤其是设计计算方法和权衡实操方面，至少不会比 V2EX 上任何程序员弱鸡。

[snw]

@snw
再补充一下，除了全年一次性奖金收入单独计税，还有股权激励、离职补偿也都是单独计税。原因是类似的：缓解一次性收入面临当月计税适用过高税率的问题。解决思路也是类似的：把一次性收入视同在一段期间均匀取得来计税。

[snw]

@matolv
你是只知其一不知其二。全年一次性奖金特殊计税方法这几年一直在延续，所以仍然有这个问题。

《财政部 税务总局关于延续实施全年一次性奖金个人所得税政策的公告》
财政部 税务总局公告 2023 年第 30 号
https://www.chinatax.gov.cn/chinatax/n363/c5171841/content.html

[zhongjun96]

@snw #38
V 站和知乎都变味了，之前都会去查条文，验真伪，现在上来就是喷，很少见到人会去查文档了。

[snw]

@alfchin
财税界真正理解前因后果的人不会认为这是 bug ，只有为流量哗众取宠或对财税一知半解的人才会管这叫 bug 。

@ZRS
速算扣除乘以 12 是不理解本质、只会拍脑袋的补丁，哪怕把速算扣除数去掉都比乘以 12 合理。

@mschultz @GuuJiang @ladypxy
数学意义上是不对的，结果也不是最好的，但税收理论的正确性与税收实践的可操作性权衡下来，这套近似算法是最恰当的，至少比 v2er 能想出的算法要好。

[GuuJiang]

@snw 你才是没有理解本质，月薪之所以有“速算扣除数”的存在，是为了简化分段函数的计算，换句话说税率的分段函数才是本体，“速算扣除数”是在计算这个分段函数的过程中产生的一个中间值，脱离了原本的分段函数，这个速算扣除数将变得毫无意义，而在计算年终奖时机械地减去这个速算扣除数，就跟把质量和温度相加一样荒谬，实际上如果先把年终奖也定义成一个没有间断点的分段函数，然后再推导出一个新的“速算扣除数”，那么这个速算扣除数将会正好是原来那个*12 ，这样的速算扣除数才是有意义的，学数学和物理的人都很容易现在这个计算方法的荒谬之处，荒谬程度就相当于一个连量纲都对不上的物理公式，其实这个政策刚推出之时就收到了很多反对的声音，并且也都指出了这个错误产生的根源，只不过因为某些大家都懂的原因不予修正，同时还提出了所谓的优惠之类的理由来进行找补，但是这些都改变不了“把一个公式的中间结论无脑套用到另一个不适用的公式上是错误的”这一事实

[cmdOptionKana]

> 这个政策刚推出之时就收到了很多反对的声音，并且也都指出了这个错误产生的根源

如果有消息来源就更好了，因为 V 站的大家可能平时对财务了解不多，未必了解背景，很难判断你说的是否真实。

> 因为某些大家都懂的原因不予修正，同时还提出了所谓的优惠之类的理由来进行找补

同样因为 V 站的大家可能平时对财务了解不多，“大家都懂的原因”还是说一说比较好，不然就变成了懂的都懂，不懂的还是不懂。

------------

也就是说，你这段话，每到关键的地方就跳过了，几乎等于直接给出结论，关键的支撑证据全是缺失的。

[xmumiffy]

@snw "即适用月度工资的边际税率（超出档次部分还要上更高的税率），压根不该减速算扣除数。"
你这说的是全额累进税率,然而国税发〔 2005 〕 9 号表明了年终奖并不是全额累进税率.

1993 年的中华人民共和国个人所得税法就已经有"超额累进税率"的说法了,也就意味着 国税发〔 2005 〕 9 号 不写年终奖适用于 "超额累进税率" 或 "全额累进税率" 并不是这些名词还没发明出来.国税发〔 2005 〕 9 号特别地描述了计算方式,意味着这种计算方式就是特意制造的,不是全额累进税率,也不是差额累进税率.
也就是 不是 bug 是 feature 。

不过争议点在于"速算扣除数"这个名词本身应该代表了这个数字应该是用于速算而不是特意制造的税额差距.

[snw]

@xmumiffy
你要理解全年一次性奖金本质并不是多一个月奖金，而是均摊到每个月的收入上再继续累进计算，所以我会提到边际税率。
严格来说当然应该继续超额累进，但稍微想一下就知道，只要一次性奖金不超过约 12 个月收入，那么按除以 12 之后的金额查找适用税率几乎总是比从月收入边际税率开始继续超额累进计税要优惠的。

速算扣除当然只是为了速算的产物。由于在以上这种“继续超额累进”的场景下不会带来便利，所以对于全年一次性奖金算法仅仅是平衡利益做的人为规定罢了。

[snw]

@GuuJiang
我上面已经详细解释了全年一次性奖金特殊计税方法的本质背景了，你还在纠结如何设计这个函数形状。。。

本质上全年一次性奖金就应该平摊到每个月，然后在每月工资达到的边际税率基础上继续超额累进，如果这么做的话不仅没有速算扣除数，超档之后还要再增加。理解这点的话，就会明白“速算扣除数×12”这个补丁多荒谬。
现在这种简化算法只要年终奖不超过约 12 个月工资，基本上都比以上这种严格算法要优惠，所谓的函数不连续无非是某些区间少掉优惠罢了。

[GuuJiang]

@snw 说白了，对任意一个由多条线段首尾相接的分段函数，都能设计出一组“速算扣除数”，是先有的分段函数，才有的速算扣除数，并且速算扣除数的取值由原始函数每一段的斜率决定，脱离了“计算原始函数的值”这个上下文，“减去速算扣除数”这个操作将毫无意义
整件事其实很简单，就是当初制定这个政策的工作人员要么没有理解“减去速算扣除数”这个操作的本质，要么就是一时疏忽，导致得出了现在这个畸形的公式，并且在审核阶段也没被发现，导致了政策被正式发出来，而一旦发出来，再修改就必然会面临之前的错误被暴露，以及权威受损等困境，所以才先射箭再画靶地提出了各种理由来往回圆，说直白点就是继续死扛呗
其实这些小心思作为成年人也都能理解，所以无非也就是苦笑一声接受而已，但是以“难道你比制定政策的人还懂”、“哗众取宠”等理由来嘲讽指出这个显而易见的数学错误的人，那简直就是对大家所受的基础教育的侮辱了

[snw]

@snw 更正：...一次性奖金不超过约 12 个月应纳税所得额...

[wonderfulcxm]

是这样的，如果以打工人税后所得为标准，减少中间商赚差价。公司可以少发钱，打工人到手反而多了。

[snw]

@GuuJiang
为什么要放一个速算扣除数，我上面也解释过了，这是实操上的考虑（符合习惯以及平衡利益）。
脱离现实背景，强行定性为“显而易见的数学错误”，这当然就是哗众取宠。

[alfchin]

@matolv 全年一次性奖金税收优惠是沿用了原来的月度计算方法和逻辑。但凡考过会计师或者税务师的税法都知道有这个问题。

[devfeng]

是的，所以有的公司年终奖支持现金+期权组合方式供员工选择

[mschultz]

@snw #38 这几段，个人感觉好像也没解释「算法的本质」啊。

赞同大部分描述事实的内容（比如全年一次性奖金单独计税对一些人（尤其收入超过基本免税额度的人）而言是一种优惠；这是一种临时性政策；未来可能不再有这种选项，全部按新税法纳入综合所得）。

====
但如果试图接受你的解释，我仍有几点不能理解：


1. 首先按照你的解释，这里的所谓「速算扣除数」是「象征性地」「为了平衡」给出的，并没有严格数学意义。至少，它和个人全年综合所得税率表里面的那个「速算扣除数」（这个我是理解其数学意义的）还不一样。那么首先两个不一样的概念用同一个名字就有误导人之嫌。
2. 「宁可造成 bug 也要给个速算扣除数」—— 如果这个「 bug 」指的是税后奖金的跳变的话，那么「扣除数」并不是造成 bug 的原因。显然，如果不考虑扣除数，算法其他部分不变，即 36000 全额按 3% 计税，36001 全额按 10%，本身就有这个「跳变 bug 」。
3. 你的帖子没有说为什么选择了 210 、1410 、2660…… 这些数学上难以解释的值。只能解释为「税务系统里的专家拍脑袋」么？
4. 总体感觉 #38 之贴文，除了强调「历史/平衡/权衡/专业/不要质疑」等词汇之外，并未提供*具体*、专业而有说服力的解释，或给出参考文献/链接。

====
最后，既然你说（#42 ）对财税一知半解/哗众取宠的人才会认为这是 bug ，我们在此引用一篇《上海注册会计师》杂志文章，说明财税界的人也难以解释这个问题：《年终奖发放中的无效纳税区间陷阱及其成因——兼议国税发[2005]9 号文》 https://www.shcpa.org.cn/journal/getJournalView.do?aid=755

> ... 由此可见，无效纳税区间的产生是国税发[2005]9 号的起草者在制度设计时的重大疏漏，简单地把按月计征工资的简便运算所用的速算扣除数用到了已经扩大了 12 倍的年终奖的计算上去了。笔者建议，国家税务总局应尽快修改全年一次性奖金等计算征收个人所得税方法，以实现国家、个人的双赢。
> ...
> 如果国家税务总局同意无效纳税区间的出现，是税收制度设计上的一个疏漏，适时修改全年一次性奖金等计算征收个人所得税方法是恰当的。
> 但是，修订任何制度政府机关都有一个全局的考虑和必要的流程。作为纳税义务人，只能按照现行的法律法规缴纳税金。如果继续按照国税发[2005]9 号计征 2011 年度年终奖的个人所得税，在选择年终奖筹划时，应尽量选无效纳税区间的下限作为年终奖最佳金额...

[PrinceofInj]

没有任何 bug ，有的只是人性化。首先你需要知道个税的累进税率是怎么来的，还有需要知道 17 年之后是按整年计算个税的，同样工资，越到年底缴纳的个税越高。如果不进行平摊的话，发一大笔年终奖，很容易一下子税率提高到一个很高的档位上，以 V 站各位的平均工资，发年终奖后扣 20%不算什么难事，但这显然不符合过年的气氛，为了个人心理感受，单独给年终开了个口子，允许你少交税。

[ajyz]

有些东西看似荒唐，无非利益在制定方，要是这么个 bug ，最终导致少收了，你看它不调整。

[body007]

你现在知道有些企业为啥要慈善捐款了吧，捐了部分，最终到手比不捐多，还提高了公众形象。

[Goooooos]

等过几年取消年终奖单独计税，才该肉疼

[paopjian]

一点年终奖不发的,才知道有很多人有几万甚至十几万的年终奖

[XueRainey]

如果我没算错的话

36000 的个税：36000 * 0.03 = 1080 到手 34920
36001 的个税：36001 * 0.1 - 2520 = 1080.1 到手 34920.9

[mschultz]

根据原帖内容，我相信 OP 发此贴的重点是讨论「全年一次性奖金单独计税」算法*本身*的反直觉之处，而不是将「单独计税」政策与「纳入综合所得计税」或者其他老税法*作比较*来看看谁优惠。

====

而这个贴里试图为该算法辩解的回复，包括 @snw #38, @PrinceofInj #55 等， 都花费了很多篇幅解释「这个一次性奖金单独计税算法不管怎么说它还算是优惠、人性化，以前/以后按其他算法你们就交更多税、更肉痛了」云云，但都回避了「算法本身为什么那么诡异」的问题。

照理说，任何一个确定的个税算法，最符合所有人直觉的情况应该是「税前越多，税后越多」，即 f(x) 是一个*连续单调增*函数，x 为税前收入，f(x) 为税后收入。这样一个符合直觉的函数，只要结合「一次性奖金单独计税」这个原则，按数学原理算出速算扣除数，制成税率表，同样也符合 @snw #38, @PrinceofInj #55 说的那些优惠啊人性化啊容易理解易操作云云。

但现在政策设计者偏偏要把这个函数搞成一个更奇怪的、不连续的锯齿状函数，如果你的税前收入落在一些（具体是 6 个）区间内时，税后收入还不如「税前收入更低一些」的人。为什么要设计成这样？与连续增函数相比，一定要设计成锯齿状的合理性在哪里？本贴里似乎没有人正面解释这个问题。

实际上你如果去网上搜索，也很难搜到对这个算法合理性的解释，你能搜到的几乎全部都是教你（和公司 HR ）发年终奖时怎么规避这些无效区间的。一个全国通用的个税算法，网上搜不到解释其原理的文章，全是教你怎么避坑的文章，这本身不就能说明一些问题吗。

根据目前我能看到的信息（包括网上搜索及本帖内回复），我还是只能认为这种奇怪的算法能出现，要么是政策制定者故意设计的陷阱，想对数学不好的公司多收点儿税；要么是政策制定者本身数学不好。

好奇是否有更具说服力的解释。

[mschultz]

@XueRainey #60 你去搜一下年终奖单独计税时的税率表，它是用"**全年**的税前收入" x "本级税率" - "**一个月**的速算扣除数"

也就是 36001 的年终奖，缴税 36001 * 0.1 - 210 = 3390.1. 扣除的是 210 不是 2520. 大家说年终奖单独计税税率表 SB 就 SB 在这一点。

2520 是全年综合「应纳税所得额」计算个税用的税率表中的扣除数，那个在数学上是没问题的。

[jose13]

查了下政策文件确实是啊。
财政部 税务总局关于延续实施全年一次性奖金个人所得税政策的公告（财政部 税务总局公告 2023 年第 30 号）
不并入当年综合所得，以全年一次性奖金收入除以 12 个月得到的数额，按照本公告所附按月换算后的综合所得税率表，确定适用税率和速算扣除数，单独计算纳税。计算公式为：应纳税额＝全年一次性奖金收入×适用税率－速算扣除数
36000 的个税：36000 * 0.03 = 1080 到手 34920
36001 的个税：36001 * 0.1 - 210 = 3390.1 到手 32610.9

[GuuJiang]

@snw 你自己真正地去亲手推导一遍速算扣除数的来源再来讨论“本质”，现实生活中这种阶梯计费的例子并不少见，比如水费、电费等，只要是阶梯计费，都能相应地推导出各自的一组“速算扣除数”，速算扣除数的值不是拍脑袋想出来的，其真正的含义是当前分段之前的所有完整分段的累加值，因为这部分已经可以视为常数了，所以可以把相乘并求和的结果保存起来，省去了重复计算，是典型的空间换时间的基本操作，所以“减去速算扣除数”不是本质，分段求和才是本质，速算扣除数只是一个中间结果，难道能在计算电费时减去水费的速算扣除数吗？
把月薪的速算扣除数无脑地挪用到年终奖的计算上来，就破坏了“速算扣除数等于前面所有完整分段的累加值”这一根本条件，所以导致了这样一个牛头不对马嘴的结果

[PrinceofInj]

@mschultz 因为多发一块钱到手更少实际上是不存在的。因为看的是全年的。这个说法是一些不懂计算方式的人瞎起哄。换句话说，多发一块钱，导致税率升级了，只会对多出来的一块钱缴纳更高的税率，而不会把所有之前的按更高的税率计算。

[nothingistrue]

@PrinceofInj #54 仔细看看你上面两楼的。你年纪越大越会发现指定规则的人并不一定都是学习好的。

[mcluyu]

@jose13 越看越糊涂了呢，我看了 10%税率的速算扣除数不是 2520 吗？

36000 * 0.03 - 0 = 1080
36001 * 0.1 - 2520 = 1080.1

单独计税时实际税额不会相差太多的啊

[mschultz]

@PrinceofInj #65 对，一般人都觉得「多发一块钱，导致税率升级了，只会对多出来的一块钱缴纳更高的税率」才是合理的，你这么觉得，我也这么觉得。

所以当我、楼主、还有这个帖子里很多人发现，现实中的政策居然真的会导致「多发一块钱到手更少」的时候，我们很震惊，觉得很离谱。

但你似乎没发现这种情况在现实中真的存在。如果你觉得这个说法只是一些不懂计算方式的人瞎起哄，那么：

1. https://www.shcpa.org.cn/journal/getJournalView.do?aid=755 《上海注册会计师》期刊文章 - 《年终奖发放中的无效纳税区间陷阱及其成因——兼议国税发[2005]9 号文》
2. https://cwb.hzau.edu.cn/info/1090/4336.htm 华中农业大学财务与资产管理部《关于做好年终绩效分配的通知》
3. https://cwc.xtu.edu.cn/info/1025/1395.htm 湘潭大学计划财务处《关于 2021 年全年一次性奖金个税扣缴有关事项的说明》
4. https://cwc.czu.cn/2021/0120/c4943a120440/page.htm 常州工学院计划财务处《关于全年一次性奖金计税的说明》
等等

都提到了这个无效区间，多发一块钱导致到手更少的问题，这些会计师杂志、大学机构财务处，他们都是瞎起哄吗？

[ddkk1112]

没有年终奖就没这个烦恼了，哦耶

[Greenm]

我们叫这部分叫做税务黑洞，大公司会有人专门计算这个，帮你算出最优发放的方法，部分奖金并入月工资发放。

楼上还有很多人不了解这个概念，说明税务黑洞真的吃了不少钱。

[mschultz]

@PrinceofInj #65 大家吐槽的这个一次性奖金计税算法，其离谱之处正在于你说的「会把所有之前的按更高的税率计算」。

本来，正确的「速算扣除数」可以把多算的税额减掉。但是一次性奖金的计算规则中，不知道谁规定的，一年的奖金计算中，只能减一个月的速算扣除数（你问我为啥我也不理解啊），纳税额扣除得少了，无法抵消税率整体升级的影响，就导致了「多发一块钱到手更少」的情况。

再补充一条参考资料：
5. https://cwc.xtu.edu.cn/info/1025/1263.htm 湘潭大学计划财务处 2018 年的通知，其引用的附件 1 明确提到了「多发一元 多交上千税钱」

[xmumiffy]

@mschultz #61 如果这个税制定之初就想着没有陷阱,按照正常的写法,直接写适用 x%至 xx%的超额累进税率就行了,而不用写这么一大段计算方法.
写明算法,就意味着制定这个税时就没把它当正常的超额累进税率,这个陷阱就是故意留下的.

[alfchin]

@mcluyu 你计算都错了。先除以 12 确定税率和月速算扣除数，再全额计算。

[xmumiffy]

至于解释,其实有的,就是
" 之所以采取上述计算方法，主要是考虑在不违背税法按月征税和便于计算以及利于征管原则的前提下，结合企业薪酬发放的实际，通过降低适用税率，适当减轻纳税人的税收负担，而不是将奖金分摊到全年计算纳税。"
https://shanghai.chinatax.gov.cn/zcfw/zcjd/200912/t291161.html
翻译:已经给你们优惠了,哪来这么多问题,不服你就按单月收入交.

[newaccount]

一个正常公司的正常财务，都会帮你把这个东西算好然后告诉你怎么合理规避的

[PrinceofInj]

@mschultz 看上去的确是我理解的问题。我翻了一下税务的那个文件，税率栏是按照常规的来的，但是还是跟按月一样有速算扣除数，查了一下刚报的税（我们 12 月底就发了），似乎的确是总额×税率-扣除数来的。这么算本身没问题，但是这个速算扣除数有点奇怪，没有发现这个扣除数是怎么来的，我能想到的就是这个扣除数算错了。

[rrfeng]

@snw
「为了缓解这种矛盾，税务局研究后出了一个红头文件给“全年一次性奖金”单独搞个暂时性的优惠算法，思路是把奖金摊到 12 个月。如果完全按照这思路，应该把奖金平摊到 12 个月加到月度工资上，即适用月度工资的边际税率（超出档次部分还要上更高的税率），压根不该减速算扣除数。但这样实操太麻烦了，所以税务局才选了个容易理解和操作的简易算法（老人事和老会计很熟悉），而这个简易算法在正常情况下都是优惠的
——是的你没看错，哪怕在踩坑情况下都是*优惠*的，请尤其注意这一点！」


我给你优惠，但是你要跟我学算 1+1 = 3 才行。
这里讨论重点是「优惠」吗？？？给「优惠」加粗就能掩盖错误了？？？

[PrinceofInj]

@mschultz 之前我看过这张表，因为也是跟标准工资是类似的，我想当然的认为也是没问题的，没想到扣除数有问题。其实各个扣除数是为了以前手工计算的方便，现在计算机时代完全可以一个函数完成了。有点像我们工作中遇到的，明明有了更先进的方式，但是为了跟旧的工作习惯保持一致或者不想更改操作文件，还在新的平台上沿用旧的办法。

[nothingistrue]

@xmumiffy #63 要搞「嗟，来食」吗。先来考考你，年终奖单独计算是哪里优惠。来看看你是真赵还是精赵。

[mschultz]

@PrinceofInj #76

这个扣除数是按月来的，比如说你年终奖 37200 ， 分摊到每月 3100 ，落入 3000-12000 档，速算扣除数 210 ，那么你「每月分摊的奖金应纳税额」是 3100 x 10% - 210 = 100 元，因此每月分摊到到手奖金 3000 元。再换算回一年，到手奖金 3000 x 12 = 36000 ，共计缴税 1200 元。一切看上去都没问题，是吧？

好，现在离谱的来了，「国家文件规定」你不能像上面那样算，而是要像下面这样算：

假设你年终奖还是 37200 ，首先分摊到每月 3100 ，查表，落入 3000-12000 档，按 10%税率，速算扣除数 210 。然后，你必须用「全年」的奖金 37200 去乘税率，再减去「一个月」的速算扣除数 210 ，即应缴税 37200 x 10% - 210 = 3510 元，到手 37200 - 3510 = 33690 元。

这个陷阱不算高明，数学上的错误也显而易见，但它还是普遍施行了，我只能说挺有意思的。

[xmumiffy]

@nothingistrue 觉得不优惠就直接合并呗（ 19 年以前合并到发放奖金的月份）

[xmumiffy]

@PrinceofInj
其实他要是叫扣除数就没争议了,扣除数税务局定下来是多少那就是多少,它是税的本身算法.
但税务局现在把他叫速算扣除数,速算扣除数应当只是为了方便计算产生的,然而 国税发〔 2005 〕 9 号 的速算扣除数其实就是税的本身算法,并没有替代另一个计算方式.
现行的 财政部 税务总局公告 2023 年第 30 号 依旧叫 速算扣除数

[GuuJiang]

@PrinceofInj 这个帖子里很多人都没有真正理解速算扣除数到底是怎么来的，我来用小学数学知识从头推导一遍吧，首先说月薪，把前几档的税率列出来如下
(0, 3000): 3%
(3000, 12000): 10%
(12000, 25000): 20%
...
假设工资在(3000, 12000)之间，那么依据上面的税率，计算公式为
(3000 * 3%) + (x - 3000) * 10%
化简一下可以得到
90 + x * 10% - 300 = x * 10% - 210
这就是第二档中的速算扣除数 210
同理假设在(12000, 25000)之间，那么依据上面的税率，计算公式为
(3000 * 3%) + (9000 * 10%) + (x - 12000) * 20%
= 90 + 900 + x * 20% - 2400
= x * 20% - 1410
得到了第三档的速算扣除数 1410
其他的依此类推
所以说 210 、1410 这些数并不是凭空冒出来的，也不是拍脑袋想出来的，真正的本质是阶梯税率，在按照阶梯税率计算的过程中对一些常数部分进行化简得到的结果，脱离了原本的分段点和税率，这些数没有任何特殊的含义
而到了年终奖这里，分段点变成了 36000 、144000 等，但仍然机械地照搬了 210 、1414 这一组速算扣除数，导致了最终的这个畸形的结果

[GuuJiang]

简单总结就是，对于政策制定者，需要提供的信息是：税率各档分界点在哪里，以及每一档的税率是多少，这就是制定一个阶梯税率政策所需要的全部信息，至于速算扣除数，是完全由前两个信息决定的，就算不直接写进政策里，实际操作的人自己也能推导出来，这个数是不能独立存在的，也就是说这里看似有 3 个参数，实际上只有 2 个
而到了年终奖这里，却离谱地直接给出了分界点和速算扣除数两个参数，并且速算扣除数还是从另一份表格里搬过来的，最终导致了产生的结果并不是一个合理的阶梯税率，反而成了一个奇怪的锯齿状函数

[mschultz]

@GuuJiang #83 😂 所以 @xmumiffy #82 楼认为如果直接叫「扣除数」，去掉「速算」两个字就没争议了。

翻译：我税务总局想扣除多少，你只有遵守的份。我们对年终奖本来实行的就是「全额累进税率」外加固定数额优惠的制度，并不是「超额累进税率」！那个扣除数是全额累进税率各级税率下的固定数额优惠！

但是这个解释仍然牵强。

====
首先，全额累进税率与公众认知、现行税法的精神都不相符。现行个税法对个税实行的是超额累进税率。

其次，如果只是为算法中一个参数改个名字，宣布这是硬性规定的常数 —— 并不能解决税后到手金额跳变的问题，这才是最容易引发争议的点。

再次，如果说这个常数就是算法本身，是个固定数额的优惠钱数，**不是**其他计算方式（即差额累进税率）的简便替代，那为啥偏偏选个「一眼就能看出是差额累进税率月度速算扣除数，仔细一看计算过程又发现在乱用」的数值？咋不选 100 ，200 ，500 这些整的？最后还是只能解释为拍脑袋。

[GuuJiang]

@mcluyu 因为文件里有三个不同的表格
第一个是《收入按月计算》，也就是适用于广大打工人的，给出了分界点、各档税率和速算扣除数三列，分界点为 3000 、12000 等，速算扣除数为 210 、1410
第二个是《收入按年计算》，适用于劳务报酬等非按月的收入，同样包含三列，分界点为 36000 、144000 等，速算扣除数为 2520 、16920 等等，你看到的应该就是这个表格，其实这恰恰就证明了这种情况下的速算扣除数本来就应该乘以 12
而年终奖是第三种计算方法，只给出了分界点和速算扣除数，分界点为 3000 、12000 等，速算扣除数却是 210 、1440 等，等于抄作业各抄了一半

其实去查一下更多的历史文件就会发现，历史上税率曾经调整过，而每一次的税率更新都会伴随着速算扣除数的更新，并且都是和我前面说的推导过程是吻合的，这也证明了早期政策制定者的本意就是规定区间和税率，同时顺带给出速算扣除数，结果后面抄作业的人把这个大前提给丢掉了，直接抄了速算扣除数，大概就相当于小 A 写了一个计算阶梯税率的函数，先是按原始公式计算的，后面进行了优化，提取出了速算扣除数，而小 B 在照抄这个函数时把它当成了原始的公式，于是只修改了分段点，却没有相应地去修改这些看不懂的 MAGIC NUMBER

[chairuosen]

发的多拿的少就是 BUG ，在数学的世界里没有权威。

[cmdOptionKana]

@rrfeng

> 我给你优惠，但是你要跟我学算 1+1 = 3 才行。

假设顾客拿了一瓶水 1 元，和一个面包 2 元，结帐。

老板说：水和面包搭配，优惠价，收你 2.5 元。

顾客说：1 + 2 等于 3 ，老板你数学错了

老板说：我说了，是给你优惠。

顾客说：你强调优惠能掩盖你的错误吗？你给我优惠，但是要我跟你学 1 + 2 = 2.5 才行，你这是侮辱我的小学数学知识！

[cmdOptionKana]

@chairuosen 两个商品同时结帐，给优惠价；同样是这两个商品单独结帐，没有优惠；买同样的东西，结帐方式不同，导致最后金额不相同，是数学 bug 吗？

[chairuosen]

@cmdOptionKana 你这不是杠精么。自己编一个场景来反驳，你这是数学问题么？

[cmdOptionKana]

@chairuosen 原来你也知道不是数学问题。

什么是数学问题，公式本身有问题。

什么不是数学问题，给出两个公式，两个公式都没问题，两个公式的计算结果不同而已。

现在原本讨论的计税问题，是公式本身的问题吗？是提出两个公式的那个提出者声称这两个公式的计算结果应该一样吗？

不是，事实是什么，事实是提出两个公式的那个提出者已经说了两个公式的结果可以不一样，其中一个是优惠价。这是数学问题？

[chairuosen]

@cmdOptionKana 当然是公式的问题啊，上面不是一直在讨论公式里的速算扣除表是错的么？你在看什么？

[cmdOptionKana]

@chairuosen 你说它错，前提是 “提出者宣称速算与不速算的结果应该一致”，人家本来就没说应该一致，错在哪里？

[chairuosen]

@cmdOptionKana 我用你自己的方法来反驳你：
老板：你这两个东西一共 10 块钱，可以分开结，也可以一起结，一起结给你 5 折优惠怎么样。
顾客：可以啊，一起结吧。
老板：付款 6 块吧。
顾客：不是 5 折么？你算错了吧。
老板：没算错，要么 10 块要么 6 块，你要不要吧

[cmdOptionKana]

@chairuosen 说死了折扣，就按宣称折扣算。如果没有说死折扣率呢？

我就抛给你两个公式，你自己算，两个结果我都同意结帐，你可以自己选择其中一个公式。这里有什么数学错误？

[chairuosen]

@cmdOptionKana 两个选项并不是“速算”与不"速算"，只有两个选项是“一次性”和“12 个月均摊”这是两个算法，不放在一起讨论。政策是二选一，本次讨论的是“一次性”这个算法的分段函数计算问题。这个分段函数每一个线段，应该是收尾相连的，但是这里的公式错误，导致分段函数断开了

[chairuosen]

@chairuosen 首尾相连的意义在于，在临界点，采用上一个分段的算法，和下一个分段的算法计算出的金额是一样的。

[cmdOptionKana]

@chairuosen

我提供给你一个函数。
你希望计算结果是首位相连的。
但我有没有说过，我这个函数，它的计算结果是首尾相连的？我没说过。

好，现在我这个函数，算出来发现，没有首尾相连。我错了吗？错在哪里？

注意，首尾相连这个要求，是你希望，不是我的承诺。我没有说过它是一个首尾相连的分段函数，这我没有说过吧？

[chairuosen]

@cmdOptionKana
OK ，确实是你说的样子。
但这个东西，在专业领域，都是首尾相连的，你在历史上给的其他公式，也都是首尾相连的，就这一个不是。那你说是哪里的问题。
你非这样说，只要他不承认错，那就不是错呗？

[chairuosen]

我给你个折扣 10 块钱打 5 折是 6 块，我不管，我没承诺你 10x0.5=5 ，我就是对的