跳到主要内容
CalcMax

双周薪计算器

范围：0 – 1,000,000,000

结果

2,500.00

每期金额

一年实际到手
65,000.00
与年薪的差额
0.00
差额占年薪的比例
0.00%
实际用到的除数
26.0000

双周发薪就是每两周到账一次，而这件事底下的算术有一处别扭：一年装不下正好的 26 个。它装 26 个整两周，再余一两天，所以一张每 14 天发一次的工资日历迟早会把第 27 个发薪日放进某一个公历年份里。美国人事管理局把这件事写得很直白——通常每年有 26 个发薪日，而在若干年的跨度里，雇员会遇上一年里有 27 个发薪日。本页就是为这处别扭做的，也是它这一族里唯一一个处理它的。本页要拆掉的那个直觉是：27 次发薪意味着年薪要除以 27。不是的。雇主定的是一个每期金额，那才是工资日历上的数，而它等于年薪除以 26——一个固定的分母，它并不知道这一年碰巧发了几次。所以在本页上改发薪次数，每期金额纹丝不动，动的只是最后三行。年薪 65,000，每期都是 2,500.00；发 26 次合计 65,000.00，发 27 次合计 67,500.00，也就是多出整整一期，比年薪多 3.85%。本页还认真对待第二个分岔。每期金额可以就是年薪的平摊，多数企业发的就是这个；也可以是美国联邦法规定的那套顺序：年薪除以 2,087 小时得到小时工资，把小时工资舍到分，再乘 80。这三步的次序不是行文习惯——5 U.S.C. 5504 就是这么写的——而它正是一年发 26 次时、按这一档算出来的钱比年薪略少而不是正好相等的原因。美国人事管理局自己的算例给出了这个差额的量级：年薪 89,033 折成每小时 42.66，再折成每期 3,412.80，发 26 次合计 88,732.80，比年薪少 300.20。下方参考表把两个分母并排放着，并说明各自对发 26 次的一年与发 27 次的一年做了什么。

两个分母，以及各自对发 26 次与发 27 次的一年做了什么

依据每期分母发 26 次与发 27 次各是什么结果
按年薪平摊26普通企业的做法：双周薪是年薪的二十六分之一，无论日历怎么走，这一整年都是这个数。于是 26 次发薪正好把年薪发回来，这是干净的那一种情形；27 次则多发一个二十六分之一，也就是多 3.85%。分母固定是 26 是有意的——它不是这一年碰巧发了几次，而这一条区别正是整页的支点。
按 2,087 小时除数26.0875美国联邦法规定的那套换算法，把年薪折成双周薪：先除以 2,087 得到小时工资，把这个小时工资舍到分，再乘 80。次序是要紧的，因为舍入落在中间——直接拿年薪除以 26.0875 会得到略不一样的答案，而这个差别正是要点而不是噪声。后果是一年发 26 次合计比年薪略少、发 27 次略多，所以这套方法自己的文档才说，雇员在某个年份里拿到的高于或低于其年薪都是可能的。

中列就是本页拿来除的那个数，末列说明两行为什么不能互换。第一行之下，26 次正好把年薪发回来，27 次是年薪加一个二十六分之一——两种情形相差 3.85%，是个干净的分数，因为两者建在同一个分母上。第二行之下，两种情形都不落在年薪上：26 次略低于它、27 次略高于它，而 27 次那一边比 3.85% 小，因为那一档真正的分母约为 26.0875 而不是 26。这条缝小到可以在单张工资条上忽略，又大到在一整年里看得出来——这就是为什么两档在本页上是一个可选项而不是一句脚注。表里不放任何金额：两个分母给出的百分比与薪资无关，在这里印钱只会让人把这些数读成在讲默认算例。

公式

每期金额 ＝ 年薪 ÷ 26　｜　一年实际到手 ＝ 每期金额 × 今年发几期

