全球PyPI仓库里有超过47万个Python包，但英国会计从业者找了7年，没找到一份能直接调用的标准科目表。
这是开发者 Matt 在 GitHub 上写下的原话。他在给英国客户做AI记账工具时，发现所有现成的会计库都是美国标准——GAAP（美国公认会计原则）的科目分类、美国的税务代码、美国的增值税逻辑。英国特有的VAT（增值税）处理、HMRC（英国税务海关总署）申报表单映射，全得自己手工维护。
于是他花了一个周末，把英国标准的166个 nominal codes（名义科目代码）写成了一个零依赖的纯Python库：uk-chart-of-accounts。
为什么美国代码在英国会"水土不服"
英美会计体系的差异，比英镑和美元的汇率更难换算。
美国会计软件通常把"租金"归为一类，但英国VAT规定：住宅租金零税率，商业租金标准税率20%。混在一起，季度申报时直接报错。更隐蔽的是"业务招待费"——英国VAT完全禁止抵扣进项税，企业所得税还要做纳税调增。美国开发者没经历过CT600（英国公司税申报表）的折磨，根本想不到这一层。
Matt 在文档里举了个例子：代码7403"业务招待费"的元数据里，直接嵌入了 HMRC VAT Notice 700/65 的引用，以及 CT600 Box 46 的填报指引。
这不是注释，是机器可读的字段。
调用 `coa.get(7403).hmrc_box` 返回字符串 `"CT600 Box 46"`，调用 `.description` 拿到完整的税务处理说明。做自动化报表时，不再需要硬编码映射表。
给AI记账工具做的" prompt 外挂"
这个库最讨巧的设计，是 `to_prompt_context()` 方法。
现在所有人都在做大模型+记账，但有个脏活躲不掉：怎么让模型知道"TESCO 15.40 GBP"该进哪个科目？常规做法是维护一套 prompt 模板，把科目表贴进去。科目表更新了，模板得跟着改，版本管理噩梦。
Matt 的做法是把整个科目表序列化成结构化文本，按账户类型过滤，直接注入 prompt：
```pythoncontext = coa.to_prompt_context(types=[AccountType.OVERHEAD])prompt = f"""Given this chart of accounts:{context}Categorise this transaction: "TESCO 15.40 GBP""""
模型拿到的是带VAT税率、带HMRC表单映射的完整上下文，不是光秃秃的科目名称。Matt 说这是他从一个更大的记账自动化项目里拆出来的"参考数据层"——原本只是内部工具，发现社区确实需要，才单独开源。
166个代码背后的合规细节
英国标准科目表的范围从1000（固定资产）到9999（系统账户），Matt 覆盖了完整的166个常用代码。每个代码包含6个字段：名称、VAT税率（标准/减免/零税率/豁免）、税率百分比、借方增减方向、HMRC表单映射、业务标签。
标签系统做得细。"motor"标签能捞出所有车辆相关费用——燃油、保险、维修、路税，方便做福利车（company car）的税务调整。按VAT税率筛选，能一键分离可抵扣和不可抵扣进项。
最枯燥的部分是 HMRC 映射。CT600的86个格子、VAT Return的9个盒子、FPS/RTI（实时报税）、EPS（雇主支付摘要）、CIS（建筑业方案），每个代码该进哪个格子，全写进了元数据。做电子申报时，直接读字段生成XML，不用再查 HMRC 的PDF手册。
零依赖、纯Python、3.10+支持。安装命令就一行：`pip install uk-chart-of-accounts`。
GitHub 仓库的星标数还没破百，但 Matt 说已经收到四大会计师事务所的私信——不是要用，是想确认"这个映射关系你们从哪验证的"。他贴出了 HMRC 官方科目表指南和 VAT Notice 的交叉引用链接。
开源社区有个经典悖论：最该被标准化基础设施，往往因为"太基础"而没人愿意维护。美国有 FASB（财务会计准则委员会）背书的 XBRL 分类标准，Python 生态里对应库一抓一把。英国 HMRC 只发PDF和Excel，开发者各自为战，重复造轮子造了七年。
Matt 的166行代码（实际代码量）算不上一场革命，但它把"查PDF-手工录入-祈祷别报错"的循环，变成了 `pip install` 之后的三行调用。对于每年要处理超过500万份CT600申报的英国中小企业来说，这个差距可能就是自动化和手工账的分水岭。
下一个被补上的缺口会是什么？澳大利亚的GST科目表，还是印度的GST州际映射？有人在 Matt 的 issue 区留言：加拿大T2申报表的科目映射，我周末也写一个。
热门跟贴