보험계약 전환일 CSM 재계산 점검 — IFRS 17 최초 적용 전환일의 CSM·손실요소·부채·이익잉여금 조정을 다시 계산해 장부와 맞춰 보는 화면

도입 포인트 — 이 앱을 사용해야 하는 이유

보험회사가 IFRS 17(K-IFRS 제1117호)을 처음 적용할 때 가장 오래 남는 질문은 “전환일의 계약서비스마진(CSM)이 맞게 잡혔나” 입니다. 같은 계약집합이라도 완전소급법이면 최초 인식 시점부터 다시 굴려야 하고, 수정소급법이면 단위 비율을 가정해 굴리며, 공정가치법이면 공정가치와 이행현금흐름의 차이로 갈립니다. 방식마다 산식이 다르고, 그 결과는 보험계약부채와 이익잉여금 조정으로 이어져 개시 재무상태표에 그대로 남습니다. 이 앱은 그 계산을 한 화면에서 다시 해 보고, 원장에 올린 금액과 얼마나 다른지를 계약집합 한 건씩 보여 줍니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 9.7억 손실요소가 장부에 없었다

24개 계약집합 가운데 6개가 점검 필요로 걸렸습니다. 금액이 가장 큰 것은 공정가치법을 쓴 한 집합입니다. 전환일 공정가치는 378.0억 원인데 이행현금흐름은 387.7억 원이라, 공정가치가 더 작아 CSM 은 0, 손실요소가 9.69억 원으로 나와야 합니다. 그런데 장부에는 손실요소 구분 없이 CSM 만 올라가 있어 손실요소 차이가 −9.69억 원으로 찍혔습니다. 같은 자료에서 다른 집합은 1.25백만 원 정도의 CSM 차이, 0.83백만 원의 부채 차이, 0.41백만 원의 이익잉여금 조정 차이처럼 작은 금액이었습니다. 큰 차이만 보면 작은 어긋남을 놓치고, 작은 것만 맞추면 구조적 누락을 놓칩니다. 이 앱은 둘을 같은 표에 놓고 코드로 가릅니다.

산식은 단순합니다. 어려운 것은 방식이 섞인 계약집합 수십 건이 같은 규칙으로 계산됐는지 확인하는 일입니다. 그래서 이 앱은 롤포워드 항등식을 매번 검산하고, 마지막 연도의 기말 CSM 이 전환일 CSM 과 같은지, 포트폴리오별 합계가 집합 합계와 같은지를 같이 돌립니다.

도입하면 달라지는 것

• 개시 잔액 점검 시간 — 방식별 파일을 열어 합계를 모으던 일이 한 화면의 탭 이동으로 바뀝니다.
• 감사 대응 — 어느 집합이 어느 방식으로 계산됐고, 근거가 적혀 있는지가 한 열에서 보입니다.
• 원인 추적 — 차이가 CSM 인지 손실요소인지 부채인지 조정인지를 코드가 먼저 알려 줍니다.
• 다음 결산으로 이어지는 기준 — 개시 잔액이 확정되면 이후 CSM 해제가 같은 기준 위에서 계산됩니다.

이런 회사에 맞습니다

IFRS 17 최초 적용을 앞두었거나 막 적용해 전환일 잔액을 감사인과 함께 확인해야 하는 보험회사, 계약집합이 수십 개 이상이라 방식별 시트로는 합계 대사가 버거운 결산팀, 그리고 보험 업무 시스템과 SAP 원장 사이의 개시 잔액이 맞는지 따져야 하는 재무회계 조직에 맞습니다. 이 글의 계약집합 자료는 가상의 검증용 샘플입니다.

숫자를 믿을 수 있는가 — 검증 결과

이 화면에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌렸습니다. 위쪽 여덟 줄은 산식끼리의 정합성이라 차이가 0 이어야 하고, 아래쪽 여섯 줄은 장부와의 대사라 의도적으로 심어 둔 예외가 걸립니다.

