확정급여제도 순이자 범주 귀속 점검 — IFRS 18 손익 범주 기록과 순이자 재계산을 한 화면에서 점검

개발 배경 — 이 앱을 사용해야 하는 이유

결산 때마다 퇴직급여 담당자에게 돌아오는 질문은 비슷합니다. 이번 해 순이자는 얼마가 기록됐나, 그 금액이 알맞은 손익 항목에 놓였나, 다시 계산하면 장부와 같은가. 지금은 이 답이 계정 잔액 조회 · 개별 항목 조회 · 보험수리 평가 보고서와 담당자의 엑셀 계산표로 흩어져 있어, 같은 숫자를 세 번 맞춰 보는 일이 반복됩니다.

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익계산서 항목을 영업 · 투자 · 재무 같은 범주로 나누어 보이도록 요구합니다. 확정급여제도의 순이자와 재측정요소가 어느 곳에 기록되어 있는지는 계정 매핑에서 정해지므로, 도입을 준비하는 회사는 ‘지금 장부가 어느 범주로 쌓이고 있는가’를 먼저 점검하게 됩니다. 현재 확정급여제도의 순이자 계산과 재측정요소의 인식은 종업원급여(K-IFRS 제1019호)의 요구에 따릅니다. 이 앱은 그 두 기준서가 만나는 자리를 조회와 점검 관점으로 한 화면에 모았습니다.

순이자는 채무 총액이 아니라 순액에 붙는다

확정급여제도의 순이자는 확정급여채무에서 사외적립자산을 뺀 순확정급여부채(자산)에 할인율을 곱해 구합니다. 그런데 장부에서는 채무 총액에 할인율을 곱한 값이 이자비용으로, 자산 수익이 따로 기록되는 일이 흔합니다. 이렇게 되면 순이자 계정의 금액이 크게 부풀고, 표준 조회로는 계정별 합계만 보이므로 어디서 어긋났는지 찾기 어렵습니다. 이 앱은 제도마다 기초 순확정급여부채를 다시 구해 순이자를 재계산하고 장부와 같은 줄에 놓습니다. 화면의 해외지점 제도는 기초 순확정급여부채 8억 원에 할인율 3.60% 라 재계산 순이자가 월 240만 원인데 장부에는 월 1,500만 원이 기록되어, 연간 +151,200,000원 차이가 한 줄로 드러납니다.

계정 매핑이 한 줄 어긋나면 순이자 전체의 범주가 바뀐다

순이자가 어느 손익 범주에 놓이는지는 제도가 아니라 기록된 계정이 정합니다. 설정에서 순이자 계정이 퇴직급여 같은 영업 계정군에 묶여 있으면 금액이 맞아도 범주는 어긋난 채 매달 쌓입니다. 같은 이유로 재측정요소가 손익 계정에 기록되면 기타포괄손익에 있어야 할 금액이 손익으로 흘러 들어갑니다. 이 앱은 제도마다 순이자와 재측정요소가 놓인 범주를 한 줄에 나란히 보여 주고, 영업범주에 기록된 건에는 점검 필요 표시를 붙입니다.

순확정급여자산은 사람이 판단할 일이다

사외적립자산이 채무보다 커서 순확정급여자산이 되는 제도는 자산으로 인식할 수 있는 한도가 있는지를 회사가 따져야 합니다. 이것이 맞는지는 제도의 약정과 사실관계에 달려 있어 화면이 단정할 수 없습니다. 그래서 이런 건은 오류가 아니라 확인 필요로 따로 세웁니다. 점검 필요는 ‘수치나 분류가 어긋났다’, 확인 필요는 ‘회사가 먼저 판단할 일이다’로 갈립니다.

사용 방법

1. 회계연도(필수)와 회사, 제도 유형, 장부 범주, 할인율 확정일 기간, 제도 이름, 점검 코드, 점검 결과를 정합니다. 선택 조건은 비워 두면 전체입니다.
2. 조회 버튼이나 입력 칸에서 Enter 로 조회합니다. 화면을 처음 열면 한 번 자동으로 조회됩니다.
3. 위쪽 요약에서 점검한 제도 수 · 점검 필요 건수 · 확인 필요 건수 · 영업범주에 기록된 건 · 범주 이동 점검 금액 · 정합성 대사 차이 건수를 봅니다.
4. 탭을 제도별 점검 → 월별 순이자 상세 → 범주별 합계 → 대사 결과 순서로 옮겨 가며 봅니다.
5. 제도별 점검 탭에서 행을 누르면 상세가 열려 기초 순확정급여부채 · 할인율 · 기록 범주 · 점검 사유와 열두 달 순이자 내역이 보입니다.
6. CSV 내려받기로 지금 보고 있는 탭의 내용을 UTF-8 파일로 받아 감사 대응 자료에 첨부합니다.

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

