专业服务工时与计费：项目工时、费率与结算依据

按人天卖服务的生意，最贵的一笔账是"人到底干了多少天"

咨询顾问、设计院、软件实施商、审计与代账机构、检测与认证机构、培训与翻译服务商——这类公司的收入不是按"卖了多少件货"算的，是按"投了多少人天"算的。人天既是报价的依据，也是成本的来源，还是客户付款前要核对的那张纸。

可现实中，这张纸往往是最后一天才凑出来的：

• 报价靠估。新项目来了，凭经验和感觉报一个"大概 40 人天"，报完没人记得当初是怎么估的。做完发现投了 70 人天，超支的部分只能自己吞。
• 工时靠回忆。工程师一周一填甚至月底一次性补填，填的时候想不起周二下午在哪个项目上，就平均分一分。填出来的数字自己都不太信，客户更不信。
• 结算拿不出证明。客户说"你们投了多少人天、谁投的、做了什么，拿出来看"，项目经理只好临时拼一张 Excel，客户拿这张纸跟自己的记忆对不上，付款就开始拖。
• 毛利算不清。收入按合同金额、成本按发出去的工资，中间那层"这个项目到底投了哪几个人、什么级别、多少小时"是空的。做十个项目，不知道哪两个在亏钱。
• 内部事务吞掉了可计费时间。售前方案、内部例会、带新人、写周报——这些时间也占了人，但没算进任何一单生意里，于是所有人都很忙，公司不赚钱。

这些问题不是"缺一个工时填写页面"。真正的缺口是一条从工时明细到结算单据的可核对链条：谁在哪一天为哪个项目做了什么事、这段工时算不算可计费、按什么费率折算、最后汇成客户能认的结算依据，每一环都有据可查。

下面按"数据怎么建 → 页面怎么用 → 移动端怎么配合 → 上线前查什么 → 之后怎么延伸 → 不做什么"讲清楚这条路怎么走。

需要先说明分工：本文讲的是工时与计费这条线。如果你的痛点是"项目整体进度到哪、里程碑延了几天、预算花了多少"，那属于项目台账的范畴，见 项目台账：进度、投入与里程碑一本账。两张表不冲突：项目台账管"项目这个实体",本文这套管"人在项目上投入的时间怎么变成钱"。下文第五节会讲两者怎么挂在一起。

一、数据怎么建：四张表 + 两张字典

建这套东西的第一步不是画界面，而是把要记的事拆成表。最小组装是四张表（项目档、人员费率档、工时明细、结算单据）加两张字典（工时类型、人员级别）。

1. 项目档：只存"约定"，不存"已发生"

每个可计费项目一行，是整套台账的锚点。建议字段：

• 项目编号（按规则自动生成）、项目名称
• 客户（引用客户档案，不要手工再打一遍客户名，否则同一客户会有七八种写法）
• 关联合同（引用合同台账；一个项目可能挂一份合同，也可能挂一份框架合同下的多个子项，看你的业务口径）
• 项目类型（字典：咨询 / 实施 / 运维 / 培训 / 检测……用于后续按类型配费率）
• 项目状态（字典：准备中 / 执行中 / 已暂停 / 已结项 / 已关闭）
• 计费方式（字典：按人天 / 按固定总价 / 按里程碑 / 不收费内部项目）
• 项目经理、签约人天（合同约定的总人天，可空）
• 计划开始日期、计划结束日期

两个容易踩的坑：

别在项目档上放"已用工时"和"已结算金额"。 这两个数都是由明细汇总出来的结果，一旦在主表上存一份，就一定会出现"主表写 300 小时、明细加起来 312 小时"的情况，而且没人知道该信哪个。主表只放约定值，实际值一律由系统汇总。

项目状态一定要有"已关闭"这一态。 项目结项后工时不该再往上填，否则上个月的结算依据会随着有人补填而变动，客户对过账的数就变了。