내부 정합성 여덟 줄이 모두 0 이므로, 장부 쪽에서 걸린 차이는 재계산이 틀려서가 아니라 장부가 다르기 때문이라고 읽을 수 있습니다. 화면 쪽은 이와 별도로 브라우저 자동화로 확인했습니다 — 조회 뒤 요약 숫자, Enter 로 조회, 계약집합 상세 대화상자의 롤포워드 줄 수, 좁은 화면 배치를 매번 다시 잽니다.

도입 후 쓰는 순서

1. 기준 연월을 넣고 조회를 누릅니다. 필요하면 포트폴리오 · 전환 방식 · 점검 코드 · 점검 결과로 범위를 좁힙니다.
2. 맨 위 요약 숫자로 계약집합 건수, 종전 기준 부채 합계, 재계산 전환일 CSM, 손실요소, 이익잉여금 조정, 점검 필요 건수를 한눈에 봅니다.
3. 계약집합 명세에서 점검 필요 줄을 찾아 눌러 상세를 열고, 점검 내용과 전환 방식 근거를 읽습니다.
4. 소급 방식 집합은 CSM 롤포워드 탭에서 연도별 기초 · 이자 부리 · 해제 · 기말을 따라갑니다.
5. 포트폴리오별 · 전환 방식별 집계로 차이가 어디에 몰려 있는지 봅니다.
6. 대사 결과 탭에서 내부 정합성이 모두 0 인지, 장부 대사에서 어떤 항목이 걸렸는지 확인하고 CSV 로 내려받아 결산 자료에 붙입니다.

실행 화면

실제로 돌아가는 화면 8종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건 아래에 요약 숫자가 먼저 서고, 그 아래로 탭과 표가 이어집니다. 숫자를 먼저 보고 표로 내려가는 순서로 읽도록 만들었습니다. 요약의 일곱 숫자는 계약집합 24건, 종전 기준 부채 합계 약 1조 3,809억 원, 재계산 전환일 CSM 약 904억 원, 재계산 손실요소 9.69억 원, 이익잉여금 조정 −12.7억 원, 점검 필요 6건, 정합성 대사 차이 0건입니다.

조회 직후에는 계약집합 24건이 번호순으로 놓입니다. 점검 결과 열은 정상과 점검 필요를 색으로 가르고, 금액 열은 오른쪽 맞춤에 천 단위 쉼표를 둡니다. 차이 열은 부호가 보이도록 − 와 + 를 모두 표시합니다.

점검 코드로 좁혀 보기

점검 필요가 6건이라면 코드별로 한 건씩입니다. 코드를 고르면 표와 요약이 같은 범위로 바뀌므로, 어느 코드가 몇 건이고 금액이 얼마인지를 바로 읽습니다.

R01 방식 근거 미기재, R02 전환일 불일치, R03 CSM 차이, R04 손실요소 누락, R05 부채 차이, R06 이익잉여금 조정 차이 — 여섯 코드가 서로 겹치지 않게 정의되어 있어, 한 건에는 가장 먼저 걸린 코드 하나가 붙습니다.

소급 롤포워드를 연도별로

완전소급법과 수정소급법 집합은 최초 인식 연도부터 전환일 직전까지 한 해씩 굴립니다. 줄마다 이자 부리와 해제가 따로 있어, 어느 해에 해제 비율이 달랐는지 바로 보입니다.

해제 비율은 제공 단위 ÷ (제공 단위 + 잔여 단위) 입니다. 이 표의 마지막 연도 기말이 계약집합 명세의 재계산 전환일 CSM 과 같아야 하고, 그 등식이 대사 결과의 세 번째 줄입니다.

포트폴리오별로 모으면

계약집합이 24건이라도 경영진이 보는 단위는 포트폴리오입니다. 네 줄로 합친 표에서 점검 건수가 있는 포트폴리오를 먼저 찾고, 계약집합 명세로 내려갑니다.

합계 열은 계약집합 명세의 같은 열을 포트폴리오별로 더한 값입니다. 대사 결과의 일곱 번째 줄이 이 합계가 집합 합계와 같은지를 매번 확인합니다.