점검 도구에서 가장 비싼 질문은 “이 합계 맞아?” 입니다. 그래서 만드는 쪽에서 대사식을 먼저 세우고 검증용 샘플 데이터로 전수 검증했습니다. 정합성 대사 다섯 가지는 모두 차이 0이고, 참고 대사 한 가지의 차이는 의도적으로 심은 점검 필요 건 때문에 생긴 것이라 정상입니다.

의도적 예외는 순이자가 영업범주에 기록된 건 2건, 장부 순이자와 재계산이 다른 건 2건, 재측정요소가 손익 계정에 기록된 건 1건, 그리고 순확정급여자산이라 확인이 필요한 건 2건입니다. 점검 필요 5건 가운데 영업범주에 놓인 항목은 3개(순이자 2건과 재측정요소 1건)이고, 이 금액을 더하면 137.8백만 원입니다.

무엇으로 만들었나

실행 화면

실제로 돌아가는 화면 5종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 보는 자리인지 아래에 적었습니다. 숫자는 모두 같은 검증용 샘플 데이터에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건 · 요약 · 제도별 점검 표가 한 화면에 세로로 쌓입니다. 처음 열면 한 번 자동으로 조회되므로 별도 조작 없이 12건의 점검 결과가 바로 보입니다.

요약 지표는 점검 필요 5건과 확인 필요 2건을 먼저 보여 주고, 영업범주에 기록된 건 3건과 범주 이동 점검 금액 합계 137.8백만 원, 정합성 대사 차이 0건이 이어집니다. 표에서는 기초 확정급여채무 · 기초 사외적립자산 · 기초 순확정급여부채와 할인율, 재계산 순이자와 장부 순이자, 차이 열을 한 줄에서 읽습니다. 오른쪽 끝 열로 가면 순이자와 재측정요소의 기록 범주가 나옵니다. 기본 회계연도는 2026이고 회사 · 유형 · 범주 조건은 전체입니다.

한 건을 열어 보면

표에서 행을 누르면 그 제도의 상세가 열립니다. 기초 순확정급여부채와 할인율, 순이자가 기록된 범주와 점검 사유가 먼저 나오고, 아래에는 열두 달 순이자 내역이 이어집니다.

행을 누르면 열리는 상세 창입니다. 위쪽에 제도 유형 · 기초 순확정급여부채 · 할인율 · 순이자와 재측정요소의 기록 범주 · 재측정요소 −18,000,000원 · 할인율 확정일 · 순이자 차이가 나오고, 오른쪽 위에는 기말 순확정급여부채 962,000,000원과 점검 결과가 나옵니다. 아래 표는 열두 달의 기록 계정과 재계산 · 장부 순이자를 견줍니다. 이 건은 재계산 2,400,000원에 장부 15,000,000원이 매달 같은 크기로 기록되어 차이 +12,600,000원이 열두 달 이어집니다. 점검 사유는 채무 총액 기준으로 이자를 계산했거나 오래된 할인율이 남아 있는지 확인하라고 안내합니다.

월별로 재계산과 장부를 견주기

월별 순이자 상세 탭은 제도 한 건을 열두 줄로 풀어 보여 줍니다. 조회조건의 제도 이름에 글자를 넣으면 그 제도만 남습니다.

월별 순이자 상세 탭은 한 줄이 한 달입니다. 본사 퇴직연금 DB제도는 기초 순확정급여부채 32억 원에 할인율 4.10% 라 월 재계산이 3,200,000,000 × 4.10% ÷ 12 = 10,933,333원(원 단위 반올림)이고 장부도 같아 차이가 0입니다. 열두 달의 합이 131,199,996원으로 제도별 점검 탭의 연간 장부 순이자와 같습니다. 차이 열이 0 이 아닌 달만 눈으로 찾으면 됩니다.

범주별 합계와 대사 결과

범주별 합계 탭은 영업범주 · 재무범주 · 기타포괄손익에 쌓인 장부 금액을 회사별로 모으고, 대사 결과 탭은 대사식의 검사 건수와 차이 건수를 보여 줍니다.

회사 1000 의 영업범주에는 순이자 98,400,000원과 손익 계정에 기록된 재측정요소 420,000원을 합쳐 98,820,000원이, 회사 2000 에는 39,000,000원이 기록되어 있습니다. 두 금액을 더하면 137.8백만 원으로, 첫 화면 요약의 범주 이동 점검 금액과 같습니다. 합계 줄은 따로 구분되어 있어 범주별 줄과 섞이지 않습니다.

대사 결과 탭은 앞의 다섯 줄이 모두 0 이어야 숫자를 믿고 볼 수 있습니다. 마지막 참고 대사는 회사별 재무범주 금액을 견주는 줄이라 검사 건수가 회사 수와 같은 2이고, 영업범주로 옮겨 기록된 순이자와 차이가 큰 제도 때문에 최대 차이 52,125,000원이 나옵니다. 이 값은 점검 필요 건이 있을 때 정상이며, 점검 필요 건을 고치면 줄어듭니다.

화면 뒤에서 일어나는 일

여기부터는 위 화면들이 어떤 규칙으로 움직이는지를 자리별로 적은 상세입니다.

점검 규칙 — 판정 조건에서 사용자 조치까지

제도 한 건은 아래 순서로 판정해 코드 하나를 받습니다. 판정은 분류 · 집계 · 대사를 돕는 점검 결과이며, 단정하지 않고 “점검 필요” · “확인 필요”로만 표시합니다. 판정 우선순위는 D01, D02, D03, D09 순입니다.

산출과 대사 순서

1. 기초 순확정급여부채 = 기초 확정급여채무 − 기초 사외적립자산. 사외적립자산이 더 크면 음수(순확정급여자산)가 됩니다.
2. 월 재계산 순이자 = 기초 순확정급여부채 × 할인율 ÷ 12 를 원 단위로 반올림합니다. 연간 재계산 순이자는 열두 달의 합계입니다.
3. 순이자 차이 = 장부 순이자 − 재계산 순이자. 장부가 적으면 음수입니다.
4. 기말 순확정급여부채 = 기초 + 장부 순이자 + 재측정요소. 이 화면이 보는 증감만 더한 값이며 근무원가 · 기여금 · 급여 지급은 제외합니다.
5. 범주별 장부 금액은 순이자와 재측정요소를 기록된 범주별로 합산하고, 재계산 기준은 순이자를 재무범주, 재측정요소를 기타포괄손익에 놓습니다.

검증용 샘플 데이터에서 한 건의 예를 들면, 물류센터 퇴직연금 DB제도는 기초 순확정급여부채가 9억 원이고 할인율 4.10% 라 월 재계산 순이자가 3,075,000원입니다. 장부에는 10~12월을 3.80% 로 적용한 금액이 기록되어 그 석 달이 월 −225,000원씩 낮고, 합쳐 연간 −675,000원 차이가 되어 이 건이 D02 로 잡힙니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 조회조건이 두 줄 세 줄로 접히고, 표는 가로로 스크롤됩니다. 상세 창은 화면 폭에 맞춰 줄어듭니다. 요약 지표는 줄을 바꿔 쌓이므로 휴대폰에서도 같은 숫자를 볼 수 있습니다.

파일 구성

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준이 이미 잘하는 일은 표준에 두고, 표준 화면 여러 개를 오가며 손으로 맞추던 대조만 한 화면으로 이어 붙였습니다.

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

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 없애지 않습니다. 이 앱을 운영에 올려도 표준 조회와 결산 절차는 그대로 남고, 이 화면은 그 앞단에서 ‘어디를 열어 볼지’를 정해 주는 점검 단계로 놓입니다.

S/4HANA 분석 스택과의 자리

표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office 는 계정 · 기간 중심의 분석에 강합니다. 이 앱은 그 위에 ‘제도 한 건 단위로 순이자를 재계산하고 범주를 대조하는’ 좁고 깊은 점검 관점을 더합니다. 분석 스택에서 이미 계정 잔액 리포트를 쓰고 있다면, 이 앱의 서비스를 별도 CDS 뷰로 얹어 같은 인증과 권한 체계 안에서 쓸 수 있습니다.

요구사항 매핑표

확장 포인트 — 운영에서 실제로 손대는 자리

