虾皮利润核算前，先把扣的名目列全

利润核算之前，先把扣的名目列全了

名目列全这件事之所以重要，是因为它决定了后面所有的减法减得干不干净。少列一项，不是少减了一块，而是整条算式都建立在一个偏乐观的前提上。偏乐观的前提不会自己暴露，只会让人一次又一次高估自己能拿到手的钱。

列名目最怕的一种做法是照着手边看得见的部分抄。看得见的部分通常是已经发生并且已经记下来的那些，看不见的部分往往是还没有到结算时点、还挂在预留里的那些。抄完名目表看起来很完整，缺的恰好是时间上最靠后的那几类。

要把名目列全，可以按发生的方向去数，而不是按平台后台的栏目去数。按方向数的时候问三个问题：这笔钱是因为成交产生的，是因为货发出去了产生的，还是因为钱要回来产生的。三种来源各自都会带出一组名目，比对着栏目抄更不容易漏。

按方向数完之后还要再按性质过一遍，看哪些是实时扣的、哪些是周期性归集的、哪些是要等条件满足才放开的。三种节奏混在一起看，很容易把周期性归集的项忘掉，因为它们不在每一单上出现。不在每一单上出现的项，最容易在按单核算时整块丢失。

名目名单要跟账期挂上钩，也就是说每一类名目都要写清它通常在什么时候第一次露面、在什么时候彻底定型。第一次露面的时点写清楚，才知道哪几个月的数还需要留出修补的余地。没有这个时点，你就会以为某个月的数字已经定下来了，实际上它还在变。

名目本身要有一个负责人，不能是所有人都觉得别人会维护。这个人不需要懂所有细节，但要负责在平台规则变化之后第一时间更新名目表，并且把变化通知给用名目表的人。一个人对一份名目表负责，这份名目表才活得下去。

名单里的每一项都该配一个来源，说明这个名目是从哪里看到的、依据是什么。来源可以是一封通知、一页说明、一段后台的截图。配上来源之后，讨论时就不必再争论这个名目到底存不存在。

名目表要允许留出待确认的项，不要为了看起来整齐就把不确定的丢掉。待确认的项单独划一栏，写上为什么还不确定、大概什么时候能确定。这一栏的存在本身就是在提醒后面的人，这份名目表还没有到最后定稿的阶段。

名目列全的标准不是一页纸写满，而是拿一笔真实成交从头对一遍，每一项都能找到落点。对不上或者对不完整的那些地方，就是名目表还缺东西的地方。这种对法比逐条读一遍名目表有效得多，也更容易被人接受，因为它用的是事实而不是判断。

名目表定稿之后要定期回看，至少每个季度一次。回看的时候不必从头重列，只要把上次列完之后新出现的那几类名目补进去，把已经消失的那几类标出来。补和标这两个动作加起来，通常只要半小时，不做的话一年之后名目表就废了。

列名目的时候要克制一种冲动，就是想把所有能想到的都写进去。名目列得太多太杂，会让人失去判断哪些是关键的。较为可行的做法是把名目分成主项与旁项两层，主项全部列出，旁项合并成一类待查，这样名目表既完整又能读。

主项与旁项的分界可以按金额占比来划，也可以按出现频率来划。按金额划适合做核算，按频率划适合做流程管理。两种划法得到的名单不一样，所以要先说明这份名目表是给谁用的，不然会出现两个人都觉得自己那份是对的。

名目要与实际发生额定期勾一次，看名目表上列的每一类是不是真的在本期出现过。半年都没出现过的名目可以从主项降到旁项，连续出现的旁项要升上来。这种升降让名目表一直贴着实际业务走，而不是贴着记忆走。

有人担心名目列全了之后，每一项都要单独处理，工作量会失控。实际情形正好相反，列全之后大部分名目可以直接按类合并，只有少数几类需要单独看。列不全的时候，恰恰是那几类需要在每次核算时临时判断，反复消耗时间。

名目这一段做完，后面才谈得上方法。方法解决的是怎么分、按什么基数分，而名目解决的是分什么。分什么没定清楚就去谈怎么分，讨论会一直在方法之间来回，而真正的漏项始终没有被补上。

五道名目各自独立，一笔钱会被好几道同时切到，切到的先后不影响它们本来都要扣。

哪些要算进去，哪些不该算进去