전환 방식별로 모으면

방식별 합계는 감사인이 가장 먼저 묻는 표입니다. 수정소급법과 공정가치법은 소급이 어려웠던 사유가 필요한 방식이라, 어느 방식에 몇 건이 있고 금액이 얼마인지가 곧 설명 범위가 됩니다.

공정가치법 줄에는 공정가치 합계 열이 따로 붙습니다. 소급 방식에는 공정가치가 없으므로 0 으로 둡니다.

한 건을 열어 보면

표에서 줄을 누르면 상세가 열립니다. 위쪽에는 재계산과 장부 값을 열 단위로 나란히 두고, 아래쪽에는 그 집합의 롤포워드 줄을 둡니다. 차이가 난 열과 그 원인이 되는 입력을 한 자리에서 봅니다.

공정가치법 집합이면 롤포워드 대신 공정가치와 이행현금흐름이 나오고, 방식 근거 문장이 함께 실립니다. 닫으면 보던 표 위치로 돌아갑니다.

스스로 하는 검산

마지막 탭이 이 화면의 신뢰를 만듭니다. 좌변과 우변, 검사 건수, 차이 건수, 최대 차이, 그리고 대사식 문장이 한 줄에 있어 숫자를 읽는 사람이 산식까지 같이 읽습니다.

대사 구분 열에는 내부 정합성이 대사 구분 열에는 내부 정합성이 ‘정합성 대사’, 장부 쪽이 ‘장부 점검 대사’ 로 표시됩니다.lsquo;정합성 대사대사 구분 열에는 내부 정합성이 ‘정합성 대사’, 장부 쪽이 ‘장부 점검 대사’ 로 표시됩니다.rsquo;, 장부 쪽이 대사 구분 열에는 내부 정합성이 ‘정합성 대사’, 장부 쪽이 ‘장부 점검 대사’ 로 표시됩니다.lsquo;장부 점검 대사대사 구분 열에는 내부 정합성이 ‘정합성 대사’, 장부 쪽이 ‘장부 점검 대사’ 로 표시됩니다.rsquo; 로 표시됩니다. 요약의 ‘정합성 대사 차이 건수’ 는 앞의 여덟 줄만 센 값이라 0 이 정상입니다.

좁은 화면에서도

결산 회의에서 휴대폰으로 숫자를 확인하는 일이 흔해서, 좁은 창에서는 요약과 필터를 세로로 쌓고 표는 가로로 밀어 보게 했습니다. 숨기는 정보는 없습니다.

표의 가로 폭은 열 수에 맞춰 늘어나고 첫 열은 머물러 있어 어느 집합의 줄인지 놓치지 않습니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 조회를 없애야 하느냐” 는 질문이 꼭 나오는데, 없애지 않고 둡니다. 장부 대사와 감사 대응은 표준 거래가 맡는 편이 안전합니다.

기준서 요구사항과 대응 기능

이 화면은 점검용입니다. 계산은 단순화한 모델이며, 회계 처리의 최종 판단은 회사와 감사인이 합니다.

CDS 구성

이 사례의 화면은 계약집합 24건과 롤포워드 49줄을 서비스에서 한 번에 받아 보여 줍니다. 데모라서 되는 일이고, 운영에서는 계약집합 수천 건에 연도별 롤포워드가 붙으므로 계산을 서비스 쪽으로 내립니다. 아래는 그때 만드는 뷰의 스케치입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르고, 계약집합 · 이행현금흐름 · 공정가치 · 제공 단위의 원천은 보험 업무 시스템에서 와서 SAP 표준 원천이 확인되지 않습니다. 확인이 필요한 자리는 주석에 적었습니다. 붙여 넣기 전에 View Browser(F2170)로 실제 이름을 확인해야 합니다.

뷰 레이어 구성

① 입력 뷰

