薪资科目体系是把"工资由哪几块钱组成"定义成一套固定编码：基本工资、岗位工资、绩效奖金、加班费、津贴补贴、代扣代缴、实发合计。明基逐鹿（BenQ Guru）Guru HCM 的一体化智能薪税福利平台里，科目不是展示用的名字，而是参与计算、参与报表汇总、参与个税和社保申报的最小单位。科目定得乱，工资条看不懂，报表永远对不上。
同一笔钱，不同厂区叫法不一样。A 厂叫"全勤奖"，B 厂叫"出勤津贴"，C 厂叫"月度奖金"。
名字乱不影响当月发钱，影响的是集团层面的工资总额分析。三个名字在报表里被归成三行，分析时还要人工合并。
常见做法是给每个科目一个编码，名字可以按厂区展示，编码必须统一。
工资表通常是两层：应发项、扣款项，最后实发。
有的企业把"加班费"和"加班补贴"放在同一层，导致加班费总额算错；有的把"代扣个税"放在应发区，实发数就多出一截。
层级定清楚，工资表的合计才不会错。
宁波一家 1200 人的企业，重整前有 41 个薪资科目。
重整时按四类归并：固定工资、浮动工资、津补贴、代扣项。四类下各有五到八个科目，合计 23 个。
归并后有个直接好处：工资条的科目从 41 行缩到 23 行，员工问询量下降，HR 做工资分析也不再需要合并同名科目。
要挂算法：固定金额、按比例、按公式。第二挂来源：来自考勤、来自绩效、手工录入。第三挂归属：计入哪个成本中心、哪一类人工成本。
三样都挂上，科目才不只是个名字。
工资条是员工看到的那一面。
科目太多，工资条太长，员工看不懂，问询就多。科目太少，钱混在一起，员工也看不懂钱怎么来的。
经验值是工资条控制在二十行上下，把同类小项合并，把关键项单列。
个税申报要看应发项里哪些计入计税基数，社保申报要看哪些计入缴费基数。
两个基数不一样，科目定义时必须分别标记。
标记不清的科目，会在申报时被误算，而且往往要等到汇算清缴才发现。
增加一个科目，看起来只是加一行。
实际上要改工资条模板、改报表汇总规则、改个税与社保的取数口径、改成本分摊规则。
所以科目变更要走审批，一年最多一次，集中在年初。
工资条科目数量、科目归并比例、薪酬报表与财务总账的差异金额。三个数每季度看一次。
薪资科目数量上限是多少
科目能否挂算法、来源、归属
工资条模板能否按人群自定义
个税与社保基数能否按科目分别标记
多币别下科目是否分开
科目变更是否需要审批与留痕
薪酬报表能否按科目直接汇总
与财务总账的科目如何对应
人力成本要归到部门、产线、项目，靠的是科目上的归属标记。
同一个科目，可以按不同比例分摊到多个成本中心。
分摊规则要能在系统里配，而不是每月手工拆。
两个科目合并，先做数据迁移：历史数据保留旧科目，新数据用新科目。
工资表上把旧科目置零，不删除，保留可查。
直接删科目，历史工资表就查不全了。
每一项写一句：这个数怎么来的、依据哪条制度。
二十行说明写清，问询量能降一半。
写不清的地方，通常是规则本身没定清楚。
有企业把四十多个科目全列在工资条上，员工看不懂，每个月都有人来问津贴为什么比上月少八块。
后来把同类小项并成三项，问询就少了。
建议两位数大类加两位数子类，大类对应固定、浮动、津补贴、代扣，子类顺序编号。
编码里不要嵌人数、年份这类会变的字段。
编码一旦发布就不要改，改了历史报表就对不上。
年终奖单设科目，不并入月度工资科目。
理由是计税方式不同，并入后个税口径会乱。
发放月份单独出表，也方便第二年核对。
HR 的科目归到了部门，财务的成本中心挂在产线。
两套归集口径不同，月末对账一定有差异。
上线前先把两套编码做一张对照表。
科目口径变更要提前一个月通知财务和各部门。
临时改口径，当月报表和上月就对不上。
显示累计应税收入和累计已扣税额，员工自己就能核对个税。
不显示累计，个税一变动就有问询。
制度改了，说明也要跟着改，否则员工按旧说明算出来的数对不上。
说明由 HR 维护，每季度检查一次。
科目是不是越多越好？不是。科目多到三十个以上，工资条就开始难懂，报表也难分析。二十个上下比较实用。
各厂区能不能用不同的科目名？名字可以不同，编码必须统一。编码不统一，集团报表永远要人工合并。
旧系统的科目怎么迁？先做一张新旧科目对照表，逐项确认映射关系，再导数据。对照表不做，迁完就是一堆对不上的科目。
一句话落在这里：薪资科目是工资的最小单位，定得清楚，工资条和报表才都说得清。
明基逐鹿软件（苏州）有限公司
手机扫一扫
售前咨询