Beancount.io LogoBeancount.io

设计一个能真正反映财务状况的会计科目表

阅读需 2 分钟Mike ThriftMike Thrift
设计一个能真正反映财务状况的会计科目表

打开大多数小企业的会计科目表文件,你会发现同样的情况:247 个科目,其中只有十几个有余额,一半是由一个找不到合适类别的疲惫会计在午夜创建的。损益表长达四页。老板看不出公司是否在赚钱。六年没人动过这个结构,因为想到要修理它就让人精疲力竭。

会计科目表(COA)本应是回答一个简单问题的答案:我们的钱从哪里来,又花到了哪里? 当它停止回答这个问题时,财务报表就变成了“墙纸”——一种你打印出来给银行看,然后在一年中剩下的时间里都视而不见的东西。解决方法不是增加更多科目,而是通过有意识的安排来减少科目数量。

本指南将介绍如何设计一个能生成你真正会去阅读的财务报表的会计科目表:如何进行编号,何时使用子科目与维度,如何处理部门和地点,以及如何识别那些将有用报告变成噪音的冗余。

会计科目表的真正用途

会计科目表是你总账的索引。你业务记录的每一笔交易——每一张发票、每一份工资单、每一笔银行手续费——都会进入其中一个科目。然后,这些科目会汇总到构成财务报表的五个类别中:

  • 资产 (1000s) — 企业拥有的东西:现金、应收账款、设备、预付费用。
  • 负债 (2000s) — 企业欠下的东西:应付账款、信用卡、贷款、递延收入。
  • 所有者权益 (3000s) — 所有者对企业的主张:资本投入、留存收益、分红。
  • 收入 (4000s) — 客户支付给你的钱。
  • 费用 (5000s, 6000s, 7000s) — 赚取这些收入所产生的成本。营业成本通常在 5000 段;营业费用在 6000 段;非营业项目(如利息支出)通常位于 7000 段。

这种五大类结构是通用的。咖啡店、SaaS 创业公司、私人基金会和货运代理商都使用同样的五个类别。不同之处在于每个类别内部的粒度——而这正是大多数会计科目表偏离正轨的地方。

编号:留出增长空间

编号惯例比看起来更重要。一个好的方案能让读者扫一眼任何交易行,就能不加思索地了解其类别。而糟糕的方案则迫使每位会计都要死记硬背一套自定义的映射表。

最常见的惯例是四位数系统:第一位数字代表类型,其余三位为你提供该类型下的 999 个槽位。三位数系统适用于非常小的企业,但四位数系统的成本几乎为零,且能避免每个成长型公司都会遇到的重新编号工程。如果你希望在多实体集团中为公司或实体设置前导数字,五位数系统会非常有用。

这是每次都能拯救你的诀窍:留出空隙。以 10 或 20 为增量为你的科目编号。

1000  现金
1010  支票账户 — 运营
1020  支票账户 — 工资
1030  储蓄账户
1040  货币市场账户

六个月后,当你开设一个新的高收益账户时,你可以将其插入 1015,而无需重新编号下游的任何科目。像 QuickBooks 这样的软件允许你按科目编号排序,因此新科目会自动插入到正确的位置。顺序编号(1000, 1001, 1002)看起来很整齐,但它会迫使你每次增加科目时都要重新编号,或者忍受不再反映业务思路的排序。

一个小企业的实用编号图如下:

  • 1000–1099 现金及现金等价物
  • 1100–1199 应收账款及备抵
  • 1200–1299 存货
  • 1300–1499 预付费用、押金及其他流动资产
  • 1500–1799 固定资产及累计折旧
  • 1800–1999 无形资产、长期资产
  • 2000–2099 应付账款
  • 2100–2199 应计负债(薪资、税收、利息)
  • 2200–2399 信用卡
  • 2400–2499 短期贷款及长期负债的流动部分
  • 2500–2999 长期负债、递延收入
  • 3000–3999 所有者权益(成员出资、留存收益、分红)
  • 4000–4999 收入
  • 5000–5999 营业成本
  • 6000–6999 营业费用
  • 7000–7999 其他收入和费用(利息、资产处置收益、税费)

这只是一个起点,而非金科玉律。关键在于每个范围都有明确的含义,并且每个范围内都有空间添加科目而不会挤占下一个类别。