2. 人员费率档：费率必须是"带生效日期的版本表"

这是整套设计里最容易被做错的一张表。多数公司的第一版做法是：在员工档案上加两列——"人员级别"和"人天单价"。跑半年就会出问题：七月调了价，回头重出三月的结算单，单价跟着变成新价，跟客户手里那份对不上；或者反过来，想按新价算八月，结果历史单据也跟着变了。

正确做法是把费率从员工档案里拿出来，单独做一张费率版本表，一行一个价位段：

• 人员级别（字典：初级顾问 / 顾问 / 高级顾问 / 专家……，级别按公司自己的职级体系定，不套外部标准）
• 适用项目类型（可与级别一起构成两维：同样是高级顾问，实施类项目和咨询类项目对外报价不同）
• 成本单价（内部成本口径，只在内部可见）
• 结算单价（对外报价口径，出结算依据时用）
• 币种、计价单位（人天 / 人时）
• 生效起始日期、生效结束日期
• 变更原因、审批单号、备注

关键约定：换价只新增一行，不修改旧行。 新版本从某天起生效，旧版本那一天自动失效。这样任何一天的工时都能找到"那天当时适用"的费率，历史结算单永远重算得出原来的数。

同时，成本单价和结算单价必须分两列存，而且权限要分开——这是内部成本和对外报价的区别，混成一列等于把公司底价发给客户。关于按角色控制字段与页面可见性，见 角色与权限配置：从内置角色到自定义授权。

3. 工时明细：一行"某人在某天为某项目做某事"

这是数据量最大、也最需要克制的一张表。一行 = 一个人 × 一天 × 一个项目 × 一类工作内容。建议字段：

• 日期、填报人（引用平台用户，自动带出所属部门与级别快照）
• 项目（引用项目档；内部事务类工时选"内部"专用项目，见下）
• 工时类型（字典：客户交付 / 售前支持 / 内部会议 / 培训带教 / 行政事务 / 休假……）
• 工时数（按公司口径定粒度：按小时填、或按半天/整天填。两种都可以，但全公司只能定一种，否则汇总时会混算）
• 工作内容（一句话描述，做成了什么；这一列是客户核对时最常看的东西，不要留空）
• 是否可计费（可计费 / 不可计费 / 待定，走字典）
• 不可计费原因（项目经理改判时必填）
• 关联结算单据（由系统回填，指向它被结算进了哪一张单据）
• 附件（可选：客户签字的工时确认单、现场照片等）

三个建模要点：

工时行只增不改，改判与更正另起一行。 项目经理事后发现某条工时不该公司承担，正确做法是新增一条负数或"冲减"行并写明原因，原行保留。这样客户质疑时，你能拿出完整的判定轨迹，而不是一个已经被改过的数字。

"内部事务"要有一个专用项目档，不要靠工时类型硬扛。 售前、内部会议、带新人这些时间必须被记下来，否则永远算不出真实的人效；但它们又不该进任何客户的结算单。给内部事务建一个（或几个）不收费的内部项目，工时照填，结算时按项目性质自动排除。

人员级别要存快照。 工时行上带一份"当时这个人是什级别"的快照字段，即使三个月后他升了级，这条历史工时仍按当时的级别归集。否则一次升职会改写历史成本。

4. 结算单据：金额只在这一次记一次

月度（或阶段）结算时，不要直接拿工时明细去开票，而是生成一张独立的结算单据。它是一张有状态的业务单，字段大致是：

• 单据号、结算周期（某月或某阶段）、客户、项目
• 结算明细（子表，一行 = 一个人员级别或一类工作，汇总工时数 × 当期适用费率）
• 结算金额（不含税 / 税额 / 价税合计，一列一义，不要合并成一个"金额"字段）
• 状态（草稿 / 已提交 / 客户确认 / 已开票 / 已作废）
• 客户确认人、确认日期、异议说明
• 关联开票申请单、备注、附件