判断一个项目该不该进这道算式，最实用的一条标准是看它是不是因为这一笔成交才发生的。因为这一笔才发生的，就该算进来；本来就要发生、跟这一笔没有直接因果的，放在另一层去处理更合适，不必硬塞进单笔的账里。

平台的各类扣项基本都属于该算进来的那一侧，因为它们是成交的直接后果。货没卖出去就不会扣，卖出去了就会扣。这种一卖就发生的关系，是判断一个项目该不该进算式最省事的依据。反过来说，凡是与单笔没有这层关系的项，都该放到别的层去处理。

广告与推广投放属于要分清边界的那一类。投给具体某一款的，算到那一款上没有争议。投在整个店铺上、按整体预算走的，硬分到每一单上会产生很大的想象空间。这种时候更诚实的做法是把它留在上一层，而不是摊到单笔。

包装耗材属于容易被忽略但确实该算的项。它跟着每一单走，看起来很小，但它确实是因为这一单才被消耗掉的。把它完全排除在算式之外，会让单品毛利偏乐观；把它按每单一个固定值放进去，又过于粗糙。先把它列出来，方法之后再谈。

人员成本是争议最大的一项。客服、运营、仓管的工资该不该进单笔的算式，取决于你做这道算式是为了什么。为了看某一款商品本身的盈利结构，不该进；为了看这个业务整体赚不赚钱，就该进。目的没说清之前，怎么放都能吵起来。

资金占用带来的成本常常被完全排除在外。备货要先垫钱，垫钱的时间长短会让同样一款商品在不同节奏下表现差很多。这一项不进算式，账面上的毛利排名可能和真实情况相差很远。先把它作为一个明确的项列出来，比含含糊糊不提要好。

退税或者返还类的项目属于反向项，容易被当成意外之喜而完全不进算式。如果它可以预期，就该作为一个正向的项目出现在算式里，而不是等到年底看到一笔钱才想起来。可预期但没进算式的项，会让月份之间的数据很难比较。

平台赔付、保险理赔这一类偶发项目不适合进单笔算式。它们金额不定、发生不定，放进去会让单品毛利来回跳。更合适的做法是把它们集中在一个期间层面处理，这样单笔的数据保持稳定，偶发的影响也不会被丢掉。

税费是另一类边界清晰但经常被放错的项目。它在多数情形下与整体经营结果相关，与某一笔成交不是一一对应的关系。放进单笔算式里会让每一单的成本虚高，放在期间层面又会让单品数据显得过于乐观。先明确它在哪一层，再谈怎么算。

已经发生的退货与预计会发生的退货要分开看。已经退回来的那一笔，各项成本都是确定的，该原样算进去。预计退货是一种估计，它属于预留的范畴，跟实际的成本不是同一类东西，混在一列里会让这一列的含金量下降。

样品的成本属于该单独列出的一项。它对应的是推广动作而不是销售动作，如果把它按比例摊到正常的销售里，会让正常商品背上一份不属于自己的成本。单独列出来，看的人才知道这笔钱花在哪里。

仓储费用的归属要看它是跟着货走还是跟着时间走。跟着特定批次走的，比较适合放到那一批的成本里；按整体占用空间计的，更接近期间开销。两种混在一起，容易出现同一笔仓储费被算了两遍的情形。

有一个好用的检验办法，就是把一个项目拿掉，看这道算式的结论会不会变方向。如果结论方向不变、只是数字略有出入，这一项的重要性就有限，不必为了它反复争论；方向会变的那几项，才值得花时间把它定清楚。

项目该不该进算式，最终要写在核算说明里，而不是留在某个人的判断里。写下来的好处是下一次遇到同类项目不用重新讨论一遍。争论的成本远高于记录的成本，这一点在人员更替之后会体会得更深。

还要提醒一点，进不进算式与金额大小是两件事。金额很小的项目也可能属于必须进的，因为它的性质决定了它跟着成交走。只按金额大小去筛，会把性质重要但金额小的项整类漏掉。按性质去归类，比按金额去筛选更不容易出错。

把项目划分清楚之后，算式里会出现几层不同的东西，单笔的、期间的、偶发的。这几层不要混在一张表里比较，各自看各自的规律。一层一层的数分开，才看得出哪一层在变、哪一层一直稳定。

