会计科目表设计

会计科目表的用途

会计科目表是企业每一笔交易最终归入的那一组“桶”。它决定了财务报表能说明什么、报告能回答哪些问题，以及从一笔交易入账到得出一个有用的数字之间还需要多少手工工作。它是任何会计系统中影响最深远的一项配置，却几乎总是在实施期间由恰好有空的人匆忙设计出来的。

它之所以值得更加用心，是因为成本不对称。好好设计只需几天的思考；日后再修正，代价是历史数据的可比性、每一个集成接口的映射工作，以及与审计师的一番沟通。几乎每一家使用同一系统超过五年的企业，都背着一套自己不会再这样设计、却又难以轻易修改的会计科目表。

核心的设计问题看似简单：什么应该放进科目代码，什么应该放在别处？几乎所有会计科目表的失败，都是对这个问题的回答把太多东西塞进了科目代码。要理解其中原因，需要先弄清楚科目到底是什么。

科目回答的问题是：这是一种什么性质的东西。租金费用、应收账款、商品销售收入。它描述的是金额的性质，这也是它唯一应当回答的问题。发生在哪里、为谁发生、属于哪个项目、哪个部门、哪条产品线：这些都是真实存在的问题，但没有一个是关于金额性质的问题。

科目泛滥的失败模式

世界上最常见的会计科目表大致是这样的。有一个租金科目。后来企业开了第二家分店，于是有了一号分店租金和二号分店租金。接着有人想按部门查看租金，于是这些科目又各自拆分。然后出现了一个新的成本中心，经营费用区间内的每一个科目都为它复制了一份。几年之内就有了四千个科目，其中大多数一年里只有三个月有余额。

这种失败不会明显地暴露出来，而是让事情逐渐变得不可能。合并报告需要把数百个科目加总，每新开一家分店，报告就得重建一次。比较各分店意味着比较不同的科目代码，而任何标准报表都做不到这一点。关闭一家分店会留下二十个废弃科目，因为带有历史数据而无法删除。新增一家分店意味着要新建二十个科目，还要记得把它们加进每一张报表、每一份预算、每一个映射。终有一天，有人把二号分店的租金记到了一号分店的科目里，而这个错误在合并总数中根本看不出来。

更深层的代价在于，这种结构把一个关于企业的事实硬编码进了总账。分店、部门和产品线都会变化：它们会合并、拆分、更名、重组。每发生一次，在结构上编码了它们的会计科目表就必须重建一次，而历史数据恰恰在有人想要比较的时候变得无法比较。

需要警惕的症状是重复。如果您浏览科目列表时，看到同一个词隔一段就出现一次，租金、租金、租金，工资、工资、工资，那么这个重复出现的概念就不是一种费用类别。它是企业的一个维度，只是因为没有别的地方可放，才被硬塞进了科目代码。

科目与维度

过去二十年间开发的几乎所有会计系统，都支持在科目代码之外随过账记录附加属性，名称各异，如维度、段、分析代码、标签、成本中心或跟踪类别，国内也常称为辅助核算。一笔过账包含一个科目以及一个或多个维度值，报告可以按科目、按维度或同时按两者生成。

这彻底改变了设计问题。租金是一个科目。分店是一个维度，每家分店对应一个值。二号分店的租金不是一个单独的科目，而是按二号分店筛选后的租金科目。新增一家分店只增加一个维度值，而不是二十个科目。关闭一家分店只需停用一个值。比较各分店是一张带分组的标准报表，而不是专门定制开发。科目列表也保持在应有的规模，对大多数中型企业来说是几百个，而不是几千个。

判断某样东西应作为科目还是维度，要看它改变的是金额的性质还是金额的背景。利雅得的租金和吉达的租金是发生在不同地点的同一类成本，因此地点是维度。租金费用和工资费用是不同类别的成本，因此是不同的科目。一贯地运用这一检验，就能在大部分科目泛滥发生之前将其消除。

关于维度有两点提醒。第一，只有在维度有意义的地方把它设为必填，它才有用；如果某个维度只在百分之八十的过账中填写，生成的报告就会有一个无法解释的剩余部分，而这个剩余部分摧毁人们对报告的信任，比根本没有报告还要快。第二，不要因为系统允许设十个维度就定义十个。每个维度都是一个需要有人在每笔交易上正确填写的字段，一个没有填写的维度比不存在的维度更糟。

