大家好，我是孟健。
我的美国商业账户此前遇到了风控。虽然一直有美国客户付费，但我来回提交了几轮材料才最终通过。这里把我们摸索出的材料核查细节，以及只能提交单份PDF时的沟通方法整理出来，供遇到类似情况的朋友参考。
我们使用的 Mercury（常被称为水星银行，本质是一家金融科技公司，底层银行服务由其合作银行提供）在账户开立并运行一段时间后，发来了要求验证美国实质业务运营（U.S. business operations）的通知。
公司的注册证书确认法人实体，工作地址验证有其自身规则，而这次业务证明审查，关注的是公司当前在美国境内是否有真实的商业往来，三者并不相同。
面对补件，我让我的主 AI 助手小墨协助我，把所有历史请求、原始收据、订单与对账流水重新逐项对齐。以下是我们处理这几轮提交的真实记录。
01 先对照官方给的可选路径
收到通知后，切忌慌乱地把手头所有涉美文件无序打包上传。Mercury 官方对证明美国实质业务有着明确的公开规则。
官方列出的是可供选择的证明路径，并非要求凑齐所有类别。比如雇员或租用当地办公室，只是其中一部分选项。
官方规则明确列出了一条可行路径：提供来自美国客户的销售记录、发票、合同，或者与美国本地供应商、合作伙伴的业务往来凭证，并且这些记录需要与银行账户中的真实交易流水形成对应。
提供真实客户记录是可选路径之一，但提交后材料是否充分、字段能否核验比对，仍取决于个案审核，并不意味着只要递交交易凭据就一定符合要求。
02 复盘前两轮漏掉了什么
我们在9月6日提交的第一版8页材料里，就已经包含了美国客户的付款明细、Stripe的结算记录，以及对应到Mercury账户的实际到账明细与ACH trace追踪号，流水并不是最后才补上的。
在那版材料中，我们选取了两笔客户付款：一笔是德克萨斯州客户的8.65美元，另一笔是纽约州客户的7.99美元。其中德州这笔款项，与其他销售一同计入Stripe一笔16.80美元的结算并打入账户。该结算批次内还包含非美国订单与平台费用，因此两笔金额相加并不等于该批结算总额。
9 月 11 日，后台发来了第二条通知，告知之前的材料未被接受。与第一条通知相比，第二条明确否定了旧材料，并补充列出员工、办公场所、投资人等可选类别。我们当天组织了第二版 10 页补强包：前面加了 1 页情况说明，补上了 Stripe 原生的收据预览界面，并保留了原有的 8 页底稿。
但这次补件依然没有通过。紧接着在 9 月 12 日，后台生成了第三条请求，要求在 9 月 21 日前完成补充。需要特别注意：第三次请求的通知邮件正文与第二次完全一致。如果只扫一眼邮件内容，很容易误以为是系统发出的重复提醒。实际上在后台系统中，那是一个全新生成的独立 Request，必须认真对待。
03 讲清公司和产品的归属
官方通知简短，并未说明具体缺少哪个字段。我们无法断言之前的具体问题，只能由自己逐项核对材料。
首先是公司实体与对外产品的归属关系。我的美国实体名为 Nextfield Labs LLC，面向海外的产品名为 Kirkify。对于外部审核人员来说，看到一笔付给 Kirkify 的款项，如果不给解释，对方很难直接确认它与 Nextfield Labs LLC 的关系。
在最终整理的材料中，我们附上了提交当时公司官网展示运营Kirkify的页面，以呈现主体与品牌关系；同时提供Dynadot后台管理记录作为辅助控制证明，这并非名下法定产权文件。
我们曾考虑将Cloudflare发票作为供应商证据，但在比对单据时，发现买方写的是个人名字与非美地址，公司买方、卖方法律主体以及对应的银行付款均未核清，因此这次没有选用。
最后是调整呈现细节。我们去掉了之前包含多国订单的汇总表格，仅保留那两笔清晰真实的美国客户订单。对于客户隐私，我们继续遮挡敏感的个人邮箱，但在提交给银行的正式材料中，完整恢复了账单所属的州与具体地址，方便审核方校验地理位置。
04 把四个疑问直接写在首页
当时我能使用的入口只接收一份合并的PDF文件，界面里没法单独打字发问。为了讲清情况，我直接在文件首页写了补充说明，并列出四个具体问题请对方核对，再附上后面的凭证。
下图为提交PDF首页节选，已去除私密编号；四问是我们主动请审核方指出缺口。
第一，公司与产品关系：若要证明 Nextfield Labs LLC、Kirkify 与商户付款记录之间的归属，目前还缺少哪些具体支持文件。
第二，客户地点与遮盖字段：除了我们提供的信息外，还有哪些客户地理位置信息，或是目前被遮盖的字段需要进一步补充。
第三，记录类型与签发主体：如果现有的销售管理后台截图与 Stripe 收据预览不够充分，具体期待哪种类型的替代文件、由谁签发、包含哪些关键字段。
第四，银行关联对应：在客户付款、Stripe 结算到 Mercury 银行账户入账的整个链条中，哪一段关联关系尚未得到证实，还缺什么匹配信息。
问题后附带了对应的原始凭据，整份文件共9页，使提出的每个问题都能在后文找到核对依据。
后台状态变为已处理（Resolved）， 仅代表本次提交完成，不等于通过。 虽然我们最终通过了审核，但无法确认是哪一处修改起到了决定作用。
05 应对出海账户合规检查的自检清单
提交版本从8页、10页再减到9页，我们意识到不要把页数多当成材料充分。银行没有逐条指出问题，全靠我们自主核对。每一页只留能相互印证的真实依据，拿掉多余信息，比盲目堆砌材料管用。
如果你也经营着独立出海业务，或者正面临类似的账户合规调取，可以按照以下步骤自查材料：
- 确认当前请求与截止日：登录后台查看具体通知，核对本次要求的具体范围与时限。
- 选择适合的真实证据：根据自身业务实际，从官方列出的路径中选取能够提供真实凭据的类别。
- 核对主体与付款链路：逐项核对公司、客户、付款明细与银行结算之间的关联记录。
- 整理材料与索引问题：在单份PDF中附上原始材料，并在首页列明索引或请对方指出具体缺口的问题。
- 等待官方最终结论：提交完成后状态更新仅代表受理，需等待后续通知以最终审核结果为准。
具体要求可参考 Mercury 官方指南。平时把往来交易的原始凭证存好，补件时反复核实各处信息能否对上，能对齐再交，比仓促提交更有准头。
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏
