SAP 사업결합 취득 보험계약 최초 측정 점검 — IFRS 17, 취득일 공정가치와 이행현금흐름의 차이를 CSM·손실요소로 나눠 영업권까지 장부와 맞춰본다

이행현금흐름은 어떻게 계산합니까?

미래 유출 현재가치 − 미래 유입 현재가치 + 위험조정입니다. 현재가치와 위험조정은 취득일 계리 평가 결과에서 받고, 이 앱은 그 세 값으로 계약 묶음마다 식을 다시 계산한 뒤 집단 · 취득건 순서로 더합니다.

장부 이행현금흐름은 별도로 읽어 재계산 값과 비교합니다. 둘이 0.1 백만원 이상 다르면 해당 집단을 점검 필요로 올립니다. 할인율과 위험조정을 어떻게 산정했는지는 평가 쪽 설계이므로 화면이 판단하지 않습니다(확인 필요).

공정가치보다 이행현금흐름이 크면 어떻게 됩니까?

그 집단은 CSM 이 0 이고 모자란 만큼이 손실요소가 됩니다. 이 앱은 공정가치에서 이행현금흐름을 뺀 차이가 0 보다 작으면 그 크기를 손실요소로 올리고, 취득일 부채를 공정가치 + 손실요소로 계산합니다.

손실요소를 당기손익이 아니라 영업권(또는 염가매수차익) 쪽에 반영한다는 처리가 이 점검의 핵심입니다. 반영의 세부와 예외는 기준서 원문으로 확인할 사항이며 화면은 그 판단을 대신하지 않습니다(확인 필요).

영업권은 어떻게 다시 계산합니까?

이전대가 − 보험계약 외 식별가능순자산 + Σ 취득일 보험계약부채입니다. 이전대가와 식별가능순자산은 사업결합 정산 자료에서, 취득일 보험계약부채는 집단 측정(공정가치 + 손실요소)에서 옵니다.

이 식의 결과를 장부 영업권과 비교해 다르거나 하위 집단에 점검 필요가 있으면 그 취득건을 점검 필요로 올립니다. 샘플에서는 취득건 3건 가운데 2건이 이렇게 올라옵니다.

허용 오차 0.1 백만원은 무엇입니까?

장부와 재계산을 같다고 볼 금액 기준입니다. 소수 첫째 자리까지 다루는 금액에서 반올림 때문에 생기는 작은 차이를 점검 필요로 올리지 않으려고 둔 샘플 값입니다.

실제 기준은 회사 정책에 따라 정하며, 운영에서는 코드에 박지 않고 파라미터로 둡니다. 너무 크게 잡으면 진짜 차이를 놓치고 너무 작게 잡으면 반올림 차이가 점검 필요로 쏟아집니다(확인 필요).

“점검 필요”가 나오면 장부가 틀렸다는 뜻입니까?

아닙니다. 차이가 확인되었다는 뜻일 뿐 원인이나 오류 여부를 단정하지 않습니다. 재계산 쪽의 평가 결과가 달라졌을 수도 있고, 장부 쪽 분개가 달랐을 수도 있습니다.

그래서 점검 내용 컬럼도 “빠진 것으로 보임” 같은 표현을 씁니다. 화면은 차이가 난 자리와 금액을 짚고, 왜 생겼는지는 회사와 감사인이 확인합니다.

대사 8종 가운데 두 쌍이 늘 같은 크기로 걸리는 이유는 무엇입니까?

같은 원인이 두 곳에 비치기 때문입니다. 장부 이행현금흐름에서 위험조정이 빠지면 이행현금흐름 대조에서 그만큼 차이가 나고, 같은 금액만큼 장부 CSM 이 커져 CSM 대조에서도 같은 크기로 걸립니다. 샘플에서 두 대사 모두 차이 2건, 최대 1,940.8 입니다.

손실요소가 영업권에 반영되지 않은 경우도 같아서, 반영 손실요소 대조와 영업권 대사가 같은 310.9 로 걸립니다. 한 쌍을 하나의 원인으로 읽는 것이 맞습니다.

금액 단위와 소수점은 어떻게 됩니까?

금액은 백만원 단위이고 소수 첫째 자리까지 다룹니다. 화면과 CSV 는 천 단위 구분 기호를 붙여 표시하고(예 309,344.0), 차이 컬럼은 부호를 함께 적습니다.

정합성 대사의 좌변 · 우변 합계와 최대 차이는 소수 둘째 자리까지 보여 줍니다. 샘플은 금액이 모두 가상이며 단위만 실제 업무와 같게 맞췄습니다.

처음 열면 무엇이 조회되어 있습니까?

회계연도 2026, 기간 전체 조건으로 한 번 자동 조회된 상태로 열립니다. 요약 지표와 첫 탭(취득건별 영업권 대사)이 채워져 있어 조회 버튼을 누르지 않아도 바로 읽을 수 있습니다.