annualSalary
合同上的年度数字，扣除任何东西之前的那个。它是每期金额的推导来源，而不是本页要复现的一个总数：这一年到底有没有把年薪原样发回来，正是末尾三行在回答的问题，而答案取决于日历。本页印出的每一个数都是税前，所以把一份按到手口径说的薪资填进来就是填错了数。
payDatesInYear
你那张工资日历在这一年里发几次——多数年份是 26，偶尔有年份塞得进第 27 个整两周。就是这个字段让本页区别于一次普通的薪资换算，而它算不出来：双周日历与公历是错开的，哪一年带 27 取决于你的发薪日锚在星期几。只能去翻自己的日历或工资条。
biweeklyRateBasis
每期金额由两种方法里的哪一种定。平摊一档是年薪除以 26，也就是常见的企业发法。法定一档是美国联邦法给出的顺序，把年薪折成双周薪：先除以 2,087 得到小时工资，把这个小时工资舍到分，再乘 80。选哪一档会让每期金额差千分之几——摊到一期很小，摊到一年不小。
payPerPeriod
一期工资里有多少钱，也是本页的主结果。它有意不受发薪次数影响：把 26 改成 27，这个数不动，因为它来自年薪与一个固定分母。这是本页的要旨而不是缺漏——发 27 次的那一年多出来的是整整一期，而不是把同一笔钱切得更薄。
receivedInYear
每期金额在一整年里究竟加总成多少，也就是每期金额乘以发薪次数。想知道十二个月里实际进账多少而不是一张工资条上写了多少时，看这一行。发 27 次的那一年就是在这里露头的：它算出来高于年薪，而不是等于年薪。
differenceFromSalary
一年实际到手减去年薪，带符号。平摊一档配 26 次时它正好是 0，这是本页唯一一个可以心算验算的等式。配 27 次时它是正的，且恰好等于一整期。法定一档配 26 次时它可以是负的，因为那一档的分母并不是正好 26。
differencePercent
同一个差额占年薪的比例，这样不必知道薪资也能读出这个效应有多大。平摊一档下两个值是 0 与 3.85%，后者正好是二十六分之一。法定一档下大约是负 0.34% 与正 3.50%，而后者比 3.85 小这件事，正是两档不能互换的全部理由。
effectiveDivisor
年薪除以每期金额，印出来是为了让那个假设露在明处而不是埋起来。平摊一档下它读作整整 26.0000。法定一档下它落在 26.0875 附近而不落在它上面，因为小时工资在乘 80 之前先舍到了分——89,033 给出 26.0880，70,623 给出 26.0871。这条小缝是法律要求的舍入，不是要去修正的错误。

你每两周发一次薪、想知道这一年实际发多少时用它，尤其是碰上带第 27 个发薪日的那种年份。也用它拿工资条对合同：如果条上的每期金额对不上年薪除以 26，差的那一点通常来自法定那一档的换算次序，而不是发薪算错了。跟预算有关的话更该先算一遍，因为两种发薪次数之间差的是整整一期工资，而这恰恰是没人想起来要核的那个输入。如果你手上真正的数是一个时薪、加上你每周干几小时，就别用它——把每周工时与一年周数当字段的那两页才是为那个问题做的。也别拿它估到手工资，这里不减所得税、不减养老保险、不减任何保险费。也别把它当成通用的薪资换算器：它只讲双周，而在周、双周、半月、月与年之间换算的是另一页。

算例

  1. 默认算例：年薪 65,000，一年发 26 次

    1. 每期金额：65,000 ÷ 26 ＝ 2,500.00
    2. 一年实际到手：2,500.00 × 26 ＝ 65,000.00
    3. 差额：65,000.00 − 65,000 ＝ 0.00（0.00%）；实际分母 65,000 ÷ 2,500 ＝ 26.0000

    本页唯一一个精确成立的等式，也是默认年薪取 65,000 而不是一个更整的数的理由：它除以 26 没有余数，于是差额那一行读作一个干净的 0。面板上其余每一行都是这个 0 的后果。

  2. 同一个年薪，一年发 27 次

    1. 每期金额：65,000 ÷ 26 ＝ 2,500.00　（不变——分母是 26，不是 27）
    2. 一年实际到手：2,500.00 × 27 ＝ 67,500.00
    3. 差额：67,500.00 − 65,000 ＝ +2,500.00，即 +3.85%（正好是 1/26）

    把这一条与上一条逐行对比：每期金额与实际分母完全一样，动的只有最后三行。这就是全部的一课。多出来的钱是整整一期，而不是同一份年薪重新分配，所以碰上发 27 次的那一年，值得在安排用度时留个心。

  3. 法定那一档，一年发 26 次

    1. 小时工资：89,033 ÷ 2,087 ＝ 42.6607…，舍到分 ⇒ 42.66
    2. 每期金额：42.66 × 80 ＝ 3,412.80
    3. 一年实际到手：3,412.80 × 26 ＝ 88,732.80；差额 −300.20，即 −0.34%

    这是美国人事管理局那篇讲 2,087 小时除数的页面上的算例，被本页算到了底。那一页把合计写成 88,733，因为它舍到整元；本页保留到分。注意符号：一年发满 26 次反而比年薪少，这与多数人的预期相反，也正是那篇说明里 more or less 那个措辞在提醒的事。

  4. 法定那一档，一年发 27 次

    1. 每期金额：3,412.80（与上一条相同——每期金额与发薪次数无关）
    2. 一年实际到手：3,412.80 × 27 ＝ 92,145.60
    3. 差额：92,145.60 − 89,033 ＝ +3,112.60，即 +3.50%

    那一页对这一年给的是 92,146。百分比值得与平摊那一条比一比：是 +3.50 而不是 +3.85，尽管两边都是多发一整期。原因是法定那一档真正的分母约为 26.0875，所以多出的一期占年薪的比重略小一点。两个分母、两个答案、同一张日历。