要点是主表不存"已用工时合计"——那个数字永远从结算明细汇总。金额一旦被结算单据锁定，工时行就不能再被改判进这张单，否则单据金额和明细对不上。

5. 两张字典：别让下拉选项自由生长

• 工时类型：客户交付、售前支持、内部会议、培训带教、行政、休假等。一次定死，新增走变更流程。字典自由生长是工时台账最常见的报废原因——半年后会出现"开会""例会""周会""内部会"四个同义选项，报表彻底筛不干净。字典怎么统一口径，见 数据字典：管好下拉选项的统一口径。
• 人员级别：与费率版本表的主键对齐，不要在两处各写一套。

二、页面怎么用：从一张周填报页到一张客户能认的结算单

数据建好之后，落到页面上大概是这样几个视图。顺序就是你上线后每天、每周、每月会走的路。

1. 我的工时（每个人最常用的那一页）

这是全套东西里唯一需要"全员高频使用"的页面，做不好整套就废了。它应该只做四件事：

• 默认打开就是本周按天排开的填写界面，每格填项目、工时数、工作内容；
• 顶部有"复制上周"和"记住上次选的项目"，让重复性工作两下点完；
• 周内没填满的日子用颜色标出来，让人一眼知道自己漏了哪天；
• 提交后进入"已提交"状态，本人不能再改，要改得走更正（新增冲减行）。

产品上最该守的一条纪律：填报粒度不要贪细。按小时填的公司最后拿到的是一堆 7.5、7.25 的假精确数字；按半天填的公司数据反而更接近真实。两种都行，选定一种,别中途换。

2. 工时明细与管理视图（项目经理、部门主管）

• 按项目筛：这个项目这周谁在、投了多少、做了什么；
• 按人员筛：这个人这周的时间都去哪了，可计费与不可计费各占多少；
• 按异常筛：工作内容为空、可计费却没挂合同、单日工时明显异常的行，单独一屏处理；
• 改判：项目经理把某条工时从"可计费"改成"不可计费"，必须填原因，系统生成一条冲减记录，原行保留。

这屏是"管理动作"发生的地方，它决定了结算依据可不可信。所以它必须比填报页更好用，而不是更简陋。

3. 项目侧汇总：签约人天还剩多少

按项目看一屏：

• 已用工时按人员级别、按工时类型分组；
• 可计费工时与不可计费工时并列显示；
• 与项目档里的"签约人天"对照，看剩余可用人天；
• 按周期（周/月）看消耗曲线，判断这个项目是会超还是有余量。

注意这里只做"对照展示"，不做什么智能预测和自动预警阈值——那是你的管理口径，不是系统该替你定的事。真需要"超过签约人天 90% 时提醒"，用定时任务配一条提醒就好，阈值由你自己填。

4. 月度结算页：月度核算的工作台

每月初，财务或商务在这里收口：

1. 选结算周期，系统列出该周期内有可计费工时、但尚未结算的项目；
2. 对某个项目生成结算单草稿：按人员级别汇总工时，套用当期生效的费率版本，算出金额，落到结算明细子表上；
3. 人工核对：工时是否合理、有没有该改判没改判的、客户上月的异议是否已处理；
4. 提交后生成一份客户可读的结算依据（项目、周期、人员级别、工时合计、单价、金额），发给客户确认；
5. 客户确认后锁定单据，工时行被标记"已结算"，再不允许改判进这张单；
6. 锁定后的结算单作为开票申请与应收挂账的依据，往下走财务流程。

这条链上有一个必须坚持的设计：金额只在结算单据上出现一次。 工时明细不算钱，项目档不存已结算金额，财务侧的应收挂账引用这张单据。三处都存钱的台账，一定会对不上。

5. 保存时自动执行的规则：把校验放在录入口