조건을 바꾸면 조회 버튼을 누르거나 회계연도 칸에서 Enter 를 누릅니다. 초기화 버튼은 조건을 처음 상태로 되돌리고 다시 조회합니다.

조회조건의 “전체”는 어떻게 처리됩니까?

그 조건을 만들지 않습니다. 전체를 뜻하는 코드값을 서비스로 보내지 않고, 선택이 “전체”면 필터 자체가 없습니다. 서비스마다 전체 코드를 다르게 해석하는 일을 피하기 위해서입니다.

회계연도만 필수이고 나머지는 모두 선택입니다.

취득일 범위 조건은 어떻게 걸러집니까?

서비스가 날짜 조건을 직접 처리합니다. 취득일 시작을 2026-08-01 로 두면 해당일 이후 집단만, 종료를 2026-08-31 로 두면 그 이전 집단만 남고, 범위 밖이면 0건이 나옵니다.

날짜 형식은 서비스 구현마다 다르게 다뤄지기 쉬워 조건이 조용히 무시되는 사고가 흔합니다. 그래서 양쪽 방향과 범위 밖을 모두 따로 시험했습니다.

행을 누르면 무엇이 열립니까?

집단 탭과 계약 묶음 탭에서 행을 누르면 집단 상세 창이 열립니다. 집단의 측정 값 · 장부와 재계산의 차이 · 점검 내용이 위에, 그 집단의 계약 묶음 명세가 아래에 나옵니다.

표에서는 컬럼이 많아 옆으로 밀어야 보이는 값들을 한 창에 모은 것입니다. 창은 오른쪽 아래 닫기 버튼으로 닫습니다.

CSV 는 화면에 보이는 표와 같습니까?

같습니다. 현재 탭의 조회 결과를 화면 컬럼 이름과 표시 형식 그대로 UTF-8 CSV 로 내려받습니다. 점검 결과나 수익성 구분도 화면에 보이는 한글 표기로 나옵니다.

감사인이나 상급자에게 화면과 같은 표를 줄 수 있어야 한다는 이유로 이렇게 했습니다.

서비스에 연결하지 못하면 어떻게 보입니까?

빈 화면이 아니라 안내 창이 뜹니다. 구성 정보를 읽지 못한 경우와 요청이 실패한 경우를 구분해 알려 주고, 연결이 되지 않는 환경에서는 일정 시간 뒤 서비스 연결 확인을 안내합니다.

“데이터가 없다”와 “서비스에 닿지 못했다”를 같은 빈 표로 보이지 않게 하려는 것입니다.

어떤 기준서의 어떤 요구사항을 점검합니까?

IFRS 17 보험계약(K-IFRS 제1117호)에서 사업결합으로 취득한 보험계약을 취득일에 처음 측정하는 요구사항을 점검합니다. 취득일 공정가치를 보험료 대용으로 보고 이행현금흐름과의 차이를 CSM 또는 손실요소로 나눈 뒤, 손실요소가 영업권 쪽에 반영되었는지를 장부와 맞춰 봅니다.

영업권은 IFRS 3 사업결합(K-IFRS 제1103호)과 이어집니다. 문단 단위 요구사항은 원문으로 확인할 사항이라 이 글은 요구사항 명칭까지만 적습니다.

적용 시기와 범위는 어떻게 됩니까?

기준서의 적용 시기와 경과규정은 원문으로 확인할 사항이며 이 화면은 적용 시기를 판단하지 않습니다(확인 필요). 화면은 이미 정리된 취득일 평가 결과를 받아 다시 계산하고 장부와 대조하는 조회 도구입니다.

적용 범위도 사업결합으로 취득한 보험계약에 한정됩니다. 일반 발행 계약의 최초 인식이나 보험료배분접근법 계약은 이 화면이 다루지 않습니다.

이 화면이 회계 처리를 확정해 줍니까?

아닙니다. 분류 · 집계 · 대사를 돕는 점검 도구이며, 취득한 보험계약의 공정가치 · 이행현금흐름 · CSM 과 손실요소 처리에 대한 최종 판단은 회사와 감사인이 합니다. 화면의 “점검 필요”는 차이가 확인된 항목이라는 뜻이며 원인을 단정하지 않습니다.

샘플의 허용 오차와 수익성 구분 규칙도 회사 정책으로 대체해야 합니다.

SAP 표준 T-code 와는 어떤 관계입니까? 기존 리포트를 없애야 합니까?

없애지 않습니다. 표준 실행과 전기는 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 원장 잔액을 보는 FAGLB03, 개별 항목을 여는 FAGLL03, 전표를 읽는 FB03 는 그대로 두고, 앱에서 “점검 필요”가 뜬 집단의 원천을 그쪽에서 확인합니다.