원천이 아직 확정되지 않은 자리입니다. 계약집합 한 건에 전환 방식과 이행현금흐름, 공정가치, 종전 기준 부채가 모입니다. 원천은 운영에서 정합니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CsmTransInput — 전환일 계약집합 입력
"  원천 : 보험 업무 시스템에서 올린 계약집합 마스터와 전환일 평가 자료
"        (SAP 표준 원천은 확인되지 않음 → 운영 연결 때 확인 필요)
"  종전 기준 부채는 ACDOCA 계정 잔액을 계약집합에 배부한 값을 쓴다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '전환일 계약집합 입력'
define view entity ZI_CsmTransInput
  as select from zcsm_trn_grp as g          " 확인 필요 : 실제 원천 테이블
{
  key g.period        as Period,            " 기준 연월(연도+월)
  key g.group_no      as GroupNo,
      g.bukrs         as CompanyCode,       " 권한 조건에 쓴다
      g.portfolio     as Portfolio,         " LIFE · HLTH · ANNU · GRP
      g.cohort        as Cohort,
      g.approach      as Approach,          " FRA 완전소급 · MRA 수정소급 · FVA 공정가치
      g.trn_date      as TrnDate,           " 기대 전환일
      g.init_date     as InitDate,
      g.prev_liab     as PrevLiab,          " 종전 기준 부채
      g.fcf_trn       as FcfTrn,            " 전환일 이행현금흐름
      g.fair_value    as FairValue,         " 공정가치법에서만 값이 있다
      g.accr_rate     as AccrRate,          " 고정 할인율(%) — 최초 인식 시점 곡선
      g.basis_note    as BasisNote          " 방식 선택 근거 문장
}

② 롤포워드 테이블 함수

소급 롤포워드는 앞 연도의 기말이 다음 연도의 기초가 되는 계산입니다. 연도마다 기말 = 기초 × (1 + 이자율) × 잔여 단위 ÷ (제공 단위 + 잔여 단위) 이므로, 연도별 계수의 곱으로 풀면 윈도 함수로 한 번에 구할 수 있습니다.

" ────────────────────────────────────────────────────────────────
"  ZTF_CsmTransRoll — 소급 롤포워드(테이블 함수)
"  기말(k) = 기말(k-1) × (1 + 이자율/100) × 잔여단위 ÷ (제공단위 + 잔여단위)
"  → 연도별 계수 f 의 누적곱 = EXP( SUM( LN( f ) ) OVER (...) )
"  계수가 0 이하이면 LN 이 실패하므로 입력 단계에서 막아 둔다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '전환일 CSM 소급 롤포워드'
define table function ZTF_CsmTransRoll
  with parameters p_period : abap.char(6)
returns {
  mandt     : abap.clnt;
  period    : abap.char(6);
  group_no  : abap.char(3);
  year_no   : abap.char(4);
  csm_open  : abap.dec(18,0);
  csm_accr  : abap.dec(18,0);
  csm_rel   : abap.dec(18,0);
  csm_close : abap.dec(18,0);
}
implemented by method zcl_csm_trans_roll=>get_roll;

" AMDP 구현 스케치 (SQLScript)
"   f   = ( 1 + accr_rate / 100 ) * cu_fut / ( cu_in + cu_fut )
"   cum = EXP( SUM( LN( f ) ) OVER ( PARTITION BY group_no ORDER BY year_no ) )
"   csm_close = csm_init * cum
"   csm_open  = LAG( csm_close, 1, csm_init ) OVER ( PARTITION BY group_no ORDER BY year_no )
"   csm_accr  = csm_open * accr_rate / 100
"   csm_rel   = ( csm_open + csm_accr ) * cu_in / ( cu_in + cu_fut )

③ 계산 뷰

