公司信息生成器要造的不是一家虚构公司的名字，而是一组彼此对得上的企业字段：公司名带着与辖区匹配的后缀、法律形式与后缀一致、注册号与税号符合该国的格式、地址与电话落在同一个国家。这类一致性在企业开户与供应商入驻流程里会被逐条检查，数据一旦互相矛盾，测试就会在无法归因的地方失败。这篇讲清企业字段之间的依赖关系、各国标识符的差别，以及 KYB 流程测试需要覆盖什么。
公司名后缀为什么随辖区变化
公司名末尾的那几个字母或缩写不是装饰，而是法律形式的声明。德国的 GmbH 与 AG、法国的 S.A. 与 SARL、马来西亚的 Sdn. Bhd.、澳大利亚的 Pty Ltd、美国的 LLC 与 Inc.、土耳其的 A.Ş. 与 Ltd. Şti.，每一种都对应一套责任形式、治理结构与申报义务。
这意味着后缀与辖区的组合不是随便配的。一家写着 GmbH 的主体注册地应当落在德语区，写着 Sdn. Bhd. 的主体应当落在马来西亚。表单如果让用户自由填写后缀，就一定会收到不可能的搭配；更稳的做法是把法律形式做成与辖区联动的选项，由系统拼出完整名称。
后缀还有书写规范的问题。有的写法带点，有的不带点，有的是全大写缩写，有的已经成为一个整体词。做名称比对时把这些变体归一化，比要求用户猜哪一种写法是官方形式要实际得多。各国的后缀与法律形式的对应关系见各国公司名后缀与各司法辖区的法律形式。
注册号与税号是一回事吗?
不是。注册号是企业在公司登记机关的身份编号，用于在国内识别这个主体，格式由登记机关规定。税号是企业与税务机关之间的标识，用于申报与开票，格式由税务规则规定。两者可能长得像，但来源、用途与校验规则都不同，数据库中应当分成两个字段。
最常见的错误是把它们当成同一个值填两遍。这样做的直接后果是当系统需要单独校验其中一项时会失败，而且失败原因很难看出来，因为两个字段看起来都没问题。第二个错误是把增值税号当成税号。增值税号是在税号基础上加了国家前缀的跨境标识，有自己的校验规则，把它和国内税号混用会在跨境场景里露馅。
第三个错误是忽略格式里的大小写与长度。有的国家的税号带字母，有的带固定长度的数字，有的允许校验位。测试样本里应当包含每种形态各一条，否则你的校验逻辑只见过一种样子。常见税号的形态可以参考各国增值税号格式与税号校验规则，注册号的形态见各国公司注册号。
LEI 与 D-U-N-S 用在什么场合
LEI 是全球法人机构识别码，长度固定、由二十位字母与数字组成，末两位是校验位。它面向跨境金融交易场景，用于唯一识别参与交易的法人。D-U-N-S 是商业数据服务商维护的企业识别码，常见于供应商准入、信贷评估与企业信用场景。
两者都不是营业执照号码，也不能互相替代。对做测试的人来说，它们的价值在于提供了「可以校验的结构」：LEI 的校验位可以本地验证，因此适合作为断言对象。相对地，注册号与税号的规则更依赖国家，需要按辖区分别处理。
如果你的流程里会出现这两个标识，样本集应当同时包含校验位正确与错误的两类，用来验证实现是否真的在校验，而不是看到一串字符就放行。相关区别可以读企业标识符与国际编码。
企业流程测试需要哪些字段自洽
第一层是辖区。国家决定公司名的语言与后缀、注册号的格式、税号的格式、地址的层级与货币。第二层是主体信息，包括法定名称、法律形式、成立日期与登记机关。第三层是联系与经营信息，包括注册地址、实际经营地址、联系电话与网站域名。
跨层的约束有几条最容易被破坏：地址所在国与注册号所属国必须一致；电话的国家码必须与地址国家一致；法律形式必须与公司名后缀一致；成立日期不能晚于开户申请日期。把这些写成断言之后，你会发现大部分看起来「奇怪的失败」其实都源于样本里某两条记录被拼在了一起。
做 KYB 测试时还要覆盖受益人信息这一层，也就是企业背后的实际控制人。这一层的字段通常包括姓名、出生日期、国籍、持股比例与证件号，其中的证件号规则又回到身份数据那一套。企业字段与受益人的关系见KYB 测试清单，字段设计思路见测试公司数据说明。
B2B 表单该测哪些用例
先测名称与法律形式的联动：选了某个辖区，后缀选项里是否还混着另一个语区的形式。再测注册号与税号的校验：格式错误的输入是否被拒，而错误提示是否指出是哪一个字段。然后测地址与电话的跨国一致性。
接着测多语言与字符集：公司名里带变音符号或者非拉丁文字时，编码、长度截断与搜索是否正常。然后测重复检测：同一家公司被录入两次时系统是否提示，以及不同辖区的同名公司是否会被误判为重复。最后测状态流转：草稿、待审核、通过、拒绝这几种状态之间的跳转是否有对应的权限与通知。
被忽略最多的是删除与更正路径。企业信息录错之后能不能修改，修改后是否需要重新审核，这些分支在测试里常常没有样本，却在真实使用中频繁发生。完整的用例结构见结算与开票表单测试用例。
公司名重复和同名要怎么处理
同名是 B2B 数据里必然会遇到的情况。不同辖区的两家公司可以叫完全一样的名字，同一辖区内的近似名称也可能同时存在。系统如果只用名称做唯一性判断，就会把合法的新公司判成重复；反过来，如果只按名称相似度给提示而不做硬拦截，重复录入又会悄无声息地积累。
更稳的做法是分层：名称相似度只作为提示，真正的主键是辖区加注册号这一组合。测试时应当准备三类样本——不同辖区的同名公司、同一辖区的近似名称、以及注册号相同但名称写法不同的记录，观察系统分别怎么反应。这三类样本能覆盖大多数重复判定的分支，比凭空猜边界情况有效。
还要留意历史名称。企业改名之后，旧名称可能仍出现在合同、发票与历史记录里，一个只匹配当前名称的系统会把这些记录当成另一家公司。样本里放一条曾用名与现用名并列的记录，能提前暴露这类问题。
注册地和经营地不一致时怎么处理?
现实里非常常见。一家公司在一个辖区完成注册，实际办公与发货在另一个辖区，账单地址可能又在第三个。把这三个位置压成一个字段，看起来简化了模型，实际会让开票、税务计算与风控判断同时失去依据。
正确的做法是把它们分开存储并各自带辖区标记。注册地决定适用哪一套公司法与注册号格式，经营地影响税率与服务可用性，账单地址用于发票与对账。三者在多数情况下相同，但代码不应当依赖这个巧合。
测试样本里应当包含三种组合：三者一致的常规情形、注册地与经营地分属不同辖区的情形、以及注册地在境外而经营地在境内的情形。第三种最容易触发分支，因为税号与注册号此时来自不同的体系，任何试图用一套格式校验全部标识符的实现都会在这里出错。
还有一个常见的坑是把注册号当成全局唯一键。不同辖区的注册号可能重名，跨辖区合并数据时必须以辖区加注册号作为联合键，否则两条不同公司的记录会互相覆盖。
企业数据也有有效期吗?
有，而且比一般主数据更容易过期。公司会变更名称、更换注册地址、改变法律形式、被收购或者注销，相邻两次变更之间可能只隔几个月。一份看起来完整的公司数据，如果采集时间是一年前，它在今天的可用性是无法假定的。
维护时至少要记录三个时间：数据采集时间、该条数据在源头最后一次变动的时间、以及你下一次计划复核的时间。只看采集时间会漏掉一类情况，即数据采集时已经过期，因为源头在你采集之前就已经变更过了。
状态字段也要带上。存续、停业、清算、注销这几种状态在法律后果上差别很大，把它们统一成「有效」与「无效」两个值，会让依赖状态分支的业务逻辑失去测试对象。样本里应当包含每一种状态各一条，尤其是清算与注销这两种在流程里出现频率低但分支特殊的。
最后是复核节奏。变更频率高的字段复核要勤，例如名称与地址；变更频率低的字段可以放宽，例如注册日期。按字段而不是按整条记录设定复核周期，能把维护成本压到实际需要的水平，相关思路见国别数据的时效与来源。
怎么判断一份企业数据是合成的?
合成数据有一套可观察的特征。第一，标识符的校验位正确，但在真实登记机关的公开库里查不到对应主体，或者查询返回的结果与记录本身的名称完全不相关。第二，地址、电话与代表人信息都指向不可能真实成立的位置与号码组合。
第三，数据内部高度自洽却缺少历史的痕迹：没有年报日期、没有变更记录、没有历史名称，这些在真实企业数据里几乎必然存在。第四，注册时间与公司业务描述之间没有可核对的对应关系，例如一家声称有多年历史的公司，成立日期却是最近的。
对测试而言，这些特征不是缺陷，而是设计目标：合成记录只保证结构与规则正确，不承诺对应任何在册主体。把这一点写进测试说明，能避免后来接手的人误以为可以直接拿来做真实业务。
给开发者的字段模型建议
把辖区放在最外层，其余字段的类型、长度与校验规则都由它派生。标识符一律按字符串存，允许字母与前导零，并保留原始输入与归一化结果两列。法律形式用受控词表而不是自由文本，公司名的后缀由法律形式派生而不是让用户手写。
成立日期存日期而不是带时区的时刻，避免算年龄或者算年限时抖出一天误差。校验函数按标识符类型拆分，返回的原因是「长度不对」「字符集不对」「校验位不对」还是「与该辖区不匹配」，四种原因分别对应不同的排查方向。
样本集按辖区组织，每个辖区至少一条完整记录与一条负样本，负样本覆盖格式错误、校验位错误与辖区不匹配三类。要一批字段互相自洽的企业记录，打开公司信息生成器，选好辖区与数量即可批量导出。这些记录都是合成出来的测试数据，格式与校验位照着真实规则写，但不对应任何在册的真实主体，只能用于开发、测试与预发布环境，不能用于开户、签约或者冒充他人企业。