• 分店、地点、场所或门店：维度。无论发生在哪里，成本都是同一类成本。
• 部门、成本中心或职能：维度。它决定的是谁负责，而不是买了什么。
• 项目、工单或合同：维度，而且往往是报告价值最高的那个维度。
• 产品线、服务线或业务分部：维度，也是大多数分部报告的基础。
• 客户和供应商：根本不是科目。它们属于统驭科目背后的明细账。
• 员工：不是科目。工资明细属于薪酬系统，汇总后再计入总账。
• 法律实体：通常是一套独立的账簿，而不是一个维度，尽管有些系统把它作为一个段来处理。

科目编号

科目编号没有维度设计重要，却比它更容易引起争论。编号方案需要做到的是：从代码就能一眼看出科目类型，留有插入新科目的空间而无须重新编号，并且无须另设映射就能按合理的报表顺序排序。

传统结构按报表分类分组：资产、负债、所有者权益、收入、费用，每类用一个首位数字或一个区间表示，每类之内再为各子类划分子区间。流动资产与非流动资产分开。营业成本与经营费用分开。财务费用与二者都分开。具体区间如何划分，远不如这样两点重要：区间确实存在，且其中的间隔足够宽，可以插入新科目。

科目名称与编号同样值得重视，却几乎没人关注。名称应当足够准确地描述该科目中应包含的内容，使两个人在记同一笔交易时会选择同一个科目。“杂项”“零星”“一般”“其他”这样的名称恰恰保证了他们不会；一个名为“一般费用”的科目会吸收任何人拿不准的东西，而这正是您最需要看清的那部分。

• 使用统一的长度。长短不一的代码排序无法预料，导出到任何将其视为文本的工具时都会出问题。
• 留出间隔。连续编号而不留空间，一年之内就会迫使您要么重新编号，要么出现一个不按顺序的科目。
• 首先按报表分类分组，使科目列表无须额外的映射层就能按报表顺序排列。
• 让子区间保持含义。如果一个科目位于流动资产区间，它就应当是流动资产，不因历史原因保留任何例外。
• 不要在编号中编码维度。一个表示“租金，二号分店”的代码，就是一个伪装起来的维度。
• 不要给现有科目重新编号。代价落在历史数据、集成接口以及每一个记住了代码的人身上，而好处只是表面上的。

统驭科目，以及不得直接过账的科目

有些资产负债表科目汇总的是明细账。应收账款、应付账款、存货、固定资产，通常还有税费，都各有一个总账科目，其余额应等于别处保存的一份明细清单的合计数。这些就是统驭科目（控制科目），而关键的设计决策是：它们不得接受直接过账。

当用户可以把手工凭证直接记入应收账款统驭科目时，统驭科目和明细账就会出现分歧，而这种分歧只有在有人核对时才会被发现。将统驭科目设为不可直接过账，或把直接过账权限限制在少数几位具名的、正在更正已知错误的人员手中，就能把每月一次的检查性控制变成结构性控制。这是大多数实施中成本最低的改进之一，却经常没有配置。

与此相关的一个结构性要点是，并非每个科目都应该可以过账。一套构建良好的科目表设有用于分组和报告的汇总科目（非末级科目），其下才是可过账的明细科目。向汇总科目过账会破坏层级结构，产生一笔出现在合计数中、却不出现在任何组成部分中的余额，这是报表所能做出的最令人困惑的事情之一。

过渡科目同样需要明确设计。已收货未开票、工资过渡、集团内部往来过渡、在途存货和网关结算，都应在设计科目表时就加以定义，载明正常余额状态并指定负责人，而不是日后由第一个需要找地方放东西的人临时创建。临时创建的科目，正是那些永远得不到复核的科目。

按照必须编制的报表来设计

会计科目表应当从它必须支撑的输出倒推设计。通常有四类：法定财务报表、管理报表、纳税申报表，以及母公司或贷款方要求的任何报告。每一类都要求一定的详细程度，而科目表必须容纳其中最细的那一层。

IAS 1 要求在主要报表正表中列示某些项目，并允许对不重要的项目进行汇总，更详细的内容放在附注中。这是一项列报要求，而不是会计科目表要求，但它会推动后者：报表或附注必须单独披露的任何项目，都必须能在总账中被单独识别，无论是作为科目还是作为维度。折旧、职工薪酬费用、财务费用和减值损失是常见的例子；把它们混入笼统类别的科目表，每年都得做一次分析才能完成披露。

税务有其自身的要求，而且与会计要求不同。税前不得扣除的费用（业务招待费是常见的例子），如果从一开始就记入单独的科目，就远比每年再从一般科目中提取出来要容易识别。不得抵扣的进项税额，以及任何适用不同税务处理的类别，也是如此。