방식별 CSM · 손실요소를 한 곳에서 정의합니다. 공정가치법은 두 값 중 하나만 0 이 아니고, 소급 방식은 롤포워드의 마지막 기말을 씁니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '전환일 계약집합 CSM 재계산'
define view entity ZI_CsmTransGroup
  as select from ZI_CsmTransInput as g
  association [0..1] to ZI_CsmTransRollLast as _Roll
    on  _Roll.Period  = $projection.Period
    and _Roll.GroupNo = $projection.GroupNo
{
  key g.Period,
  key g.GroupNo,
      g.CompanyCode,
      g.Portfolio,
      g.Approach,
      g.PrevLiab,
      g.FcfTrn,
      g.FairValue,

      " CSM : 공정가치법은 공정가치 - 이행현금흐름(양수일 때), 소급은 마지막 기말
      case g.Approach
        when 'FVA' then
          case when g.FairValue > g.FcfTrn
               then g.FairValue - g.FcfTrn else 0 end
        else coalesce( _Roll.CsmClose, 0 )
      end                                         as CsmCalc,

      " 손실요소 : 공정가치법에서 공정가치가 더 작을 때만 값이 생긴다
      case when g.Approach = 'FVA' and g.FcfTrn > g.FairValue
           then g.FcfTrn - g.FairValue else 0 end as LossCalc,

      _Roll
}
" 부채 = 이행현금흐름 + CSM,  이익잉여금 조정 = 종전 부채 - 부채  는 이 뷰를 읽는
" 상위 뷰(ZI_CsmTransCheck)에서 계산한다. 기준서 문단 확인이 필요한 부분은 주석으로 남긴다.

④ 장부 뷰와 점검 뷰

장부 쪽 금액은 ACDOCA 에서 읽고, 재계산과 맞춰 차이와 점검 코드를 한 번에 냅니다. 코드 판정이 이 뷰에 있으면 화면은 값을 그대로 보이기만 하면 됩니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '전환일 CSM 점검'
define view entity ZI_CsmTransCheck
  as select from ZI_CsmTransGroup as c
  inner join      ZI_CsmTransLedger as l           " ACDOCA 장부 집계(계약집합 단위)
    on  l.Period  = c.Period
    and l.GroupNo = c.GroupNo
{
  key c.Period,
  key c.GroupNo,
      c.CsmCalc,
      l.CsmLedg,
      l.CsmLedg - c.CsmCalc                        as CsmDiff,
      c.FcfTrn + c.CsmCalc                         as LiabCalc,
      l.LiabLedg,
      l.LiabLedg - ( c.FcfTrn + c.CsmCalc )        as LiabDiff,
      c.PrevLiab - ( c.FcfTrn + c.CsmCalc )        as RetCalc,

      " 점검 코드 — 앞에서 걸린 하나만 남긴다
      case
        when c.Approach <> 'FRA' and c.BasisNote  = ''         then 'R01'
        when l.LedgTrnDate <> c.TrnDate                         then 'R02'
        when l.CsmLedg  <> c.CsmCalc                            then 'R03'
        when c.LossCalc <> 0 and l.LossLedg = 0                 then 'R04'
        when l.LiabLedg <> c.FcfTrn + c.CsmCalc                 then 'R05'
        when l.RetLedg  <> c.PrevLiab - ( c.FcfTrn + c.CsmCalc ) then 'R06'
        else 'I00'
      end                                          as CheckCode
}

⑤ 권한 조건(DCL)

집계를 읽는 자리에 권한을 걸어야 합계로 새지 않습니다. 표준 권한 오브젝트 F_BKPF_BUK 의 회사코드로 겁니다.

@EndUserText.label : '전환일 CSM 권한'
@MappingRole : true
define role ZI_CSMTRANSGROUP {
  grant select on ZI_CsmTransGroup
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
    " 포트폴리오별로도 나누려면 회사 오브젝트를 따로 만들어 조건을 더한다(운영 정책).
}

뷰 이름은 모두 스케치입니다. 서비스의 실제 구성은 운영 연결 때 확인해야 하며, 보험 업무 시스템 원천은 SAP 표준 원천이 확인되지 않습니다.

자주 묻는 질문

도입 상담과 데모에서 실제로 받을 만한 질문들입니다. 네 묶음으로 나누어 적었습니다.

숫자와 산식

화면과 조작

OData 서비스와 운영 연결

도입과 운영