局限

本页只做乘法与加法，它不算到手工资。这里不减所得税、不减社保、不减养老保险、不减学生贷款还款、不减工会会费，所以每一个数都是税前。它也判断不出你这一年有几次发薪日：那是雇主工资日历的属性，而那张日历与公历年是错开的，因为 26 个整两周只有 364 天；用这个页面的前提就是先去日历上把它读出来，这一步只能你自己做。它只建模一种发薪频率：半月薪也是一月发两次，但它恒为 24 次、不会漂移，那是另一种安排，住在薪资换算那一页里，与它同住的还有按周发薪——按周发薪有它自己的 53 次之年。它假设年薪与每期金额全年不变，所以涨薪、奖金、加班、无薪假都会把真实合计推离屏幕上那个数。它假设这一年里每一期都一样长，对双周日历来说这是构造上就成立的，但对这两周里实际发生的事并不成立。它完全不碰预扣问题：第 27 个发薪日在某些系统里会影响预扣多少，而那三个字段够不到这件事。它不做货币换算，也不给任何数挂币种，这是有意的：算术在哪种货币里都一样，而挂上一个单位只会让人把这些数读成在讲某个特定的地方。它也判断不了你这套工资走的到底是平摊那一档还是法定那一档——那是第二个下拉框的用途，而诚实的答案是：你可能得去问发薪部门，或者翻一张工资条才知道。最后，本页把你选的那个次数当成关于这一年的事实而不是预测：你选了 27，它就会照着 27 算，哪怕你这一年其实是 26 次。

常见问题

一年发 27 次，是不是每期工资就变少了？
不会，而这正是本页要纠正的那个假设。每期金额是雇主按年薪与一个固定分母定下来的费率，日历多出一次发薪时它不动。发 27 次的那一年做的是把这个不变的数多发一次，于是全年落在年薪之上而不是落在年薪上。反过来说，如果雇主确实拿年薪除以这一年的发薪次数，那每期工资就会缩一点——但那是另一种、更少见的安排，本页的平摊一档建模的是常见的那一种。
分母为什么是 26 而不是 26.07？
因为双周薪是工资日历上的事实，而不是年份长度的除法结果。26 个整两周是 364 天，比平年短一天、比闰年短两天，所以一张每两周发一次的日历与公历年对不齐——它会漂，大约每十一年漂到能塞进第 27 个发薪日。拿 365 除以 14 得到 26.07，那是个没有哪套发薪系统会用的数，因为发薪日必须落在真实的星期几上。
2,087 小时除数是什么，它为什么会让一年发得比年薪少？
它是在日历重复的那个 28 年周期里，一个公历年平均含有的工作小时数，美国联邦法用它把年薪折成小时工资。因为 2,087 除以 80 约为 26.0875 而不是 26，算出来的双周薪比年薪除以 26 略小一点——于是 26 次发薪合计比年薪略少，同样一套算术换成 27 次则合计比年薪多。发布这套方法的机构自己就写明：雇员在某个公历年份里拿到的高于或低于年薪都是可能的。
我该选哪一档？
如果你是在普通企业按常规方式领薪，平摊那一档几乎肯定就是你的发薪方式，它能把工资条对到分。法定那一档存在，是因为有些雇主、尤其是美国联邦政府，被要求先把年薪按 2,087 小时除数折成小时工资再折成双周薪。两者相差千分之几，所以选错了给出的是一个看似合理、而不是一眼就错的数——最快的判断办法是拿年薪除以工资条上的税前金额，看答案是 26 还是约 26.09。
它跟通用的薪资换算页有什么区别？
那一页把一种发薪频率换成另一种——周、双周、半月、月、年——并且把双周固定为一年 26 次，因为在一场纯换算里，发多少次是定义的一部分而不是变量。本页拿年薪当既定条件，问的是日历拿它做了什么，所以它带着一个换算页用不上的发薪次数。想知道一个双周数折成一年是多少，去那一页；想知道你今年实际发多少，是这一页。
这个页面在美国之外成立吗？
算术成立，因为拿薪资除以发薪期数不是哪一个国家的规则。法定那一档不成立：它是某一个国家特定的换算次序，写在这里是因为它是有据可查的「非纯平摊」工资率的最好例子，也因为它的舍入产生了那道小差额，而正是那道差额让两档能被区分开。本页印出的每一个数都是税前且不挂币种，这是有意的，好让这些数字放在哪里读都一样。

参考资料

相关计算器

薪资计算器在周薪、双周薪、半月薪、月薪与年薪之间换算。年薪转时薪计算器由年薪与每周工时算出小时工资。年收入计算器由时薪、日薪、周薪或月薪换算出年收入。工时卡计算器由上下班打卡时间算每周工时与工资。