从小规模开始,甚至小到令人尴尬

新企业主最常犯的错误就是照搬模板,开启包含 80 个科目的账簿。其中 60 个他们永远不会用到。这 60 个闲置科目并不是免费的——它们让每笔交易的编码更难,让每次对账更慢,让每份报告更长。

一个独立顾问运行业务可能只需要大约 20 个科目:一个现金账户、一张信用卡、应收账款、几行收入、如果有的话再加上工资单,以及十几个经常性的经营类别(租金、软件、承包商、差旅、餐费、专业费用、营销、税费、银行手续费)。这就是全部了。只有当业务确实需要一个新类别时才添加科目,而不是为了预测某天可能会做的事情而添加。

测试一个科目是否值得存在的标准很简单:我是否会因为这个科目的独立存在而做出不同的决策? 如果是,保留它。如果不是,将其并入父级科目。

“办公用品”是一个科目。“笔”不是一个科目。

子科目:可以使用,但要限制深度

当你需要同时查看明细和汇总时,子科目非常有用。最经典的例子是差旅费:

6400  差旅费
6410   差旅费 — 机票
6420   差旅费 — 住宿
6430   差旅费 — 地面交通
6440   差旅费 — 餐饮

在损益表(P&L)上,你可以显示所有四个子科目以查看构成比例,也可以为银行将其折叠为单行“差旅费”。这种父子关系让你能从同一套日记账分录中获得两种视角。

让子科目保持规范的经验法则是:层级不超过三层。超过三层,你是在构建数据库,而不是会计科目表。如果你发现自己想要四层或五层,你真正需要的不是更深的科目表,而是维度(Dimensions)。

何时使用维度而非更多科目

这是大多数小企业陷入困境的地方。

你经营着三个地点。你有五条产品线。你服务于两个客户群体。于是你创建了:

6010  房租 — 地点 A
6011  房租 — 地点 B
6012  房租 — 地点 C
6110  市场推广 — 产品线 1
6111  市场推广 — 产品线 2
...

当你将会计科目结构与地点、产品线和客户群体进行交叉组合时,你会得到一个无法管理的矩阵和一个拥有 600 个科目的科目表。每一个新地点都会触发一波新科目的产生。每个科目都必须被记住、被一致使用,并培训给每一位新员工。

更简洁的模式是维度会计(Dimensional Accounting):保持科目表精简,并为每笔交易标记地点、项目、部门或客户等属性。大多数现代会计平台通过类别(Classes)、标签(Tags)、项目(Projects)、地点(Locations)或自定义段(Custom Segments)来支持这一点。像 Beancount 这样的纯文本会计工具通过在每条过账(Posting)上使用元数据(Metadata)和命名标签来原生支持这一功能。

维度化方法将:

6010 房租 — 地点 A
6011 房租 — 地点 B
6012 房租 — 地点 C

转变为:

6010 房租  [location: A]
6010 房租  [location: B]
6010 房租  [location: C]

一个科目,三份报告。当你开设地点 D 时,你不需要对科目表做任何改动——只需开始为新交易打上 location: D 的标签。会计科目表保持整洁,而报表变得更加丰富。

科目与维度之间的划分遵循一个简单的原则:会计科目表回答发生了什么类型的事情。维度回答在哪里发生、为谁发生以及关于什么。 无论地点在哪里,房租就是房租。无论部门在哪里,工资就是工资。“事情的类别”进入科目,“上下文信息”进入维度。

值得借鉴的行业模式

虽然每个企业最终都会自定义其科目表(COA),但某些模式会按行业重复出现,复制这些模式比重新发明要廉价得多。

零售与电子商务

存货占据主导地位。你需要在存货下设立子科目,分别对应原材料、在途物资、库存商品和退货。销售成本(COGS)需要将商品成本与进货运费、支付处理费和损耗区分开。运输收入和运输支出通常各占一个科目,因为总额与净额的区别对毛利分析至关重要。

服务与咨询

存货缩减到几乎为零。收入按服务类型(固定费用、小时计费、预留费)进行细分,以便查看哪种参与模式真正盈利。分包商成本和专业执照通常需要独立科目,因为它们金额大、变动性强且与决策相关。

SaaS 与订阅