CDS 구성 — 최대한 자세히

이 앱의 서비스를 S/4HANA 위에서 운영하려면 아래 순서로 CDS 객체를 쌓습니다. 아래 코드는 구조를 보이기 위한 예시이며, 표준 CDS 뷰 이름과 필드는 시스템 릴리스마다 다를 수 있으므로 실제 이름은 해당 시스템에서 확인이 필요합니다.

뷰 레이어 구성

① 계정 범주 매핑 테이블 — 범주를 데이터로 둔다

이 테이블이 순이자 범주 점검의 기준입니다. 계정이 어느 범주이고, 순이자 계정인지 재측정요소 계정인지를 여기서 정합니다. 매핑이 틀리면 점검 결과 전체가 틀리므로, 운영에서는 이 테이블의 변경 이력과 책임자를 가장 먼저 정합니다.

@EndUserText.label : '확정급여제도 순이자 계정 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpdb_acctcat {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key racct      : racct not null;
  cat_code       : abap.char(4) not null;  " OPER 영업 / FIN 재무 / OCI 기타포괄손익
  acct_kind      : abap.char(1) not null;  " I 순이자 / R 재측정요소
  valid_from     : abap.dats;
}

② 제도 기준 테이블 — 회사가 입력하는 값

기초 채무와 기초 사외적립자산, 할인율은 보험수리 평가 결과를 회사가 확정해 넣는 값입니다. 원장에서 계산해 낼 수 있는 값이 아니므로 별도 테이블로 두고, 확정일을 함께 적어 어느 시점의 할인율인지 추적합니다.

@EndUserText.label : '확정급여제도 기준 값'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpdb_planmst {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key gjahr      : gjahr not null;
  key plancode   : abap.char(4) not null;
  planname       : abap.char(60);
  kindcode       : abap.char(4);           " FUND 기금형 / UNFD 비적립 / OVRS 해외
  open_dbo       : abap.curr(23,2);        " 기초 확정급여채무
  open_asset     : abap.curr(23,2);        " 기초 사외적립자산
  disc_rate      : abap.dec(5,2);          " 할인율(%)
  basis_date     : abap.dats;              " 할인율 확정일
  waers          : waers;
}

③ 기본 뷰 — 원천 읽기를 한 곳에

원장에서 순이자와 재측정요소 계정의 금액을 월별로 읽어 매핑 테이블과 붙입니다. 이 뷰가 원천을 읽는 유일한 자리이며, 뒤의 뷰는 모두 이 뷰만 봅니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '확정급여제도 순이자 점검 - 기본'
define view entity ZI_DbNetIntBase
  as select from I_JournalEntryItem as j        -- 표준 CDS 뷰 이름은 확인 필요
  inner join zpdb_acctcat as m
    on  m.bukrs = j.CompanyCode
    and m.racct = j.GLAccount
{
  key j.CompanyCode,
  key j.FiscalYear,
  key j.GLAccount,
  key j.AccountingDocument,
  key j.LedgerGLLineItem,
      j.PostingDate,
      substring(j.PostingDate, 5, 2)          as Period,
      m.cat_code                              as CatCode,
      m.acct_kind                             as AcctKind,
      @Semantics.amount.currencyCode: 'Currency'
      j.AmountInCompanyCodeCurrency           as Amount,
      j.CompanyCodeCurrency                   as Currency
}
where j.Ledger = '0L'                           -- 주 원장만 읽음. 값은 확인 필요

④ 큐브 뷰 — 제도 × 월 × 범주 집계

기본 뷰의 전표 줄을 제도와 월과 범주로 모읍니다. 화면의 월별 순이자 상세와 범주별 합계가 모두 이 집계에서 나오므로 두 탭의 합계가 어긋나지 않습니다. 계정과 제도를 잇는 키(여기서는 코스트 오브젝트 대신 지정 필드)는 회사의 전기 방식에 따라 정해야 합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '확정급여제도 순이자 점검 - 큐브'
define view entity ZI_DbNetIntCube
  as select from ZI_DbNetIntBase as b
  inner join zpdb_planmst as p
    on  p.bukrs = b.CompanyCode
    and p.gjahr = b.FiscalYear
{
  key b.CompanyCode,
  key b.FiscalYear,
  key p.plancode                                as PlanCode,
  key b.Period,
  key b.CatCode,
  key b.AcctKind,
      @Semantics.amount.currencyCode: 'Currency'
      sum(b.Amount)                             as BookedAmt,
      b.Currency
}
group by b.CompanyCode, b.FiscalYear, p.plancode, b.Period,
         b.CatCode, b.AcctKind, b.Currency

