去年旺季补货期，我经手过一个很典型的情形：一家做亚马逊北美站的卖家，在补货高峰把 ERP 的采购模块开放给了三名采购专员，为了方便对账，又给两家主力供应商各开了一个协同账号。三个月后他们做数据抽查时发现，其中一个供应商账号的登录 IP 分布在三个省份，而采购价格表在那个账号最后一次登录后被导出过一次。没有人能说清这次导出是谁做的，因为那段时间团队用的是同一个共用登录名加群聊里发的密码。
这件事没有造成直接损失，但它暴露的问题足够典型：很多卖家的账号安全不是被攻破的，是被“为了方便”一点点让渡出去的。采购补货恰恰是整个跨境电商业务里，让渡最频繁、最不容易被察觉的那条链路。
这篇内容不打算做泛化的账号安全科普。我只讲一件事：在采购补货这条业务流上，账号安全到底该在哪里画线，怎么画，画到什么颗粒度够用，以及当效率和隔离冲突时，该怎么取舍。
我接触过几十家做跨境的中小卖家，在账号安全这件事上普遍存在一个认知错位：把安全当成“IT 部门的配置项”，而不是“业务负责人要定的规则”。
配置项是可以勾选的，开启二次验证、设置密码复杂度、限制登录 IP。但规则是要判断的，谁在什么场景下可以碰哪个账号，碰完之后留下什么痕迹，出了事能不能追回去。
采购补货场景里的账号安全，本质上不是技术问题，而是四道边界的划分问题。这四道边界一旦含糊，再多技术手段也只是补丁。
第一道边界管的是“操作环境”。同一个人，用同一台电脑、同一条网络、同一个浏览器，频繁登录多个平台店铺后台去查库存、看销量、核对在途，这在采购补货环节是高频动作。
这道边界的核心问题不是“会不会被判定关联”，而是你根本不知道自己的操作轨迹在平台侧长什么样。你不知道，就无法判断风险，也无法在出问题后自证。
第二道边界管的是“你能看到什么、能改什么、能导出什么”。采购角色手里握着供应商名单、采购底价、账期、补货节奏，这些信息的商业价值远高于很多人以为的程度。
一个采购专员如果同时拥有“查看全部供应商底价”“修改采购单”“批量导出数据”三项权限，那他在系统里的破坏力，等同于一个没有审批约束的老板。
第三道边界管的是“非员工账号”。为对账、为代发、为让供应商自己填发货信息，很多卖家会给供应商开 ERP 账号。开的时候很快，回收的时候很少有人记得。
开通容易、回收困难，是协同类账号最普遍的失控点。合作终止半年后账号还能登录的情况，我在实际排查里见过不止一次。
第四道边界管的是“钱”。补货链路最终会落到付款或请款动作上。如果同一个账号既能发起采购单、又能审批、还能执行付款，那么对账异常发生时，你连“是流程错了还是人错了”都分不清。
下面这张图，是四道边界在真实业务里失控后的典型后果排序，按我实际处置过的案例频次做了权重推演。
账号安全在每个业务环节都存在，但采购补货有三个特殊性，让它的风险被成倍放大：跨系统、高频次、强时效。
我把一次完整的补货决策拆开数了一遍。从发现某个 SKU 需要补货，到采购单最终变成付款，中间至少要经过这些动作：
七个动作，至少涉及四个不同的账号体系。而这个过程通常要在同一天、甚至同一小时内完成，因为补货窗口期很短，晚两天可能就赶不上船期。
补货的效率要求，天然在和账号隔离的要求打架。这是所有问题的起点，不承认这一点，后面所有方案都是空谈。
我记录过一个三人采购小组在旺季补货日的操作时间线，脱敏后大致是这样：上午 9 点开始查库存，10 点半切换到 ERP 看建议，下午 1 点集中联系供应商比价，3 点集中创建采购单，4 点半走审批，5 点处理付款。
关键点在下午 1 点到 3 点这段：采购员会在两个小时内，在平台后台、ERP、供应商沟通工具之间来回切换十几次。这种切换强度下，任何“多一步验证”的设计都会被绕开，不是员工不守规矩，是规矩在设计时就没有考虑人的操作节奏。
切换本身不是风险，切换带来的“记忆负担”才是。当一个人一天要记三到四套账号密码，并且这些密码按制度要求每 90 天更换一次时，他一定会找一个更省事的方式。
省事的方式通常是三种：密码记在备忘录里、密码发在群里、直接用同事的账号。三种方式的共同点是：账号身份和真实操作人脱钩了。
一旦脱钩，后面所有的审计、追溯、责任认定都会失效。你在 ERP 里看到的所有操作日志，都只能证明“某个账号做了什么”，而不能证明“某个人做了什么”。这是采购补货账号安全最致命的结构性问题。
“账号安全”这个词之所以讨论不清，是因为在跨境采购补货语境下，它至少指四类完全不同的东西。这四类账号的归属人、风险类型、管理方式都不一样。
这是企业内部人员使用的账号，包括主账号和子账号。核心管理点是角色划分：谁能看到什么数据、谁能修改什么单据、谁能批量导出。
这类账号的可控性最高，因为系统在你手里，权限模型是你可以定义的。问题不在于能不能管，而在于有没有人认真设计过角色矩阵。
这是亚马逊、Shopee、TikTok Shop、Temu 等平台的后台账号。它与 ERP 账号的区别是：你对它的控制力有限，规则由平台定。
这类账号的核心风险不是“被猜到密码”，而是操作环境和使用主体过于混乱，导致平台侧看到的行为特征不可解释。采购补货需要大量查询库存和订单，正是这类操作最密集的环节。
这是开放给外部合作方的账号，包括 ERP 协同账号、共享文档账号、独立站后台账号等。这类账号的特点是：你主动把访问权限交出去，但回收机制往往缺失。
这类账号是我见过最多“僵尸权限”的地方。合作停了、账号还在，权限没降、密码没改，是常态而不是意外。
这是付款环节涉及的账号，可能包括第三方收款工具、企业网银、平台钱包等。它和采购补货的连接点是付款动作。
这类账号的安全问题不在于被盗，而在于内部控制失效：谁发起、谁审批、谁执行，如果全由一个人完成，那所谓的内控就只是形式。
| 账号类型 | 归属方 | 开通由谁决定 | 回收由谁负责 | 失控后的主要后果 |
|---|---|---|---|---|
| ERP 系统账号 | 企业内部 | 业务负责人 / 系统管理员 | HR + 系统管理员 | 敏感采购数据外流、单据被篡改 |
| 平台卖家账号 | 企业内部（受平台约束） | 账号所有者 | 账号所有者 | 操作行为不可解释，影响账号健康度 |
| 供应商协同账号 | 外部合作方 | 采购负责人 | 几乎无人负责 | 长期僵尸权限、竞品可得内部数据 |
| 资金支付类账号 | 企业财务 | 财务负责人 | 财务负责人 | 付款无法追溯、内控形同虚设 |
这四类账号里，第三类的回收责任最模糊，第四类的追溯设计最薄弱。如果只能先解决一个问题，我建议先解决供应商协同账号的回收。
下面这八个认知，我在和卖家交流时几乎每次都会碰到至少三四个。它们不是明显的错误，而是“听起来对、用起来错”的中间态判断。
最常见的说法是“这个让技术去处理”。但技术能处理的只有配置层面的事，开二次验证、设密码策略、限制登录设备。
真正决定账号安全水位的是业务规则，而业务规则只有业务负责人能定。比如“采购员能不能看到供应商底价”这个问题，技术无法回答，只有业务负责人知道这个信息泄露的代价有多大。
这是市场上被宣传得最含糊的一个点。部分 ERP 产品确实提供了多店铺统一登录、操作环境管理相关的能力，但这类能力的效果边界取决于产品实现方式和使用方式，不是一句“能防关联”可以概括的。
我建议的判断方法是：不要问“能不能防”，要问“怎么实现的、边界在哪、什么情况下会失效”。如果一个产品说不出这三点的具体答案，那它提供的能力大概率和你的预期有落差。
强密码是必要条件，不是充分条件。一个 16 位大小写加符号的密码，如果被写在群公告里，安全性等于零。
在采购补货场景里，密码泄露的主要渠道不是撞库，是内部传递。所以与其花精力把密码从 12 位提到 16 位，不如花精力把密码传递这个动作从流程里彻底删掉。
开通协同账号确实提升效率，供应商自己填发货信息，比采购员代填快得多。但很多人只算了效率账，没算风险账。
一个供应商账号如果能看到你的全部采购单，他就知道你的采购节奏、采购量、以及对其他供应商的依赖程度。这些信息在谈判桌上的价值，可能远超你省下的那点人工。
“采购专员就给采购权限”，听起来合理，实际上太粗。同样是采购权限，里面至少包含三层：能不能看到全部供应商的报价、能不能修改已提交的采购单、能不能批量导出历史采购数据。
大部分权限事故不是出在“岗位错了”，而是出在“岗位内的颗粒度太粗”。一个只需要下单的采购员，不应该同时拥有导出三年采购数据的权限。
改密码只解决了一部分问题。你需要同时处理的至少包括：ERP 子账号是否停用、协同账号是否需要换绑、共享文档权限是否移除、是否存在用个人邮箱注册的第三方工具账号。
我见过最典型的疏漏是：员工离职三个月后，用当初自己手机号注册的某个供应商比价工具账号，还能直接登录看到公司的采购历史。因为那个账号从一开始就不在公司的账号清单上。
子账号是形式，隔离才是目的。如果所有子账号都用同一个 IP 段、共享同一套密码规则、权限又都指向同一批数据，那子账号只是多了一层登录界面。
判断隔离是否真实有效，我通常看一个动作：能不能把这个子账号的所有操作，从其他人里面单独拎出来看。拎不出来，就说明隔离没做到位。
这是最需要纠正的一个误区。粗糙的安全措施确实会拖慢效率，比如每做一次操作都要输入动态口令。
但设计良好的安全措施，很多时候反而提升效率。把权限按角色预设好，采购员登录后直接看到自己该看的界面，反而比登录主账号在几十个菜单里找入口更快。问题不在于要不要加约束，而在于约束加在哪里。
讲完误区，需要给一套能落地的判断方法。我给卖家做账号安全梳理时，习惯用三条线过一遍所有账号，基本能在半小时内定位出真正的薄弱环节。
第一条线是影响面判断。如果一个账号失控后，既不涉及资金流出、也不涉及货物调度、更不会影响店铺健康度，那它的安全管理优先级应该往后排。
按这条线过一遍，采购补货涉及的账号里，优先级最高的是三类：能发起或审批付款的账号、能看到或修改采购价的账号、能代表店铺对外操作（比如修改库存、回复买家消息）的账号。
第二条线是追溯能力判断。具体问三个问题：这个账号的操作日志能不能查到时间点、能不能确认到具体的人、能不能导出取证。
三个问题里有一个答不上来，这个账号就属于追溯断点。追溯断点不一定是高风险，但一定是高处理成本。出事之后你花在“搞清发生了什么”上的时间，往往比损失本身更贵。
第三条线是撤销能力判断。人员在今天离职、合作在今天终止，你能不能在当天把这个账号的所有入口全部切断？
如果答案是“需要挨个系统找、可能漏掉一两个”，那就说明你没有账号清单。没有账号清单的团队，账号安全一定是靠运气在维持。
把三条线交叉起来，可以得到一个简单的分级：三条线都踩中的账号是红色，两条踩中是黄色，一条是蓝色。红色账号必须做到专人专号、权限最小、操作留痕、撤销可即时。
大部分卖家的问题在于：所有账号都是同一套管理方式，没有分级。结果是该严的没严起来，不该管的管得太死，一线员工天天抱怨流程重。
前面讲的都是原则，原则要落地需要工具支撑。我在梳理过几套跨境 ERP 的权限体系后，实际使用体验相对完整的是数跨境（官网地址：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。下面我按实际用下来的感受，讲三个具体场景。
情形一：供应商账号从来没被回收过。一家做 Temu 和亚马逊双平台的卖家，两年里合作过十一家供应商，ERP 里有九个协同账号还处于可登录状态，其中四家已经停止合作超过半年。他们自己完全不知道，直到做账号清理才发现。
情形二：采购员权限过宽导致比价信息外流。采购员能看到所有供应商的历史报价，跳槽后把完整的价格对照表带走了。因为权限设计是“采购角色 = 采购模块全权限”，从系统角度看，这个操作完全合规。
情形三：审批和付款由同一人完成。规模不大的团队里很常见。财务和采购是同一个人，采购单提交后自己审批、自己付款。这套流程在没有异常时运行得很顺畅，一旦出现金额错误，追溯成本极高。
这三个情形有一个共同点：没有任何一个环节是“被黑客攻破”的，全部是权限设计层面的结构性缺口。
我在数跨境里配置采购相关角色时，注意到它的权限切分不是按“模块”一刀切的，而是可以细分到具体动作。这一点对采购补货场景很关键，因为采购这个岗位本身就横跨了好几个敏感动作。
具体来说，我会把采购相关角色切成四类：
这套切法的核心思路是：把“比价能力”单独拎出来作为一个权限项，而不是默认包含在采购权限里。这是很多团队容易忽略的一点，也是最容易出事的一点。
{
"role": "采购单创建角色",
"permissions": {
"purchase_order": ["create", "edit_own", "view_own"],
"supplier_quote": ["view_related_only"],
"supplier_comparison": [],
"purchase_price_history": ["view_own_orders"],
"data_export": ["disable"],
"inventory": ["view"],
"approval": []
},
"scope": "self_created_only",
"session": {
"force_logout_on_role_change": true
}
}
上面这段是权限配置的结构示意，重点不在具体字段名，而在于“supplier_comparison”这一项被显式设置为空。默认不授予，需要时再单独申请，比默认授予、出事后再收回要安全得多。
我把自己接触过的卖家样本按权限颗粒度粗分成三档，粗略统计了两年内出现账号相关异常的次数。需要说明的是，这是我个人的样本观察，不是行业统计，只能看趋势不能看绝对值。
第一档是“单账号共用”，也就是采购团队共用一个登录名。这档样本里，两年内出现至少一次数据异常或权限纠纷的比例是七成左右。
第二档是“按岗位分子账号，但不控导出”。这档样本里，出现异常的比例降到三成左右，但一旦出现，往往是批量数据外流这类后果较重的问题。
第三档是“按角色细分权限，且导出权限单独审批”。这档样本里，出现异常的比例降到一成左右，且异常类型多为操作失误而非数据外流。
这三档之间的差距，不在于用了哪个系统，而在于角色矩阵是不是被人认真设计过。同一款 ERP，配置方式不同，安全水位可以差出好几倍。
账号安全这件事没有通用方案，团队规模、店铺数量、人员流动率不同，优先级完全不一样。下面按四种常见情况分别给建议。
这个阶段最容易出现的想法是“人这么少，不用搞那么复杂”。我的判断恰恰相反：人少的时候，一个人的失误没有第二道防线兜底，容错率反而最低。
建议按这个顺序做三件事：给采购单独开 ERP 子账号，不要用主账号；把导出权限从采购角色里去掉，需要数据时走申请；供应商协同账号统一设有效期，到期自动失效。
这三件事加起来，配置时间大概两小时，但能覆盖这个规模下八成的风险场景。
这个规模开始出现分工问题：有人负责选品补货，有人负责议价，有人负责跟单。权限如果不跟着分工走，就会出现“所有人权限一样”的尴尬局面。
建议按前面提到的四类采购角色做切分，同时建立账号清单。账号清单是这个阶段最重要的管理资产，一页表格，记录账号名、归属人、开通时间、权限范围、回收状态。
另外建议加一条规则：任何权限变更必须由账号所有者之外的第二人确认。这一条能挡掉大部分“为了方便随手开权限”的情况。
到这个规模，问题从“权限怎么分”升级为“主体之间怎么隔离”。不同店铺可能挂在不同的公司主体下，采购可能共用同一批供应商。
建议做两件事：一是按主体划分数据边界，采购人员只在自己负责的主体范围内有权限；二是把供应商协同账号的审批权收到一个统一出口，不允许各主体自行开通。
多主体场景下的最大风险不是外部入侵，是内部信息串味。A 主体的采购能看到 B 主体的采购价，本身就是一种管理失控。
已经出过事的团队，最该做的不是加更多限制，而是先把追溯链条补上。具体动作是：查清历史操作日志能追到什么程度、找出所有无法定位到人的账号、把这些账号列入第一批改造名单。
同时建议做一次完整的账号盘点，把“谁在用、用来做什么、什么时候停用”三个问题过一遍。没有盘点的加固，都是局部补丁，下一次换个地方还会出问题。
前面讲了怎么做，这一节讲做的时候要放弃什么。任何安全措施都有成本，不承认成本的存在，方案就落不了地。
子账号越细，追溯越清楚，但管理成本越高。一个 5 人团队开 20 个子账号，光是维护密码和权限就是负担。
我的取舍标准是：只对“能碰到钱、能改价、能导出”的三类动作做账号级隔离，其余动作可以用角色共用但保留操作日志。这样既能控制住关键风险，又不会让管理复杂到没人愿意执行。
补货窗口期很短，审批每多一环，可能就多耽误半天。这个取舍没有标准答案，取决于你的补货节奏。
我的建议是设置金额阈值：低于阈值走快速通道，高于阈值走完整审批。比如单笔采购低于两千元的直接执行，高于两千元的走两段审批。这样既保住时效，又管住了大额风险。
让供应商深度参与协同（自己看库存、自己排产、自己填发货）能大幅提升效率，但暴露的数据也更多。
我的判断是：只开放与该供应商自身订单相关的数据，不开放全局库存水位和全局采购计划。前者是效率所必需，后者对效率帮助有限但暴露的商业信息价值很高。
自建的好处是完全可控，坏处是维护成本高、迭代慢。SaaS 的好处是权限模型现成、迭代快，坏处是配置深度取决于产品设计。
对绝大多数中小卖家而言，SaaS 是更现实的选择。关键不在于自建还是 SaaS，而在于你选的工具能不能支持细分到动作级别的权限配置。如果只能按模块授权，那无论自建还是 SaaS，都会遇到权限过粗的问题。
下面这份清单是我给卖家做梳理时实际在用的版本，按处理紧急程度分三档。建议直接照着过一遍，能勾上的先勾上，勾不上的记下来排期。
这份清单看起来简单，但我实际陪跑下来的经验是：能完整勾完第一档的团队，不超过三成。而这三成团队，在后续两年的账号相关异常发生率，明显低于其他样本。
去年那家卖家的最终处理方式，是停用了所有供应商协同账号，改为供应商通过邮件提报发货信息，然后由采购统一录入。效率确实降了一些，但他们觉得值得，因为在没有能力审计“那个账号在做什么”之前，把入口关掉是唯一可靠的选择。
这件事让我更确信一个判断：采购补货中的账号安全，核心不是“防住外部”，而是“说清楚内部”。说清楚谁在什么时间、用什么身份、做了什么事、做完之后能不能收回。四件事说清楚了，安全水位自然就上来了。
所以我不建议你从“上一个安全工具”开始。更实际的起点是：打开你的 ERP，把所有涉及采购补货的账号列一遍，逐个回答三个问题，这个账号能看到什么、这个账号做的事能不能追到人、这个人不干了账号能不能当天关掉。
三个问题里但凡有一个答不上来，那个账号就是你这一周要处理的第一个目标。做完整份自查清单的第一档，大概需要两到三个小时，但它解决的是后面所有动作能否成立的前提。
下一步动作很明确：今天先把账号清单建起来，一张表格就够了。清单建不起来，谈权限设计、谈协同治理、谈工具选型，都会变成没有地基的装修。
我们团队几个采购共用两台电脑，补货季基本是早上开A店后台看库存、中午开B店、下午开C店，我一直觉得“只是看看库存又不下单，应该没事”。直到上个月有个店收到平台的关联核查通知，我才开始慌，到底是我操作的问题，还是本来就撞枪口上了？
先给结论：会不会被判关联，取决于平台规则和你是否留下了可被交叉比对的痕迹，没人能给你“一定没事”的承诺，但可以把风险压到可控。可执行的做法有四条。第一，按“人，店，环境”做固定绑定，谁负责哪几个店，就固定用哪套设备和网络，不要今天这台明天那台。
第二，浏览器层面做隔离，不同店铺的主账号不要在同一浏览器里反复登录，Cookie、本地缓存、指纹混在一起是最典型的交叉点。第三，采购查库存这类只读需求，优先通过ERP的订单与库存同步数据来看，能不进后台就不进后台。第四，确实必须登后台的操作，集中到固定的一个人、固定的时段完成，不要全员随时登。
判断依据：各家平台对关联的判定维度是动态调整的，一切以平台官方最新规则和卖家后台通知为准；凡是“这样操作100%不会被关联”的说法，包括部分ERP厂商的宣传口径，都不要当成事实，正确做法是把隔离做成习惯，而不是赌概率。
我们采购要看的供应商名单、采购价、补货建议参数，其实都是最敏感的东西。之前图省事，采购主管的账号基本等于管理员，什么都能看什么都能导。后来有个采购离职去了同行，我才反应过来那套价格表可能早就被带走了。现在想收权限，又怕影响日常补货效率，老板天天催我别卡流程。
核心原则是把权限拆成三层而不是两级：可见、可改、可导出，绝大多数人只需要第一层。具体做法：采购专员默认只给“可见”，能看到自己负责品类的供应商名称、采购价、库存周转和补货建议；“可改”单独开，只给采购主管及以上，用来调整补货参数、修改采购单；
“可导出”是最危险的一层，默认全部关闭，需要时走单次申请、限定品类和时间范围，并留下操作日志。判断依据：泄露造成的损失排序是导出大于修改、修改大于查看，所以收权限要优先收导出，而不是先收查看，先收查看会立刻卡住效率，先收导出几乎不影响日常补货节奏。
落地时可以联合采购主管和HR确认一份敏感字段清单，把供应商名称、联系人、账期、采购价、补货模型参数、历史成交价都列进去，凡是清单里的字段，导出必须留痕。还有一点很关键：ERP的权限体系要支持按品类、按供应商维度切分，如果只能做到“全部可见或全部不可见”，说明颗粒度不够，采购规模越大这个问题越突出。
具体能力边界请以你实际使用的系统版本为准，别只看销售演示时的效果。
我们为了省事，给两家代发供应商开了ERP子账号，让他们自己看订单和库存好安排发货。结果上个月有一家合作终止了，我才想起来那个账号好像没停。说实话我根本不知道他这段时间看到了什么，而且密码还是当初微信直接发给他的。现在想梳理一遍，又怕一停账号影响还在合作的那家。
先做一次全量盘点，把所有对外开出去的账号列成一张表，字段至少包括账号名、对应供应商、开通时间、开通人、权限范围、最后一次登录时间、当前合作状态。这张表第一次做基本都会吓一跳，因为总能翻出几个僵尸账号。
然后按三种状态分别处理：还在合作的，把权限降到最小必要，能看订单状态和待发货量就够了，不要给采购价、成本价、其他供应商信息，同时把登录方式改成一人一号、禁止共享密码，密码由对方自己保管，你只知道账号名；
已终止合作的，立即停用而不是删除，删除会丢掉日志，停用可以保留追溯痕迹，同时在合同或补充协议里写明合作终止后多少个工作日内账号自动失效；长期不用的，设一个到期日，比如90天未登录自动锁定，避免开通时记得、回收时忘掉。
判断依据：外部账号的风险不在开通那一刻，而在合作结束之后的那段时间，所以真正的管理动作不是审批开通，而是定期复核加到期回收，建议每季度做一次，采购负责人交接时强制再做一次。制度上写清“谁开通谁负责回收”，比写十遍“账号安全很重要”有用得多。
我们团队就五个人，老板管钱，采购主管提需求，我负责执行。真按书里说的三方分离，根本没人可分。但我也确实担心，万一采购和付款是同一个人操作，出了错或者有人动了手脚，连查都查不清。有没有适合小团队的折中办法？
不分离不等于不能审，小团队的折中思路是把“人分离”换成“证据链分离”。可执行做法有四条。第一，同一个人可以发起采购单，但付款环节必须由另一个人确认，哪怕是老板本人，也不能在同一个账号里一路走完。第二，付款账号（网银、支付账号）的持有人不与采购单发起人重合，这条最关键，人手再少也要守住。
第三，把所有关键动作变成系统留痕，谁改的采购价、谁调的补货量、谁发起的付款、谁审批的，这四条记录要能在同一张单据上串起来。第四，设金额阈值，比如单笔超过某个金额或涉及新供应商时，强制第二人复核，阈值以下走快速流程保效率。
判断依据：资金边界的目的不是防止所有人犯错，而是出问题时能定位到人和动作，并且让一个人无法独立完成从发起到付款的闭环。如果实在做不到双人复核，退一步的最低要求是付款账号由不参与采购执行的人持有，并让每一笔付款的短信或邮件通知独立触达第二个人，异常能被看见。
阈值定多少，建议按你月均补货金额和团队规模先跑一个季度，再根据实际报警量调整。
读者评论
文章把协同账号回收单拎出来讲很到位。我们公司也给供应商开过 ERP 对账账号，合作结束后没人记得停，后来还是财务发现登录记录异常才处理。供应商底价、账期这些数据一旦外流，比丢一个店铺账号麻烦得多，建议至少每季度做一次外部账号盘点。
从系统管理员角度看，权限矩阵确实不能只靠 IT 拍脑袋。采购能不能看底价、能不能导出，必须业务负责人定。但文章说的多一步验证会被绕开也是现实，我们推二次验证时一线就抱怨影响比价效率，最后只能按角色分级，高敏感操作才强制验证。
一线采购的视角：旺季补货时一天切十几个系统，密码规则再复杂，最后大概率变成群里发密码或借同事账号。不是不守规矩，是流程没考虑操作节奏。文章说账号身份和真实操作人脱钩后审计失效，这个点很扎心，我们后来把 ERP 子账号和个人绑定才好转。