법정 · 감사 대응 자료는 표준 거래에서 뽑는 편이 안전합니다.

보험 전용 솔루션이 이미 있으면 이 화면은 필요 없습니까?

측정 엔진은 보통 그쪽에 있고, 이 화면은 그 결과를 다시 계산해 장부와 맞춰 보는 자리입니다. 엔진이 있어도 취득건 → 집단 → 계약 묶음 순서로 영업권까지 맞물려 있는지를 사람이 한 번 훑어볼 화면은 따로 필요한 경우가 많습니다.

엔진 결과를 평가 결과 적재 테이블에 같은 모양으로 받아 오기만 하면 위쪽 계산 뷰는 그대로 씁니다.

누가 어떤 상황에서 쓰는 화면입니까?

인수 직후 마감을 맡은 회계팀과 계리팀이 주 사용자입니다. 계리에서 받은 평가 결과, 사업결합 정산 자료, 장부를 엑셀 한 통에 모아 맞추던 일을 한 화면으로 옮깁니다. 감사 대응 때는 같은 화면을 띄워 집단 → 묶음으로 내려가며 설명할 수 있습니다.

인수 건이 한두 건이면 효과가 작고, 여러 건이 연달아 생기는 회사일수록 같은 표를 건마다 복제하는 부담이 줄어듭니다.

샘플 데이터는 실제 자료입니까?

아닙니다. 피취득자 · 집단 · 금액은 모두 가상이며 검증용 샘플 데이터입니다. 피취득자 이름에도 “(가상)”을 붙였습니다.

운영 연결 시에는 앱 설정의 서비스 주소만 실제 서비스로 바꾸면 됩니다. 샘플에서 일부러 심어 둔 점검 대상 3건은 점검 흐름을 보여 주려는 것입니다.

운영에 연결하려면 무엇이 필요합니까?

순서는 평가 결과 적재 → 계정 역할 매핑 → 계산 뷰 → 서비스 게시 → 서비스 활성화 → 주소 교체입니다. 개발 자체보다 집단 구분 기준과 평가 결과 원천 · 손실요소 반영 방식 · 허용 오차를 정하는 합의에 시간이 걸립니다.

합의가 끝난 뒤의 기술 작업은 뷰 몇 벌을 만들고 올리는 일로, 이 글의 CDS 구성에 코드를 공개해 두었습니다. 소요 기간은 회사의 원천 시스템과 합의 속도에 따라 크게 달라지므로 확인 필요입니다.

권한과 보안은 어떻게 걸어야 합니까?

집계를 읽는 뷰에 걸어야 합니다. 상세 행에만 권한을 걸면 전체 합계에서 보이는 행을 빼는 식으로 안 보이는 행의 크기를 짐작할 수 있기 때문입니다. 스케치에서는 회사코드 권한을 집단 측정 뷰에 걸었습니다.

인수 협상 중인 건처럼 담당 밖에 보이면 곤란한 숫자가 있다면 취득건 단위 제한을 한 줄 더합니다. 평가 결과 적재 테이블의 변경 권한은 따로 최소화합니다.

대용량에서도 쓸 수 있습니까?

이 앱이 다루는 단위는 집단과 보장개시 연도로 묶은 계약 묶음이라 행 수가 크지 않은 점검 화면입니다. 무거워지는 곳은 원장에서 장부 값을 집단 배정별로 읽는 부분인데, 이 집계를 화면이 아니라 CDS 뷰에서 하고 계정 · 기간 · 회사코드 조건을 반드시 걸어 읽습니다.

표는 서버 쪽 정렬과 페이징으로 읽으므로 건수가 늘어도 처음 받는 양이 일정합니다. 응답 시간 기준은 회사가 정합니다(확인 필요).

집단 구분 기준이나 계정 체계가 바뀌면 어떻게 됩니까?

계정은 계정 역할 매핑 테이블에 유효기간과 함께 두므로, 계정이 늘거나 바뀌어도 매핑 한 줄을 고치면 됩니다. 과거 취득건은 옛 유효기간의 매핑으로 읽혀 점검 결과가 흔들리지 않습니다.

집단 구분 기준이 바뀌면 평가 결과를 적재하는 단계의 규칙을 고칩니다. 이미 점검이 끝난 취득건을 새 기준으로 다시 읽을지는 회사의 정책 결정입니다.

서비스는 어떤 구조로 되어 있습니까?

OData V2 서비스 하나를 화면이 모델로 받습니다. 탭마다 한 컬렉션에 표를 직접 바인딩하고, 조회조건은 표준 필터 객체로 만들어 $filter 로, 정렬과 스크롤은 $orderby · $top · $skip 으로 서비스에 전달합니다.

판정과 재계산은 서비스 로직이 하고 화면은 결과만 그립니다. 같은 서비스를 배치나 다른 화면이 불러도 같은 판정이 나옵니다.