In one sentence: Throw in the business registration data of the audited entity + customers + suppliers, and automatically uncover related-party relationships that "should have been disclosed but were not."
Why do this
In recent years, the CSRC/Ministry of Finance have penalized a large number of accounting firms, and the same types of faults repeatedly appear in the penalty decisions:
"The audit working papers already containedadjacent phone number ranges, similar addressesand other obvious anomalies, but no attention was paid" (Lanshan Technology case) "The counterparty'semail domainwas the same as the company's,was both a customer and a supplier、offices in the same building and same suite...no further procedures were implemented" (Tianwo Technology case) "The relevant customer's thensupervisor and legal representative were employees of the company...was not identified as a related party" (Zhuolang Technology case)
These anomaliescan all be automatically determined using business registration data. This skill is precisely to solidify these "minimum verification actions recognized by regulators" into a rules engine, so auditors will no longer miss them. For the alignment between the rule set and penalty cases, see references/cases.md。
Core concepts
Two-tier output (avoid false positives while still capturing substance)
Related-party determination is essentially "substance over form." The tool does not draw conclusions for the auditor, but presents evidence in two tiers:
| Tier | Meaning | Typical hits | Report presentation |
|---|---|---|---|
| 🔴 Hard related party (high) | Business registration data directly proves the relationship; strong evidence recognized by regulators | Same phone/same email/same address/same legal representative/equity penetration hit/customer table already marked as related party | Must be investigated thoroughly |
| 🟡 Suspicious red flag (medium/low) | Abnormal characteristics suggest a relationship; further procedures are needed | Large transactions shortly after establishment, 0 insured persons, scale mismatch, same-named personnel, both customer and supplier, historical related-party traces | Recommend attention |
Eight major verification dimensions
P0（监管反复处罚 + 工商数据现成，必做）：
1️⃣ 工商指纹重合 地址/电话/邮箱/网址/经纬度完全或高度相近
2️⃣ 关键人员重合 法定代表人/董监高/核心团队/最终受益人姓名跨公司撞名
3️⃣ 客商异常画像 成立即大客户、注册资本VS交易额不匹配、0参保、居民楼地址、经营范围不符
4️⃣ 已知关联方差集 客户/供应商表自带的"关联方名称"字段，与企业自报清单做差集
P1（监管点名，需穿透）：
5️⃣ 股权/控制穿透 多层股权、代持、实控人/最终受益人一致（默认穿透5层）
6️⃣ 历史关联痕迹 曾用名、曾任法人/股东、变更记录中的关联痕迹、非关联化
P2（实务有效，部分需配合银行/函证数据）：
7️⃣ 担保/资金链 互保、股权质押给对方、动产抵押关系
8️⃣ 无形资产/资源共用 商标/著作权/专利/微信公众号共有人、招聘办公地点重合
For each dimension's [identification principle + specific rules + red flag signals + regulatory source], see references/rules.md。
Workflow (four steps)
Step 1: Data retrieval (first discover subsidiaries through equity penetration, then batch download)
⚠️ Equity penetration must be done first: Fraud often occurs at the subsidiary level (e.g., in the Zhuolang Technology case, the fraudulent customers and suppliers were under the subsidiary "Zhuolang Development," and looking only at the parent company would not reveal the relationship). Only by first including the audited entity's subsidiaries in the verification scope can they be accurately identified.
1a. Equity penetration to discover subsidiaries (default 5 levels, shareholding >=20%)
SCOPE=~/.claude/skills/related-party-identification/scripts/discover_scope.py
python3 $SCOPE --target "被审计单位全称" --depth 5 --threshold 20 -o 核查名单.txt
# 输出 核查名单.txt：被审计单位 + 所有子公司/参控股企业（按股权链5层递归穿透）
1b. Merge list: Merge 核查名单.txt(subsidiaries discovered through penetration) + the customers/suppliers provided by the auditor, deduplicate, and put them into the same file.
1c. Batch download business registration data
SCRIPT=~/.claude/skills/cicpa-company-query/scripts/cicpa_query.py
python3 $SCRIPT -n $(cat 核查名单.txt | tr '\n' ' ') --browser-export
# 输出 ZIP，解压后得到 完整维度导出_files/ 目录（含52个xlsx）
For threshold use 20% (significant influence line) rather than 50% — regulators determine related parties based on "substance over form," and a shareholding of 20% or more in a company may also constitute a related party, so it must not be omitted. Company names must use the full name as registered with the business authorities.
The number of subsidiaries may be large (a group may have dozens to hundreds), and if it exceeds the download limit, prioritize keeping: ① those directly controlled by the target ② those with a high shareholding percentage ③ those with suspected business registration overlap with customers/suppliers.
Step 2: Verification (invoke this skill's engine)
ENGINE=~/.claude/skills/related-party-identification/scripts/related_party_check.py
python3 $ENGINE \
--data-dir "完整维度导出_files/" \
--target "被审计单位全称" \
-o "关联方核查报告.xlsx"
--data-dir: the fully exported and extracted cicpa_filesdirectory--target: the full name of the audited entity (used to focus the report and mark the main audit target)--depth: equity penetration depth, default 5--counterparties-file: optional, specify which are customers and which are suppliers (otherwise the engine treats everything other than the target as a counterparty)
The engine will read all companies in data-dir and perform afull-graph comparison(not only target vs each counterparty, but also cross-checks among counterparties — which can uncover "hidden groups"), run eight layers of rules, and output Excel.
Step 3: Interpret the report
The report is a multi-sheet Excel; see "Output Format" below for its structure. Focus on:
- Summary sheet: the determination of whether it is a related party + hit dimensions + risk level
- Evidence sheets for each dimension: the specific field values for each hit (address, original phone number, etc.)
Step 4: Auditor follow-up
The tool is only responsible for "identifying suspicions," not for drawing conclusions on behalf of the auditor. For each 🔴 hard link, the auditor should:
- Perform further procedures (confirmations, on-site visits, bank transaction verification)
- Inquire of management and require disclosure
- Assess the impact on the audit opinion
Output Format (multi-sheet Excel)
关联方核查报告.xlsx
├── 📋 汇总判断 ← 主表，每对公司一行：是否关联方/命中维度/风险等级/建议程序
├── 🔴 01_工商指纹重合 ← 同地址/同电话/同邮箱/同网址的具体记录
├── 🔴 02_关键人员重合 ← 法人/董监高/最终受益人撞名记录
├── 🟡 03_客商异常画像 ← 每个客户/供应商的异常特征清单（成立时间/规模/参保/经营范围）
├── 🔴 04_已知关联方差集 ← 客户/供应商表已标注关联方 vs 企业自报清单的差集
├── 🟡 05_股权控制穿透 ← 股权穿透路径、实控人/最终受益人重合
├── 🟡 06_历史关联痕迹 ← 曾用名、曾任法人/股东、变更记录痕迹
├── 🟡 07_担保资金链 ← 互保、股权质押、动产抵押关系
├── 🟡 08_无形资产共用 ← 商标/著作权/专利/公众号共有人
└── 📊 输入数据概览 ← 本次核查的公司清单 + 数据完整性
Column structure of the summary judgment sheet:
| Company A | Company B | Relationship Type | Is Related Party | Risk Level | Hit Dimensions | Key Evidence | Recommended Audit Procedures | Regulatory Source |
|---|---|---|---|---|---|---|---|---|
| XX Company | YY Company | Customer | 🔴Yes | high | Business registration fingerprint|Personnel overlap | Same phone 138xxxx | Same legal representative Zhang San | Confirmation + on-site visit | Zhuolang Technology case |
| XX Company | ZZ Company | Supplier | 🟡Suspicious | medium | Customer/supplier profile | Large amount just 6 months after establishment|0 insured employees | Bank transaction verification | Private network communication case |
Collaboration with cicpa-company-query
This skill does not directly call the business registration API, but instead consumes the _files directory exported by cicpa-company-query:
| This skill requires | Files provided by cicpa | Purpose |
|---|---|---|
| Address/phone/email/website/legal representative/establishment date/insured employees/former names/business scope | 基础工商信息.xlsx |
Fingerprint overlap + customer/supplier profile (one-stop) |
| Shareholders, capital contribution ratios | 股东信息.xlsx / 最新公示股东.xlsx |
Equity penetration |
| Actual controller, ultimate beneficial owner | 实际控制人.xlsx / 最终受益人.xlsx |
Overlap in control relationships |
| Directors, supervisors, senior management, core team | 核心团队.xlsx / 主要人员（高管）.xlsx |
Overlapping personnel |
| Customers/suppliers + self-declared related-party annotations | 客户.xlsx / 供应商.xlsx |
Customer/supplier profile + known related-party set difference |
| Outbound investment, equity participation/holding, branches | 对外投资（新）.xlsx / 参控股企业.xlsx / 分支机构.xlsx |
Investment relationship network |
| Guarantees, pledges, mortgages | 股权质押.xlsx / 动产抵押.xlsx / 对外担保.xlsx |
Guarantee chain |
| Trademarks, copyrights, patents, official accounts | 商标.xlsx / 软件著作权.xlsx / 专利信息.xlsx / 微信公众号.xlsx |
Shared intangible assets |
| Change history | 变更记录.xlsx / 法定代表人变更.xlsx |
Historical related-party traces |
| Supplementary address/phone/tax number | 发票信息.xlsx |
Cross-validation fingerprint |
Full field mapping see references/dimensions.md。
Eight-layer rules quick overview (see references/rules.md for details)
Dimension 1: Business registration fingerprint overlap (strongest signal)
- Registered address exactly the same / highly similar (compared after removing province/city/postal code)
- Same contact phone (remove prefix for mobile, remove area code for landline)
- Same email or same domain (the part after @)
- Same official website URL or same domain
- Regulatory source: Bluestone Technology, Tianwo Technology, Zhuolang Technology, Aikang Technology cases
Dimension 2: Key personnel overlap
- Same legal representative name (natural person, excluding false positives from "high-frequency same-name surnames")
- Directors/supervisors/senior management/core team names overlap across companies
- Same ultimate beneficiary/actual controller name
- Regulatory source: Zhuolang Technology (the counterparty's supervisor is an employee of this company), Aikang Technology (same person as legal representative)
Dimension 3: Abnormal customer/supplier profile
- Customer/supplier established too recently before a large transaction occurred (<12 months)
- Registered capital far smaller than disclosed transaction amount (e.g., registered capital 100,000, annual transactions 10,000,000)
- Number of insured persons is 0 or <5 (shell company characteristic)
- Registered address is a residential building/centralized registration address
- Business scope does not match the transaction category
- Both customer and supplier (two-way transactions)
- Regulatory source: Aikang Technology, private network communication series of cases, Tianwo Technology
Dimension 4: Known related-party set difference ⭐
客户.xlsx/供应商.xlsxbuilt-in关联方名称/关联方ID/关联理由field- Take the related parties already annotated in the database and compute the set difference against the list of related parties disclosed by the enterprise itself → directly uncover undisclosed related parties
- Regulatory source: Luowa Group case (5 of the public customers were related parties but were not identified)
Dimension 5: Equity/control penetration
- Penetrate equity upward (5 layers by default), see whether the counterparty is on target's equity chain, or target is on the counterparty's equity chain
- Actual controller / ultimate beneficiary name is consistent across companies
- Common shareholder (A and B have the same shareholder)
- Traces of nominee holding (frequent equity changes in change records, legal representative changes)
- Regulatory source: Huadao Biology (the legal representative once held shares on behalf of the actual controller), common to multiple cases
Dimension 6: Historical related-party traces
- Former name hit (
基础工商信息.曾用名） - Formerly served as legal representative/shareholder (the same person appeared in change records, legal representative change records)
- Former address (a historical address in change records matches the counterparty's current address)
- Suspicion of de-related-partying (was formerly a related party, later "whitewashed" through equity transfer)
- Regulatory source: ST Xinyi and Yangzi New Material cases
Dimension 7: Guarantees/Funding Chain
- Mutual guarantee relationship (A pledges to B, and B also pledges to A)
- The pledgee/pledgor of the equity pledge is the counterparty
- The mortgagee/debtor counterparty of the chattel mortgage
- Regulatory source: Kangdexin and Yan'an Bikang cases
Dimension 8: Intangible Assets/Resource Sharing
- The co-owners or agents of trademarks/software copyrights/patents are the same
- WeChat official account entity association
- The office location in the recruitment information overlaps with the counterparty
- Regulatory source: Effective in practice, partially discoverable through business registration
Boundaries and Cautions
- The tool only identifies "suspicion" and does not issue a final conclusion that someone "is a related party": The final determination requires the auditor to judge in accordance with the standards (CAS 36 / CSA 1323). The "whether a related party" column in the report is a rule-based preliminary judgment for the auditor's reference.
- Enterprise names must use the full registered business name: Otherwise, the cicpa export will match 0 companies.
- Data timeliness: Business registration data lags (changes and deregistrations may not be updated in time), and verification results need to be validated through procedures such as confirmations and site visits.
- Deregistered companies cannot be found: Some shell companies used for fraud are deregistered afterward, and cicpa may have no data. In such cases, the report will mark "data missing".
- Kinship relationships (Dimension 9) are limited by public data: Business registration data does not directly provide kinship relationships; they can only be inferred indirectly through "same name + same surname + same address", and caution is required.
When not to use
- When only confirmation address verification is needed (use the address-verification skill)
- When only business registration information for a single company is needed (use cicpa-company-query's --detail)
- When consultation is needed on related party determination at the accounting standards level (use the chen-yiwei-perspective skill)
References
references/rules.md— Detailed explanation of the eight layers of rules (identification principles, specific rules, thresholds, red flag signals, regulatory sources)references/cases.md— Penalty case library (regulatory findings of fault → corresponding verification rules)references/dimensions.md— Complete mapping of cicpa's 52-dimension fields to this skill's rulesscripts/related_party_check.py— Main script of the verification engine
Author: nigo WeChat official account: 逆行的狗