@whirlp00l
如果只看公式就容易陷入困惑迷茫。股权激励与全年一次性奖金的业务实质有一些区别。

全年一次性奖金基本上只是对于当年工作的奖励，所以摊在当年月度工资上是合适的。而且年度奖金金额与当年的月度工资一般是相称的，所以要实现“在实际月度工资边际税率上累进”时使用奖金/12 查表作为近似税率一般只低不高。

股权激励实质则是对于过去若干年的工作奖励，如果要摊的话照理应该摊到整个限制期间，短则 12 个月、长则 60 个月，差别较大。同时由于跨越时间较长，且行权方式不同（一次性、多次），难以用本次行权所得去估计被摊月份的边际税率。所以套用全年一次性奖金的思路不太行，才改用“分摊到凭空多出来的月份，但不超过 12 个月”这种妥协的设计。

顺带一提，现在个税改革为年度综合所得，其实只解决了月与月之间收入分布不均匀（比如全年一次性奖金），但并不能解决年与年之间收入分布不均匀（比如股权激励，比如离职一次性补偿）。再拓展一下，即使解决了时间分布不均匀，总还有其他维度的问题，例如家庭成员之间收入不均匀（比如一方高收入、另一方无收入），这些都是要不断改进的。

@GuuJiang
你的话就原封不动地送还给你：
没想到你的理解能力低下到这种程度，就不要在这里继续浪费公共空间了。
友情提醒你一句，V 站一般情况下无法删帖，希望你若干年后回想起来不要后悔在这里留下的黑历史。

你一大堆废话我都不厌其烦地看完，耐心地逐一给你指出你错在哪里，给你解释什么叫业务逻辑，你倒是连看都不看，自始至终只是复读自己的错误认知。
带你到这个程度你都理解不了，确实没有任何讨论的必要了，祝你春节快乐算了

@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.，“月”是单位，不是量纲，谢谢。

@Padawan
地税局或地方国税局可能会有你说的这种情况，但这是国税总局发文，而且不是针对某个(些)纳税人的定向政策，不要太想当然了。

@GuuJiang
再读读 120, 145, 150 楼吧，你仍然没有理解我重复了很多遍的业务逻辑。

速算算法本来就是怎么简单怎么来，而不是什么好理解。你给出的月收入“速算添加”算法并不比速算扣除有什么优势，甚至实操上更麻烦（多一个参数），2005 年仍有不少企业的工资表是手动算的（纸+笔+计算器），多减一个数就多一分工作量。

顺便说一句，如果平行宇宙的税务局把“速算扣除”算法套用到全年一次性奖金计算上，那么减的边界数也会是按月度表来的，结果仍是跳增而非跳减🐶
36000*3%=1080
(36001-3000)*10%+90=3390.1

@GuuJiang
我 145 楼、120 楼等已经重复解释过很多遍业务逻辑了，如果你思路还转不过弯来那我真没办法教会你。

最后实现的公式不需要你所谓的一一对应的“意义”，你讨论一大通公式哪一部分具体对应什么东西是没意义的。

@GuuJiang
你会提出全额累进，以及你提出的参数建议，说明你压根没理解业务逻辑。

请理解(1)“把年终奖摊到 12 个月的月度收入之上继续适用超额累进税率”与(2)“把年终奖摊到额外的 12 个月，每个月单独适用超额累进税率”这两种业务逻辑的区别。

对于第 1 种，实操中还需要由人事/会计给每个人添加每个人月度收入的参数，并且这个参数每月是不同的，并且如果一次性奖金不是在最后一个月发你都没法确定这个参数。
对于第 2 种，从业务逻辑上就不是这样设计的。

@chairuosen
首先，上面提出的那些简单的改 bug 方案是违背业务逻辑的，这比一个有部分意外结果的不优雅的业务逻辑更糟糕。
其次，这个问题已经被“年度综合所得”方案彻底解决了，所以剩下的问题只是什么时候把过时补丁删掉罢了，不需要再修改补丁。
最后，老用户也是用户，所以政策变动一般会考虑延续性。

@kkbblzq
并不是唯权威论。我已经介绍了前因后果，也没有认为这个方案没问题。我想说的是，你们能想到的“正确方案”要么错得更大，要么不具可操作性。另外，彻底的修正已经上线了，没必要再改这个临时的补丁。

@chairuosen
我是(半个)业务部门，我很讨厌开发用“代码优雅性”、“我觉得应该怎样怎样”来试图直接篡改业务逻辑。
由业务逻辑导致的意外结果，而且有 workaround 的情况下，应该先制定业务逻辑的改进方案，而不是想当然地直接改代码。

@xmumiffy
谢谢，这解答了我的困惑。
看起来像是政策升级（从“视同单独一个月计税”升级成“视同在 12 个月均匀取得”）过程中，为了兼容旧政策所以留下的“祖传代码”😂

@mschultz
见 126 楼，你提的方案相当于额外给了 12 个月用来分摊年终奖（即从 3%开始适用累进税率），这就是我说的看起来很好看但离本质差很远的东西。

@fzls
要是速算扣除数乘以 12 ，曲线是顺眼了，但离业务逻辑差远了。
乘以 12 翻译成业务语言是：“把年终奖分成 12 个月，每个月重新从最低档税率开始重新累进个税”，相当于额外给了 12 个月给你分摊年终奖，而不是把年终奖摊到月度工资上面。

至于你说年终奖单独适用一套累进计算额度......个税的税率表是写进税法的，那得修改税法才行。

至于你说现在年度综合所得纳税+年终奖可以单独计算......我前面说过了，改成年度综合所得纳税之后，理论上就没必要继续给年终奖单独计算了，无非是现在经济不好，所以打着延续政策的名义给个税优惠罢了。这是暂时补丁，不是应该有的东西。

@anzu
很简单的道理：年终奖平摊到 12 个月的话，年终奖的个税应当是从月度工资之上继续超额累进，而非从零开始超额累进。由于每个人的月度工资不同，所以在此之上继续累进难以统一做出月度工资速算扣除这样的公式。

然后你是不是想说“那就在月度工资之上继续超额累进计算呗”？嗯，老人事/老会计们都会想打死你的。。。

@mschultz
我非常赞同你 #107 说的“缝合怪”一词。
是的，全年一次性奖金这个补丁就是个缝合怪，函数长相怪异，数学上也没严格意义，然而它就是长得像本质啊。而其他许多方案长得好看是好看（比如速算扣除数×12 ），但问题是长得很不像本质。
本质在 #46 楼已经提过了，摊到每月收入上再超额累进，然而最大的问题在于没有实操性。

我也赞同现在年度综合所得计算个税才是更合理的方案，但你不能拿现在的情况去评价 19 年前的补丁。综合所得的实施有太多的前置条件了，大部分条件在 2005 年根本不具备，所以不可能在 2005 年实施。而往后知道个税准备向年度综合所得方向改革，自然就没动力去修补那个缝合怪了（就像知道项目要重构，自然懒得去改还能跑的屎山）。

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