份额大的那几类经常被反复讨论，份额最小的那几类反而最容易在核算时整块忘掉。

口径之外还有哪些隐性项要单独看

有些项目既不是费率表上明确写着的那几项，也不是完全跟成交无关的杂支，它们处在中间地带。这类项目共同的特征是知道它存在的人很少，而一旦出问题影响又不小。把它们单独划出来看，比混在大类里更有用。

资金在途期间的时间成本是第一类隐性项。钱从买家付出去到真正能用的这段时间里，它既不算已经到手，也不算还没发生。这段时间的占用对不同商品的影响差别很大，周转慢的那几款受影响最明显，而它们在费率表上是看不出区别的。

汇率在两个时点之间的差额是第二类。成交时的汇率和到账时的汇率可能并不相同，这中间的差额不是费用，所以费率表上不会有它，但它确实会吃掉一部分钱。单独看这一项，才知道它一年到底影响多少。

库存减值与滞销处理是第三类。它发生的时点不规律，金额也不一定连年出现，所以经常在核算时被当成偶发事项放到一边。但它确实与前面的备货决策相关，完全放到一边会让备货看起来比实际更安全。

货款被部分预留是第四类。预留这件事本身在费率表上可能有说明，但预留到什么程度、什么时候全部放开，往往只有实际经历过才知道。按费率表上写的比例去核算，可能与真实的资金节奏相差不少。

同一批货在不同站点之间的成本差异是第五类。从知虾公开面的站点分析里，各站点的成交与费用结构分组呈现，数据按日更新到前一交易日。能不能归到某一款商品上仍然要看你的名目表。看到某个站的结构明显不同时，先回头确认这一站有没有你还没列进来的名目。

人员更替带来的效率波动是第六类隐性项，也是最不容易被写进算式的一项。它不产生任何一笔可以直接挂账的支出，但会真实影响同一款商品在不同月份的表现。把它当成噪音而完全忽略，容易把人的问题误判成商品的问题。

这几类隐性项有一个共同的处理原则，就是不要试图把它们精确地摊到每一单上。摊到单笔会引入大量假设，而假设本身会成为新的争议来源。更合适的做法是单独成一块，按期看它的总量与走向，不往单笔里硬塞。

单独成块之后，要在核算说明里明确它们的性质是估计还是实际。估计的部分应该在后续得到实际数之后被替换掉，替换的动作要有人做。只估不换的项会慢慢变成一块谁也不去动的陈年数字。

隐性项单独看还有一个好处，就是能比较它们的相对大小。一直不单独看的时候，所有人都以为它们很小；真正列出来之后，往往有几项的体量超出预期，而它们的处理方式会因此完全改变。先看清体量，再决定它们是单独成块还是并进大类里去。

判断一个隐性项值不值得单独看，可以看它的波动是否会影响决策。如果它对结果的干扰始终在一个很小的范围内，放在大类里也没有关系。如果它会让两个月的结论方向反过来，那就必须单独拎出来。

把隐性项拎出来之后，要注意它们与主项之间不能重复计算。时间成本与资金占用容易重复，库存减值与已计提的部分也容易重复。列名目表的时候顺手标一句它与哪一项可能有重叠，可以省掉后面的核对。

隐性项的名目表通常会随着经营阶段变化。规模小的时候主要看汇差与预留，规模起来之后时间成本与减值会变得更重要。变化本身不是坏事，说明关注点在跟着实际的风险走。规模一变，该重点看的项也要跟着换。

这些项要不要进入最终的利润数字，取决于这道算式的目的。要看单品的经营结构，可以把它们留在另一层；要看这个业务整体到底剩多少，就必须把它们算进去。目的不同，答案就不同，所以在讨论之前先说清这一层算式是给谁看的。

有一类项目既不属于名目也不属于隐性项，就是完全没有任何凭据的支出。这类项不进算式，但也不该被直接丢掉，应该在名目表上留一个位置，写清它暂时没有依据，等找到依据再决定。丢掉之后，想找回来就难了。

把主项与隐性项都列出来之后，算式会从原来的一行变成有层次的几块。这几块各自成立，合起来才构成完整的减法。下一步要处理的是每一块该按什么去算，那属于另一段要回答的问题。这一段只负责把要减的东西摆齐。