⑤ 점검 뷰 — 재계산과 판정을 한곳에

기초 순확정급여부채를 구하고, 월 재계산 순이자와 연간 합계를 만들고, 장부와 견주어 점검 코드를 정합니다. 판정 우선순위를 case 문 순서로 그대로 적었으므로 규칙을 하나 더하려면 이 뷰에 조건 하나를 더하면 됩니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '확정급여제도 순이자 점검 - 판정'
define view entity ZI_DbNetIntCheck
  as select from zpdb_planmst as p
  association [0..*] to ZI_DbNetIntCube as _Cube
    on  _Cube.CompanyCode = p.bukrs
    and _Cube.FiscalYear  = p.gjahr
    and _Cube.PlanCode    = p.plancode
{
  key p.bukrs                                   as CompanyCode,
  key p.gjahr                                   as FiscalYear,
  key p.plancode                                as PlanCode,
      p.planname                                as PlanName,
      p.open_dbo - p.open_asset                 as OpenNet,
      -- 월 재계산 순이자 = 순부채 × 할인율 ÷ 12 (원 단위 반올림, 12개월 합)
      cast( round( ( p.open_dbo - p.open_asset ) * p.disc_rate / 1200, 0 ) * 12
            as abap.curr(23,2) )                 as ExpectInt,
      p.disc_rate                               as DiscRate,
      case
        when _Cube.CatCode = 'OPER' and _Cube.AcctKind = 'I' then 'D01'
        when ( p.open_dbo - p.open_asset ) <> 0 /* 차이 조건은 연간 합 비교로 대체 */ then 'D02'
        when _Cube.CatCode <> 'OCI' and _Cube.AcctKind = 'R' then 'D03'
        when p.open_asset > p.open_dbo then 'D09'
        else 'D00'
      end                                       as CheckCode,
      _Cube
}

⑥ 쿼리 뷰 — 화면이 보는 컬럼과 필터

화면의 조회조건과 결과 컬럼을 소비 계층에 선언합니다. 필수 조건인 회계연도는 파라미터 대신 필터로 두어 OData 요청의 $filter 에 그대로 실리게 합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '확정급여제도 순이자 점검 - 화면'
@Metadata.allowExtensions: true
define view entity ZC_DbNetIntCheck
  as projection on ZI_DbNetIntCheck
{
  key CompanyCode,
  key FiscalYear,
  key PlanCode,
      PlanName,
      OpenNet,
      DiscRate,
      ExpectInt,
      CheckCode,
      _Cube
}

⑦ 권한 — 집계 이전에 건다

회사코드 권한을 쿼리 뷰에 걸어 허용된 회사의 줄만 집계되게 합니다. 합계 줄에서 다른 회사 숫자를 뺄셈으로 짐작하지 못하게 하려면 드릴다운에만 권한을 거는 방식은 피합니다.

@EndUserText.label: '확정급여제도 순이자 점검 - 권한'
@MappingRole: true
define role ZC_DbNetIntCheck {
  grant select on ZC_DbNetIntCheck
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 부르는 단일 문

쿼리 뷰를 엔티티셋으로 올려 OData V2 서비스로 게시합니다. 이 글의 화면은 같은 이름의 엔티티셋 네 개(제도 · 월별 · 범주 · 대사)와 점검 필요 건수를 돌려주는 함수 하나를 호출하며, 운영에서는 서비스 주소만 바꾸면 됩니다.

@EndUserText.label: '확정급여제도 순이자 점검 서비스'
define service ZUI_DbNetIntCheck {
  expose ZC_DbNetIntCheck as PlanSet;
  expose ZI_DbNetIntCube  as LineSet;
  -- 범주 합계와 대사 결과는 별도 뷰로 만들어 같은 서비스에 노출 (이름은 확인 필요)
}

운영 시점에 해야 할 일

코드는 구조일 뿐이고 숫자를 믿게 만드는 일은 합의입니다. 아래는 실제 시스템에 올릴 때 개발 전에 정해야 하는 항목입니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문을 네 묶음으로 나눠 적었습니다.

숫자와 산식

화면과 조작

기준서와 범주

도입과 운영