金管会规定保险业於2026年起实施《IFRS 17》公报准则。
该准则的重点要求之一：预期於未来发生的收入，於未来逐期实现；当时发生的损失，立即实现。
本文探讨人寿保险公司、产物保险公司、再保险公司首当其冲的挑战和待办事项。
保险公司的会计分录应记录各项必要【明细信息】！
谨邀请董事长、总经理、信息长、财务长、精算部人员您尽速用放大镜检视贵司现有信息系统（ERP)并且回答下列是非题：
- 各交易与会计无缝集成：
- 你的ERP应符合OLTP精神：在各业务模块发生与金钱相关的全部交易一律生成会计分录。而不是各业务模块「拥钱自重」，拒绝会计模块窥知各种单据里面的金钱数据，各业务模块与会计模块暂时甚至永远、局部甚至全部彻底脱勾的那种ERP。
- 各交易在会计即时呈现：
- 在各业务模块发生与金钱相关的全部交易立即生成会计分录。而非等到本月底、下个月初、甚至下个月中某夜深人静时才去「跑批次（batch）」「月结」、「年结」、「介接不同模块」、「转资料」程序，一次生成成千上万笔信息落后时效性会计分录的那种ERP。
- 会计可追溯各原始交易：
- 财报签证会计师可从会计模块记录的信息循线调阅出其在各业务模块发生的原始交易，例如：缴费单、理赔付款单。
如果您对这些问题的回答都是「是」，那么您的 ERP 系统实际上已经符合 IFR-17，您根本不需要任何第三方会计报表模块。 如果您的答案含任何「否」，我可以帮助您快速实现这些目标。
兹举下列假设例来说明保险业ERP的品质。
例一： 收到保费时
分录#1：
未来现金流量 40
风险调整 10
合约服务边际 50
保险负债 100
挑战：
- 分录#1的数据来源是哪一张收款单？如果不知道，则一旦修改该原始收款单时，IT人员将无法得知应该同步修改分录#1！
- 分录#1系针对那几张保单编号？如果不知道，则IT人员无法读取会计分录，按保单种类（群组）分类，出具盈亏、摊销、准备金等各种汇总（aggregation）报表！
例二：保险公司【数字转型】
如何设计网站，供业务员在外地输入代收保费资料？
1、业务员#9代收下列款项并且输入ERP，但是尚未转帐该款项至保险公司银行帐户：
- 保单#1，第2期全额保费 $100、第3期预缴保费 $90
- 保单#2，补缴第5期全额保费 $200、滞纳金$20、第6期预缴保费 $200、第7期预缴保费 $200
ERP应如何开立分录？
2、该业务员於三日后转帐全部金额至公司银行帐户。
- ERP被动收到银行到款通知，或主动询问（poll）银行API而获知到款消息之后，ERP应如何立即开立会计分录？
- ERP如何比对会计分录与银行到款资料？
- ERP能否从会计分录回溯业务员#9输入的前述资料，而得出这些数据：保单#1、保单#2、各缴费期别与金额？如果ERP办不到，则保险公司如何管理收款作业，精准分期冲销、局部冲销预收款、应收款，从何处读取数据以计算业务员奖金...？
如果无法克服1或2，则表示金流与会计存在断层，网站设计技术即使高超，也不宜上线供业务员使用，以免铸成无法收拾的乱局。
一套ERP如果无法实现前面任何一项提问的话，则该ERP未符合OLTP的精神，而且未能无缝集成业务与财务。
这种业务与财务脱勾、欠缺OLTP特性的保险业ERP具有下列无法彻底改善的重大缺陷：
- 因为ERP错综复杂，不易比对数据与稽核，所以其会计数据即使暗藏错误，包括签证会计师事务所在内的各界人士咸误以为保险公司符合《IFRS 17》要求，其实不然。ERP犹如一颗未爆弹，无人有能力去挖掘，遑论拆解？参与者普遍心存「任内不出事佳！」心理。
- 会计模块成为【信息孤岛】。会计模块浑然不知在各业务模块随时增、改、删的金钱数据。会计人员为了做帐而被迫於下个月从各业务模块转档、下载文档、实施（import）到工作表，甚至手工输入报表数据，然后加工、输入分录至会计模块。是一套各业务模块与会计模块彻底脱勾，无数代MIS人拼凑起来的庞大、混乱、松散、急就章而成、MIS老手难以驾驭、IT新手无力承接维护的一堆代码，包括会计和精算人员在内的使用者怨声载道。
- 会计信息不即时。大部分会计信息必须等到成功跑完月结批次作业之后才能提供予信息使用人，信息服务品质不佳。
- ERP容易暗藏业务模块数据与会计模块数据，二者不一致错误，导致包括公司内部人员、业务员、金管会、政府税徵机关...等信息使用人不知道应该相信那一份数据；客户服务人员接不完电话，MIS人员和会计人员周末天天加班有苦劳无功劳...全公司乱成一团。
- 为追求业务模块数据与会计模块数据，二者一致目标，ERP一定庞大、复杂、「牵一发，动全身」、极难维护，所以MIS部门的人员编制庞大。
- 因为信息集成困难，所以MIS部门推出网络在线加保、退保等新信息服务的步调迟缓。
- IT人员修改了处理业务的OLTP代码，未修改处理金额的批次作业的代码，导致批次作业输出错误数据，甚至执行中途遇到异常（exception）。
- 因为数据散置於各业务模块，所以MIS部门生产力低落，不易提供优质信息服务。例如：精算人员和会计人员需要统计资料，IT人员必须全盘了解各业务模块的资料表（database tables）结构，才有能力开始撰写复杂的程序，去读取大量的原始数据，花费长时间才有机会完成程序并且满足精算人员和会计人员的信息服务需求。
- 批次作业执行中途可能遇到异常而中断，且非操作员（operator）所能除错，延误结帐时间。
- 因为数据散置於各业务模块，导致执行批次作业必须耗费大量主机的运算和网络资源，拉低ERP回应其他信息使用者的速度，出现「蓝三点」（三个蓝色的点一直转）的待机状态。所以必须安排批次作业於离峰时间执行，所以必须编制轮夜班的MIS operator人员。
- 保险公司被迫采用这种下策：增加硬件花费，购买七十亿元的伺服器，去弥补ERP软件缺陷 – 龟速运行。
最不良的安排：外购并且外挂「预制符合《IFRS 17》要求报表」的【特制模块】
这种【联合国软件】将导致下列不良后遗症：
- 特制模块与集成各业务模块不易集成。
- 特制模块采用的程序语言和数据库未必与各业务模块采用的程序语言和数据库相同，不易与各业务模块无缝和即时集成。它带给MIS人员额外的痛苦负担和技术考验：单向甚至双向无缺漏资料、无重复资料、即时同步（synchronize）两个以上（甚至品牌不同）的数据库。
- 外购会计模块可能是一个黑箱
- 软件供应商如果不提供原代码，则
- MIS人员无法自行优化该模块。
- MIS人员没机会从中学习，提升自我专业。
- 公司形同被软件供应商绑架。
决策者之所以出此下策，是因为下列误解：
- 误以为公司自己的人员没有能力开发出品质优於该外购会计模块的系统。
- 误以为MIS人员承接外购会计模块，比自己开发一套容易。
公司自己人员其实未必如此不堪承担重任。最理想的策略是：专业经理人自己或外聘讲师训练部属，提升部属的专业能力，令部属有能力开发出品质优於市场贩售的会计模块，永续自主优化会计模块。
待办事项：打造一套无缝集成业务与财务，具有下列特质的保险业ERP：
- 完全符合《IFRS 17》要求。
- 会计资料没有隐藏性错误。
- 会计分录信息与各业务模块一致、及时、完整。
- 包括业务员奖金等各类统计数据全部取自会计分录。绝对不出现业务模块数据与会计模块数据，二者不一致，困惑信息使用人乱象。
- 会计分录信息细致、可回溯、可勾稽至原始交易单据。
- 分期付款、预收冲销对象、预付、应收帐款当事人、银行帐号、应收票据编号、缴款单编号、理赔单编号、退保单编号、固定资产编号、帐款到期日...。
- ERP减少batch作业的数量。
- 批次处理仅限於汇总（aggregate）计算（例如：加总某类别的金额，然后据以计算摊销金额并且批次生成分录，或是计算业务员奖金）。
- 会计资料表结构简单，ERP为【低代码开发平台，low code development platform】。
- 不仅MIS人员，最了解自己业务的精算人员、会计人员也都有机会参与ERP开发，快速自我满足信息需求，实现【全民开发，citizen development】ERP的理想。
我帮助保险公司建立符合IFRS 17的信息系统。
【低代码开发平台】PostERP的会计模块於2006年起即开始支持无缝集成各业务模块，即时生成可勾稽的ERP信息。
攸关保险公司【数字转型】成效的因素非止於本文聚焦的《IFRS 17准则》。这里有更多探讨：
本文作者C.N. Liou的保险业ERP经验：
- 巨型人寿保险公司首位负责【user computing】业务的System Analyst。请参见《大型主机上面跑的信息系统缺陷》。
- 承包并完成英国【Commercial Union】再保险公司台湾分公司完整的信息系统。