那些一直没开发票的，最容易被漏在外

没有发票的支出在核算里处在一种很奇怪的位置。钱是真花了，事情是真发生了，但因为手上没有一张标准的凭据，它在很多流程里进不去。进不去的支出不会消失，只会停在某个没人管的角落。

缺少凭据的支出最常见于零散采购。单笔金额小、供应商又远，走一遍正规流程的成本可能比货本身还高。于是这类支出就被压在一边，等到月底或者年底才被想起来。想起来的时候，细节往往已经记不清了。

另一类常见情形是跨境电商特有的费用，流程上本来就不一定开票。这类费用的特点是稳定发生、金额可估，但在形式上永远凑不齐标准凭据。如果核算流程只认凭据，这一类就会被系统性地排除在算式之外。

自付的样品与测试费用也常常没有凭据。它们对应的是一次尝试，而尝试的结果不一定成功，于是这笔支出就被默认当成不必记录的成本。不记录的结果是不知道一年在尝试上到底花了多少。这笔钱在总额里可能不显眼，但它决定了试错的空间有多大。

被漏在外面的支出会让账面净利虚高，这一点很容易理解。不太容易理解的是它还会让分析失去可信度。当你发现某一款商品的账面表现特别好，却找不到原因时，很可能就是它上面挂着一批没被算进去的支出。

处理这类支出第一步不是去补票，而是在算式里给它一个位置。位置的意思是这一类支出要有一个明确的归口，而不是散落在各个经手人手上。归口之后，金额再小也是可统计的。没有归口，连汇总都做不到，更谈不上判断它的合理程度。

给定一个估算规则往往比追着要凭据更现实。规则可以很简单，比如按采购金额的一定比例预留，或者按上一期的实际发生额折算。规则的目的不是准确，而是让这一块有一个数量级，不至于完全看不见。

估算规则要写明年内什么时候用实际数替换。替换这个动作如果不写下来，估算就会一直挂着，几年之后没人知道它是怎么来的。写明替换时点，这块数字才会自己更新。没写这个时点，它就会一年一年地沿用下去，谁也不去碰。

凭据的形式可以放宽，不必都要求标准票据。一份确认的往来记录、一张付款截图、一段内部说明，都能作为支出真实发生的证据。证据的价值在于它能被别人重核一遍，形式反倒是次要的，经手人才愿意把手上零散的东西交出来。而它的形式并不重要。

放宽凭据形式的同时要收紧另一个东西，就是支出的归口人。每一笔无凭据支出都要明确是谁经手的，以便后续追问。没有归口人的支出，即使记下来了，也没有人能说清它到底对应什么事。归口人不必是花钱的人，但要是能解释用途的人。

这一类支出在月度之间的波动往往很大，因为它们的处理时点取决于谁先想起来。为了让波动变小，可以把归口检查做成一个固定动作，比如每周清一次未归口的项。固定动作能有效减少积压。

有人会把无凭据的支出全部并入一个大类，到年底一次性处理。这样做省事，但会让整年的月度数据都不可比。每月估一部分、年底再校准总量，而不是全部堆到最后。逐月估、年末校，月度之间的可比性才保得住。

要定期看这一类支出占总额的比例。比例稳定在一个可控的水平上，说明流程在运作；比例逐月在涨，说明前面某个环节的凭据要求出了变化，而这个变化可能来自合作方的调整，也可能来自内部流程的松动。

当这类支出的比例高到影响结论时，要考虑的不再是估算规则，而是与合作方重新谈一次结算与凭据的安排。这是从根上解决，比反复调整估算比例有效得多，成本也更高，需要权衡。如果比例一直压不下来，这条路迟早要走一次。

这一项在核算表上的呈现方式建议单独成行，写清其中多少是已确认、多少是估算。两栏分开写，看表的人才知道这一行有多大的不确定程度。混成一栏，风险就被掩盖了。两栏各自的数字怎么变，也能看出估算规则是不是该调整。

把这类支出从算式外面挪到算式里面，短期看会让账面数字变差，长期看会让判断变准。变得准的判断才有后续的动作价值，而不准的判断只会让人反复怀疑是不是哪里算错了。宁可先接受一个不好看的数字，也不要留着一个说不清的缺口。

全列齐之后，账面净利差出多少来

