能够读取电表而不仅仅是总金额的公用事业账单OCR

关键要点

  • 公用事业账单OCR是利用光学字符识别(OCR)结合AI技术,从电力、燃气、水务和电信账单中自动提取结构化数据,返回命名字段而非原始文本。
  • 重要的字段并非发票字段。电表号、电表读数、带单位的用量、千瓦(kW)需求、费率,以及供应与配送费用的明细,这些才是公用事业账单OCR区别于普通发票OCR的地方。
  • 每种公用事业都有不同特点。电费包含需求和分时电价;燃气费包含热量单位(therms或CCF)及热值;水费包含水表读数和排污费;电信费则包含多行明细费用的表格。
  • 手动录入每份账单需8到12分钟,成本为1到3美元,错误率在1%到5%之间。如果每月处理几千份账单,这将是一份没人愿意做的全职工作。
  • 免模板的AI提取技术无需任何设置即可处理新的供应商和重新设计的版式,这完美解决了大规模管理时的核心痛点。

什么是公用事业账单OCR?

公用事业账单OCR是通过光学字符识别结合AI技术,从电力、燃气、水务或电信账单中自动抓取结构化数据,返回命名字段而非一整页零散的文本。普通OCR只读取页面并返回文本;而AI OCR则读取页面并返回特定字段,这才是真正重要的部分,因为没有任何财务系统会需要一大段毫无结构的纯文本。

账单通常以PDF、扫描件和电子邮件附件的形式出现,而且没有任何两家供应商的排版是一致的。一家可能把电表读数印在侧边栏,另一家可能把它藏在第三页的表格里,还有一家可能把供应和配送费用分列在两页上,并认为这是在提供便利。人工可能只需一秒钟就能看懂这些,但模板却会因此彻底失效。

如果每月只有一份账单,这些都无关紧要。但如果有四百个网点,这就成了一条必须靠人工在中间苦苦支撑的数据管道。

可以从公用事业账单中提取哪些字段?

所有字段。更好的问题是“需要提取哪些字段”,因为那些真正让公用事业账单具有其独特属性的字段,永远不会出现在普通发票上。

分组 字段
账户与服务 账号、客户或账户持有人姓名、服务地址、账单地址、公用事业供应商、表号或设备ID
账单周期 账单日期、到期日、服务起止时间、发票或对账单号、上期余额、本期费用
用量与费用 本期及上期读数、抄表日期、带单位的用量(kWh、therms、CCF、加仑、MMBtu)、千瓦(kW)需求、单价、费率或资费套餐、供应与配送费用、明细项描述、税费和附加费、抵扣与调整项
支付信息 应付总额、支付方式、滞纳金、参考号

资金的奥秘藏在第三行。账号和应付总额告诉应付账款部门需要支付多少。而读数、用量、需求和费率则告诉运营部门:这笔账单最初算得对不对,哪个网点的能耗出现了异常,以及ESG报告将会呈现什么数据。普通的发票工具只读取前两行就停止了,而公用事业账单解析器则会继续深入。

Benefits of utility bill OCR
Benefits of Utility Bill Extraction

电、气、水和电信是四个截然不同的问题

把这四者一概而论,是导致公用事业账单解析项目最终只有“一半管用”的最常见原因。它们确实有共同的字段,但有价值的数据却各不相同。

电费。 千瓦时(kWh)的用量,加上通常比能源本身更贵的千瓦(kW)峰值需求。分时电价将用量划分为高峰、低谷和平段。在解除管制的市场中,同一张账单上的供应费和配送费分别来自两家不同的公司,且只有其中一项是可以议价的。

燃气费。 根据不同地区,体积单位为therms、CCF或MMBtu。账单上通常会印有转换系数,如果你需要以能源单位进行报告,这个系数必不可少。由于季节性波动极大,只有同比数据才能说明问题。

水费。 水表读数在这里起着关键作用。排污费通常是根据用水量计算而非实际测量的,且灌溉用水有时会单独计量。用量激增意味着漏水,而从数据中发现漏水绝对好过在地下挖开寻找。

