在线费用汇总表的关键不是把 Excel 原样搬进浏览器，而是让明细、科目主数据和汇总结果保持联动。SpreadJS 19.1 中，XLOOKUP 可以根据科目编码补齐名称和类别，SUMIFS 可以按部门、审批状态和费用类别汇总金额。两者结合，能搭出一张可追溯、可复核的费用表；但权限、审批和正式入账仍须由后端系统负责。

手工汇总为什么容易失控

很多费用月报从多份部门明细开始。财务先复制到总表，再查科目名称、调整费用类别，最后用筛选或计算器汇总。只要有人新增一行、改了科目编码，或者忘记更新公式范围，汇总结果就可能与明细脱节。表面上是一张熟悉的 Excel，实际上缺少统一数据源、稳定引用和变更记录。

在线化可以把流程拆成三张表：科目表保存编码、名称和类别；费用明细保存日期、部门、科目编码、状态和金额；费用汇总只读取前两张表并计算。XLOOKUP 负责“这条明细属于什么科目”，SUMIFS 负责“满足这些条件的金额合计是多少”。职责清楚后，错误也更容易定位。

上图来自本文配套的 SpreadJS HTML 示例。截图在 19.1 评估环境中实际运行生成，展示费用明细、公式结果和待核对科目；正式发布时应使用项目合法授权环境复核并更新无评估水印截图。

先把字段和口径定下来

科目编码应是稳定键，名称和类别属于可维护属性。费用明细至少要有单据编号、业务日期、部门、科目编码、审批状态和金额。汇总表则明确维度与条件，例如“华东事业部、已审批、差旅费”。如果“已审批”还有已复核、已入账等后续状态，必须提前确定哪一种状态可以进入月报。

金额也要明确含税与否，日期要明确按申请日、审批日还是入账日。SUMIFS 只会严格执行条件，不会判断条件是否符合财务制度。XLOOKUP 能返回匹配结果，也不会识别同一个科目编码是否被错误地维护了两次。

为什么优先使用结构化引用

传统公式常写成固定范围。明细增长到范围之外，新记录便不会被统计。SpreadJS 支持 Table 的结构化引用，可以用表名和列名表达区域，例如 ExpenseTable[金额]。它比一串坐标更容易阅读，也能减少新增记录后忘记扩展范围的问题。

结构化引用仍依赖稳定的表名与列名。列标题包含特殊字符时需要按官方规则转义；模板升级时也要测试重命名和插列行为。它提高可维护性，但并不会自动修复错误的业务字段。

用 XLOOKUP 补齐科目信息

XLOOKUP 的基本结构是查找值、查找区域、返回区域以及可选的未找到结果。官方文档说明默认匹配模式为精确匹配。费用明细中应坚持精确查找科目编码，避免用近似匹配把错误编码映射到相邻科目。

=XLOOKUP([@科目编码],SubjectTable[科目编码],SubjectTable[科目名称],"待核对")

还可以用相同方式返回费用类别。把未匹配结果写成“待核对”，比返回空白更利于财务发现问题。正式提交前，应阻止含待核对科目的记录进入汇总或审批。查找区域与返回区域维度必须兼容，否则会得到公式错误。

用 SUMIFS 汇总多重条件

SUMIFS 先指定求和区域，再按“条件区域、条件”成对追加。下面的公式汇总指定部门、已审批状态和费用类别的金额：

=SUMIFS(ExpenseTable[金额],
        ExpenseTable[部门],A2,
        ExpenseTable[审批状态],"已审批",
        ExpenseTable[费用类别],B2)

所有区域必须描述同一批记录。部门名称、状态枚举和费用类别也要与明细完全一致。若要按月份统计，还应增加明确的起止日期条件，避免用“当前月”这类随时间变化但不可追溯的表达。

在 SpreadJS 19.1 中建立三张表

核心包已经包含本篇所需的普通工作表、Table 与公式计算能力，无须加载 AI 插件或 ReportSheet：

import * as GC from '@grapecity-software/spread-sheets';
import '@grapecity-software/spread-sheets/styles/gc.spread.sheets.excel2013white.css';
​
const spread = new GC.Spread.Sheets.Workbook('ss', { sheetCount: 3 });
const subjects = spread.getSheet(0);
const detail = spread.getSheet(1);
const summary = spread.getSheet(2);
subjects.name('科目表');
detail.name('费用明细');
summary.name('费用汇总');
​
const subjectData = [
  ['科目编码', '科目名称', '费用类别'],
  ['6601', '差旅费', '差旅'],
  ['6602', '业务招待费', '招待']
];
subjects.setArray(0, 0, subjectData);
subjects.tables.add('SubjectTable', 0, 0,
  subjectData.length, subjectData[0].length);