把名目从原来常见的五六项补到二十项左右之后，账面净利通常会明显下降。下降的幅度与商品结构有关，周转快的商品受影响小，涉及活动、退货、跨境环节多的商品受影响大。受影响大的那几款，往往正是平时被当成主力在推的那几款。

下降最多的一块往往来自之前完全没进算式的项目，而不是之前算错的项目。算错是数字层面的偏差，漏项是结构层面的缺口。结构缺口补上之后，表会从原来的一层结构变成几层结构，看起来复杂了，实际上更接近真实。

另一个常见的下降来源是把之前摊在整体上的项目落到了具体商品上。落下来之后，某些原本看起来赚钱的商品会露出真面目。这不是商品变差了，是它一直如此，只是之前被整体平均掩盖着。

也会出现方向相反的情况。有些项目之前被过度地摊到了商品上，列清楚之后发现它们其实属于期间层面，不应该压到单笔。把这些项目移出去之后，部分商品的账面反而会好看一些。一升一降之间，商品之间的相对位置会移动不小的一段。

净利下降之后最容易做错的一件事是立刻去调价格或者削减投入。账面变化来自核算口径的补全，而不是市场本身变差了。按核算变化去调经营动作，容易做出方向错误的决定。先分清账面变化的原因，再决定要不要动经营动作。

拆分来看更靠得住。多少来自补进了新名目，多少来自原来项目的重新归类，多少来自估算被替换成实际。三部分分开看，才知道这是账算得更细了，还是生意真的变差了。两种原因的处理方式完全不同，混着看只会做错判断。

补全名目之后，商品之间的排名往往会发生比较大的变化。之前排名靠前的几款可能落到中游，之前不起眼的几款可能浮上来。排名变化本身就是一个值得研究的信号，它说明之前的判断依据里有一块一直是空的。

排名变化之后不要急着重新安排资源。先看变化是否稳定，至少观察两个完整周期。只在一个周期里出现的排名变化，可能只是某个项目的时点差异造成的，不代表结构变了。稳定两个周期之后再动资源，改动才不容易被反复推翻。

名目补齐之后，整体回顾的动作会变得更容易，因为每一款商品都能说清它的减法是从哪几项来的。说不清的情况减少，讨论的效率就会提升。这是补全名目最直接的一处收益，通常比数字变准更早被感受到。

补全之后要注意表本身的可用性。项目从六项变成二十项，如果所有项都并排展示，看表的人会直接放弃。建议按层展示，第一层只看几个大项，后面几层再展开。层级按使用习惯来切，比按名目自身的分类去切更贴近实际。

分层展示的关键是让上下层之和能够对得上。这是补全名目之后最容易出问题的地方，因为项多了之后，重复计算的机会也多了。每个月做一次上下层核对，能把这个风险压住。核对的做法很简单，把上层几个数加一遍，与总数对一次就行。

补齐名目也会让跨期比较变得困难。上个月是六项的算法，这个月是二十项的算法，两个月的数字不能直接比。处理办法是顺着新算法把旧的周期也重算一遍，或者明确标注算法变更的时点，前后分段看。

名目台账要定期回看，至少要跟账期的节奏对上。在知虾公开面的定价计算页里，各项费用按站点分开摆列，更新时间标在顶端。不涉及你这份名目表里哪些项该进算式。把它当作核对名目的一个参照，比凭记忆去想要可靠一些。

名目补齐之后，利润数值本身会在一段时间内处在调整状态。这时候对外报数要特别谨慎，说明清楚这一版包含哪些项、与上一版差在哪里。不说明就报出去，很容易被理解成经营出现了重大变化。

最后要说清，补齐名目的目的不是让数字变小，而是让数字能用。一个偏乐观但稳定的数字，长期看比一个偏保守但频繁变化的数字更危险，因为它会持续鼓励超出实际能力的动作。数字能用，指的是它经得起追问，也经得起拿去和别的周期对照。

名目列到这里，才谈得上怎么对每一项去算。那一步要处理的是基数与规则的问题，与今天列名目不是同一件事。名目清楚而算法还没定，至少知道要算哪几样；名目不清而算法很细，只是把空的地方算得更精确而已。

三处属性各打一个分，能看出不同名目的可预见程度差别很大，因此列名单的方式也不该一样。

更新名目的标准是什么，按什么来更新

