我见过最贵的一张 Excel 表，是深圳一个做家居品类的卖家用来对平台回款的。表里有 17 个 sheet，横跨 Amazon、Shopee、TikTok Shop 三个平台、五个店铺、四种结算币种，公式套了七层。他们每月 8 号开始对账，平均 11 号才能出上个月的利润表，而且财务和运营对同一个店铺的“利润”永远差 3 万到 8 万。老板的第一反应是“赶紧上 ERP”，我的判断恰好相反：他们缺的不是 ERP，是把业务事实翻译成会计语言的规则。
ERP 只是规则的执行器，规则没定清楚，上 ERP 只会把错误自动化，并且让你更难发现错误。
我做过三个跨境卖家的财务流程梳理项目，从年 GMV 六百万到年 GMV 四亿都有，结论高度一致。第一条结论：跨境电商财务核算的复杂度，80% 来自口径定义，20% 才来自系统和工具。口径指的是收入确认时点、费用归属期间、成本归集路径、分摊动因、汇率取值来源这五件事，它们和 ERP 品牌没关系，和你的会计政策有关系。
第二条结论：ERP 的财务模块能替你做的是“搬运、映射、汇总、生成凭证”，不能替你做的是“判断”。比如一笔平台赔付到底算营业外收入还是冲减平台费用，ERP 不会替你决定，它只会按你预设的科目去记。第三条结论：先跑通一个月的完整闭环，再谈全面上线。我见过太多团队一次性把三个平台的历史数据全导进去，最后连差异出在哪一层都定位不到。
2023 年我参与过一家母婴跨境卖家的 ERP 财务模块上线，团队 6 个人，年 GMV 约 4000 万。这里给出的是一组示意数据，来自我当时的项目记录整理，不代表行业统计。反常识的地方在于：上线首月，财务的人工耗时不但没降，反而在异常排查这一项上翻了两倍多，因为原来 Excel 里“看不见但也不影响出表”的差异，被系统全部暴露出来了。
不是所有团队都需要马上上 ERP。我给客户的判断标准有三条。第一，如果你每天手工处理的订单行超过 800 行，或者金额超过 20 万元，手工对账的出错概率会进入一个明显上升的区间。第二，如果你需要同时回答“按店铺”“按 SKU”“按国家”三个维度的利润问题，Excel 的多维透视会很快失控。第三，如果你已经有多个主体、多个收款账户、多个结算币种，那么你需要的其实是数据归集和映射能力，而不一定是完整的 ERP 套件。
这三条只要中两条，就值得动手；只中一条，我通常建议先把口径文档写清楚，用轻量工具过渡半年再做决策。
为了把案例拆解讲清楚，我构造一个简化但贴近真实的账套，后面所有拆解都基于它。以下所有费率、周期、汇率、税率都是示意假设，用于说明方法，不构成任何平台规则或税务结论，实际业务必须回到平台官方结算说明和专业财税意见。
| 维度 | 设定 | 带来的核算影响 |
|---|---|---|
| 平台与店铺 | Amazon 美国站、Amazon 德国站、Shopee 新加坡站、Shopee 马来站、TikTok Shop 英国站 | 三套结算逻辑、三套费用名目、三套报表口径 |
| 结算币种 | USD、EUR、SGD、MYR、GBP | 记账本位币折算、期末调汇、汇兑损益 |
| 物流结构 | 国内头程集运 + 目的国海外仓 + 平台仓（部分） | 头程、关税、仓储、尾程四段成本归集 |
| 费用结构 | 平台佣金、FBA 或平台仓费、站内广告、退款、赔付、软件订阅 | 费用归属期间和分摊动因差异极大 |
| 结算周期 | 周结、双周结、月结混合 | 回款与收入的跨期错配 |
这个账套的“乱”，具体乱在五个地方，我按财务痛感从高到低排序。
第一个卡点是平台回款和订单收入的金额对不上，而且不是差一点点。很多财务第一次做多平台对账时会有一个误解，以为回款就是订单金额减掉佣金。实际上，一个结算周期内的回款，混合了本期订单、上期尾款、退款冲回、广告费扣减、仓储费扣减、平台赔付、汇率折算差，甚至是上一个周期未结清的挂账。
第二个卡点是收入确认时点没有统一口径。运营看的是下单时间，平台看的是结算时间，仓库看的是发货时间，财务如果按签收时间确认，四套时间在每个月末都会打架。这不是谁对谁错，而是必须先明确一个主口径，再定义例外情况怎么处理。
第三个卡点是成本归集没有路径。采购价、国内头程、出口报关相关费用、目的国关税、海外仓仓储、尾程配送，这六段费用分散在采购、物流、仓储三个部门，如果不定义清楚哪一段进存货成本、哪一段进期间费用，同一个 SKU 在两个月的毛利可以差出十几个百分点。
第四个卡点是汇兑损益只在期末一次性调。收款日汇率、交易日汇率、期末汇率三者的差额混在一起，最后财务只知道“这个月汇兑亏了 4 万”，但不知道是业务造成的还是汇率波动造成的，也就无法优化收款节奏。
第五个卡点是费用分摊动因凭感觉。广告费按 GMV 分摊是最常见的做法，也是最容易误导决策的做法，因为高 GMV 的 SKU 不一定消耗了同等比例的广告预算。
这是最致命也最常见的一个误区。回款是现金流口径，收入是权责发生制口径，两者之间隔着佣金、退款、赔付、广告扣减、跨期结算和汇率折算。把回款当收入，直接后果是毛利虚高、库存周转判断失真、备货决策失误。
我的判断逻辑是：收入永远从订单侧确认，回款永远从结算侧核对，两条线各自独立，最后在“未结算挂账”这个科目上碰头。如果这两条线能对上，说明你的核算体系是闭环的；如果长期对不上，说明要么收入口径有问题，要么结算数据没抓全。
我见过一个团队，上了 ERP 之后所有费用还是手工在 Excel 里算完，再以“其他费用”一笔录入系统。这样做的后果是系统里只有一个汇总数，任何维度分析都做不了，ERP 退化成了一个更贵的记账本。
正确的用法是把 ERP 当成规则引擎：你告诉它“这个来源的这笔钱，按这个维度、进这个科目、归属这个期间”，它负责批量执行。凡是能定义成规则的东西，都不要留在 Excel 里。
只按店铺设维度，能回答“哪个店赚钱”，回答不了“哪个 SKU 赚钱”“哪个国家赚钱”“哪个渠道赚钱”。而跨境电商的决策往往发生在 SKU 和国家层面。
我的建议是维度不要一次设太细，但一定要预留扩展能力。起步阶段至少要有：主体、平台、店铺、国家、币种、SKU 六层，其中 SKU 层可以先按“类目 + 价格带”做粗粒度归集，等数据质量稳定后再下沉。
期末一次性调汇的问题是丢失了归因信息。我在项目里会把汇兑拆成两部分看：交易性汇兑损益（交易日到收款日之间的汇率变动）和折算性汇兑损益（期末对未结算余额重估产生的变动）。前者反映收款效率，后者反映敞口管理，两者的优化动作完全不同。
按 GMV 分摊广告费，等于假设广告投入和销售额严格成正比。现实中，新品期 SKU 的广告消耗远高于其销售占比，成熟期 SKU 可能几乎不投广告靠自然流量。一刀切会把新品算得特别赚钱，把成熟品算得特别不赚钱，导致备货和投放方向全部错位。
更贴近现实的做法是：能直接归因的广告费直接挂到 SKU，不能归因的（比如品牌广告、店铺级活动）再按合理动因分摊。这个“直接归因比例”每家都不一样，我见过做得好的团队能到 70% 以上。
ERP 能做的是把数据整理好、把明细备齐、把报表出对，它不能替代税务意见。VAT、GST、关税、所得税的适用规则、申报义务、抵扣条件，必须由企业自己和专业税务顾问确认。我在任何项目里都不会在核算规则文档里写死税率，只写“税率参数从外部配置读取”。
这一层解决的问题是“我们公司的规则是什么”。收入确认时点选发货、签收还是结算？存货成本包含哪几段费用？汇率取哪一天的、取自哪个来源？这些政策一旦确定，应该写成文档，由财务负责人签字确认，并且保持至少一个完整会计年度的一致性。
我的经验是：政策层最忌讳“每个平台一套口径”。可以有例外，但例外必须有明确列举和理由，不能因为“这个平台数据抓不到”就默默换一套做法。
政策层是抽象的，业务事件层是具体的。你需要在系统里定义清楚哪些业务动作会产生财务影响。跨境卖家的核心事件通常有八类：下单、发货、签收、平台结算、收款、采购入库、费用发生、退款赔付。每一类事件都要问三个问题：影响什么科目、影响什么期间、需要什么凭证。
这一层是最容易被忽略但最影响效率的。平台导出的字段名和你的科目体系之间，需要一张映射表。没有这张表，每次对账都要人工判断“Settlement Fee 这一列到底对应哪个科目”。
# 科目与维度映射规则示例（示意结构，非任何 ERP 的官方配置格式）
mapping_rules:
source_field: settlement.commission_fee
target_account: "6602.03 平台佣金"
dimensions: [主体, 平台, 店铺, 国家, 币种]
period_basis: 结算所属期
auto_voucher: true
review_required: false
source_field: settlement.advertising_cost
target_account: "6601.07 站内广告费"
dimensions: [主体, 平台, 店铺, 国家, 币种, SKU或活动]
period_basis: 结算所属期
auto_voucher: true
review_required: true
review_reason: 直接归因与分摊混合，需人工复核归因比例
source_field: settlement.refund_amount
target_account: "6001.01 主营业务收入-退回"
dimensions: [主体, 平台, 店铺, 国家, 币种]
period_basis: 原始订单所属期
auto_voucher: true
review_required: true
review_reason: 跨期退款需判断是否调整原期间
source_field: settlement.fx_difference
target_account: "6603.02 汇兑损益"
dimensions: [主体, 币种, 收款账户]
period_basis: 发生期
auto_voucher: true
review_required: true
review_reason: 需拆分交易性与折算性汇兑损益
review_policy:
auto_post_threshold: 单笔金额 < 5000 且规则命中置信度为高
manual_post: 上述条件之外的场景全部人工复核
这段配置结构看起来简单，但它决定了一件事：哪些凭证可以自动生成，哪些必须人工复核。我在项目里见过最有效的做法，是把“自动过账阈值”和“复核理由”也写进规则里，而不是靠人的责任心。
前三层定清楚之后，系统配置才有意义。这一层要做的具体动作包括：维度档案搭建、币种与汇率表维护、科目映射维护、结算单模板匹配、自动凭证规则、对账规则、报表模板。
我把上面四层合并成一张表，这张表是每次上线前必须过一遍的。每上一类新费用，就往这张表里加一行，行数增长本身就是业务复杂度的可视化。
| 业务事件 | 科目方向 | 归属期间 | 是否自动 | 必须人工复核的条件 |
|---|---|---|---|---|
| 订单发货 | 收入 / 应收 | 发货所属期 | 是 | 跨月发货、部分发货 |
| 平台结算 | 应收 / 银行存款 + 各项扣减 | 结算所属期 | 是 | 结算单含上期尾款 |
| 退款 | 收入冲减 / 应收冲减 | 原订单所属期 | 是 | 跨月退款、超期退款 |
| 赔付 | 营业外收入 或 费用冲减 | 收到期间 | 否 | 全部人工判断 |
| 采购入库 | 存货 / 应付 | 入库所属期 | 是 | 到货数量与订单不符 |
| 头程与关税 | 存货成本 / 应付 | 入库所属期 | 是 | 多批次合并运输需分摊 |
| 海外仓仓储费 | 销售费用 或 存货成本 | 发生期间 | 否 | 是否资本化的政策判断 |
| 站内广告费 | 销售费用 | 结算所属期 | 部分 | 直接归因与分摊的边界 |
| 汇兑损益 | 财务费用 | 发生期 / 期末 | 是 | 需拆分交易性与折算性 |
回到前面那个三平台五店铺的账套。假设某一周，五个店铺合计产生 4200 笔有效订单，订单金额按各自币种折算后约为人民币 186 万元。运营侧看到的数字是这 186 万，财务侧要回答的是：这 186 万里，多少属于本期收入，多少属于已发货未确认，多少因为退款要冲减。
我的做法是把收入确认拆成两段判断：第一段判断订单是否满足确认条件（发货或签收，取决于你的政策），第二段判断退款准备金是否要计提。第二段常被忽略，但在退货率高的品类里，它能让月度收入口径产生 3 到 8 个百分点的差异。
同样是这一周，五个店铺实际到账人民币约 118 万元。财务要做的是把 118 万拆回到 186 万的订单上去，或者更准确地说，把差异拆到可解释的科目上去。
我常用的对账顺序是：先对总额，再对结构，最后对明细。总额对不上说明数据源有问题；总额对上但结构不对说明映射规则有问题；结构对上但明细有差异说明跨期或人工调整项没记全。
成本这一段，我要求客户必须能回答一个问题：某个 SKU 从采购到进入目的国可售状态，一共花了多少钱，每一段各占多少。这个问题的答案决定了你的定价底线和清仓判断。
六段费用的处理倾向，我自己的做法是这样的：采购价、国内头程、出口相关费用、目的国关税，一般计入存货成本；海外仓仓储费和尾程配送费，如果和销售强相关则计入销售费用，如果是入库前必需环节则可考虑计入存货成本。具体怎么分，要以企业会计政策为准，我这里给的是判断思路，不是准则结论。
实操中最大的坑是多批次合并运输的分摊。一批集装箱里装了 40 个 SKU，头程费用按什么分摊？按体积、按重量、按货值，结论完全不同。我的建议是选定一个动因之后至少坚持一年，中途换动因会让成本可比性直接归零。
这个账套涉及五种结算币种，汇兑处理是绕不开的。我把它拆成三个动作：交易日按即期汇率或当期平均汇率折算，收款日按实际汇率折算并确认交易性汇兑损益，期末对未结算的应收应付和银行存款余额按期末汇率重估并确认折算性汇兑损益。
三件事做全了，你才能回答“这个月汇兑损失里多少是汇率波动造成的、多少是收款太慢造成的”。这个区别很关键，因为前者只能通过金融工具管理，后者可以通过加快提现频率来改善。
最后一步是把所有东西汇总成一张能看懂的利润表。我的做法是从 GMV 出发，一层一层往下减，每一层都标清楚减的是什么，让运营也能看懂。
说到这里必须回答一个现实问题：这套规则靠人执行得通吗？在订单量不大的时候行得通，一旦多平台多币种并行，数据归集本身就会吃掉大量时间。我在一个多平台卖家项目里用过数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）来做跨境数据的归集和核算处理，它的定位更接近“把多平台经营数据算清楚”的工具，而不是替代财务判断的 ERP 全套。
具体在流程里，它承担的是我前面说的“第三层：数据映射层”和“第四层：系统配置层”里偏数据侧的活儿。多平台结算数据归集、币种折算、费用项归类、店铺与 SKU 维度的利润核算，这些动作如果能自动跑，财务就可以把精力放在口径判断和异常复核上，而不是花在导表和拼表上。
我自己的使用感受是：工具替你解决“算得快”，不会替你解决“算得对”。所以用它之前，那份科目映射表和核算事件清单必须先写好，否则你只是把一个乱账套从 Excel 搬到了另一个系统里，速度变快了，但方向还是错的。
另外提醒一句，任何工具的功能边界都会随版本更新变化，具体支持哪些平台、哪些字段、哪些核算维度，要以官方最新文档为准，不要拿我这里的描述当成功能清单。
这个阶段我不建议上重系统。你要做的是三件事：写一份不超过五页的核算口径说明；建一张能覆盖所有费用项的科目映射表；每月固定做一次“收入线 vs 回款线”的双线核对。这三件事做完，你的账就已经比大多数同规模卖家清楚了。
系统方面，用轻量的数据归集工具配合 Excel 完全够用。这个阶段最大的风险不是效率低，而是为了上系统而打乱本来就不多的业务节奏。
这个区间是矛盾最集中的阶段：业务量已经让手工对账吃力，但还没到必须上完整 ERP 的规模。我的建议是先自动化“高频、规则明确、金额大”的三类动作：平台结算单解析、费用科目映射、多币种折算。这三类占财务手工时间的比例通常在 60% 以上。
同时开始建立维度体系，至少覆盖主体、平台、店铺、国家、币种五层。SKU 维度可以先按类目粗分，等数据质量稳定后再下沉。这个阶段用数跨境这类工具做数据归集和利润核算，配合 ERP 做账务处理，是比较常见也比较务实的组合。
这个规模下，核算体系本身就是一项资产。要做的不只是工具选型，而是整体的核算架构设计：主体之间怎么划分、内部交易怎么处理、合并报表怎么做、不同国家的税务义务怎么承接。
我的经验是，这个阶段的实施周期按“月”算而不是按“周”算，第一阶段先跑通一个主体一个平台的完整闭环，验证无误后再横向复制。不要一次性全面铺开，那是失败率最高的做法。
自动化程度越高，规则越刚性，遇到平台改规则或者业务模式调整时，改造成本也越高。我的判断标准是看业务变化频率：如果一个平台一年改两次结算字段，那这部分就不要做全自动，保留人工确认环节更划算。
常见的做法是分级：高频稳定的走全自动，低频易变的走半自动，金额重大的无论频率都保留人工复核。这个分级不写在制度里就会变成口头的“看着办”，最后一定失控。
分摊粒度越细，结论越准，但维护成本也越高。我做过一个测算：把广告费分摊从“店铺级”下沉到“SKU 级”，SKU 层利润表的准确性明显提升，但每月额外增加的人工维护时间大约是 8 到 12 小时，而且前提是广告数据源本身要支持 SKU 级归因。
自建的吸引力在于完全贴合自己的口径，代价是需要持续的开发和维护投入，而且规则一变就得改代码。采购的优势是成熟度和实施速度，代价是口径需要向工具的模型妥协。
我的判断是：除非你的业务模式足够特殊，导致市面工具的核心模型都无法表达，否则优先采购；但采购的前提是你自己的口径文档已经写好，否则你连“需要什么”都说不清楚。
这个取舍经常被忽略，但它对抗风险的影响很大。财务主导的项目，口径严谨但容易脱离业务实际，运营觉得报表看不懂、用不上；运营主导的项目，指标贴合业务但容易被“好看的指标”带偏。
我的做法是分层负责：口径定义由财务主导，维度设计由财务和运营共同确认，报表呈现由运营提需求、财务审核逻辑。这样能兼顾准确性和可用性。
清单的价值在于把“应该做的事”变成“固定做的事”。下面这张清单是我在项目里用得比较顺手的一版，你可以按自己的业务增删。
| 频率 | 动作 | 负责人倾向 | 输出物 |
|---|---|---|---|
| 每日 | 核对当日订单量与发货量是否一致 | 运营 | 异常订单清单 |
| 每日 | 核对当日到账金额与系统收款记录 | 财务 | 到账差异记录 |
| 每周 | 核对本周结算单与订单明细的金额差异 | 财务 | 未对平金额台账 |
| 每周 | 核对退款与赔付的记账方向 | 财务 | 需复核事项清单 |
| 每周 | 核对广告费直接归因与分摊的比例 | 财务 + 运营 | 归因比例确认单 |
| 每月 | 收入线 vs 回款线双线核对 | 财务 | 未结算挂账余额表 |
| 每月 | 存货成本分摊复核 | 财务 + 供应链 | 成本分摊复核表 |
| 每月 | 期末调汇与汇兑损益归因分析 | 财务 | 汇兑损益归因说明 |
| 每月 | 多维度利润表出具与差异说明 | 财务 | 利润表 + 环比差异分析 |
| 每季 | 核算口径文档复盘与更新 | 财务负责人 | 口径文档新版本 |
一张合格的科目映射表，至少要有这些字段：来源系统、来源字段名、中文含义、目标科目编码、目标科目名称、维度组合、归属期间规则、是否自动过账、复核条件、生效日期、停用日期。
最后两个字段最容易被省掉，但没有生效和停用日期，你就无法回答“三个月前那笔账当时是按什么规则记的”，审计和复盘都会很痛苦。
原则一：能配置的不要写死。税率、费率、汇率来源、结算周期这些参数都应该从外部配置读取，不要在凭证模板或报表公式里硬编码。
原则二：能自动的不要手工，但自动的必须有监控。自动过账的凭证要有数量监控和金额监控，某天自动凭证数量突然翻倍或归零，都应该是告警项，而不是等你月末才发现。
原则三：复核环节要留痕。每一笔人工调整都要记录调整人、调整原因、依据单据。这在业务量小的时候看起来麻烦，但在业务量大的时候，它是你唯一能追溯错误的路径。
如果这篇拆解只留一句话，我会留这句：ERP 是放大器，不是替代品；核算规则不清楚的时候，自动化只会把错误放大得更快、更隐蔽。我见过太多团队把“上系统”当成解决财务混乱的方案，结果三个月后发现只是把混乱从 Excel 搬到了系统里，而且更难排查。
另一个我想强调的独特判断是：跨境电商财务核算的核心能力，不是熟练操作某个软件，而是把杂乱的平台数据翻译成可解释的会计事件的能力。这个能力体现在你能不能快速说出“这 68 万的回款，对应哪些订单、扣了哪些费用、为什么和收入差这么多”。能说清楚，工具随便选都能用好；说不清楚，换十个系统也一样。
下一步怎么走，我给一个具体的三周行动计划。第一周，把你现在的收入确认口径、成本归集路径、汇率取值来源写成文档，不超过五页，越具体越好。第二周，把过去一个完整月的平台结算数据导出来，手工做一次收入线和回款线的双线核对，记录下所有对不上的差异和原因。第三周，根据差异原因反推你的映射规则缺了什么，补齐科目映射表，再决定是先用轻量工具还是直接上完整系统。
这三周做完，你会得到一个比任何选型报告都更有用的东西：一份属于你自己业务的核算规则。有了它，无论后面选择哪条技术路线，你都能判断出方案是真正解决了问题，还是只是换了个说法。
我自己做两个平台，月底导结算报表的时候发现回款金额跟 ERP 里的订单收入总差几万块，一开始以为是系统算错了，后来才发现佣金、退款、广告费全混在里面。我想知道到底该按什么口径对账，才不会每个月都翻半天账还翻不明白。
先明确一个前提：平台回款不等于订单收入，两者之间隔着佣金、平台费、广告费、退款、赔付、促销补贴、仓储费和结算时间差这几层。
可执行做法分三步：第一步做桥接表，把结算周期内的期初应收、本期订单收入、本期各项扣费、本期退款、本期实收回款、期末应收列成一行，差额必须能被这几个项目解释干净，解释不掉的才叫待查项；
第二步在 ERP 里把结算单做成独立单据类型，按费用类型建二级科目，佣金、广告、仓储、退款分开挂，不要把所有扣款都塞进手续费一个科目，否则永远拆不出问题；第三步确定对账频率，订单量大的卖家建议按平台结算周期对，而不是按自然月，因为平台结算周期和会计月经常错位。
判断依据是每一笔钱都能追到单据，如果某个差额连续两个周期都追不到，优先排查跨期结算和退款跨月，而不是先怀疑 ERP 算错。具体到账口径仍要以各平台官方结算说明为准。
我们店铺收美元、欧元、英镑，采购却用人民币付款，每次财务问我汇率按哪个口径，我都答不上来。之前试过全按月末汇率统一折算，结果利润表跟实际到账差挺多，老板还以为账做错了。
核心是先定三件事：记账本位币、汇率来源、调汇频率，定了就不要频繁改。常见做法是交易日按当日汇率或当月固定汇率记账，收付款日按实际结汇汇率记账，期末对未结清的外币货币性项目按期末汇率调汇，差额进汇兑损益。判断依据是会计准则对货币性项目和非货币性项目的处理要求不同，不要把所有权责类科目都拿来调汇。
落地到 ERP 有三个动作：维护一张带来源标注的汇率表，建议用官方或银行中间价；把币别设置到客户、供应商、银行账户这一层，而不是只在单据上临时填；汇兑损益单独设科目并绑定自动凭证模板。实操最容易踩的坑是同一笔收款分两次到账、两次汇率不同，这时要按每笔实际结汇金额分别入账，不能拿平均汇率一次性冲掉。
汇率口径和调汇规则建议先由财务负责人或税务顾问确认、写进会计政策文档，再让 ERP 按文档配置，而不是反过来让系统决定口径。
我们算 SKU 利润的时候，运营和财务老是吵。运营觉得广告费就该按投放的 ASIN 算，财务觉得很多费用根本拆不到 SKU，只能到店铺层。我也想知道到底拆到哪一层合适，拆错了会有什么后果。
先回答要不要拆：能直接归属的费用必须直接归属，不能直接归属的才做分摊，而且分摊口径要写进制度。佣金、平台配送费、退款通常能按订单行直接归属到 SKU；广告费如果有广告报表可以按 ASIN 归属，没有的就按店铺或广告活动分摊；
软件订阅费、人员工资、海外仓固定租金这类建议先分摊到店铺或国家层，不要硬拆到 SKU。落地方法是在 ERP 里建直接费用和分摊费用两套费用类型，分摊基数固定成一种，比如按销售额、按订单行数或按体积重，选定后至少一个财年不动。
判断依据是 SKU 利润表主要服务于选品和定价，如果分摊基数频繁变化，同一款产品这个月赚下个月亏，决策就失去意义。建议同时保留贡献毛利（只扣直接费用）和净利（扣完分摊）两张报表，运营看前者、老板看后者，争议会少很多。
我想把公司自己的核算流程整理成案例给团队和同行看，但写出来总是很像功能说明书，别人看完不知道能拿走什么。而且我们的一些费率、退款率是内部数据，直接放出去也不合适。
案例的参考价值不来自结果多漂亮，而来自假设条件写得够不够清楚。建议按这个骨架搭：一，案例背景交代平台数量、店铺数量、币种、物流模式、结算周期、团队规模这六个变量，缺任何一个读者都无法判断自己能不能套用；二，所有数字标注是假设值还是实测值，假设值要写清取值来源，比如平台官方费率页或某月平均汇率；
三，每个核算环节按业务发生了什么、财务口径是什么、ERP 配了什么、哪些必须人工复核这四段写，缺第三段就退化成业务科普，缺第四段读者会误以为全自动；四，结尾给可复用检查清单，比如期末必查五项，未结算订单、跨期退款、未匹配收款、未结清外币科目、库存成本差异。
判断标准很简单：读者看完能不能在自己账套里复制其中至少一个动作，能复制就有价值。另外提醒一句，平台费率、税率、结算周期变化频繁，案例里写的规则一定要标注生效日期，否则半年后就成了误导。
读者评论
文章把口径和系统分开讲很关键。很多卖家以为上线ERP就能解决利润差异，实际首月异常排查翻倍才是常态。尤其是收入确认时点和平台回款两条线，不先定义清楚，系统只会把差异固化。
广告费按GMV分摊这点很扎心。我们做TikTok Shop时新品广告扣减经常超过销售额占比，一刀切会把新品算得虚高。直接归因能挂SKU的先挂，剩余再分摊，利润才接近真实。
作为财务，最认同汇兑拆成交易性和折算性两部分。期末一次性调汇只知道亏了多少，无法判断是收款节奏还是敞口问题。不过文章假设数据较多，实际落地还要考虑平台结算文件字段完整性。
判断标准里订单行超800或金额超20万值得参考，但中小卖家不一定马上上完整ERP。先把口径文档、未结算挂账和六层维度做出来，用轻量工具过渡半年，可能比仓促上线更稳。