IFRS 17安永洞察 — IFRS 17子帳系統的現況與未來發展

本文將進一步分享IFRS 17子帳系統導入後的現況以及未來可能優化方向，期盼透過本文整理，能使臺灣保險業者進一步掌握子帳系統的細節，也作為未來對於系統作業面持續優化的參考。

概要

• 子帳系統出現的背景
• 子帳系統的定位及使用
• 子帳系統未來可能面臨的挑戰
• 未持續精進可能被其他系統取代

子帳系統出現的背景

國際財務報告準則第17號（以下簡稱“IFRS 17”）對於適用保險合約定義的合約，規範了新的負債衡量方式與揭露要求，這些規範包括：

1. 現金流量區分為保險組成部分及投資組成部分
2. 負債項目包含最佳估計負債（BEL）、非財務風險之風險調整（RA）及合約服務邊際（CSM）
3. 除了現行的財務報表外，需要分別揭露期初到期末BEL、RA、CSM的各項變動
4. 損益表中保險收入跟保險費用與現行國際財務報導準則第4號的認列方式不同等等。

在適用IFRS 17之前，精算部門僅需將計算出的準備金餘額提供給會計部門，會計部門依據前後期的準備金餘額進行資產負債表、損益表等財務報表的編製。而適用IFRS 17後，負債項目可細分為BEL、RA、CSM，且期初至期末的會計處理將更加細緻，例如：報導期間的實際現金流量與預期現金流量的差額，會依據是否為保費（及其相關現金流量）或是否屬投資組成部分來判斷調整至CSM，其餘則是反映在損益；又與未來服務有關之履約現金流估計變動及財務風險的假設變動將反應至損益，非財務風險的假設變動則以CSM調整等。在多個衡量值的產出需求下，子帳系統因應而生。子帳系統可以在計算出各衡量值後，直接連結會計事件以產出財務報表，無須透過人工的銜接。
 

子帳系統的定位及使用

1. 子帳系統與公司現行系統的互動
   子帳系統的出現也改變了保險公司的結帳流程，為了支持子帳系統的計算與出帳，需要核心系統、資料平台及精算系統間的相互配合，產出子帳系統所需的資料，後續在子帳系統進行衡量。所計算之衡量值將連結會計事件後，產出IFRS 17所規定的揭露報表，最後將子帳系統的結果提供至總帳系統以完成結帳流程作業。
   
   
2. 子帳系統操作與維護
   目前市面上的子帳系統，因為是商用套裝軟體，各廠商系統的介面、操作步驟大同小異，在系統介面已經配置按鈕或選單來運行，執行的步驟可以歸納如下：
   1. 結帳日資料需求準備好後，於系統介面可以點選執行以報導日為基準的cycle。
   2. 進行相關參數的設定，例如篩選匯率類型、選擇是否執行費用分攤、選擇CSM攤銷的方式、進行會計分錄借貸的配置等。
   3. 執行計算端運算，精算部門檢核運算結果。
   4. 執行會計事件與計算變數配對。
   5. 分錄與報表製作。
   
   關於子帳系統的核心中樞-運算邏輯與會計事件配對的設置，大部分的子帳系統廠商都將其建置在系統中以程式語法處理。另外有廠商為了方便使用者控管，將部分的運算邏輯與會計事件以EXCEL列表方式輸入變數公式及對應會計事件進行配對。然而，這兩種方式都需要精算部門及會計部門之專責人員加入，熟悉並了解精算端與會計端配置的語法及邏輯。此外，在資料輸入到子帳系統時，亦需要資訊部門協助進行資料轉換。
   
   
3. 子帳系統與總帳系統比較
   總帳系統是負責統整公司的財務資料，例如各種費用項目、資產負債項目等，統整完畢後產出各種財務報表，因此總帳系統會與公司的各種系統串聯並吸收產出的資料。子帳系統雖然也是吸收前端資料平臺產出的資訊，但子帳系統的性質跟總帳系統較不相同。子帳系統需要先建置運算邏輯，再配合會計事件進而產生分錄，因此若是準則變更，或主管機關要求改變影響了運算邏輯，子帳系統就需要配合調整。然而，總帳系統是收取各系統的帳務結果或會計分錄，進而產出財務報表，因為準則變更或主管機關要求改變而調整總帳系統的機率較低，這也間接導致了維護人員組成的不同。總帳系統維護人員基本上以會計部門使用者為主，子帳系統因為還要處理計算邏輯，因此除了會計部門以外，精算部門也需要規劃人員一同維護。
   
   
4. 子帳系統與精算系統的差異
   子帳系統結合精算系統提供的預期現金流量，以及資料平臺提供的實際現金流量，計算保險合約群組的BEL、RA各項變動下的數值增減和CSM滾動等。與精算系統產出逐單的各項現金流量相比，在計算上相對簡單許多，多數保險公司常用的訂價系統、精算系統等亦可執行相同的計算。但針對會計事件配對的設置及帳務的處理，並非現行精算系統導入的目的。另外，目前市面上的子帳系統的計算公式，僅開放使用者修改部分計算公式，或是根本無法修改，相較之下，精算系統的靈活性較高。
    

子帳系統未來可能面臨的挑戰