名目要有更新的标准，否则它会慢慢变成一份越用越不准的旧文件。最常见的更新触发点是平台规则的正式变更，这类变更有明确的时间点，处理起来最省事，只要在生效日前把名目表改掉并且通知用表的人。

第二类触发点是出现了第一次发生的新项目。名目表上本来没有这一项，但某一期的账单上突然多了一行。这种情况要立刻记下来，不要等到下个月再看它还会不会出现。等一个月的代价是这一期的数已经用出去了。

第三类触发点是某一项连续多个周期都没再出现。连续三个周期没出现，就可以把它从主项降到旁项；连续六个周期都没有，可以考虑移出名目表。留下来的价值在于提醒，而不在于填满表格。

第四类触发点是金额占比发生了明显的结构性变化。某一项从很小变成很大，即使它的名字没变，处理方式也应该跟着变。名字不变而分量变了，是名目表最容易被忽略的一类过期状态。每隔一段时间按占比重排一次，能看出哪些项的分量已经和当初不一样了。

第五类触发点是内部经营方式变了。比如备货节奏调整、退货政策收紧、换了收款方式，这些变化都会带来名目层面的增减。内部的变动不一定会通知到做核算的人，所以要有一个定期的沟通动作补上这一环。

更新名目表的周期不建议定得太短。每个月都改一次，用过的人会记不住，反而容易在讨论里各说各的。按季度做一次常规更新，中间出现重大变更时临时加一次，是比较稳的节奏。节奏定下来之后，用表的人也会知道什么时候该重新对一遍。

每次更新都要留一份变更记录，写清改了哪几项、为什么改、从哪一期开始适用。变更记录是名目表的一部分，不是额外的东西。没有变更记录，半年之后连做更新的人自己都说不清某一项是什么时候进来的。

更新之后的名目表要重新发给所有用表的人，并且要求确认。确认这一步看起来多余，但它能确认信息真的到了需要它的人手上。发而不确认，等于把更新的责任推给了收件人。确认的动作可以很简单，回一句话说明已经收到就够了。

名目表的更新不应该只在核算团队内部流转。采购、仓储、运营都可能先于核算发现新的名目，要给这些角色一个简单的反馈入口。入口越简单，反馈越多，反馈进来之后要有人接住，只收不办，入口很快就会没人再用。名目表也就越接近实际。

有人主张名目表越短越好，只用最关键的几项。这个主张在只看整体结论时成立，在需要解释单品差异时不成立。两种用途可以共用一个名目表库，但呈现出来的版本应该不一样。底库只留一份，给不同的人看的时候各取所需，不必各建一套。

判断一项该不该进入主名目表，可以看它会不会影响比较。会让两个商品或者两个周期的比较结论发生变化的项目，就该进主名目表。只是让数字整体下移一点的项目，放在旁项里也不影响判断。

更新名目的时候要注意与已经发出的历史数据保持一致。历史数据已经用于某个决策，就不该在新名目表里被悄悄改掉。正确的做法是在新的一期启用新名目表，同时标注历史数据适用的是哪一版。

名目表的版本号建议体现在文件名和表头两处。只在文件名里标，打开表格复制出去之后就丢了；只在表头标，文件多了又分不清。两处都标，追踪成本最低。版本号不必复杂，一个日期加一个序号就够用了。

每次更新之后要顺手检查一遍算式里有哪几处引用了旧名目。名目改了而算式没改，会出现某一项被算了两遍或者一遍都没算。这种错在总额上可能看不出来，要拆到项才能发现。每次更新之后做一次分项对总，是成本最低的一道检查。

更新这件事可以由一个人固定牵头，但不要由一个人独自决定。牵头的人负责收集变化、整理名目表、组织确认，具体哪一项该不该进去，由那条线上最熟悉的人来定。牵头与决定分开，这一份名目表既不会停摆，也不会被一个人随意改。

名目更新到位之后，这一层的稳定性就建立起来了。名目稳定，后面无论用哪一种算法去算，比较的基础都是同一套。比较基础一致，方法之间的差异才有意义，否则只能得出一个说不清的结论。

两条线一升一降，说明名目名单会在结算推进的过程中不断补全，早列比晚列省事得多。

名目列全了，具体算法在下一节里