这套系统里最省人力的部分，是"不合规的单据根本提交不上去"。这类规则在平台里叫数据流规则——一种挂在表单保存动作上的条件判断，满足条件就拦截、提示或自动填值。建议至少配这几条：

注意最后一条：金额一致性不靠人核对，靠规则算。同样地，结算单提交时也可以自动把明细行状态改为"结算中"，防止同一批工时被两张单重复结算。

6. 定时任务：让提醒代替催收

• 每周五下午：给本周工时未填满的人发一条提醒（站内信即可），比 HR 挨个催有效得多；
• 每月初：给财务生成待结算项目清单，把草稿单据准备好，人只做核对；
• 费率到期前：提醒管理岗"某级别费率版本 X 月 X 日到期，请确认是否续期或换价"——这条漏了，月底出单据时就会卡住。

定时任务与提醒的配置方式，见 工作流与定时任务：让重复性工作自动跑。

7. 哪些动作才走审批

日常工时填报不要审批。每天让人点一次"同意"，最后的结果是项目经理闭眼批，审批记录一堆但没有信息量。

只在三类例外上挂审批：

• 超期补填（比如超过本月 5 日再补上个月工时）；
• 费率临时调整（某个项目给客户打折、或临时用特殊单价）；
• 改判为不可计费（涉及收入，需要有第二个人知道）。

审批流本身怎么搭、节点怎么配，见 审批流落地：请假、报销与通用申请怎么在线化。

三、移动端怎么配合：让工时在"离现场最近的那一刻"被记下来

这套东西成败的分水岭不在 PC 端，在手机上。顾问一天跑两个客户现场，回到工位已经晚上七点，让他打开电脑填工时的概率很低；让他在客户楼下掏出手机点三下，概率就高得多。

移动端要做的和不要做的，界限很清：

手机端做这些

• 填报今天/本周工时，项目从"我参与的项目"里选，不用搜索；
• 常用项目默认置顶，工时数用大按钮（0.5 / 1 天）代替输入框；
• 拍一张客户签字的工时确认单直接作为附件挂在工时行上（手机拍照上传是平台自带能力）；
• 查我本周填了没有、我这个项目还剩多少人天；
• 项目经理在手机上做快速改判和异常行处理。

手机端不做这些

• 不显示结算单价与成本单价——手机上给人看的东西，等于随时可能被人看到；
• 不做结算单生成与提交，那是电脑上对着数据核的事；
• 不承诺离线填写：现场没信号就先记在纸上或手机备忘录，回到有网的地方补填。补填时日期要选实际发生的那一天，系统会同时记下录入时间，两者不一致不影响工时有效性，但必须如实填。

移动端页面不需要另外开发一套。模块发布时，平台会把同一份页面同步到手机端工作台，员工打开手机就能看到该看的模块；权限沿用 PC 端配置，手机上不该看的字段照样看不到。产品侧的能力说明见 移动端。

四、上线前查什么：十项对账清单

这套系统的特点是"错了不会报错，只会算错钱"，所以上线前的核对比一般模块更值得花时间。建议逐条过：

1. 填报粒度定了没有：按小时还是按半天，全公司一句话说清楚，并且已经反映在页面和汇总公式里。
2. 费率版本表填全了没有：现有每个级别、每个适用项目类型，都有且仅有一个当期生效的版本；没有空档期（空档期会让人到月底才发现算不出钱）。
3. 历史数据怎么过渡定了没有：本期上线，就从本期开始填，不补历史；如果必须补上个月，先补工时再补费率版本，顺序反了会算错。
4. 内部项目建好了没有：售前、内部会议、带教这些去处的项目档存在，且被标记为不收费，结算时自动排除。
5. 项目和客户、合同挂上了没有：跑一遍结算试算，看有没有工时行因为缺客户而算不进去。
6. 权限对不对：员工只看自己；项目经理看本项目；财务与合伙人看得到费率与金额。用一个普通员工账号登录，亲自确认他看不到别人的工时和单价。
7. 字典有没有同义词：工时类型、人员级别里没有"例会/周会"这种重复项，没有拼写不一致的级别名。
8. 校验规则逐条走了一遍：故意填一条超过上限的工时、一条没写工作内容的工时、一条挂在已关闭项目上的工时，确认都被拦住了。
9. 试跑一个月度结算：用测试数据生成一张结算单草稿，人工把工时明细加起来跟单据金额核一遍，数字一致才算这条链通了。
10. 移动端看一眼：用手机打开填报页，确认项目能选到、附件能传、不该显示的单价确实没显示。