由于 ASC 606 标准,你的资产负债表上会出现递延收入、应计收入和递延合同成本。收入科目分为订阅收入、实施/一次性收入和按量计费收入。在支出方面,托管/基础设施通常值得拥有一个独立的运营支出行,而不是埋没在“软件”中。

非营利组织

净资产取代了所有者权益,科目表分为非限定性、暂时限定性和永久限定性。支出必须能够按功能(项目、管理、筹款)报告,以便填写 Form 990 和进行审计财务报表。大多数非营利组织使用部门或类别维度来处理功能拆分,而不是将每个费用科目都复制三份。

选择最接近的模式,将其简化,然后在此基础上进行自定义。

臃肿测试:年终清理仪式

会计科目表的腐化方式与抽屉如出一辙。有人在晚上 11 点将一次 Costco 采购归入一个新的“办公室零食”科目。六个月后,“零食”、“茶歇”和“厨房用品”都共存着,没人记得哪个才是标准的。这种偏移是渐进且无形的,直到你试图针对一个存在于三个地方的类别制定预算时才会发现。

每年一月运行一次此清理仪式,如果你的簿记员经常轮换,则每季度运行一次:

  1. 生成试算平衡表。全年余额为零的任何科目都是停用的候选对象。
  2. 生成显示所有科目的损益表,按金额排序。任何低于有意义阈值的科目(对于小企业,通常是 1,000 美元以下)都是合并到父级科目的候选对象。
  3. 查找重复项。“软件订阅”、“SaaS 工具”和“在线服务”可能应该是一个科目。选择一个并将其余的合并进去。
  4. 检查子科目深度。任何超过三层的地方,询问最深的一层是否真的是一个科目,还是应该是一个维度/标签/类别。
  5. 记录科目表。每个科目的一行说明是决定科目表能延续到下一任簿记员,还是每次有新人加入都要重建的关键。

会计师按小时收费。整洁的科目表每个月都能降低结算成本,并且每年都能降低审计和税务申报成本。

为什么簿记规范比科目表本身更重要

即使是设计得再完美的会计科目表,其价值也仅取决于背后的簿记执行力。不一致的归类会使原本清晰的五页科目表变得一团糟:由于没有对新员工进行培训,营销费用被拆分到三个不同的账户中;业主提款在一个月被归类为利润分配,下个月又被归类为薪资;销货成本(COGS)项目由于簿记员的猜测而被记入运营支出。报告开始失真。

保持科目表实用性的规范并不显眼:一份书面的归类指南,以便每位簿记员都能以相同的方式解读科目表;一次月末结账,在偏差累积之前及时发现;以及版本控制记录,以便你可以追溯某个账户被添加、重命名或停用的原因。那些将账本视为“活文档”而非年终税务任务的企业,能够从同样的科目表中获得有价值的报告,而其他人得到的只是噪音。

纯文本会计让规范变得更简单

上述许多科目表问题实际上是工具问题。拥有 247 个选项的下拉菜单很容易误点。包含大量预设账户的模板会导致冗余。将科目表(COA)隐藏在 UI 界面后的软件让人难以查看整体结构。

纯文本会计改变了这一点。会计科目表只是一个文件中的账户名称列表,你可以在 30 秒内从头到尾读完。层级结构通过名称中的冒号体现:Expenses:Travel:Airfare 自动成为 Expenses:Travel 的子账户,并最终汇总到 Expenses。维度是单个分录上的标签,而不是硬编码的段。科目表的每一次变动都会显示在 git diff 中,并附带解释原因的提交消息。年终清理只是一个合并请求(pull request),而不是在 QuickBooks 中度过一个压力山大的周末。

如果你能在一个屏幕内看全你的会计科目表,你就能保持它的准确。如果做不到,结构可能已经失控了。

从第一天起保持账目真实

会计科目表是一个具有巨大杠杆作用的小工具。把它做对,你的月末结账、税务申报、与银行的预算沟通,以及关于如何投入每一分钱的决策都会变得更容易。把它做错,上述每一个流程都会永远变得更加困难。

Beancount.io 提供纯文本会计服务,让简洁、有条理的科目表成为默认标准而非特例 —— 透明、受版本控制且适配 AI。免费开始使用,亲身体验为什么开发者和财务团队正转向他们真正读得懂的纯文本会计。