电信费。 这其实不能算作“一张”账单。它是一个包含多条线路、号码或电路的表格,每一项都有其套餐费、用量、超额费和税费。如果将其简单地汇总成一个总额,你就会扔掉唯一能告诉你“自2024年以来有12部电话根本没人用过”的关键数据。

手动录入公用事业账单的真实成本

这项成本从未作为单独的明细项出现过,而这正是它一直存在的原因。以下是相关研究得出的结论:

  • **每张账单耗时:**根据Resolve的数据,根据复杂程度,手动录入平均需要8到12分钟。而围绕它展开的整个发票处理流程耗时更长。
  • 单次处理成本:ERP Software Blog指出,简单录入的直接人力成本约为1至3美元。如果加上审批、核对和异常处理,成本还会进一步攀升。
  • **错误率:**根据Fluxygen的数据,结构化录入的错误率通常在1%到5%之间,在复杂的多字段文档中更高。你有一小部分账单数据正悄无声息地出错,而手动流程中没有任何环节是为了发现这些错误而设计的。
  • **自动化的改变:**据Ramp报道,在发票和账单的工作流程中,与手动方法相比,自动化最高可节省约80%的时间。
  • 预期准确率:Gartner报告指出,文档解析的提取准确率为90%到99%,具体取决于文档质量以及是否应用了人工验证。

拿这些数据去算算每月3000份账单的情况,这笔账很快就会让人感到不适。录入需要400到600个小时,这相当于两个本可以去做其他工作的人的全部工时。同时,每月会有30到150份带错的账单,这些错误只有在季度结算时才会浮出水面(如果能被发现的话)。

为什么公用事业账单比普通发票更难处理

Challenges of utility bill OCR
Challenges of Utility Bill Extraction

有四点让公用事业账单区别于供应商发票。每家供应商都会自行设计账单,然后还会不定期重新设计,因此数十家供应商的四类公用事业服务,就像是一个按别人节奏不断移动的标靶。很多账单是以手机拍摄的纸质照片形式发送的,光线昏暗、角度倾斜,这是最难处理的非结构化数据,也是模板匹配功能直接宕机的地方。

其次是这些数据的用途。公用事业账单不仅用作地址证明,还是税务和ESG报告的记录,因此错误的数据会引发连锁反应。在每月数千张账单的体量下,2%的错误率不是什么“舍入误差”,而是一起每个月都会发生的数据事故。

如何在不使用任何模板的情况下提取账单数据

Parseur是一款免模板的AI解析器,专为大规模文档数据提取而打造。账单可通过专属邮箱、API或受监控的文件夹进入系统。Vision AI引擎可读取PDF、扫描件和照片。Text AI引擎则负责读取电子邮件和纯文本账单。两者均经过预训练,因此对于你从未处理过的供应商账单,完全不需要任何设置。

你只需列出你想要的字段一次。之后的每一张账单无论排版如何,都会自动匹配到这些字段上。

  • 免模板。 重新设计的账单不会破坏任何东西,因为从一开始就不存在会被打破的固定版式。
  • 涵盖各类业务。 电、气、水、电信,以及管理过程中涉及的任何其他公用事业服务。
  • 表格依然是表格。 电信费用的行级别明细会被提取为可供你分配的行,而不是一个扁平化的总额。

它可以每天处理数千张账单,并在收到时即刻解析。它符合GDPR规范——考虑到你输入的每一份文件都带有某人的姓名、家庭住址和账号,这绝对不是个小细节。

但这些都不是真正的考验。真正的考验是你自己的邮件。从文件夹里挑出一张最难处理的账单,比如那家在3月份刚改版、扫描得皱巴巴的账单,拿它先跑一次试试。因为你候选名单上的每一款工具,在处理干净的PDF时演示效果都很完美。

我需要训练AI模型吗?

不需要。不需要训练集,不需要贴好标签的样本账单文件夹,更不需要你花上一个周末教软件“电表读数长什么样”。

Parseur是一款预训练的AI文档提取引擎,添加第一百家供应商所需的工作量和第一家一样——也就是零。