第 9 条最容易被跳过，也最容易出问题——它是唯一能证明"工时明细 → 结算单据"这条链没有断的动作。模块发布前平台本身会跑一遍预检（页面、接口、权限挂载），那层预检管的是"模块能不能用"，不管"你的业务口径对不对"，两者都要过。预检与发布流程见 模块的测试与发布：预检、挂载菜单与移动端同步。

五、之后怎么延伸：这套工时能喂给三个地方

工时台账一旦跑起来，最值钱的地方是它能给别的账当底稿。三个延伸方向，按落地顺序排：

1. 往上接项目台账 —— 项目台账管项目的进度、里程碑与整体投入；本文这套提供"人在这上面投入了多少小时、按什么级别"。两张表通过项目编号挂在一起，项目台账就能看到"进度到 60%、人天已用 80%"这类真实对照。谁负责哪张表、哪两个字段对齐，见 项目台账：进度、投入与里程碑一本账。

2. 往下接薪资核算 —— 可计费工时、加班工时、项目奖金基数，都能从工时明细汇总出来交给薪资核算，不必让 HR 再手工统计一遍。两边口径要对齐一件事：工时台账记的是"投入项目的时间"，薪资核算要的是"计薪口径的工时"，中间可能差着请假与加班规则，别直接相等。参考 薪资核算与发放：从考勤绩效到工资条。

3. 往财务侧接应收与开票 —— 结算单确认后，作为开票申请与应收挂账的依据，客户回款进度再回到项目视角。这条链上最好只留一处金额源头（结算单），应收与开票都只是引用。见 开票申请与发票台账：开了哪些、进项有没有到 与 应收应付：老板最关心的一本账，业务台账怎么建。

六、这套方案不做什么

写清边界，比多列几个功能更有用。以下这些不在本文这套模块的能力范围内，上线前别指望它：

• 不做人天估算与智能预测。系统不会替你判断"这个项目该报 40 人天还是 70 人天"，它只忠实记录已经发生的投入，并让下一次估得更准。
• 不做自动排班与资源调度优化。谁该去哪个项目、哪个顾问手上有空，这类调配靠人判断，系统只提供"谁在哪个项目上投了多少天"的事实。
• 不接考勤机、门禁与人脸识别硬件。工时是员工自报的业务记录，不是打卡记录；两者口径不同，也不该互相顶替。
• 不做电子签章。客户确认那一步，系统记录"谁在什么时候确认/提了什么异议"，纸质签字件可以拍照作为附件挂上去，但不做数字签名。
• 不与客户侧系统直连对账。结算依据的交付方式是按需导出或发送，客户那边的系统里怎么走账，不是这套模块的事。
• 不承诺离线填报。现场没网就走纸质兜底，事后补填并如实填写实际发生日期。
• 不内置任何法定或行业默认的人天上限、费率与结算周期。这些数值因公司、地区、项目类型而异，全部作为配置项由你的管理口径填进去；填什么就是什么，系统不替你设定"标准值"。

把边界放在明面上，是因为这类系统最容易在上线第一个月被寄予过高期望：以为它能估工期、能优化人力、能自动跟客户对账。它做不到这些。它能做到的是——任何一个项目，任何一天的工时，都能查到是谁、做了什么、算不算钱、按哪一版费率算的；月末的结算单，加得起来、对得上、拿得出手。