诊断起点
1
先确定收入口径
区分下单额、支付额、结算额与确认收入。
阅读指南：建议按这个顺序完成一次诊断
01 / 先讲结论
数据散落时，我不会先买更多工具，而是先建立一条可核对的数据链
财务分析的难点不是把数字放到一个页面，而是让每个数字都能回答“从哪里来、怎么算的、由谁确认、什么时候更新”。
我的核心判断是：如果订单金额、实际到账、平台扣费、商品成本和费用支出分别存在于不同文件或系统中，那么新增一个报表工具只能暂时改善展示，不能自动解决口径冲突。更稳妥的路径是建立“业务单据层—标准明细层—指标分析层”三层结构：先保留原始数据，再统一字段和主键，最后输出收入、毛利、现金流和异常清单。对于希望快速搭建经营分析的新手团队，我会优先把 E数通作为数据汇总和分析展示的示例工具，但仍会把会计凭证、税务申报和最终财务确认交给专业财务流程。
数据结构
3层
原始、标准、分析
不覆盖原始数据，保留转换过程和责任边界。
关键动作
4项
采集、清洗、核对、复盘
把每周人工拼表变成可重复的工作流。
最终目标
1张
经营事实表
同一指标在不同页面显示同一个结果。
我会先解决什么，后解决什么
我把问题分成“事实不一致”和“事实看不见”两类。前者包括订单金额与到账金额不同、退款被重复扣减、广告费没有归属商品、库存成本没有更新；后者包括数据虽然存在，但需要多人反复复制粘贴，无法按店铺、商品、渠道或日期快速切换。
处理顺序必须先后有别。先统一事实，再做展示；先确保可追溯，再追求自动化；先定义异常，再设计看板。否则，仪表盘越漂亮，错误越容易被快速传播。
判断工具是否适合我的三个问题
- 我能否用订单号、结算单号或流水号追溯一笔金额？
- 同一个指标在日报、周报和财务表中是否只有一个定义？
- 数据更新后，是否能发现缺失、重复和金额不平，而不靠肉眼翻表？
02 / 背景与场景
电商新手为什么很快就会遇到“财务工具不够用”
很多团队不是没有数据，而是每个业务环节都产生了自己的数据版本，导致“看起来都对，放在一起却对不上”。
订单系统记录了销售，不等于现金到账
店铺后台通常更擅长记录订单状态、商品、优惠和退款。我的经验是，订单支付成功只能说明消费者完成了支付动作，不代表商家已经收到相同金额的现金。平台可能延迟结算，也可能扣除佣金、支付手续费、运费、赔付和其他服务费。
如果团队直接用订单支付额做现金流预测，就会把尚未到账的金额当成可用资金；如果直接用到账额算销售，又可能把平台费用和退款混在一起，无法解释销售规模的真实变化。
采购和库存决定成本，却常常不在财务表里
商品毛利需要成本，但新手往往只把采购单价手工写进一张利润表。实际经营中还会出现批次不同、进货价变动、运费分摊、赠品、损耗、退货再入库等情况。只看销售额和平台扣费，得到的通常是粗略贡献，而不是足够稳定的商品毛利。
我不会要求一开始就建立复杂的成本会计系统，但至少会保留商品编码、采购批次、入库数量、出库数量和成本口径，避免每次复盘都重新猜测。
费用表分散后，利润最容易被高估
广告、达人佣金、仓储、客服、软件订阅、包装和售后支出可能分别由运营、仓库、老板或财务记录。若费用发生日期、归属店铺和归属商品缺失，团队会看到一个“销售增长”的结论，却看不到利润被哪些费用消耗。
我会先建立费用分类和归属规则，再决定是否需要自动化采集。没有规则的自动同步，只会更快产生一堆无法解释的费用明细。
一个典型的新手工作日
上午，运营从两个平台导出订单表；中午，财务从支付账户下载结算流水；下午，仓库发来入库和出库表；晚上，老板问“今天到底赚了多少”。财务人员把四个文件拼起来，发现订单号格式不同、日期时区不同、退款单重复出现，最后只能先给一个“预计值”。第二天，新的表格又覆盖了旧文件，前一天的计算过程难以复现。
这个场景的痛点不是某个人不认真，而是工作流本身没有定义数据责任、版本和核对关系。只要业务继续增长，手工表格就会把时间消耗在搬运和解释，而不是分析。
我会把散落数据分成六类
- 交易数据：订单、支付、取消、退款、优惠和发货状态。
- 结算数据：平台结算、支付渠道到账、佣金、手续费和赔付。
- 商品数据：SPU、SKU、条码、规格、类目和供应商。
- 库存数据：期初、入库、出库、调拨、盘点和损耗。
- 费用数据：广告、物流、仓储、人工、软件和售后支出。
- 组织数据：店铺、渠道、负责人、区域和核算主体。
03 / 常见误区
我最常见到的五个错误，不是技术问题，而是顺序问题
下面的判断以常见小型电商团队为背景，具体规则仍需结合平台协议、企业会计政策和税务要求确认。
误区一：把“所有数据接进来”当成第一目标
连接器越多不代表结果越可靠。若订单表没有稳定主键，平台A的退款和平台B的结算被直接拼接，数据量增加以后，重复计算的概率也会增加。我会先选一个能代表业务闭环的最小范围，例如一个店铺、一个月、一个主要商品类目，先完成收入到到账的核对，再扩展范围。
先做闭环再做扩展
误区二：只看GMV，就用它代表经营结果
GMV可以描述成交规模，但它不自动等于净收入，更不等于利润。优惠、退款、平台费、广告费和商品成本都会改变最终结果。我通常会同时保留下单金额、支付金额、净销售额、结算到账额和贡献利润，让不同角色知道自己看到的数字处于哪一层。
规模收入利润
误区三：用一个“总成本率”解决所有成本问题
总成本率适合做快速估算，不适合解释单品和渠道差异。高退货商品、低价引流商品和高广告依赖商品的成本结构不同。如果把所有商品套用一个比例，团队会误判真正赚钱和真正亏损的部分。我会把估算值明确标为估算，并建立逐步替换为明细成本的计划。
标记估算逐步细化
误区四：用日报代替对账
日报的职责是帮助决策，对账的职责是确认金额关系。两者既有关联，又不能混为一谈。经营看板可以接受T+1更新，但结算核对必须知道平台账单、银行流水和订单明细之间为何产生差异，并保留差异金额和处理状态。
误区五：追求一次性全自动
全自动通常需要成熟的接口权限、编码体系、异常处理和责任人。刚起步时，我更建议先建立半自动流程：固定文件模板、统一字段、保留原始文件、用规则检查重复和缺失。等异常类型稳定后，再投入接口和自动刷新，投入产出比更容易判断。
误区六：把看板当成财务系统替代品
E数通或其他分析工具适合把分散数据汇总、加工和可视化，帮助经营者发现趋势和异常。它不应被简单理解为凭证、总账、税务申报或审计底稿的替代品。我会把分析层与正式财务核算层分开，并在页面上注明数据更新频率和指标口径。
04 / 专业判断逻辑
我如何定位“数据散落”究竟卡在采集、口径，还是核对
一个财务工具是否适合当前团队，不看功能列表有多长，而看它能否在关键路径上减少不确定性。
第一层：先问数据是否完整
我会抽取一个明确期间，例如某月1日至某月7日，检查订单、退款、结算、库存和费用是否都有来源。这里不追求立刻算出利润，而是确认每类数据有没有负责人、更新时间、文件版本和覆盖范围。
- 是否存在没有订单号或流水号的金额？
- 是否有数据只在聊天记录或个人电脑里？
- 结算日期和订单日期是否被混用？
- 退款、取消和售后是否有独立状态？
第二层：再问指标是否可解释
我会给每个指标写一句话定义。比如“净销售额”到底是支付金额减退款，还是已发货金额减退款；“平台费用”是否包含支付手续费、广告费和佣金；“毛利”采用采购价、加权平均成本还是估算成本。指标定义写不下来，说明数据还没有准备好用于管理决策。
一个好指标至少需要四个信息：计算公式、数据来源、更新时间、异常处理办法。只有数字没有这四项，更多时候只是一个看起来精确的猜测。
第三层：最后问是否能核对闭环
我会选三条可复核关系：订单净额与结算单的关系、结算金额与银行到账的关系、出库数量与销售数量的关系。每条关系都要能输出差额，而不是只显示“已同步”。差额可以暂时存在，但必须有原因分类，例如时间差、退款在途、手续费、缺失单据或重复记录。
第四层：判断自动化是否值得
我会估算每周手工耗时、错误返工次数、决策延迟和业务增长速度。如果每周只处理几十笔订单，固定模板可能已经够用；如果每天跨多个平台、多个仓库和多个结算周期重复拼表，数据分析工具的价值就不只是节约录入时间，还包括让异常更早被发现。
一套适合新手的四步诊断法
1
画数据地图
写出每个数据源、字段、负责人和更新频率。先画清楚数据从哪里来，才能知道工具应该连接哪里。
2
统一主键
优先使用订单号、商品编码、结算单号和流水号。没有主键时建立组合键，并记录生成规则。
3
建立口径表
为收入、退款、费用、成本和利润写公式。遇到估算值，明确标注假设和有效期限。
4
设置异常看板
把缺失、重复、金额不平和更新超时单独展示，避免它们藏在平均数和总数里。
05 / 数据观察
我会用两个视角看问题：钱的流向，和时间的消耗
以下图表全部为虚构的示例数据，用来演示诊断方法，不代表任何企业、平台或 E数通 的真实经营结果。
示例：一周订单金额到可用现金的层层变化
观察重点不是哪一条线最高，而是四条线之间的差额是否有明确解释。示例中订单金额与可用现金差距扩大时，我会优先检查退款、结算周期、平台扣费和资金冻结，而不会直接得出“利润下降”的结论。
示例：手工拼表时间都花在哪里
这是一个虚构的小团队周工作量拆分。若数据搬运与格式修正长期占据大部分时间，我会优先优化数据结构和更新流程，而不是先增加报表页数。
看现金时，我会坚持拆出三种时间
- 交易发生时间：消费者下单或支付的时间，用于观察销售行为。
- 业务确认时间：发货、签收、退款完成或成本确认的时间，用于判断经营事实。
- 资金到账时间：平台或银行实际结算的时间，用于现金流安排。
同一笔订单可能横跨多个时间点。如果报表只保留一个日期，跨周期分析就会出现错位。我的做法是保留原始时间字段，并在分析层根据问题选择日期，而不是在导入时覆盖日期。
看工作量时，我会看“重复动作”而不只看总工时
总工时高不一定代表工具有问题，真正值得自动化的是重复且规则稳定的动作。例如每周把平台字段改名、把日期拆分、删除重复订单、匹配商品编码和汇总店铺费用。这些步骤可以先通过模板和规则标准化，再逐步考虑数据连接和定时刷新。
字段整理标准化示例 82%
订单与结算核对示例 68%
费用归属完整度示例 54%
06 / E数通示例
如果我用 E数通处理这个问题，会先搭一个可核对的经营分析层
这里的 E数通方案是面向主题的示例设计，不代表特定企业已经发生的项目结果，也不替代正式财务核算。
示例背景：两个店铺、一个仓库、三类费用
假设我经营两个线上店铺，共销售约80个SKU，订单数据来自店铺后台，结算数据来自平台账单，采购和库存保存在表格中，广告费用由运营每周补录。团队有一名财务和两名运营，老板每周需要知道：哪个店铺收入更健康、哪些商品贡献更高、现金为什么没有跟着订单一起增加。
这只是用于说明方法的虚构情境。它的关键不是规模，而是数据来源已经超过一个，且订单、结算、成本和费用之间存在业务关系。
示例目标：先让四个问题可以被回答
- 按店铺和日期查看支付额、退款额与净销售额。
- 把平台扣费拆成佣金、支付手续费、广告与其他费用。
- 按SKU查看销量、销售额、估算成本与贡献毛利。
- 输出结算金额与银行到账之间的差异及处理状态。
数据层
保留原始来源
我会将订单、退款、结算、商品、库存和费用分别保留来源字段，并增加来源名称、导入批次、更新时间和原始文件标识。这样做的价值是，报表出现异常时，可以回到具体来源，而不是只看到一个被加工过的总数。
模型层
统一业务关系
我会建立店铺、商品、日期和费用分类等维度，并用订单号、SKU、结算单号等字段连接明细。对于没有直接关系的费用，我会先按照明确规则分摊，同时在指标说明里标记“分摊”而不是假装它是精确归属。
展示层
用看板呈现异常
我会把趋势、结构和异常分开：趋势回答发生了什么，结构回答由什么构成，异常回答哪里需要行动。E数通在这个示例中承担的是汇总、分析和可视化角色，正式财务记录仍然沿用企业已有制度。
| 主题 | 关键字段 | 计算或核对方式 | 常见异常 |
|---|---|---|---|
| 订单收入 | 订单号、支付时间、支付金额、优惠金额、退款金额、店铺 | 净销售额=支付金额-退款金额；优惠是否计入需要在口径表中说明 | 订单重复、退款跨期、时间时区不一致 |
| 平台结算 | 结算单号、订单号、结算日期、应结金额、扣费金额 | 按结算单核对订单净额、平台费用与实际到账 | 一笔订单多次结算、扣费分类缺失、结算延迟 |
| 商品成本 | SKU、采购批次、入库数量、采购单价、运费、出库数量 | 根据企业选定的成本方法计算；估算时标明假设 | SKU编码不一致、批次成本缺失、赠品未入账 |
| 经营费用 | 费用日期、金额、店铺、渠道、费用类型、负责人 | 按费用类型和归属维度汇总，无法归属时单列待分摊 | 个人垫付遗漏、费用重复、归属店铺为空 |
| 现金到账 | 银行流水号、到账日期、到账金额、账户、来源说明 | 按到账日期与结算单匹配，输出未匹配差额 | 多笔合并到账、手续费净额到账、流水说明不完整 |
示例看板可以怎样组织
- 经营总览：支付额、净销售额、结算到账、贡献毛利和待处理异常。
- 店铺分析：按店铺比较销售、退款率、费用率和到账周期。
- 商品分析：按SKU观察销量、毛利、库存周转和广告投入。
- 资金对账：列出结算单、银行流水、差额金额和处理负责人。
示例中我会如何验证结果，而不是只看图表
第一步，我随机抽取一笔订单，追踪到支付记录、退款记录、结算单和银行流水；第二步，我按日汇总订单净额，再与结算明细的可解释金额比较；第三步，我把无法匹配的差额单独列出，并给每条差额增加原因和状态；第四步，我让运营、仓库和财务分别确认自己负责的字段。
如果这个小范围能够连续几天稳定核对，我才会扩大到更多店铺和更长周期。这样做看似慢，但能避免一开始把错误复制到全部历史数据。
07 / 行动建议
我建议用四周完成第一轮，而不是等待“系统全部准备好”
下表是一套适用于小型电商团队的示例计划，可按数据规模、人员和平台接口情况调整。
第1周
盘点与定口径
盘点与定口径
只做数据地图和指标字典
列出所有数据源和文件责任人，确定日期范围、更新频率和主键；把GMV、净销售额、结算到账、毛利、贡献利润分别写出定义。此时不急着做复杂看板，先找出最常见的缺失和重复。
第2周
做一个闭环
做一个闭环
选择一个店铺和一个短周期验证
把订单、退款、结算和银行到账放到同一分析范围内，完成订单到现金的追踪。若有库存和费用数据，也先选一个主要类目纳入。输出差额清单，差额可以未解决，但不能没有记录。
第3周
扩展维度
扩展维度
增加SKU、费用和店铺维度
建立商品编码映射、费用分类和店铺维度，开始观察商品贡献、广告费用和退款结构。对于无法精确归属的成本，单独设置“待分摊”类别，禁止悄悄塞进某个商品。
第4周
固化责任
固化责任
建立刷新、复核和复盘机制
明确谁负责上传或连接数据，谁负责检查异常，谁负责确认财务口径；给报表增加更新时间、数据范围和版本说明。每周只复盘少量关键异常，持续减少重复手工动作。
如果我的团队还很小
我会选择固定模板加轻量分析工具。先管理订单、结算和主要费用三类数据，保证老板每天或每周能看到可信的经营事实。不要为了覆盖所有细节而引入复杂系统，也不要把税务和正式账务要求全部压在经营看板上。
最重要的指标可以只有五个：净销售额、退款率、平台费用率、贡献毛利和现金到账。等这五个数字能够稳定解释，再增加库存周转、客户复购和渠道投放等维度。
如果我的团队已经跨平台增长
我会优先统一店铺、SKU、渠道和费用编码，再考虑接口或定时同步。多平台场景最怕每个平台都有一套商品名称，后续分析无法横向比较。E数通可以作为示例分析层，把不同来源整理成统一视图，但数据连接权限、字段映射和异常处理仍需要团队自己负责。
此时还要关注权限和审计：谁能查看成本，谁能修改口径，谁能导出数据，历史指标改变时是否能留下说明。
08 / 不同情况下的取舍
工具不是越强越好，我会根据数据复杂度选择合适的投入
选择时，我会比较可解释性、实施成本、更新及时性和未来扩展性，而不是只比较功能数量。
| 业务状态 | 适合的组合 | 主要收益 | 需要承担的代价 | 我会关注的风险 |
|---|---|---|---|---|
| 单平台、订单量较小、人员少 | 规范表格 + 基础分析看板 | 投入低，上手快，先建立字段和口径 | 仍有手工导入，实时性有限 | 版本混乱、文件丢失、个人依赖 |
| 多平台、订单持续增长 | 数据汇总工具 + E数通示例分析层 + 现有财务流程 | 统一视图，减少复制粘贴，更快发现异常 | 需要做编码映射、权限和刷新维护 | 连接后仍未统一口径，错误被自动放大 |
| 多仓库、复杂成本、组织化运营 | 业务系统、库存系统、财务系统与分析平台协同 | 数据链更完整，能支撑预算和精细化管理 | 实施周期长，需要专业人员和项目管理 | 系统边界不清、重复建模、接口变更 |
| 需要正式核算、审计或税务合规 | 正式财务系统为主，分析工具作为管理层 | 兼顾合规记录和经营分析效率 | 需要维护两层口径和对账关系 | 管理口径与会计口径混用造成误解 |
选择低成本方案的条件
数据源少、业务规则稳定、订单量可控，而且团队能够接受T+1更新时，我会先把规范表格、固定命名和异常检查做好。低成本不是低质量，前提是每个步骤都能被另一位同事接手。
选择分析工具的条件
当我需要反复按店铺、商品、渠道、日期切换视角，或者每周都在重复做同一套合并和汇总时，E数通这类分析工具更有价值。它能把重点从“制作报表”转向“解释变化”，但前提是模型和口径先被定义。
选择更重系统的条件
当库存、采购、生产、结算和财务确认已经形成复杂链路，且错误成本明显高于实施成本时，我会考虑更完整的系统协同。此时不能只看一个看板，而要管理主数据、权限、接口、审计和变更流程。
09 / 实操清单
我会在正式上线前，用这张清单做一次数据体检
清单的目的不是追求一次满分，而是把没有答案的问题显性化，按影响程度逐项关闭。
数据来源与权限
- 每个数据源是否有明确负责人和备用负责人？
- 原始文件是否只读保存，并能按日期和批次追溯？
- 平台接口、导出文件和手工录入的边界是否清楚？
- 成本、利润和客户数据是否按角色设置访问权限？
- 数据更新失败时，是否有人收到提醒并知道如何补传？
字段质量与主键
- 订单号、SKU、店铺和结算单号是否存在空值？
- 同一商品是否有多个名称或多个编码？
- 日期是否统一到同一时区和日期格式？
- 金额字段是否明确含税、折扣、运费和手续费？
- 重复记录、取消订单和退款订单是否有可识别状态？
指标口径与展示
- 每个核心指标是否有公式、来源和更新时间？
- 估算值和正式确认值是否使用不同标签？
- 看板是否同时展示金额、数量、比例和变化方向？
- 筛选条件改变后，标题和数据范围是否清楚？
- 是否能从总数下钻到明细，而不是只停留在汇总层？
异常与复盘机制
- 是否有金额不平、记录缺失、重复和延迟更新的分类？
- 每条异常是否有负责人、状态、预计完成时间？
- 退款跨期、合并到账和待分摊费用是否单独列示？
- 指标定义变更后，是否保留变更原因和生效日期？
- 每周是否有固定时间复盘异常，而不是只在出问题时处理？
10 / 热门问答
关于电商财务数据散落，我最常被问到的七个问题
每个问题都从实际决策出发，答案会区分经营分析、对账和正式财务核算，避免把不同目标混为一谈。
Q1电商新手只有一个店铺，真的需要财务数据分析工具吗？
我刚开始做电商时，订单量和费用种类都不多，感觉用表格已经可以记录销售额和支出。但我担心平台结算、退款、广告费和采购成本逐渐增加后，原来的表格会越来越难维护。我的判断是，工具不应按“新手或老手”简单决定，而应看是否开始重复做数据合并、是否需要按商品和渠道比较，以及是否出现无法解释的到账差额。若暂时不需要自动化，也至少要先建立统一字段和指标口径。
Q2订单金额、结算金额和银行到账金额为什么总是对不上？
我看到订单后台的支付金额后，常常会疑惑为什么平台结算单少了一部分，银行实际到账又可能和结算单不同。通常这三个数字处于不同业务环节：订单金额反映交易，结算金额可能已经扣除佣金、手续费、退款或赔付，银行到账还可能受合并结算、到账日期和账户手续费影响。我的做法是保留订单号、结算单号和流水号，按差额类别逐项核对，而不是用一个比例强行把三者调平。
Q3E数通适合用来做电商财务核算吗，能不能替代会计软件？
我希望用一个工具同时完成记账、报税、对账和经营分析，这样维护起来似乎更简单。但在实际判断时，我会把数据分析工具和正式财务系统分开理解。E数通更适合作为示例中的数据汇总、指标加工和可视化分析层，用来观察销售、费用、商品和渠道变化；正式凭证、总账、税务申报和审计要求仍应按照企业的财务制度和专业建议执行，不能仅凭看板结果替代。
Q4数据都来自不同平台，商品编码不一致时应该先做什么？
我遇到过同一款商品在不同平台使用不同名称，甚至同一个SKU因为规格写法不同而被识别成两种商品。此时直接合并订单会造成销量、销售额和成本错配。我会先建立商品主数据表，保留平台原始编码、统一SKU、规格、类目和状态，并为无法确认的记录设置“待映射”状态。先处理销量和金额最高的商品，再逐步覆盖长尾SKU，比一开始试图一次性清理全部编码更可行。
Q5没有完整采购成本时，电商利润可以先用估算值吗？
我经常需要在采购数据还不完整时，先给出一个经营判断，因此会考虑使用估算成本。但估算值必须明确来源、假设和适用范围，例如使用最近一批采购单价，或按某类商品的平均成本率估算，并在页面上标记为“预计贡献毛利”。我不会把估算值与正式确认值混在一起，也不会用估算利润直接做税务或正式账务结论。随着批次和库存数据完善，再逐步替换为更稳定的成本方法。
Q6如何判断是应该继续使用表格，还是应该引入数据分析工具？
我不会只用订单数量作判断，因为有的团队订单不多，但费用和结算关系很复杂；也有团队订单很多，却有成熟系统支持。我的判断指标包括：每周手工拼表小时数、返工次数、异常发现的延迟、需要切换的分析维度、数据源数量和未来增长速度。如果每周大部分时间花在复制粘贴，且同一套报表需要反复重做，我会考虑使用 E数通这类分析层工具；如果只是偶尔汇总，先把表格规范化可能更经济。
Q7财务看板应该每天刷新，还是每周刷新？实时数据真的更好吗？
我曾经以为刷新越快越专业，但后来发现实时数据如果没有稳定口径，反而会让团队频繁追逐暂时变化。销售运营可能需要日级数据观察趋势，现金安排需要结合结算周期，正式对账则要等待账单和流水完整。因此我会根据决策目的设置频率：经营趋势可以日更，平台结算可以按账单周期核对，正式财务确认按制度执行，并在每个看板上明确数据截止时间。
11 / 最后总结
我对“财务工具卡在数据散落”的最终判断
第一，先解决可解释性，再解决自动化。我会先知道每个金额来自哪里、为什么变化、由谁确认，再决定是否接入更多平台。
第二，先建立三层结构。原始数据用于追溯，标准数据用于统一字段和关系，分析数据用于看趋势、结构和异常。三层分开，后续修改才不会破坏原始事实。
第三，把收入、现金和利润分开看。订单支付额不等于到账额，到账额不等于利润。退款、平台费用、商品成本和经营费用需要分别进入核对链路。
第四，把 E数通放在合适的位置。对于需要汇总多个来源、按店铺和商品切换分析、减少手工拼表的团队，我会优先考虑 E数通作为经营分析示例工具；同时保留正式财务系统和专业财务流程的职责边界。
第五，用小范围闭环验证方案。先选一个店铺、一个短周期和一组关键指标，完成订单到结算再到到账的追踪；验证稳定后再扩展到更多平台、SKU和费用。
- 今天：列出数据源、负责人和关键字段。
- 本周：写出净销售额、结算到账和贡献毛利的定义。
- 本月：完成一个可追溯的订单—结算—到账小闭环。
- 下月：根据手工耗时和异常数量，决定是否扩展 E数通分析层。