注册您的免费账户
使用 Parseur 节省时间和精力。自动处理您的文档。

创建一个邮箱,将账单转发过去,AI引擎就会在收到文件时将非结构化文档转换为结构化数据

Extracted utility bill data
Extracted data from utility bill

提取的字段去哪儿了?

去你需要的任何地方。发送到Excel和Google表格进行分析,传到财务和ERP系统进行支付,导入能源和ESG平台进行报告,或者通过Zapier、Make、n8n以及Webhooks发送到其他系统。每张账单解析完毕后都会立即送达,无需苦等每月的批量导出。

想了解完整的工作流程,请查看如何用AI提取公用事业账单数据,或者前往公用事业账单提取解决方案页面,了解大规模组合管理的实际效果。

你的账单处理量已经让你付出了某种代价。唯一的问题是,这种代价是否被看见。

通过成本模拟器算算你自己的业务量

最后更新于

立即开始

准备好实现
文档数据提取自动化了吗?

几分钟免费上手,亲自体验Parseur如何融入您的工作流。

无需训练模型
自动从任何文档录入数据
从点击操作到API调用轻松扩展

常见问题解答

当面对成百上千份公用事业账单PDF和一张必须手动填写的电子表格时,人们最常提出的实际问题。

公用事业账单OCR是利用光学字符识别(OCR)结合AI技术,从电力、燃气、水务和电信账单中自动抓取结构化数据。它能读取PDF、扫描件或通过电子邮件发送的账单,并返回已命名的字段,如账号、服务地址、表号、用量、费率和应付总额。这些数据可以直接加载到ERP或电子表格中,完全无需人工重新录入。

建议使用AI提取引擎,而不是基于模板的解析器。模板工具在供应商更改排版的瞬间就会失效,而在大规模处理时,你需要应对电力、燃气、水务和电信等供应商数百种不同的版式。Parseur的Vision AI引擎会自主读取每份账单,因此新的供应商或重新设计的账单不需要任何设置。你只需定义一次字段,所有版式都会自动映射到这些字段。

首先集中账单,然后再进行提取。将所有网点的账单接收邮箱指向同一个解析邮箱,从中提取相同的字段集,并在这些字段中包含服务地址和账号,以便每条记录都能对应到相应的网点。输出结果将汇总在一个表格中,每个网点的每张账单占一行,从而实现组合级别的成本和消耗报告。

在账单处理中,OCR意味着使用光学字符识别技术,将账单图像或PDF转换为机器可读文本。这样就能在无需人工录入的情况下捕获金额、日期和账户明细。然而,单纯的OCR只会生成一段文本;AI OCR则更进一步,能返回命名的、结构化的字段,这才是财务或ERP系统真正需要的数据。

可以。电信账单包含重复的行(每条线路、号码或服务占一行),每行都有各自的套餐费、用量和附加费。Parseur会将这些提取为表格数据,而不是简单地压平为一个总额,这样你就能保留每行与其费用的对应关系,方便进行成本分摊和核对。

不需要。Parseur是免模板的。AI引擎已在文档结构上进行了预训练,因此处理一份来自全新供应商的账单就像处理熟悉的账单一样。你只需列出一次想要的字段,这就完成了所有的设置工作。

定价取决于你处理的文档数量,而不是登录的人数。因此,真正关键的比较是,自动处理每份账单的成本,与纯人工录入所需的1到3美元直接人力成本之间的差异。在与任何人(包括我们在内)沟通之前,不妨先把你的每月业务量输入价格模拟器算算看。

Gartner报告指出,文档解析的提取准确率为90%到99%,具体取决于文档质量以及是否进行了人工验证。原生PDF的准确率最高,而在质量较差的扫描件和照片上准确率会有所下降。这就是为什么在大规模处理时,保留对低置信度字段的人工审核步骤是值得的。

公用事业账单OCR引擎可以提取账单上打印的每个字段,实际上它们可分为四类。账户与服务数据包括账号、账户持有人、服务地址、账单地址、供应商和表号。账单周期类包含账单日期、到期日、服务起止时间、对账单号、上期余额和本期费用。用量与费用是普通发票工具容易遗漏的类别,涵盖本期及上期读数、以kWh、therms、CCF或加仑为单位的用量、kW需求、单价、费率或资费套餐、供应与配送费用、税费和附加费,以及抵扣项。支付数据则包括应付金额、支付方式、滞纳金和参考号。