做到这里，减法里要减的东西已经一项一项摆开了。哪些因为成交而发生、哪些属于期间、哪些是隐性项、哪些暂时没有凭据，四类分开之后，算式里就有了清晰的几块，后面无论换哪一种算法，要减的东西都不会再变。

名目清楚之后，剩下的问题才轮到方法。方法要回答的是每一块按什么基数去算，按销售额还是按件数、按当期还是按累计、按站点分开还是合并。这些选择的差别不小，但它们都建立在名目已经定下来的前提上。

如果名目没列全就开始讨论方法，讨论会很自然地滑向细节。两个人争论某个项目该按哪个基数算，争论了半天才发现其中一个压根不知道还有别的一些项目存在。这种讨论耗时且没有产出。把次序摆正，讨论才会落在真正需要判断的地方。

把名目与方法分成两段来处理，还有一个好处是可以用不同的频率更新它们。名目通常跟着平台规则和内部流程走，变化相对慢；方法跟着经营重点走，变化可以快一些。两段分开，各自的更新不会互相牵动。

名目这一段做完之后，可以做一次整体复核，把算式里的每一块拿出来单独看一遍，确认它确实对应着真实发生的支出。核对的时候不必追到原始凭证，但要能说清这一块是什么、为什么在这里。

复核时如果发现某一项说不清来由，不要急着删掉。说不清通常意味着它在某个环节上与另一项有重叠，或者它是从上一版算法里留下来的历史项目。先标出来，等在做法的那一段里再确认它该不该留。

名目这一段还留下了几个接口给后面的段落。第一个是指向方法的接口，也就是每一块该怎么算；第二个是指向核算周期的接口，也就是这些块按什么周期去汇总。两个接口都留出位置，后面的段落才不必回头改动这一层。

把接口说清楚，是为了让后面的工作不需要回头重新讨论名目。很多团队做核算时反复返工，原因不是方法难，而是名目这一层没定，每换一个方法就要重新决定一次要不要算某一项。名目定下来，方法就成了一件可以单独讨论的事。

在名目没有定稿之前，先不要对外发布任何基于单品毛利的判断。判断一旦发布出去，后面改起来要解释的东西就多了，而且会让人觉得结论不可靠，尽管实际上只是核算在逐步完善。等算法也定下来之后，再对外说明这一版包含了哪些项。

名目定稿之后可以做的事情变多了。可以按商品看结构，可以对比不同站点的差异，也可以把同一款商品在不同周期的表现放在一起看。这些分析都依赖同一件事，就是减法里的项目没有遗漏。

从这一篇的角度看，值得带走的一条经验是先把名目表列全，再谈精确度。列全是一个可以一次性做完的事情，精确度是一个需要长期打磨的过程。先做完可以一次做完的那件的，后面的打磨才有意义。

还有一点要说明，名目的完整不等于算式的完美。名目表只能说明减法里没有漏项，不能说明每一项的数值都是准的。数值的准确度取决于方法，这就是为什么这两段必须分开来看。先做到不漏项，再谈每项算得准不准，先后不能颠倒。

到这一步，名目这一段的边界就清楚了。它不定基数、不排路径、不说账本的归属，只负责说清楚钱被哪些名义切走。这三件事分别属于另外三段，各段把各段的问题回答完，整个核算的骨架才立得住。

名目这一段讲完，下一步要看的就是每一项具体怎么算。那一段要处理基数的选择与周期的界定，与这一篇列名目是两件不同的事。两件事都做完，账面数字才既有来处也有算法。只有来处没有算法，数字说得清来源却说不清大小。

最后提醒一句，名目不是一次性的交付物。它会随着业务变化持续调整，所以更重要的不是今天这份名目表有多长，而是有没有人、有没有机制让它在半年之后仍然是准的。机制比内容更需要提前安排，也更容易被忽略掉。

如果只能从这一篇带走一句话，那就是先把减法里的项目数清楚，再谈每一项算得有多细。项目数不清的时候，算得再细也只是在一个不完整的框架里追求精度，而那个框架本身才是决定结论方向的东西。

名目列全了，接下来才轮到算法。这一段就此收住，具体每一项该怎么算，留到口径那一段去谈。两段接上，利润这道减法才算完整地摆在了桌面上。名目是减法的项目，方法是减法的算数，两者缺一不可。

常见问题（FAQ）