​
const expenseData = [
  ['单据编号', '日期', '部门', '科目编码', '审批状态', '金额', '科目名称', '费用类别'],
  ['BX-001', new Date(2026, 7, 5), '华东事业部', '6601', '已审批', 3200, null, null],
  ['BX-002', new Date(2026, 7, 8), '华东事业部', '6602', '待审批', 1800, null, null]
];
detail.setArray(0, 0, expenseData);
const expenseTable = detail.tables.add('ExpenseTable', 0, 0,
  expenseData.length, expenseData[0].length);
expenseTable.setColumnDataFormula(6,
  '=XLOOKUP([@科目编码],SubjectTable[科目编码],SubjectTable[科目名称],"待核对")');
expenseTable.setColumnDataFormula(7,
  '=XLOOKUP([@科目编码],SubjectTable[科目编码],SubjectTable[费用类别],"待核对")');
​
summary.setArray(0, 0, [
  ['部门', '费用类别', '已审批金额'],
  ['华东事业部', '差旅', null],
  ['华东事业部', '招待', null]
]);
summary.setFormula(1, 2,
  '=SUMIFS(ExpenseTable[金额],ExpenseTable[部门],A2,ExpenseTable[审批状态],"已审批",ExpenseTable[费用类别],B2)');
summary.setFormula(2, 2,
  '=SUMIFS(ExpenseTable[金额],ExpenseTable[部门],A3,ExpenseTable[审批状态],"已审批",ExpenseTable[费用类别],B3)');

setColumnDataFormula() 为 Table 数据列设置公式，列索引从零开始；setFormula() 则把公式写入指定工作表单元格。结构化引用中的表名在工作簿范围内被公式使用，因此命名必须唯一、稳定并经过模板测试。

上线前重点检查四类问题

第一类是主数据问题：空编码、重复编码、停用科目和未匹配结果。第二类是汇总问题：条件区域长度不一致、状态文本不统一、负数冲销是否纳入以及月份边界。第三类是权限问题：用户只能编辑授权部门和期间，前端锁定不能代替服务端鉴权。第四类是版本问题：科目名称或类别变化后，历史报表应使用当期快照还是最新主数据，必须由制度决定。

建议准备一组可手算样例，包含已审批、待审批、跨部门、未知科目、负数金额和月末记录。逐项比较明细合计、分类汇总和预期值。新增明细行、修改科目映射、重命名列和重新加载数据后，都要重新检查结果。

月度汇总不要只判断“月份相等”

实际费用表通常还要限定统计期间。简单提取月份会把不同年份的八月混在一起，更稳妥的方式是为汇总表准备期间开始日和下一期间开始日，再让 SUMIFS 同时判断业务日期大于等于开始日、小于下一期间开始日。采用左闭右开的区间，可以避免带时间值的月末记录因截止时刻不同而被漏掉。

但日期条件正确之前，要先确定使用哪一个日期字段。报销申请日、审批完成日、付款日和入账日可能落在不同月份。技术人员不能擅自选择看起来最方便的一列；财务应明确月报口径，后端则保证该字段在状态变化时受到控制。跨期调整、冲销和补录也要有单独规则，不能简单修改原单日期来“挪动”报表结果。

汇总表最好显示当前数据截止时间、统计期间、审批状态范围和异常记录数量。读者看到一个金额时，能够同时知道它来自哪批数据。如果存在待核对科目，可以显示明确警告，并阻止报表进入正式确认。这样，公式结果不仅可计算，也具有可解释的上下文。

科目表更新后，历史结果是否应该变化

XLOOKUP 默认读取当前科目表。如果某个科目从“管理费用”调整为“销售费用”，历史明细在重新计算后可能随之改变。这种变化有时符合管理分析需要，有时却破坏已关账报表。因此系统应先决定采用“始终读取最新主数据”，还是在费用提交时保存科目名称、类别和主数据版本快照。

对于已关账期间，通常更需要稳定和可追溯。可以保留当期映射快照，后续科目调整只影响新期间；对于实时经营看板，则可能允许按最新分类重新归集，但要标明重算时间和规则版本。无论选择哪一种，不能仅依赖工作簿当前显示结果作为历史凭证。

主数据维护也需要校验唯一性。XLOOKUP 默认精确匹配并返回找到的结果，但重复编码本身就是治理问题。后端在保存科目表时应拒绝重复键，记录启停日期和修改人；浏览器端则提示未知、停用或不适用于当前组织的科目。通过公式发现异常之后，真正修复仍要回到权威主数据，而不是在明细中手工改一个显示名称。

SpreadJS 负责浏览器中的表格交互和公式计算；后端负责权限、审批状态、正式校验、持久化与审计；数据库保存权威数据；财务负责人维护科目和汇总口径。MCP 仅在开发写作阶段帮助核验 19.1 API，不属于用户页面的运行链路。

结语

SUMIFS 与 XLOOKUP 的价值，不只是少写几段 JavaScript，而是把“主数据关联”和“条件汇总”变成财务与开发都能阅读、检查的规则。再配合稳定的表结构、异常拦截、服务端权限和版本记录，费用汇总表才能从一次性文件升级为可治理的在线业务工具。