将它们汇集到一个专用邮箱中,而不是手动收集。你可以让客户或供应商直接将账单发送到Parseur邮箱地址,或者通过邮件客户端的规则自动转发,每份账单在收到时都会被即刻解析。你还可以通过API推送文件,或将它们放入受监控的云文件夹中。

Parseur将公用事业账单数据采集作为一个特定文档类型来处理。它的Vision AI引擎负责处理PDF和扫描件,Text AI引擎则负责处理电子邮件账单。Parseur专为那些需要将干净的结构化数据直接导入财务、ERP或能源报告工具的团队打造,而不是作为一个臃肿的支付与审计平台。请参考公用事业账单数据提取用例,了解端到端的工作流程。

将它们定义为字段,让AI引擎在每种排版上自动寻找它们。电费账单通常包含以kWh计的用量、以kW计的峰值需求数据、本期和上期电表读数、抄表日期、单价,以及分开列出的供应和配送费。Parseur会将每一项都提取为独立字段,因此用量分析和成本分配将不再依赖于人工去阅读PDF文件。

可以。提取的公用事业账单数据可导出到Excel和Google表格,并通过与Zapier、Make、n8n的本机集成或直接通过Webhook流入财务、ERP和BI工具中。每张解析的账单都能在处理完成后立即交付,无需等待月度批量处理。

完全不需要安排实施项目。只需创建一个邮箱,列出所需的字段,然后转发一张真实账单,看看返回什么结果即可。由于引擎是预训练的,并且不需要构建模板,你大部分的工作是决定你的ERP真正需要哪些字段,而不是配置软件。之后添加下一个供应商根本不需要任何额外工作。

适用,这也是许多公司实现自动化的最常见原因之一。验证工作流需要从文档中提取账户持有人姓名、服务地址和账单日期,并将其与客户在注册时输入的信息进行核对。自动提取这三个字段,将原本需要人工排队审核的流程变成了简单的规则校验。请参阅KYC自动化,了解它是如何融入更广泛的客户入职流程的。

公用事业账单包含账户持有人姓名、服务地址和账号,这些都是真实的个人数据,因此提出这个问题非常合理。Parseur完全符合GDPR标准。在将生产环境中的账单交给任何供应商(包括我们)之前,请务必询问:文档存储在哪里、保留多长时间,以及公司内谁有权限打开它们。如果一个供应商无法迅速回答这三个问题,那本身就已经说明了答案。

stener("alpine:init", () => { Alpine.data("statusIndicator", () => ({ statusData: { indicator: "loading" }, // Configuration mapping config: { up: { color: "bg-green-500", label: "所有系统运行正常", ring: "bg-green-400" }, maintenance: { color: "bg-blue-500", label: "维护中", ring: "bg-blue-400" }, incident: { color: "bg-yellow-500", label: "故障", ring: "bg-yellow-400" }, outage: { color: "bg-red-500", label: "停机", ring: "bg-red-400" }, loading: { color: "bg-gray-300", label: "检查中...", ring: "bg-gray-300" }, }, // Getter for the current active state get current() { return this.config[this.statusData.indicator] || this.config.loading }, // Runs automatically when the component is initialized async init() { const baseUrl = "https://status.parseur.com" const STATUS_URL = `${baseUrl}/status.json` try { const response = await fetch(STATUS_URL) if (!response.ok) throw new Error(`Network response from ${STATUS_URL} was not ok`) this.statusData = await response.json() } catch (err) { console.error("Error fetching status:", err) this.statusData = { indicator: "loading" } } }, })) }) function psrSetLang(lang) { var date = new Date() date.setTime(date.getTime() + 365 * 24 * 60 * 60 * 1000) expires = "; expires=" + date.toUTCString() document.cookie = "cf_lang=" + (lang || "") + expires + "; path=/" }