管理报告通常想要的恰恰与法定报告相反：结构更少，维度更多。它需要按产品线的毛利、按部门的成本、按分店的贡献，而法定报表对这些都不关心。这正是科目与维度分离之所以是正确架构的原因。科目服务于法定视角，维度服务于管理视角，二者都来自同一批过账，无须另设一套账。

多实体与合并

当一个集团拥有多个法律实体时，最有利的做法是所有实体使用同一套集团会计科目表，只在当地法律确实要求时才增设实体专用科目。这样，合并就变成了对同类科目加总并抵销集团内部往来余额，而不是一项需要每期维护和重新核实的映射工作。

常见的反对意见是各实体情况不同。确实不同，但差异比预想的要小。一家贸易公司和一家服务公司使用的费用结构大体相同。不同的是它们使用了哪些科目，而不是这些科目代表什么。某个实体中未使用的科目不产生任何成本；而各实体之间科目含义不一致，则每月都要付出一次核对的代价，并产生无人能够拆解的合并数字。

如果各实体沿用了不同的科目表（大多数通过收购扩张的集团都会如此），那么用来转换它们的映射层就是一项永久性负担。任何一方科目表发生变化时它都必须维护，它必须经过核实，而且它在合并结果中是不可见的；因此其中的一个错误会导致合并数字出错，而对任何一个实体进行核对都无法发现。统一到共同的科目表，只需一次性付出较高代价，此后成本更低。

集团内部往来科目应当明确并成对设置：针对每个对方实体分别设置应收和应付科目，而不是用一个集团内部往来科目持有与所有实体之间的净额。合并时的抵销取决于知道每笔余额是与哪个实体之间的，而单一科目中的净额不经过进一步分析就无法抵销，这项分析必须有人手工完成。

实际该如何设计

方法很简短，难点在于按部就班地执行，而不是直接跳到科目列表，而后者恰恰是通常的做法。

第六步是发现设计错误的那一步，也是最常被跳过的一步，因为它看起来像重复劳动。其实不是。用一个月的真实交易编制出一份真实的法定报表、一套真实的管理报表和一份真实的纳税计算，一个下午就能揭示出您无法报告的那三件事。那时发现它们不花任何代价；到第四个月才发现，代价就是下文所述的变更。

• 首先列出输出：法定报表、纳税申报表、管理报告、贷款方或母公司的要求。这些决定了最低的详细程度。
• 识别维度。把整个业务过一遍，列出别人会用来切分数字的每一种方式。除非它改变了金额的性质，否则每一种都是一个维度。
• 然后才编写科目列表，从报表结构往下展开，在进一步拆分只能回答维度问题、而非性质问题的那一层停下来。
• 将统驭科目和汇总科目标记为不可过账，并有意识地定义每一个过渡科目，明确其正常状态和负责人。
• 编写过账规则：每种交易类型对应哪个科目，因为审计线索真正丢失的地方正是这个映射层。
• 用去年的数据测试。取一个期间的真实交易，按新结构过账，然后用结果生成全部四类输出。
• 形成书面文件。一份没有配套文件说明每个科目应包含什么的科目列表，一年之内就会被不同的人作出不同的解读。

日后变更的代价

会计科目表确实会变化，而代价并不在变更本身。新建科目轻而易举。代价在于与旧结构相关联的一切，其中大部分从科目列表上是看不出来的。

因此，大多数变更应当是增量式的，而不是结构性的。新增一个科目、从某个财务年度开始起将一个科目拆分为两个（仅对未来生效），或在现有结构之外引入一个维度，都是可控的。对整个科目表重新编号、合并带有历史数据的科目或改变现有科目的含义则不然，其中最后一种最糟，因为没有任何东西会明显出错；报告只是悄然变得不正确。

进行结构性变更的恰当时机是财务年度开始时，要事先规划，新旧结构都要形成文件，映射要永久保留，变更后的第一个期间要双向核对。为了解决一个紧急报告问题而在年中变更，会产生一整年无人能与任何数据比较的账目。

