金管會規定保險業於2026年起實施《IFRS 17》公報準則。
該準則的重點要求之一： 預期於未來發生的收入，於未來逐期實現；當時發生的損失，立即實現。
本文探討人壽保險公司、產物保險公司、再保險公司首當其衝的挑戰和解法。
保險公司的會計分錄應記錄各項必要【明細資訊】！
邀請 董事長、 總經理、 資訊長、 財務長、 或精算部人員您儘速用放大鏡檢視現有資訊系統，並回答下列是非題：
- 各交易與會計無縫整合：你的ERP應符合OLTP精神：在各業務模組發生與金錢相關的全部交易一律生成會計分錄。而不是各業務模組「擁錢自重」，拒絕會計模組窺知各種單據裡面的金錢數據，各業務模組與會計模組暫時甚至永遠、局部甚至全部徹底脫勾的那種ERP。
- 各交易在會計即時呈現：在各業務模組發生與金錢相關的全部交易立即生成會計分錄。而非等到本月底、下個月初、甚至下個月中某夜深人靜時才去「跑批次（batch）」「月結」、「年結」、「介接不同模組」、「轉資料」程式，一次生成成千上萬筆資訊落後時效性會計分錄的那種ERP。
- 會計可追溯各原始交易：財報簽證會計師可從會計模組記錄的資訊循線調閱出其在各業務模組發生的原始交易，例如：繳費單、理賠付款單。無縫：
你的ERP應符合OLTP精神：在各業務模組發生與金錢相關的全部交易一律生成會計分錄。而不是各業務模組「擁錢自重」，拒絕會計模組窺知各種單據裡面的金錢數據，各業務模組與會計模組暫時甚至永遠、局部甚至全部徹底脫勾的那種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軟體缺陷 — 龜速運行。
- 最不良的ERP架構可能非此莫屬：外購並且外掛「預製符合《IFRS 17》要求報表」的【特製模組】。這種【聯合國軟體】架構毫無【整合度】可言，其缺陷顯而易見而且幾乎沒有優化的空間。它帶給MIS人員無限痛苦的額外負擔和技術考驗：單向甚至雙向無缺漏資料、無重複資料、即時同步（synchronize）兩個以上（甚至品牌不同）的資料庫。
一套無縫整合業務與財務的保險業ERP具有下列特質：
- 完全符合《IFRS 17》要求。會計資料沒有隱藏性錯誤。
- 會計分錄資訊與各業務模組一致、及時、完整。包括業務員獎金等各類統計數據全部取自會計分錄。絕對不出現業務模組數據與會計模組數據，二者不一致，困惑資訊使用人亂象。
- 會計分錄資訊細緻、可回溯、可勾稽至原始交易單據。分期付款、預收沖銷對象、預付、應收帳款當事人、銀行帳號、應收票據編號、繳款單編號、理賠單編號、退保單編號、固定資產編號、帳款到期日…。
- ERP減少batch作業的數量。批次處理僅限於匯總（aggregate）計算（例如：加總某類別的金額，然後據以計算攤銷金額並且批次生成分錄，或是計算業務員獎金）。
- 會計資料表結構簡單，ERP為【低程式碼，low code】。不僅MIS人員，最瞭解自己業務的精算人員、會計人員也都有機會參與ERP開發，快速自我滿足資訊需求，實現【全民開發，citizen development】ERP的理想。
我幫助保險公司建立符合IFRS 17的資訊系統。
【低程式碼】PostERP的會計模組於2006年起即開始無縫整合各業務模組，即時生成可勾稽的分錄。
攸關保險公司【數位轉型】成效的因素非止於本文聚焦的《IFRS 17準則》。這裡有更多探討ERP架構的文章：
本文作者LCN的保險業ERP經驗：
- 巨型人壽保險公司首位負責【user computing】業務的System Analyst。請參見《大型主機上面跑的資訊系統缺陷》。
- 承包並完成英國【Commercial Union】再保險公司台灣分公司完整的資訊系統。
Originally published at https://www.terarows.com.