1. 多套系統後續維護
   子帳系統是因應IFRS 17上線所衍生的新系統，目前保險公司普遍已有多套系統運行中如核心系統、理賠系統、總帳系統、精算系統等，因為子帳系統的需求，需要各部門配置專責人員維護，因此未來公司在多套系統並行下，勢必會增加負擔。例如IFRS 17準則或主管機關的法令變更，到子帳系統的版本更新，都需要投入時間與人力重新測試。
   
   
2. 計算過程不透明且使用者難以即時修改
   現行市場上子帳系統的計算平臺與公司精算人員使用的計算平臺差異較大，加上計算過程較不透明，且在公式修改上亦受到限制，使計算結果有誤時無法順利追蹤過程。我們觀察到臺灣的壽險公司在精算系統的使用，紛紛轉而選擇計算過程較透明的系統，說明計算平臺的透明度將影響使用者的續約意願。因此如何提供更透明，甚至使用者可以更靈活地進行修改的計算平臺，可能是未來子帳廠商可以思考的改良方向。
   
   
3. 管理報表功能不足
   目前市面上的子帳系統主要目的皆為產出IFRS 17財務報表，對於管理報表功能的開發較少。對於保險公司而言，雖然管理報表可以額外獨立製作，但是在IFRS 17上線後，績效指標也相對應的產生了改變，這些績效指標幾乎都與財務報表的項目相同，例如，新契約原始認列CSM、報導期間的CSM攤銷、RA釋放或理賠費用的實際預期差等，皆可基於財務報表的項目計算而得。因此，若與財務報表使用同個資料庫，並以財務報表相同基礎製作管理報表，則可以減少資料不一致的狀況，以及減少資料處理與計算的時間。
   
   
4. 無預算與實際財務報表偏差分析功能
   一般保險公司需要預測未來的財務報表表現，以估計下一年度的目標業績或擬定未來商品策略。預測的準確度對公司來說相當重要，因此公司會需要將當年實際的財務表現與前一年度的預測比對，以確認實際經驗與預期的差異原因。例如新契約的CSM比預期多、實際的理賠比預期少等，該偏差的項目及原因都可以作為下一年度預測的調整依據，並讓管理階層快速了解差異的項目以及影響數。若可以在一個系統中同時預測未來財務表現和檢視當年度財務報表，就可以很容易對實際經驗與預期的差異進行比較。然而觀察目前市面上現有的子帳系統，並沒有支援這個功能。
   
   

未持續精進可能被其他系統取代

綜觀市面上現有的子帳系統功能，多數仍侷限在法定財務報表的產出，子帳系統中的的計算及出帳功能，基本上可以研究透過現行保險公司常使用的軟體或是系統來取代。例如，將IFRS 17要求的負債項目滾動的計算公式，輸入實際現金流資料建置於精算系統，即可以產出出帳所需要的衡量值。該衡量值則可以透過公司的資料庫系統，以會計事件的對應表，產出各衡量值的會計事件以及分錄，並依據IFRS 17揭露要求製作出財務報表及調節表。

將子帳系統計算功能以精算系統取代的好處包含：

1. 結帳流程可以減少維護一個系統，維護的人力可以減少，產生報表的時程也可以縮短。
   
2. 計算邏輯的建置可以更透明化、容易追蹤且容易修改，目前市面上的精算系統在計算端的建置方式已經非常成熟，若有準則變更或是公司會計選擇需要重新檢視IFRS 17報表內容、會計帳務、計算結果時，使用精算系統配合修改可以更清楚且容易。

以精算系統計算之負債衡量值儲存於公司資料庫系統中，配合會計事件的對應表，除了符合法定財報的揭露要求之外，在與財報相同的資料基礎下，亦可以進行下列的延伸運用：

1. 精算系統加入資產衡量模型，IFRS 17準則的一大重點是處理IFRS 4下的資產負債會計衡量不匹配的問題，子帳系統目前只處理負債端的衡量，未來若能將資產負債管理（Asset Liability Management; ALM）與負債端在精算系統進行整合，不同IFRS 17的衡量模型（GMM法、VFA法、PAA法）所對應的資產理應有不同的配置，需要考量對應資產的權益類占比或固定收益類的占比，監測淨值比、資產收益率及損益的波動，以此決定未來的戰略資產配置，而此整合也會使資產負債管理更即時且容易控管。
2. 承上，保險公司將資產評價模型建置於精算系統後，對保險資本標準ICS（Insurance Capital Standard）的計算上亦可事半功倍。ICS的負債可與財報使用相同的資料基礎由精算系統計算，而資產模型則依據ICS的要求做補充，在負債與資產整合於精算系統的狀況下，即可於同一系統平臺進行資產負債情境加壓計算各種風險，以得出風險資本要求。
3. 在IFRS 17下部分績效指標與財務報表的衡量值雷同，因此都可由精算系統產出，即使有新增的績效指標，亦可以即時地在精算系統中新增，快速提供公司管理層客製化的管理報表，檢視各項績效指標。
4. 財務報表預測一般也會透過精算系統產出未來的現金流量，因此若財務報表的衡量值可以由精算系統計算，未來的財務報表預測亦可以由精算系統計算，無論是實際或預測的財務報表衡量值結果，最終都會記錄在同一個資料庫系統，由同一個資料庫系統進行實際經驗與預期的差異比較，可以節省資料落地的頻率，較不容易產生操作風險的問題。