内审通把七个阶段的门禁、34 张底稿的结论等级、每一条发现的证据级别，摆在同一屏上。客户导出的 Excel 直接吃进去，能自动算的底稿当场算完。双击运行，不联网、不起服务，数据不出本机。
这三件事不解决，内审报告写得再漂亮，复核的人也判断不了哪句话站得住。
34 张底稿分散在几十个 Excel 里，谁做到哪一步只能靠周会问。进度表和实际情况隔一周就对不上，驻场三周变成漫无目的地翻凭证。
一个"差不多"的数顶上去，会一路传到报告里。复核的人看不出这个数是算出来的还是编出来的——而这正是报告能不能被银行、税务机关采信的分界线。
status；算不出来就写"缺数据·缺哪张表"，不猜、不填。只有账簿和发票（L1/L2）就把结论写成"已确认"。等对方律师问一句"你函证了吗"，整份报告的证明力当场归零。
内审通不做 KPI 大屏。它只回答三件事：现在卡在哪个阶段、哪张底稿还没做、哪条发现还差证据。
P0 立项授权到 P6 本地化培训，横向铺开。每阶段标注驻场／远程、周期、人天与主要任务，底部一盏门禁灯——那是进入下一阶段的硬门槛。
左索引右详情的双栏结构。左栏按 6 条线归组、带结论等级状态点、可搜索；右栏逐张给出目的与关注点／数据源／主要审计程序／判断标准，加证据级别与结论等级徽章、签字栏。
载入客户导出表后，能算的底稿一次跑出：采购／销售集中度、同规格同期单价逐笔比对、双向对倒、三表勾稽、应收关联方挂账、Benford 与整数偏好、进项税额转出率。
已确认／候选·待核实／第三方。字号前缀相同但主体不同（某某新材料 vs 某某包装制品）判为候选，候选一律不进占比，只列进 WP-A01 待核实——认定关联方要的是工商档案。
工具算出来的数逐项对已核基线。对不上不许往下走。它的用途不是"验证审计做得对"，是验证取数口径没被人动过——这让 P1 的门禁灯从手工置位变成自动判定。
通用阈值与底稿清单放 audit_spec.json，某一家的案情、发现、资料、阶段进度放 case_客户名.json。换客户整份换掉案卷，代码一行不动——项目经理自己就能改，不用等开发排期。
以下为演示案卷的真实界面结构。企业名称为化名，金额为构造值，仅用于展示版面与逻辑。
| 条线 | 发现 | 底稿 | 结论等级 |
|---|---|---|---|
| 定价 | 关联方采购占比畸高，定价无审批依据 | C01/C02/C04 | 已确认 |
| 真实性 | 同一对手方同期双向购销 | C03 | 方向性判断 |
| 资金 | 集中借入资金去向未取得流水 | F01/F02 | 待核实 |
| 账务 | 资产负债表不平 | E03 | 已确认 |
| 税务 | 进项税额转出率超阈值 | G01 | 待核实 |
| 时点 | 应到 | 已到 | 到位率 |
|---|---|---|---|
| 立项前 ★ | 12 | 10 | 83% |
| 进场第 1 天 | 7 | 5 | 71% |
| 进场第 1 周 | 5 | 2 | 40% |
★类资料缺失本身即构成结论——例如比价询价记录不存在，这就是内控缺陷的证据，不必再找。
WP-A01 关联方完整性清单WP-A02 采购集中度WP-A03 销售集中度WP-C01 同规格同期单价比对 ★WP-C02 价差与加工成本覆盖WP-C03 双向对倒识别WP-C04 定价机制与审批证据WP-C05 目标加成率与调价建议WP-E01 其他应付款专项WP-E03 三表勾稽与平衡性WP-E05 应收关联方挂账WP-E08 Benford 与整数偏好WP-G01 进项税额转出率WP-F02 银行账户完整性WP-H01 存货监盘与倒轧WP-C01audit_spec.json，不在底稿里硬编码。34 张底稿没有做成 tab——34 个标签一行放不下也找不着。审计人员的实际动作是「按条线找到某一张，读程序，填结论」，这是文档工作台的交互，不是看板。
| 对手方（化名） | 判定 | 依据 | 关系 | 进入占比 |
|---|---|---|---|---|
| 某新材料有限公司 | 已确认 | entity_key 精确相等 | 股东兼供应商兼客户 | 是 |
| 某贸易（简称登记为别名） | 已确认 | 命中案卷登记别名 | 共同实控人 | 是 |
| 某包装制品有限公司 | 候选 | 字号前缀相同但主体不同 | — | 否 |
| 某精密机械有限公司 | 候选 | 首次交易相隔 ≤7 天且品类完全一致 | — | 否 |
| 其余 175 家 | 第三方 | 两者都不是 | — | 计入第三方 |
早期版本用包含匹配，把一家不相干的第三方算成了关联方，A02/A03/C01/C03/E05 五张底稿的占比全部受影响。现在由一条行为断言守着：把诱饵当成已确认关联方重算，占比偏差必须被回归容差捕获。
| 供应商 | 属性 | 占比 |
|---|---|---|
| 供应商 A | 已确认关联方 | 52.60% |
| 供应商 B | 已确认关联方 | 38.44% |
| 供应商 C | 第三方 | 3.12% |
| 其余 172 家 | 第三方 | 5.84% |
| 规格 | 关联方均价 | 第三方基准 | 偏离 | 基准质量 |
|---|---|---|---|---|
| 规格 01 | 12.86 | 11.40 | +12.8% | 强 |
| 规格 02 | 9.44 | 8.72 | +8.3% | 强 |
| 规格 03 | 15.10 | 14.86 | +1.6% | 强 |
| 规格 04 | 7.02 | 6.55 | +7.2% | 弱 · 2 笔 |
| 规格 05 | — | 无样本 | — | 缺基准 |
基准质量「弱」与「缺基准」的规格不参与多付金额合计——样本不足就说样本不足，不拿一个"差不多"的数去顶。
| 期间 | 资产 | 负债+权益 | 差额 |
|---|---|---|---|
| 2024-12 | 312,406,118 | 312,406,118 | 0 |
| 2025-12 | 348,772,905 | 348,772,905 | 0 |
| 2026-06 | 366,015,220 | 364,174,720 | 1,840,500 |
| 科目 | MAD | 一致性 | 抽样优先级 |
|---|---|---|---|
| 其他应付款 | 0.0171 | 不符 | 1 |
| 管理费用 | 0.0138 | 临界 | 2 |
| 应付账款 | 0.0094 | 可接受 | 3 |
| 基线项 | 已核基线 | 工具算出 | 偏差 | 结果 |
|---|---|---|---|---|
| 关联方采购占比 | 91.0400% | 91.0400% | 0.0000% | 一致 |
| 第一大供应商占比 | 52.6000% | 52.6000% | 0.0000% | 一致 |
| 关联方销售占比 | 68.2000% | 68.2000% | 0.0000% | 一致 |
| 独立第三方采购额 | 12,480,600.00 | 12,480,600.00 | 0.00 | 一致 |
| 进项税额转出率 | 6.1000% | 6.1000% | 0.0000% | 一致 |
| 采购发票行数 | 14,860 | 14,860 | 0 | 一致 |
| 资产负债表不平金额 | 1,840,500.00 | 1,840,500.00 | 0.00 | 一致 |
| 应收关联方占比 | 64.0000% | 64.0000% | 0.0000% | 一致 |
回归基线的用途不是"验证审计做得对"，是验证取数口径没被人动过。半年后有人改了列名映射或规格归并规则，回归会先失败——而不是等报告写完才发现分母变了。
以上界面为演示案卷：企业名称系化名，金额为构造值，用于验证计算路径与展示版面，不代表任何真实客户数据。
内审面对的是客户最敏感的账簿、发票、银行流水与工商档案。数据不出厂不是一句承诺，而是由架构保证的——内审通不联网、不起服务、不开浏览器，装载脚本对原始文件只读。这也是这类项目能被客户接受的前提。
不需要装 Python，不需要建数据库，不需要 IT 支持。驻场笔记本双击就能跑。
用友、金蝶等第三方软件导出的科目余额表、发票明细、凭证序时簿、财务报表、应收账龄等，原样保存即可。分年度、分月的多份文件不用手工合并。
多选 Excel → 自动判型 → 全量合并。分年度的发票、分月的凭证必须首尾相接，少一张就少一段期间，占比全错——所以内审通做全量合并，不像看板类工具只留字段最全的那张表。
能自动算的底稿当场出结果并跑回归基线；人工底稿给出程序与判断标准，审计人员按条线找到某一张，读程序，填结论、签字。缺数据的底稿明确写缺哪张表。
判型引擎与「经营通宝」共用同一套底座——按文件头路由，抗三种常见伪装（假 xls、多层表头、合计行混排），自动剔除合计行。
兼容 用友、金蝶 等主流财务软件的导出格式，同时处理老式 .xls 与现代表格结构。真实导出表几乎总有引擎没见过的列名（「不含税金额」「货物名称及规格」）——这类不改通用判型规则，在案卷里登记别名即可，客户写法优先，不会污染其他客户的判型。
进项／销项按本企业名出现在购方还是销方一侧区分。两侧都不含本企业名的行是脏数据（别家发票混进来了），单独计数并报告——不能默默丢掉，那会让占比的分母悄悄变小。
内审通是义道「驻场内审 FDE 交付」的工具层。企业内审岗自查、事务所多客户复用、义道团队全程驻场，三种用法对应三档。
三档的具体范围以书面方案为准。驻场项目在立项前须书面确认委托人身份、报告用途与披露范围——这既是义道的保护，也是报告将来能不能被采信的前提。
把贵司的情况说一下——审计期间多长、有没有关联交易主线、导出表长什么样。我们会先判断内审通能不能吃下你的数据，再给方案。
同一套外壳、同一套取数判型引擎、同一条「数据不出本机」的底线，但两个完全不同的版面。经营通宝的报告页是给老板看数的：KPI 行 + 图 + 表，一屏看完就走。内审是做事的：要知道现在卡在哪个阶段、哪张底稿还没做、哪条发现还差证据。信息结构不同，所以另起了一套版面。
不会，也不应该。工具只做「数据到界面」，不做判断。能自动算的底稿它算，算不出来就明确写「缺数据·缺哪张表」，绝不拿一个"差不多"的数去顶——那种数会一路传到报告里，而复核的人看不出它是算的还是编的。结论等级、门禁置位、关联方最终认定，都由人来做。
因为两种简单做法都会错。包含匹配会把「某某包装制品」这种不相干的第三方算成关联方；严格相等又会让「某某」永远匹配不上发票上的「某某新材料有限公司」，占比从 91% 掉到 0。所以分三档：精确相等或命中登记别名判「已确认」，字号前缀相同但主体不同判「候选」，其余判「第三方」。候选一律不进占比——宁可算低，人会去查；算高了，没人会怀疑。
两种都有，界面上会标清楚。能自动判的两盏是 P0（★类资料到位率是否达标）和 P1（回归基线是否全部一致）。P2–P6 依赖现场事实——有没有出核查计划、发现有没有逐项定性、整改项有没有真的关闭——由项目经理在案卷里手工置位。宁可显示"未达成"也不假装通过：门禁灯一旦说谎，这个版面就没用了。
大概率能，认不出来也有正规的处理办法。判型是 941 份真实客户表实测调出来的，覆盖 9 类财务表。遇到没见过的列名（比如「不含税金额」「货物名称及规格」），不改通用判型规则——那是所有客户共用的，为一家客户改会污染别人——在贵司的案卷里登记别名即可，启动时注入，客户写法优先。
不用，改两个文件，代码一行不动。通用阈值与底稿清单在 audit_spec.json，基本不动，只调阈值；这一家的案情、发现、资料、阶段进度在 case_客户名.json，整份换掉。这是刻意的设计：第二个客户来的时候，项目经理（非程序员）要能自己改底稿清单和发现条目，否则这个工具在第二个项目上就废了。
内审通不联网、不起服务、不开浏览器，也不监听任何端口。你可以在断网的机器上完整跑一遍——载入、判型、算底稿、跑回归，全部正常。这不是配置项，是架构决定的：程序里根本没有对外发送数据的路径。
可以，这正是 P6 那一档的意义。工具部署在内审岗的机器上，培训 2 名内审人员：装载数据、跑底稿、读异常清单、维护关联方清单，客户自己每月能跑一次。这把义道从「每年来查一次」变成「客户自己天天在查、有事叫义道」——对客户更省钱，对我们更黏。