一、为什么做这个
去年帮朋友看一家供应商的财报，我把年报摘要翻出来，抄了 8 个数字进 Excel，加了两条公式，花了大概四十分钟。结论出来后，我又随手把分季度数加起来，发现和全年差了 0.3%——不是四舍五入，是追溯调整。
那一刻我意识到：财报里最容易被忽略的，不是某个指标高低，是这些数字彼此对不对得上。
一家公司如果四季度的净利加起来不等于全年，可能是会计差错更正，也可能是同一控制下合并；如果自算的营收增速和披露的增速不一致，多半是上年同期数被重述过。这些"内部矛盾"不会写在任何一行报表里，只能靠验算发现。人工验算要半小时，还容易算错；而这恰恰是最适合交给程序的事——规则固定、答案唯一、不依赖任何判断力。
于是就有了 ReadOne：拖一份年报摘要进去，3 秒给你一页卡 + 9 项勾稽验算。
二、它做了什么
输入：年度报告摘要 / 年度报告 PDF，也可以是拍照件、扫描件。
输出：四样东西。
- 一页卡：8 个关键数（营收、归母净利、净利率、ROE、现金含量、扣非占比、资产负债率、经营现金流），每个都配一句人话解释。
- 自洽校验：9 项数字互相验算，逐行给出「自算值 / 披露值 / 偏差 / 结论」。
- 异常信号：命中才提示，不命中也会给结论。
- 导出：一页卡 PNG + 指标 CSV。
9 项校验分三类：
| 类别 | 校验项 | 容差 |
|---|---|---|
| 加总类 | 分季度营收 / 净利 / 扣非 / 经营现金流各自四季之和 = 全年 | 0.5% |
| 增速类 | 营收 / 净利 / 总资产 / 净资产的自算增速 vs 披露增减 | 0.15pp |
| 口径类 | 归母净利 ÷ 平均净资产 vs 披露加权 ROE | 5pp |
容差写死在代码里，不随文档变化，所以同一份年报谁跑都是同一个结果——这是它能当尽调底稿的前提。
三、技术实现：两个关键字段
整个应用是纯前端单文件，浏览器直连 xParse：
constCONFIG={capabilities:{title_tree:true,pages:true,include_table_structure:true,// ← 关键include_inline_objects:true,include_image_data:false,},};constfd=newFormData();fd.append('file',file);fd.append('config',JSON.stringify(CONFIG));constres=awaitfetch('https://api.textin.com/api/v1/agent/parse/sync',{method:'POST',headers:{'x-ti-app-id':APP_ID,'x-ti-secret-code':SECRET_CODE},body:fd,});关键字段 1：table_structure.cells
这是能算数的根本。每个单元格带row/col/text/row_span/col_span，按row、col铺进二维数组就是一张完整的表：
functiongrid(tbl){constcells=tbl.table_structure.cells;constrows=Math.max(...cells.map(c=>c.row))+1;constcols=Math.max(...cells.map(c=>c.col))+1;constg=Array.from({length:rows},()=>Array(cols).fill(''));for(constcofcells)g[c.row][c.col]=String(c.text??'').trim();returng;}不传config时这个字段根本不返回，接口也不会报错——只有elements和markdown。想做表格级抽取，第一件事就是把include_table_structure打开。
关键字段 2：page_number
每个元素都带页码。所有指标卡和校验行都标注"数据来源第 X 页"，评审或同事要核对时，直接翻过去就能对上。
四、三个踩坑与解法
坑 1：行名匹配会被"截胡"
「归属于上市公司股东的净利润」和「归属于上市公司股东的扣除非经常性损益的净利润」，用/净利润/去匹配，第一行永远先命中。
解法是扣非优先，且匹配顺序必须是：扣非 → 净利：
constRE={netDed:/扣除非经常性损益.*净利润|扣非.*净利润/,// 先匹配net:/归属于上市公司股东的净利润|归母净利润|^净利润$/,};坑 2：EPS 和 ROE 常常不在主表里
主要会计数据表只列 6 项，EPS 与 ROE 被拆到独立的「主要财务指标」表。而且那张表的表头年份有时因合并单元格整行丢失——五粮液那份摘要就是这样，2024 年 / 2023 年全空。
解法两段兜底：先跨表按行名回捞；如果连年份表头都没有，就按"数值列出现顺序"推断本期 / 上期：
if(colY==null){for(constrowofg2){constnumCols=[];row.forEach((c,ci)=>{if(ci>0&&Number.isFinite(num(row[ci])))numCols.push(ci);});if(numCols.length>=2){colY=numCols[0];colY1=numCols[1];break;}}}坑 3：单位不是"元"
有的摘要在表上方写「单位：万元」。错一个数量级，所有校验都会误报。解法是回溯该页之前最近的单位标记，得到乘数再统一换算：
constm=text.match(/单位\s*[:：]\s*(人民币)?\s*(亿元|万元|千元|元)/);constf={元:1,千元:1e3,万元:1e4,亿元:1e8}[m[2]]||1;五、实测：两份真实年报
| 样本 | 解析耗时 | 自洽度 | 结论 |
|---|---|---|---|
| 贵州茅台 2024 年报摘要（7 页） | 约 3 秒 | 100 / 9 项全过 | 净利率 50.5%、现金含量 1.07、扣非占比 100.01% |
| 宜宾五粮液 2024 年报摘要（4 页） | 约 3.3 秒 | 100 / 9 项全过 | 营收 +7.09% 但经营现金流 −18.69%，命中「增收但现金流没跟上」 |
两句值得单独说的：
茅台的 ROE 有两套数。我按"归母净利 ÷ 平均净资产"算出 38.43%，年报披露的加权 ROE 是 36.02%，差 2.41 个百分点。这不是错，是加权平均（按月加权净资产）与期末平均的口径差。工具会把这类差异标注为"正常口径差"而不是判死——验算工具的价值是指出可疑之处，不是把每个差异都判成造假。
五粮液的现金流信号。营收涨 7%，经营现金流掉了 18.7%，现金含量却还有 1.07。这组合说明利润本身有现金支撑，但增量收入没带来增量现金——通常意味着账期放宽或票据结算变多。这种"表内不矛盾、表间有张力"的情况，正是人工翻年报最容易漏掉的。
六、边界
说清楚，免得误用：
- 只覆盖摘要级指标。营收、利润、现金流、资产负债、每股指标够做初筛，但应收周转、存货结构、关联交易、会计政策变更原因，还得读全文。
- 免费通道单次 50 页上限。150 页的年报全文传不上去，界面会直接引导改传"年度报告摘要"——摘要 5–10 页，关键财务数据一个不少。
- 不判断会计政策好坏。它只做算术，不做审计意见。
- ROE 差超过 5 个百分点只提示不判死，因为年内增发、大额分红都会造成真实的口径差，机器不该替人下结论。
七、一点想法
做这个作品之前，我以为"文档解析"的终点是"把表格变成 Excel"。
做完之后发现，xParse 给的table_structure其实是一份可以计算的证据：行列结构在，页码在，合并跨度在，那就意味着程序不只是能抄数字，还能让数字互相验算。
摘抄是搬运，验算是判断。搬运省的是时间，验算省的是错误——对财报这种"一个数字错位就改结论"的场景，后者更值钱。
如果你的团队在做投研、信贷或供应商准入，建议在流程里加一道自动验算：先确认这份报表自己能跟自己对上，再去看它讲的故事。