• 历史数据。旧交易留在旧科目中。要么重新映射历史数据，这会改动已过账的期间；要么接受比较数据跨越了一个断点，每一份同比报告都需要一个衔接调整。
• 映射。每一个集成接口、每一条过账规则、每一条银行流水规则、每一笔定期凭证以及每一个导入模板都引用了科目代码，都必须找出来并更新。
• 报表。财务报表格式、管理报表、预算、仪表板，以及任何按代码提取试算平衡表的电子表格都会失效，而且是悄无声息地失效：不是报错，而是漏掉新科目。
• 预算和预测。基于旧结构编制的预算，若没有映射就无法与新结构下的实际数比较，而映射本身又是一个错误来源。
• 人员。每一个给发票编码的人都记住了代码，过渡期会产生错误过账，随后还需要更正。
• 审计。审计师需要了解这次变更，确认重述后的比较数据是一致的，并测试映射。这场沟通应当事先进行，而不是在现场审计时才开始。

设计有误的迹象

大多数企业不会复核自己的会计科目表，因为没有任何事件迫使它们这样做。以下信号说明它正在让您付出代价，而这些信号无须立项就能看到。

这些迹象单独出现都不致命。但几个同时出现，就说明这套结构编码了一些早已发生变化的企业事实，而建立在它之上的每一张报告都在悄悄承担这一代价。

• 同一个词在科目列表中反复出现，这意味着科目代码中承载了一个维度。
• 很大一部分科目在本年度没有任何交易，这意味着这套结构已经比它所描述的组织活得更久。
• 编制管理报表需要一张把科目映射到报表项目的电子表格，而且只由一个人维护。
• 一般费用或杂项费用科目有一笔重大余额，这意味着人们分不清东西应该记到哪里。
• 回答一个常规问题，例如按分店的成本或按产品线的毛利，需要导出数据，而不是运行一张报表。
• 新开一家分店或一个部门是一个配置项目，而不是增加一个维度值。
• 问两个人某项成本记在哪里，得到两个不同的答案。

治理

会计科目表是在时间压力下通过一个个小决定逐渐退化的。有人需要为一项新成本设一个科目，于是新建一个，以供应商名称命名，并往里过账。五年后，这样的科目有两百个，而当初精心设计的结构已被这些无人决定过的东西稀释了。

控制措施很普通，也很有效：新建或修改科目需要由一名具名人员依据书面的结构定义批准，并记录变更。审批人只问一个问题：这个新东西是一种不同性质的金额，还是现有金额的一种不同背景？大多数申请属于后者，答案是一个维度值，而不是一个科目。

Skyline Nexus 将分店和地点记录在交易本身上，每一条总账分录行都关联回生成它的单据，因此按分店的视图是回溯到来源单据的关联查询，而不是用科目代码重建出来的结构。对于任何系统（包括本系统），都值得确切地问一问：总账分录“行”本身存储了哪些维度，哪些维度只存在于来源单据上。这一区别决定了维度报告是直接读取还是重新构建，以及当某种单据类型发生变化时它能否继续成立。这描述的是一个系统保存了什么。它不能替您决定设计，也没有任何系统能阻止一套把本应作为维度的内容编码进科目代码的会计科目表。

• 一份书面的会计科目表文件，说明每个科目应包含的内容，并保持更新。
• 科目的新建和修改受到限制并需批准，同时记录原因。
• 每年复核一次没有发生额的科目，以及任何吸收杂项内容的科目。
• 每当来源系统发生变化时，复核过账规则和映射，因为审计线索正是在这里丢失的。
• 维度值与科目采用同样的方式管理，因为不受控制的维度列表本身就会变成另一种泛滥。

一个合理的默认方案

对于没有特殊报告要求的企业，下面这种形态是可行的，只有在有明确理由时才值得偏离。几百个科目，按报表分类分组，并留有宽裕的间隔。只有在金额性质不同，或法定披露、税务披露有要求时才拆分科目。三到五个维度，通常是分店或地点、部门或成本中心，以及项目。统驭科目和汇总科目不可过账。过渡科目有定义、有负责人。再加上一份关于什么应记在哪里的书面定义。

这种结构能够依据同一批过账、在不借助映射电子表格的情况下，编制出法定报表、可从多个角度切分的管理报表，以及纳税计算。它能经受住新开分店、组织重组和收购，而无须进行结构调整项目。它还能让科目列表保持足够精简，使给发票编码的人能找到正确的科目；归根结底，这正是决定其余一切能否奏效的约束条件。

会计科目表是财务系统中唯一一个花一小时设计就能省下一年工作量的部分，而设计失误的后果显现得如此缓慢，以至于没有人会把它们与原因联系起来。如果您正在实施系统，请花上这几天时间。如果您已经上线，并且认出了上述症状，请把变更安排在年末进行，而不是将就下去，并尽可能采用增量方式。