很多跨境电商卖家问我"财务核算从哪里开始"，我的回答通常让人意外：不是从建科目表开始，也不是从录凭证开始，更不是从买 ERP 开始。我见过最典型的一家深圳卖家，科目表建了 186 个一级二级科目，比很多上市公司还细，结果月末仍然要 12 个自然日才能结账，因为业务数据本身对不上。这篇文章我用一个脱敏改造过的复合案例，把财务核算的真正起点拆开讲：先定核算边界和主数据，再拉通订单，结算，回款，费用链路，最后才做 ERP 里的科目映射和凭证生成。
文中涉及的工具以"数跨境"为例说明做法，数据部分是脱敏或情景模拟，具体功能边界请以官方最新说明为准。读完你至少能判断出，自己公司的财务核算应该从哪一块先动手。
我把这个结论放在最前面，是因为它决定了后面所有工作的顺序。财务核算的本质是"用会计语言复述业务事实"，如果业务事实本身是散乱、对不上、口径不一致的，那你在 ERP 里做的所有凭证，都是在给一堆不可靠的数字做二次加工。
换句话说，科目表决定的是"怎么记"，而对账关系决定的是"能不能记准"。绝大多数跨境电商的财务困局，卡在后者，不在前者。
2021 年我参与一个家居类目的项目，老板是运营出身，对数据极度重视，要求财务"一步到位"。我们花了三周设计科目体系，把平台佣金、广告费、仓储费、尾程派送、退款、赔付、汇兑损益全部拆到二级甚至三级科目，看起来很专业。
结果第一个月结账就崩了。原因很朴素：平台的结算单里，佣金、广告费、退款是打包在一个"调整项"字段里的，我们根本没有办法把它们拆到三级科目。为了把科目填满，会计只能手工估算分摊，估出来的数字连自己都不敢签字。
那次教训让我彻底转变了思路。科目体系的精细程度，不能超过业务数据本身的可得粒度。这是财务设计的一条铁律，违反它只会制造虚假的精确。
后来我总结出一套判断标准，用来回答"我们该从哪里开始"。如果一个环节同时满足下面三条，它就是起点；如果只满足一两条，它只是过程。
用这三条去套常见选项：平台账单下载满足可重复但未必可对账；科目表三条全不满足；资金账户流水满足可对账和可追溯；订单数据满足可追溯但需要和结算单建立映射。所以真正的起点，是"边界 + 主数据 + 资金链路"这三件事的组合。
我把顺序写成一个五步链路，每一步都有明确的交付物。这个顺序不是理论推导，是我们在多个项目里反复试错后收敛出来的。
第 5 步排最后，不是因为它不重要，而是因为它依赖前 4 步。前 4 步没做,第 5 步做出来的东西只能叫"账"，不能叫"核算"。
颠倒顺序最常见的后果是返工。先建科目再想边界，会导致科目里混入了不该进这套账的主体数据；先录凭证再拉链路，会导致凭证和平台账单长期挂不上；先上系统再定主数据，会导致店铺名称在一个系统叫"US-Store-01"，在另一个系统叫"美国站一号店"，永远对不上。
为了讲清楚"从哪里开始"为什么重要，我先把案例背景交代清楚。这是我把三个真实项目合并脱敏后的复合案例，不是单一客户，数据经过比例调整，但流程和问题都是真实发生过的。
卖家主营家居小件，年 GMV 约 2200 万元人民币。销售分布在 Amazon、Shopee、TikTok Shop 三个平台，合计 5 个店铺。收款走 2 个第三方收款账户和 1 个平台自有钱包，结算币种涉及美元、欧元和人民币。
主体结构上，国内 1 家贸易公司负责采购和出口，香港 1 家公司负责部分平台店铺收款。财务团队 3 人：1 名总账会计，1 名成本会计，1 名出纳兼对账。ERP 用的是通用型进销存模块，财务模块只开了总账和应收应付。
老板的诉求很具体：月结要在次月 5 个工作日内完成，每个店铺的利润要能算清楚，税务申报要有据可查。当时的实际状态是月结 12 个自然日，店铺利润只能按 GMV 简单倒扣，没人敢签字确认。
我把改造前的月结动作按类型做了工时归集。3 个人合计投入 128 人时，但因为账单获取时间分散、人员交叉安排，实际跨越了 12 个自然日。
| 月结动作 | 投入人时 | 主要卡点 |
|---|---|---|
| 下载与清洗平台账单 | 32 人时 | 三个平台字段命名不同，CSV 与 API 混用 |
| 店铺与平台口径对齐 | 26 人时 | 店铺名称在 ERP、平台后台、收款账户三处不一致 |
| 资金到账核对 | 22 人时 | 一笔回款对应多个结算批次，无法一一对应 |
| 费用归集与分摊 | 18 人时 | 广告费按店铺拆分靠人工估算 |
| 凭证录入 | 16 人时 | 同一业务在不同月份用不同科目 |
| 差异追溯 | 14 人时 | 差异发现晚，跨月后需做调整分录 |
这张表里最值得注意的不是总工时，而是前两项占了 58 人时，接近一半，而这两项本质上都不产生会计信息，只是在做数据搬运和口径统一。这就是典型的"起点错了，后面全在补窟窿"。
月结会议上老板问了三个问题：第一，哪个店铺在亏钱？第二，为什么收款账户里的钱比系统里的应收少？第三，平台扣的那些钱到底是什么？
这三个问题，没有一个能靠"把凭证录得更仔细"回答。第一个问题是主数据和辅助核算维度问题，第二个问题是对账关系问题，第三个问题是费用颗粒度问题。三个问题全部指向起点，而不是指向记账动作。
我在这类项目里见过大量重复出现的误区。它们有一个共同特征：看起来都在解决财务问题，实际上都在绕开起点。下面逐个拆。
这是最普遍的一条。逻辑听起来很对：上了系统就有标准流程了。但实际发生的往往是，系统上线后流程变得更加混乱，因为 ERP 只是把你的数据照单全收，它不会帮你判断数据对不对。
我见过一个卖家上线 ERP 后，把三个店铺的数据全部导进同一个账套，结果应收余额比实际回款高出 40 多万。查了两周才发现，其中一个店铺的收款主体是香港公司，钱根本没进国内账户。系统不会阻止你犯错，它只会让你的错误变得更快、更规模化。
科目表的精细度必须匹配数据可得性，这一点我在第一节已经讲过。这里补充一个更隐蔽的问题：科目表一旦投入使用，调整成本极高，因为它会影响历史数据和报表可比性。
我的建议是反过来做：先把平台账单、费用账单、账户流水的字段列全，看看哪些费用天然是分开的，哪些是打包的。能被数据天然区分的，才值得单独设科目。不能天然区分的，设了科目也只能靠估。
很多会计的月结动作是：平台后台显示本月回款 100 万，银行到账 100 万，对上，结束。这种做法在单平台小规模时勉强能用，一旦店铺数量增加就会失效。
因为总额相等可能掩盖两类问题：一是明细层面的错配，A 店铺的钱记到了 B 店铺；二是时间性差异，本月的钱其实是上月的结算批次。总额对平是必要条件，不是充分条件。真正的对账必须下钻到结算批次和订单层级。
平台结算单里的"净额"是回款金额，不是收入金额。它已经扣除了佣金、广告费、退款、赔付等项目。如果你直接按净额确认收入，会同时犯三个错：收入被低估、费用被漏记、平台费和广告费的税务凭证链断裂。
正确的做法是用结算单拆出收入总额和各扣款项目，再按性质分别归集。这件事在 ERP 里需要有明确的映射规则，不能靠会计每月手工判断。
多主体混账是税务风险最高的一个误区。国内公司和香港公司如果共用一套科目和账套，不仅核算不清晰，在转让定价、利润分配、税务申报上都会留下隐患。
更麻烦的是，一旦被要求补正，历史数据几乎无法追溯分离，因为业务单据本身就没有按主体打标。主体维度不是财务偏好，是合规底线。
把五个误区放在一起看，根因只有一个：把"财务动作"当成了"核算起点"。建科目、录凭证、上系统、对总额、混账套，全部都是财务动作，它们解决的是"怎么记录"，不是"记录什么"。
而跨境场景的特殊性放大了这个问题。多平台、多店铺、多主体、多币种、多结算周期这五个"多"，任何一个都会让数据口径分裂，五个叠在一起，靠人工对齐的成本会指数上升。
讲完误区，我给出正面方法。判断核算起点，我习惯把边界拆成四层，从外到内逐层收敛。这个框架在实务中比"先做什么后做什么"更好用，因为它能帮你定位问题究竟卡在哪一层。
主体层要回答的问题是：哪些法人主体纳入这套核算，各自的收入、成本、费用如何归属。跨境电商常见的主体安排是国内贸易公司 + 香港公司 + 可能的境外子公司。
这一层的判断重点是合同流、资金流、货物流、发票流是否四流一致。如果收款主体和签约主体不一致，或者货物由国内公司出口但收入记在香港公司，就要提前评估税务解释成本，而不是等月结时再补。
平台店铺层是跨境电商最有价值也最容易做乱的一层。老板最关心的"哪个店铺赚钱"，答案就出在这一层。但前提是店铺主数据必须先统一。
我建议的做法是给每个店铺分配唯一编码，并建立一张对照表，把平台后台名称、ERP 名称、收款账户名称、物流商系统名称全部映射到同一个编码上。这张对照表是整个核算体系的枢纽，它的完整性直接决定后续所有对账能不能自动化。
资金账户层要梳理清楚钱在哪里、怎么流转。包括平台钱包、第三方收款账户、银行账户三层，以及它们之间的提现路径。
这一层的关键产出是账户余额调节逻辑：平台钱包余额、在途提现、已到账金额三者的关系要能算清楚。很多卖家账上对不上，就是因为把"平台已结算但未提现"的金额当成了已回款。
单据层是最后一层，也是 ERP 真正发挥作用的地方。要定义清楚每一种业务单据在什么条件下触发什么凭证，包括结算单、退款单、广告账单、物流账单、收款单、付款单。
这一层做得好，凭证可以自动生成；做得不好，会计就要每天在两个系统之间来回复制粘贴。判断标准很简单：如果一个动作每天重复超过 20 次，它就应该被规则化。
四层拆完之后，必须做一次交叉验证，确认层与层之间能一一对上。我通常用三个问题来验证：每个店铺是否都归属到明确主体？每笔回款是否能追到具体结算批次？每类费用是否能对应到具体店铺或订单？
三个问题里有任何一个答不上来，说明对应的那一层还没做完，这时候不应该往下走，应该回到那一层补齐。
下面进入具体怎么做。这一节我以数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例说明操作思路。需要先说明：工具解决的是数据归集、对账和映射的效率问题，它不能替代你对核算边界的判断。如果你的主体和主数据还没理清，先理清再上工具，顺序不能反。
我在案例里做的第一件事，是把三个平台的结算数据、两个收款账户的流水、广告后台的费用数据全部接入进来做归集。这一步的目的不是出报表，而是让不同来源的数据第一次放在同一个口径下，暴露差异。
实际接入时最花时间的不是技术对接，而是字段对齐。比如平台 A 的结算单里结算批次叫 settlement_id，平台 B 叫 settlementId，平台 C 干脆没有批次号只能用结算周期代替。这些字段如果不统一，后面的对账根本无从谈起。
归集完成后，我们得到了一张按店铺、按结算周期、按批次组织的统一视图。这张视图是整个核算体系的地基，它比任何一张财务报表都重要。
在数跨境里建立主数据时，我坚持了"编码唯一、名称可选"的原则。也就是说，每个店铺、每个账户、每个主体都有一个不可变的编码，显示名称可以随业务调整，但编码一旦确定就不再更改。
辅助核算维度我最初设计了六个：主体、店铺、平台、币种、期间、费用类型。运行两个月后，我砍掉了"平台"维度，因为平台信息已经可以通过店铺维度推导出来，重复设置只会让录凭证变慢。
维度不是越多越好，能通过已有维度推导出来的，就不要单独设。这是我在多次配置后形成的判断。
单据层映射是整个环节的技术核心。我用一个简化后的配置示例说明写法。这个示例展示的是"平台结算单如何拆分为收入与各类费用"，实际配置会比这个复杂，但结构一致。
{
"rule_id": "SETTLE_TO_VOUCHER_001",
"rule_name": "平台结算单拆分为收入与扣款费用",
"source": {
"system": "platform_settlement",
"filter": "settlement_status = 'closed'"
},
"dimensions": {
"entity": "{{shop.entity_code}}",
"shop": "{{shop.code}}",
"currency": "{{settlement.currency}}",
"period": "{{settlement.period}}"
},
"lines": [
{
"amount_field": "gross_sales",
"voucher_subject": "6001.01 主营业务收入-跨境",
"direction": "credit"
},
{
"amount_field": "platform_commission",
"voucher_subject": "6601.03 销售费用-平台佣金",
"direction": "debit"
},
{
"amount_field": "advertising_fee",
"voucher_subject": "6601.05 销售费用-广告费",
"direction": "debit"
},
{
"amount_field": "refund_amount",
"voucher_subject": "6001.02 主营业务收入-退款冲减",
"direction": "debit"
},
{
"amount_field": "net_settlement",
"voucher_subject": "1122.01 应收账款-平台",
"direction": "debit"
}
],
"balance_check": "sum(debit) == sum(credit)",
"exception_handler": "diff_amount > 0.5 ? route_to_manual_review : auto_pass"
}这段配置里有三个设计要点值得说明。第一，所有金额字段都来自结算单原始字段，不做事后估算。第二，设置了借贷平衡校验，不平衡的单据不允许自动过账。第三，设置了差异阈值，超过 0.5 元的差异自动转人工复核。
最后这条阈值设置，是我认为最容易被忽略但最有价值的一条规则。它把人工精力集中在真正有问题的单据上，而不是平均分配到所有单据。
我把对账关系归纳成一个三角：平台应收 vs 账户实收 vs 总账记录。三者必须能互相解释，任何两个对上但第三个对不上，都要查。
在案例里，我们按月做了一个瀑布式拆解，从平台确认的应收金额开始，逐项减去各类扣款，再减去跨期未到账部分，得到当期实际回款，然后与账户流水核对。
这套改造从启动到跑通第一个完整月结，用了 7 周。我把前后对比的关键指标列出来，数据来自脱敏统计，用于说明改造效果的量级。
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 月结自然日 | 12 天 | 5 天 | 缩短 58% |
| 月结投入人时 | 128 人时 | 46 人时 | 下降 64% |
| 凭证自动生成率 | 12% | 78% | 提升 66 个百分点 |
| 回款可追溯到批次的比例 | 48% | 94% | 提升 46 个百分点 |
| 店铺利润可出具时间 | 无固定周期 | 次月 5 个工作日 | 从不可得变为可承诺 |
| 跨月调整分录笔数 | 平均 37 笔/月 | 平均 9 笔/月 | 下降 76% |
这张表里我最看重的不是月结天数，而是跨月调整分录从 37 笔降到 9 笔。调整分录的数量，本质上是核算质量的体温计，它直接反映了有多少问题是在当月没被发现、被迫推到下月处理的。
链路跑通之后，必须把它固化成可重复执行的清单，否则三个月后又会退化回手工状态。我把清单分成日清、周核、月结三段，每段都有明确的输出物和责任人。
日清阶段的目的是保证数据不过夜积累，而不是出报表。我要求每天只做三件事，超出范围的一律不做，避免把日清做成小型月结。
这三件事合计约 40 分钟。看起来简单，但坚持一个月的效果非常明显：月底不再需要集中下载和补录，差异也能在发生当天被发现。
周核的核心是验证，不是记录。每周固定时间做一次对账三角的抽检，重点看不一致的地方，而不是确认一致的地方。
周核的价值在于把差异的发现时点从月底提前到周内，这样处理成本会低很多。跨月差异需要做调整分录，周内差异往往只需要改一条记录。
月结阶段我要求严格按照固定顺序执行，因为这个顺序保证了每一步都建立在已验证的数据之上。
如果只能保留一份文档，我会保留异常台账，而不是月结清单。台账记录每一笔差异的发现时间、金额、原因、处理方式和责任人。
台账的长期价值在于模式识别。当你积累了 6 个月的异常记录后，会发现 80% 的差异集中在少数几类原因上，比如某个平台的退款延迟入账、某个物流商的账单跨期、某个币种的汇率取值不同。针对这几类原因做专项规则，比全面优化有效得多。
上面讲的是完整链路，但并不是每个卖家都需要一次做到位。我按规模和阶段给出分档建议，你可以对照自己的情况选择。
这个阶段的卖家，业务复杂度还不足以支撑一套完整核算体系。我的建议是只做两件事：统一店铺和账户的主数据，建立最简单的对账三角。
具体做法是每周核对一次平台结算净额与账户到账金额，差异记录在台账里。不需要上复杂工具，用表格就能完成。这个阶段最大的风险是过早引入复杂系统，反而增加维护成本。
当店铺数量超过 3 个、平台超过 2 个时，人工对齐的成本会快速上升。这个阶段的核心任务是主数据统一和账单归集自动化。
建议顺序是：先建立店铺编码对照表，再接入各平台结算数据，最后建立按批次的对账关系。工具层面可以考虑使用数跨境这类的数据协同工具来处理归集和对账，把会计精力释放到异常处理上。
涉及两个以上法人主体和两种以上币种时，主体划分必须最先确定。因为主体决定了账套结构、决定了收入成本归属，也决定了税务申报路径。
这个阶段我强烈建议在系统配置之前，先做一次主体架构梳理，把合同流、资金流、货物流、发票流画出来。主体架构一旦上线就极难调整，它值得花两周时间想清楚。
这是最常见的情况，也是最容易做错决策的情况。很多企业一发现跑不通就想换系统，但问题往往不在系统，而在数据层。
我的建议是先补对账层，也就是把 ERP 里的应收数据与平台账单、账户流水做一次全面比对，找出所有对不上的地方。这个过程通常会暴露出主数据和映射规则的问题，而不是系统功能的问题。换系统解决不了口径不一致，只会把问题带到新系统里。
如果企业面临审计、融资或合规要求，重点不是当月做得多漂亮，而是历史数据的完整性。投资人和审计师关心的是，你的收入确认有没有依据，你的费用归集有没有逻辑。
这个阶段建议做一次历史数据回溯，至少覆盖最近 3 个月，逐月验证平台应收、账户实收和总账记录的三角关系。回溯过程中发现的差异要留存说明，而不是直接调平。
最后讲取舍。资源永远有限，把所有事都做了等于什么都没做好。我按这三类给出判断。
第一是主体边界划分。它决定合规底线，晚做的代价是历史数据无法分离。第二是店铺主数据统一。它是所有对账的前提，不做则一切自动化无从谈起。第三是资金链路对账。它决定你的利润数据可不可信。
这三件事的共同特点是：不做不会立刻出事，但会持续积累风险，且越晚做成本越高。
第一是精细化的成本分摊，比如按 SKU 分摊头程运费。在店铺级利润还没算清之前，做到 SKU 级没有意义。第二是复杂的预算管理体系，它需要稳定的历史数据支撑。第三是多维度的经营分析报表，口径稳定后再做才有参考价值。
这三件事不是不重要，而是它们的价值建立在前面的基础之上。基础没打好就做这些，产出的数字没人敢用。
第一是超过数据可得粒度的科目细分，它会制造虚假精确。第二是用估算代替数据，比如按比例拍脑袋分摊广告费，一旦形成习惯就很难纠正。第三是在口径未统一前就上 BI 看板，看板会把不一致的数据以非常专业的方式呈现出来，反而增加误判风险。
第三点尤其值得警惕。数据可视化会放大数据的可信度错觉，错误的数据配上漂亮的图表，比错误的数据本身更危险。
如果记不住具体清单，记住这三条原则也能做出大致正确的判断。
回到标题的问题：ERP 跨境电商的财务核算从哪里开始？我的答案是，从判断核算边界开始，从建立可对账的数据底座开始，从统一主数据开始。科目表、凭证、报表都是这个底座之上的产物，不是起点。
这个判断背后有一个更本质的观点：跨境电商财务核算的难点，从来不是会计技术，而是数据治理。多平台、多店铺、多主体、多币种、多结算周期带来的口径分裂，才是绝大多数月末痛苦的真正来源。把这个问题解决了，会计技术层面的事情反而简单。
我也要诚实地说明工具的位置。以数跨境为代表的跨境数据协同工具，解决的是归集、对账、映射的效率问题，它能显著降低人工搬运和口径对齐的成本，但它替代不了你对主体边界、主数据规则和映射逻辑的判断。工具是把正确的判断规模化，不是替你做判断。
如果你现在就要动手，我建议按这个顺序走：第一步，用一张表列出你所有的法人主体、店铺、收款账户和结算币种，确认它们之间的归属关系；第二步，建立店铺编码对照表，把平台、ERP、账户三处的名称统一；第三步，选一个完整的结算周期，做一次平台应收、账户实收、总账记录的三角核对，把所有对不上的地方记进台账；第四步，再根据台账里的高频问题决定要不要上工具、上什么工具。
这四步做完，你就会清楚地知道自己缺的是数据、是规则还是工具。到那时候，工具选型会变成一个相对简单的技术问题，而不是一道猜谜题。
我是一家多平台卖家的财务负责人，最近刚上ERP，内部有人说先把会计科目建起来，实施顾问又说要先把期初余额导进去，我夹在中间不知道该听谁的。结果折腾了两周，科目改了三版，期初还是对不上，月底连一份分店铺的毛利表都出不来。
真正的起点既不是科目也不是期初，而是先定核算边界和主数据。具体做法是先把主体、平台、店铺、结算账户、仓库、SKU、供应商、物流商这八类主数据列成清单，把编码规则定死，再谈科目和期初。判断依据很简单：如果主体、店铺、币种这些维度没定，科目建得再细也无法按维度出报表，期初导进去也只是把历史混乱搬进系统。
数据口径上，建议先盘点清楚主体数、店铺数、平台数、币种数和结算账户数，比如三个平台、五个店铺、两个主体、三种币种，把这些维度的编码在ERP里固定下来，然后才建科目表、导期初。顺序错了，后面每加一个平台就要返工一次。
我每个月从平台后台下载结算报告，发现结算金额和支付账户实际到账总是差一截，运营说那是平台扣的手续费和广告费，财务说没看到明细不敢入账。到了月底，平台应收、账户实收、总账收入三个数各说各话，我也不知道该以哪个为准。
应以平台结算报告作为收入和平台费用确认的主依据，以支付账户流水作为资金核对依据，两者角色不能混。做法是先把结算单拆成收入、平台佣金、广告扣款、退款、物流代扣等明细行，再跟支付账户到账做时间差和金额差核对，在ERP里分别设置平台应收、平台费用、回款三个辅助核算维度。
判断依据是收入确认看的是平台结算周期和扣费明细，资金到账只是后续动作，到账金额天然不等于收入。数据口径建议：平台结算金额与账户实收的差异要逐项拆到手续费、退款、广告、跨期四类，当月能对平的必须归零，对不平的挂差异台账并注明责任人和预计关闭时间，差异率控制在结算金额的千分之五以内作为健康线。
我们之前为了看得细，一个平台建一个科目，结果平台一多科目表直接爆炸，报表也跑不动。后来想改成辅助核算，又发现历史凭证带不过去，只能手工补。现在准备换ERP重新初始化，我特别担心再踩一次同样的坑。
原则是科目按会计要素设，平台、店铺、主体、币种这些管理维度放辅助核算，两者不要混在一起。具体做法：科目级次控制在三级以内，一级按资产、负债、权益、收入、成本、费用大类，二级按必要明细，三级只留给确实需要单独列报的项目；
辅助核算维度先定六个以内，比如主体、平台、店铺、币种、项目、期间，业务单据到凭证做一张映射表，明确哪类单据带哪些维度。判断依据是科目决定报表科目行，辅助核算决定管理分析口径，科目一旦按平台建，新增平台就必须改科目体系，而辅助核算加一个维度值就行。
数据口径上，目标是任意一个店铺乘平台乘币种的组合都能拉出收入、成本、费用和毛利，且不需要新增会计科目。
我们每个月月结都要等平台账单、等物流对账、等运营确认退款，财务只能干等，老板还问为什么不能五号出报表。上个月还漏记了一笔海外仓仓储费，导致毛利虚高，被审计追问了半天。
把月结拆成日清、周核、月结三段，而不是月底集中补。日清动作是每天下载平台结算单和支付流水，导入ERP并与订单做初步匹配；周核动作是每周归集广告费、物流费、仓储费，登记差异台账，把跨期和补扣单独标记；月结只做计提、汇兑损益、成本结转和复核。判断依据是月底大部分差异来自平时没对，集中处理时信息已经失真。
数据口径建议：把月结目标定为T加五到T加七个工作日，平台应收与账户实收差异当月清零或明确挂账，费用漏记率以零为目标，每笔异常台账必须有责任人、金额、原因和关闭时间，海外仓、广告、物流这三类高频漏记项每周至少核一次。
读者评论
看完挺有共鸣的。我们公司也是先急着上ERP，结果店铺编码三个系统三套名字，每月对账全靠人工拉表格。文章说起点是边界和主数据，这个顺序确实是被返工教育出来的。
科目表精细度不能超过账单颗粒度这句说到点上了。之前我们把平台佣金和广告费拆到三级科目，结果结算单里根本分不开，会计每月手工分摊，数字自己都不敢签字。
三个硬标准里我觉得可追溯最实用。建议补充一下多主体情况下主数据怎么打标，我们国内公司和香港公司混在一个账套，历史数据现在想拆都拆不出来。