打开几乎任何一家经营困难的小企业的会计科目表，你都会发现同样的情况：280 个科目，其中 90 个仅使用过一次，有十几种“办公用品”的变体，还有三个没人能解释清楚的科目。老板能准确地告诉你 2022 年在某个特定供应商那里花了多少钱，却说不清上个季度生意是否盈利。
这就是臃肿的会计科目表所带来的悖论。更多的科目看似能提供更多信息。但在实践中，它们的效果恰恰相反——产生的损益表过于细碎且缺乏一致性，以至于没人读得懂。一个好的会计科目表不是一个给每样东西都准备了抽屉的档案柜。它是一个报告工具，就像任何工具一样，只有在为了回答特定问题而构建时，它的效果才最好。
本指南将介绍如何设计一个真正能提供有效信息的会计科目表：如何对其进行编号，嵌套深度应该是多少，何时使用子科目而不是部门或类别，以及如何识别并削减那些让财务报表在不知不觉中失去价值的臃肿科目。
会计科目表的真正用途
会计科目表 (COA) 是企业用于记录资金往来的所有类别的总清单。你记录的每笔交易都会落入这些科目之一，而每个科目最终都会汇总到两份报告之一：资产负债表或损益表。
科目分为五大类，这个顺序并非随意安排——它反映了财务报表的结构：
- 资产 (Assets) —— 企业拥有的财物：现金、应收账款、设备、存货。
- 负债 (Liabilities) —— 企业欠下的债务：应付账款、贷款、信用卡、未缴税款。
- 权益 (Equity) —— 所有者的剩余权益：投入资本、留存收益、分红。
- 收入 (Revenue) —— 企业通过经营活动赚取的钱。
- 支出 (Expenses) —— 企业为运营而花费的钱，包括所售商品的直接成本。
前三类构建了资产负债表。后两类构建了损益表。你在设计 COA 时所做的一切，都是为了让这两份报表能够一目了然。
衡量会计科目表好坏的标准很简单：当你打印损益表时，你是否能看着任何一行并知道该为此做些什么？如果一行写着“杂项 —— $14,200”，答案就是否定的。那个科目没有告诉你任何信息，它在掩盖信息。
编号：在挂任何东西之前，先搭好框架
科目编号是骨架。即使你的会计软件允许你仅使用名称，编号方案也能保持科目顺序的可预测性，并使 COA 易于扫描。
近乎通用的惯例是按类别以一千为单位对科目进行分组：
| 范围 | 科目类别 |
|---|---|
| 1000–1999 | 资产 |
| 2000–2999 | 负债 |
| 3000–3999 | 权益 |
| 4000–4999 | 收入 |
| 5000–5999 | 销货成本 |
| 6000–7999 | 经营费用 |
| 8000–9999 | 其他收入与支出 |
大多数小企业使用四位数字就足够了。如果你规模非常小且预计保持不变，三位数字方案也可以，但四位数字几乎没有额外成本，且预留了更多空间。
两条规则能让编号方案在现实应用中经受住考验：
留出间隔编号。 不要分配 6000, 6001, 6002。要分配 6000, 6010, 6020 —— 对于大类甚至可以分配 6100, 6200, 6300。当你不可避免地需要在两个现有科目之间增加新科目时，你可以将其插入间隔，而不是重新编写其下所有科目的编号。留出空间是 COA 设计中最省钱的决策，而忘记这样做则是最常见的遗憾。
保持首位数字的一致性。 6000 系列的数字必须始终是经营费用。一旦有人因为“离得近”而将负债归入 5000 系列编号，你的报表就会失去勾稽关系，你的编号方案也就失去了它唯一的作用。
应该嵌套多深？臃肿问题
这是大多数会计科目表出错的地方。企业里的某人提出了一个合理的问题——“我们在软件上花了多少钱？”——下意识的反应就是创建一个新科目。然后是另一个。接着为每个软件供应商创建一个单独的科目。COA 在被动反应中增长，一次增加一个初衷良好的科目，直到它变得无法阅读。
这就是 COA 臃肿：为了满足本应通过其他方式处理的报告需求而创建的分类账科目的失控增长。其机制总是一样的——有人想要一个新的数据切片，于是增加了一个新科目，而不是增加一个新的属性。
臃肿的代价往往容易被忽视：
- 编码不一致。 如果有 12 个看似合理的科目可以记录软件费用，两个簿记员（或者同一个簿记员在两天内）会做出不同的选择。你的趋势线变成了噪音。
- 报表不可读。 一份拥有 140 行费用明细的损益表并不比 30 行的提供更多信息。它的信息量反而更少，因为没有人能同时在脑子里记住 140 个数字。
- 结账缓慢。 每个科目都需要审核、对账和解释。臃肿会让五天的结账流程变成三周。
- 死科目。 臃肿的科目表中有一半是只用过一次就被遗弃的科目，每一个都是未来可能发生编码错误的陷阱。
作为一个粗略的基准，大多数小企业总共需要 30 到 60 个科目。少量的收入科目，清晰划分的销货成本，20 到 30 个经营费用科目，以及企业实际拥有的资产负债表科目。如果你的科目表有 200 个科目，而你的公司只有 8 名员工，那么这个表描述的不是你的业务，而是所有人曾经问过的每一个问题。
防止臃肿的原则是在增加每个新科目之前问一个问题：“我会因为这一行的存在而做出不同的决定吗？” 如果将“市场推广”拆分为“Facebook 广告”和“Google 广告”会改变你的预算分配方式，那就拆分它。如果你只是扫一眼这两个数字然后继续，那就把它们放在一起。一个科目应该通过改变决策来赢得它在表中的位置，而不是因为它在理论上是独特的。
以账户作为结构，以维度体现细节
大多数账目臃肿都可以追溯到一个错误：使用账户来捕捉那些不属于账户范畴的事物。
企业不仅想知道钱花在了什么地方，还想知道花在哪里、哪个项目、哪个地点以及哪个客户身上。回答这些问题的错误方法是不断增加账户：
6100 工资 — 销售
6101 工资 — 研发
6102 工资 — 运营
6110 差旅 — 销售
6111 差旅 — 研发
6112 差旅 — 运营
6120 软件 — 销售
...三个部门加上三种费用类型就产生了九个账户，而且在不进行加总的情况下，会计科目表（COA）仍然无法告诉你工资总额。再增加第四个部门，你就得再次修改科目表。
正确的方法是每种费用类型只保留一个账户，并为每笔交易标记其他事实：
6100 工资
6110 差旅
6120 软件部门（销售、研发、运营）是交易中的一个独立字段。不同的会计软件对该字段有不同的称呼：QuickBooks 中称为类别（class）或位置（location），Xero 中称为跟踪类别（tracking category），Sage Intacct 和 NetSuite 中则称为维度（dimension）。其原理是完全相同的：账户回答了费用的种类，而维度回答了业务的归属。
这种分离具有复合收益。通过一个“工资”账户外加一个“部门”维度，你可以得出工资总额、按部门划分的工资、差旅总额、按部门划分的差旅以及按部门划分的总支出——所有这些都来自同一组数据，无需手动计算。而使用九个重复账户，你只能得到其中一种视图，其余的必须手动求和。
一个实用的经验法则是：如果一个标签描述的是资金的本质，它就是一个账户；如果它描述的是资金发生的背景——如部门、项目、地点、客户、拨款、融资轮次——它就是一个维度。纯文本记账工具直接应用了这一理念：在 Beancount 中，你可以利用元数据（metadata）为分录添加标签，或利用账户层级结构，并让报告层对数据进行切片分析，而不是将每种组合都硬编码到科目表本身。
子账户：适度使用方显成效
子账户（将子账户嵌套在父账户下）是细节的一种合法且具有结构性的形式。例如，在 6200 保险 下设立子账户 6210 综合责任险、6220 工伤保险 和 6230 医疗保险 是合理的：这些是性质截然不同的成本，其表现各异，管理层可能会针对每一项采取行动。
子账户在以下情况发挥作用：
- 父账户的总额是你需要报告的内容，且
- 每个子账户都是你会单独调查或采取行动的对象。
当它们细化到超出实际决策层面时，就会变成累赘。将“办公用品”拆分为“纸张”、“笔”、“墨粉”和“便利贴”就没能通过测试——没有人会专门管理便利贴的预算。单一的“办公用品”账户才是合理的细节水平。
两个实际限制：最多保持两个层级——父级和子级——因为第三层几乎总是伪装成账户的维度。另外，永远不要将交易记入含有子账户的父账户中；应当记入子账户并让父账户进行汇总，否则你的报告会出现重复计算。
将销售成本与运营费用分开
对于销售产品或提供收费服务的业务来说，有一个结构性决策比其他任何决策都重要：主营业务成本（COGS）必须作为独立的板块，与运营费用分开。
主营业务成本（COGS）是与交付所售商品或服务直接相关的成本——包括原材料、生产产品的劳务、销售时的商户手续费、计费项目中的分包商费用等。运营费用（Operating expenses）则是企业维持生存的成本——如租金、会计软件订阅费、办公室经理的工资。
这种分离产生了毛利润（gross profit）——即收入减去主营业务成本——这是小企业利润表中最关键的数字。毛利润能告诉你，在计入管理费用之前，你的核心业务本身是否盈利。如果主营业务成本与租金一起混在 6000 序列的账户中，毛利润就无从得知，你也失去了报告中最具行动参考价值的一行。将主营业务成本放在 5000 序列，运营费用放在 6000 序列，报表就会自动为你计算这些结果。
从第一天起保持账目整洁
会计科目表在交易开始发生之前建立时价值最高，而在事后修复则最为痛苦。重组正在使用的科目表意味着要重新映射历史数据，等待时间越长，需要重新映射的历史就越多。
这就是纯文本记账（plain-text accounting）的真正优势所在。由于 Beancount.io 将你的整个账本存储为可读且版本化的文本，重组科目表是一个透明、可审查的变更，而不是“黑盒式”的数据迁移——而且账户层级加元数据的设计，天生就实现了“以账户作为结构，以维度体现细节”的分离。你可以在可视化仪表板 Fava 中探索你的财务数据，同时始终能看到具体变更的内容和原因。免费开始使用，建立一个能够解答疑问而非掩盖问题的会计科目表。
快速检查清单
在你认为会计科目表大功告成之前，请对照以下各项进行检查：
- 科目按类别分块编号，并留有间隙以备未来扩充。
- 销货成本 (COGS) 位于独立的编号区间，与营业费用分开。
- 科目总数与业务规模相匹配——应以十计，而非数百个。
- 每个科目都能影响决策；不存在“以防万一”而设立的科目。
- 部门、项目和地点存在于维度中，而不是通过重复科目来实现。
- 子科目最多细分两层，且永远不在父级科目上直接记账。
- 你每年至少审查一次完整的科目表，并停用废弃科目。
做好这些，你的利润表将不再是堆砌数字的长篇大论。它将回归其本职——一份简明、真实的报告，告诉你哪些环节在正常运作，哪些环节出了问题，以及下一步该往哪看。