충당부채 할인 풀림 범주 귀속 점검 — IFRS 18 손익 범주 기록과 풀림 재계산을 한 화면에서 점검

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

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

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익계산서 항목을 영업 · 투자 · 재무 같은 범주로 나누어 보이도록 요구합니다. 충당부채의 시간 경과에 따른 할인 풀림과 할인율 변동 효과가 어느 범주에 기록되어 있는지는 계정 매핑에서 정해지므로, 도입을 준비하는 회사는 ‘지금 장부가 어느 범주로 쌓이고 있는가’를 먼저 점검하게 됩니다. 현재 충당부채의 현재가치 할인과 풀림은 충당부채, 우발부채 및 우발자산(K-IFRS 제1037호)의 요구에 따라 계산합니다. 이 앱은 그 두 기준서가 만나는 자리를 조회와 점검 관점으로 한 화면에 모았습니다.

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

풀림이 어느 손익 범주에 놓이는지는 충당부채가 아니라 기록된 계정이 정합니다. 설정에서 풀림 계정이 영업 계정군에 묶여 있으면 금액이 맞아도 범주는 어긋난 채 매달 쌓입니다. 표준 조회로는 계정별 합계만 보이므로 ‘이 계정이 어느 범주인가’를 따로 대조해야 하고, 충당부채가 수십 건이면 이 대조가 결산 일정의 병목이 됩니다. 이 앱은 충당부채마다 풀림과 할인율 변동 효과가 놓인 범주를 한 줄에 나란히 보여 주고, 영업범주에 기록된 건에는 점검 필요 표시를 붙입니다.

금액이 맞아도 할인율이 다르면 장부는 틀린다

풀림은 기초 잔액에 할인율을 곱해 달마다 인식합니다. 할인율 개정을 월 중에 반영하거나 이전 율이 그대로 남아 있으면 장부 풀림과 다시 계산한 값이 조금씩 벌어집니다. 이 앱은 월마다 기초 잔액 × 할인율 ÷ 12를 원 단위로 반올림해 다시 계산하고 장부 금액과 같은 줄에 놓습니다. 차이가 있는 달은 차이 열에서 바로 찾을 수 있고, 한 건의 연간 차이는 열두 달 차이의 합과 같아야 한다는 대사식이 그 계산을 지켜봅니다.

할인 적용 여부는 사람이 판단할 일이다

할인 효과가 크지 않다고 보아 할인율을 적용하지 않은 충당부채가 있을 수 있습니다. 이것이 맞는지는 회사의 정책과 사실관계에 달려 있어 화면이 단정할 수 없습니다. 그래서 이런 건은 오류가 아니라 확인 필요로 따로 세웁니다. 점검 필요는 ‘수치나 분류가 어긋났다’, 확인 필요는 ‘회사가 먼저 판단할 일이다’로 갈립니다.

사용 방법

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

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

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

의도적 예외는 풀림이 영업범주에 기록된 건 2건, 장부 풀림과 재계산이 다른 건 1건, 할인율 변동 효과만 영업범주에 기록된 건 1건, 그리고 할인 미적용으로 확인이 필요한 건 1건입니다. 점검 필요 4건은 참고 대사의 차이 4건과 같습니다.

무엇으로 만들었나

실행 화면

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

처음 열었을 때

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

요약 지표는 점검 필요 4건과 확인 필요 1건을 먼저 보여 주고, 영업범주에 기록된 건 3건과 재무범주 이동 점검 금액 합계 218.5백만 원, 정합성 대사 차이 0건이 이어집니다. 표에서는 풀림 범주 · 할인율 변동 효과 · 변동 효과 범주 열을 보면 어느 건이 영업범주에 놓였는지 바로 찾을 수 있습니다. 기본 회계연도는 2026이고 회사 · 유형 · 범주 조건은 전체입니다.

한 건을 열어 보면

표에서 행을 누르면 그 충당부채의 상세가 열립니다. 기초 잔액과 할인율, 풀림이 기록된 범주와 점검 사유가 먼저 나오고, 아래에는 열두 달 풀림 내역이 이어집니다.

행을 누르면 열리는 상세 창입니다. 위쪽에 기초 잔액 · 할인율 · 풀림과 변동 효과의 기록 범주 · 확정일 · 풀림 차이가 나오고, 아래 표에서 열두 달의 기록 계정과 재계산 · 장부 풀림을 견줍니다. 이 건은 풀림 126,000,000원이 영업범주 계정에 기록되어 있어 점검 필요로 표시되며, 월 10,500,000원씩 재계산과 장부가 같은 점도 함께 읽을 수 있습니다.

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

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

월별 풀림 상세 탭은 기록 계정과 기록 범주, 기초 잔액, 적용 할인율, 재계산 풀림, 장부 풀림, 차이를 열두 줄로 보여 줍니다. 이 건은 재계산 3,750,000원에 장부 3,375,000원이라 매달 −375,000원이고, 열두 달의 합이 연간 −4,500,000원 차이입니다. 차이 열의 값이 0 이 아닌 달만 눈으로 찾으면 됩니다.

범주별 합계와 대사 결과

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

회사 1000 의 영업범주에는 풀림과 변동 효과를 합쳐 201,000,000원이, 회사 2000 에는 17,499,996원이 기록되어 있습니다. 두 금액을 더하면 218.5백만 원으로, 첫 화면 요약의 재무범주 이동 점검 금액과 같습니다. 합계 줄은 따로 구분되어 있어 범주별 줄과 섞이지 않습니다.

대사 결과 탭은 대사식마다 왼쪽 값과 오른쪽 값, 검사 건수, 차이 건수, 최대 차이를 보여 줍니다. 앞의 네 줄이 모두 0 이어야 숫자를 믿고 볼 수 있고, 마지막 참고 대사의 차이 건수가 점검 필요 건수 4와 같은지를 함께 확인합니다.

화면 뒤에서 일어나는 일

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

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

충당부채 한 건은 아래 순서로 판정해 코드 하나를 받습니다. 판정은 분류 · 집계 · 대사를 돕는 점검 결과이며, 단정하지 않고 “점검 필요” · “확인 필요”로만 표시합니다.

산출과 대사 순서

1. 월 재계산 풀림 = 기초 잔액 × 할인율 ÷ 12 를 원 단위로 반올림합니다. 연간 재계산 풀림은 열두 달의 합계입니다.
2. 풀림 차이 = 장부 풀림 − 재계산 풀림. 장부가 적으면 음수입니다.
3. 기말 잔액 = 기초 잔액 + 장부 풀림 + 할인율 변동 효과. 이 화면이 보는 증감만 더한 값입니다.
4. 범주별 장부 금액은 풀림과 변동 효과를 기록된 범주별로 합산하고, 재계산 기준은 모두 재무범주로 놓습니다.

검증용 샘플 데이터에서 한 건의 예를 들면, 리콜 보증충당부채는 기초 잔액 15억 원에 할인율 3.00% 라 월 재계산 풀림이 3,750,000원인데 장부에는 2.70% 를 적용한 3,375,000원이 기록되어 있습니다. 월 −375,000원이 열두 달 쌓여 연간 −4,500,000원 차이가 되고, 이 건이 U02 로 잡힙니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

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

파일 구성

앱 폴더
├─ index.html · readme.html · Component.js · manifest.json
├─ controller/   화면 제어 (공통 · 메인)
├─ view/         메인 화면 · 상세 창
├─ model/        표시 형식 · 오류 처리
├─ css/ · i18n/  스타일 · 문구
├─ odata/        서비스 정의와 구현 · 검증용 샘플 데이터
└─ media/        소개 영상 · 포스터

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 zprv_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 재무범주
  acct_kind      : abap.char(1) not null;  " U 풀림 / R 할인율 변동 효과
  valid_from     : abap.dats;
}

② 충당부채 기준 테이블 — 회사가 입력하는 값

기초 잔액과 할인율은 원장에서 나오지 않는 회사 입력입니다. 확정일을 함께 받아 두면 ‘어느 시점의 할인율로 계산했는가’를 점검 결과에 남길 수 있습니다.

@EndUserText.label : '충당부채 기준 (기초 잔액 · 할인율)'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table zprv_master {
  key client     : abap.clnt not null;
  key gjahr      : gjahr not null;
  key bukrs      : bukrs not null;
  key prov_code  : abap.char(6) not null;
  prov_name      : abap.char(60);
  kind_code      : abap.char(4);           " 복구 · 보증 · 소송 · 손실부담계약
  @Semantics.amount.currencyCode : 'zprv_master.waers'
  open_amt       : abap.curr(23,2);
  disc_rate      : abap.dec(5,2);          " 연 % 단위
  basis_date     : abap.dats;
  waers          : waers;
  unwind_racct   : racct;                  " 이 충당부채의 풀림 기록 계정
}

③ 기본 뷰 — 풀림 계정의 월별 금액

원장 라인에서 매핑 테이블에 있는 계정만 골라 충당부채 · 월 단위로 읽습니다. 표준 CDS 뷰 이름은 확인이 필요하므로 원천은 ACDOCA 필드 기준으로 적었습니다.

" ─── ZI_ProvUnwindBase ───────────────────────────────────────────
" 역할 : 풀림 · 변동 효과 계정의 월별 장부 금액을 한 곳에서 읽는다.
" 나눈 이유 : 큐브와 점검 뷰가 같은 원천 읽기를 공유해야 합계가 갈라지지 않는다.
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '충당부채 풀림 - 기본'
define view entity ZI_ProvUnwindBase
  as select from acdoca as j
    inner join zprv_acctcat as m
      on  m.bukrs = j.rbukrs
      and m.racct = j.racct
    inner join zprv_master as p
      on  p.bukrs = j.rbukrs
      and p.gjahr = j.gjahr
      and p.unwind_racct = j.racct
{
  key j.rbukrs                       as CompanyCode,
  key j.gjahr                        as FiscalYear,
  key p.prov_code                    as ProvCode,
  key j.poper                        as PostingPeriod,
      m.cat_code                     as CatCode,
      m.acct_kind                    as AcctKind,
      j.racct                        as GLAccount,
      @Semantics.amount.currencyCode : 'Currency'
      j.hsl                          as BookedAmount,
      j.rhcur                        as Currency
}
where j.rldnr = '0L'

④ 큐브 — 충당부채 × 월 × 범주 집계

풀림과 할인율 변동 효과를 같은 큐브에서 case 로 갈라 합산합니다. 화면의 월별 탭과 범주별 탭이 이 큐브 한 곳에서 나오므로 두 탭의 합계가 서로 어긋날 자리가 없습니다.

" ─── ZI_ProvUnwindCube ───────────────────────────────────────────
" 역할 : 충당부채 · 월 · 범주 단위로 풀림과 변동 효과를 집계한다.
" 나눈 이유 : 탭마다 따로 집계하면 같은 질문에 다른 답이 나온다.
@AbapCatalog.viewEnhancementCategory : [#NONE]
@Analytics.dataCategory : #CUBE
@EndUserText.label : '충당부채 풀림 - 큐브'
define view entity ZI_ProvUnwindCube
  as select from ZI_ProvUnwindBase
{
  key CompanyCode,
  key FiscalYear,
  key ProvCode,
  key PostingPeriod,
  key CatCode,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case AcctKind when 'U' then BookedAmount else cast( 0 as abap.curr(23,2) ) end ) as UnwindAmount,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case AcctKind when 'R' then BookedAmount else cast( 0 as abap.curr(23,2) ) end ) as RateChgAmount,
      Currency
}
group by CompanyCode, FiscalYear, ProvCode, PostingPeriod, CatCode, Currency

⑤ 점검 뷰 — 재계산과 코드 판정

점검 규칙이 가장 바뀌기 쉬운 자리이므로 한 뷰에 모았습니다. 재계산은 월 단위로 하고, 열두 달의 합이 연간 재계산 풀림이 됩니다. 판정 순서는 U01 → U03 → U02 → U09 → U00 입니다.

" ─── ZI_ProvUnwindCheck ──────────────────────────────────────────
" 역할 : 재계산 풀림 · 차이 · 점검 코드를 만든다.
" 나눈 이유 : 판정 규칙을 한 곳에 두면 화면 · 배치 · 보고서가 같은 답을 받는다.
@AbapCatalog.viewEnhancementCategory : [#NONE]
@EndUserText.label : '충당부채 풀림 - 점검'
define view entity ZI_ProvUnwindCheck
  as select from zprv_master as p
    inner join ZI_ProvUnwindCube as c
      on  c.CompanyCode = p.bukrs
      and c.FiscalYear  = p.gjahr
      and c.ProvCode    = p.prov_code
{
  key p.gjahr      as FiscalYear,
  key p.bukrs      as CompanyCode,
  key p.prov_code  as ProvCode,
      p.prov_name  as ProvName,
      p.open_amt   as OpenAmount,
      p.disc_rate  as DiscRate,
      @Semantics.amount.currencyCode : 'Currency'
      sum( c.UnwindAmount )  as BookedUnwind,
      @Semantics.amount.currencyCode : 'Currency'
      cast( round( p.open_amt * p.disc_rate / 1200, 0 ) * 12 as abap.curr(23,2) ) as ExpectUnwind,
      case
        when max( case c.CatCode when 'OPER' then 1 else 0 end ) = 1 then 'U01'
        when p.disc_rate = 0                                         then 'U09'
        else 'U00'
      end as CheckCode,
      c.Currency
}
group by p.gjahr, p.bukrs, p.prov_code, p.prov_name, p.open_amt, p.disc_rate, c.Currency

⑥ 분석 쿼리 · Consumption 뷰 — 화면이 쓰는 모양

조회조건과 결과 컬럼을 소비 계층에서 선언합니다. 화면의 조회조건은 이 필터 선언과 이름이 같아야 하며, 날짜 범위는 한 묶음의 범위 필터로 선언합니다.

" ─── ZC_ProvUnwindCheck ──────────────────────────────────────────
" 역할 : 조회조건 · 결과 컬럼 선언
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '충당부채 풀림 범주 점검'
@Metadata.allowExtensions : true
@VDM.viewType : #CONSUMPTION
define view entity ZC_ProvUnwindCheck
  as projection on ZI_ProvUnwindCheck
{
      @Consumption.filter : { mandatory : true, selectionType : #SINGLE }
  key FiscalYear,
      @Consumption.filter.selectionType : #SINGLE
  key CompanyCode,
  key ProvCode,
      @UI.lineItem : [{ position : 10 }]
      ProvName,
      @UI.lineItem : [{ position : 20 }]
      OpenAmount,
      @UI.lineItem : [{ position : 30 }]
      DiscRate,
      @UI.lineItem : [{ position : 40 }]
      ExpectUnwind,
      @UI.lineItem : [{ position : 50 }]
      BookedUnwind,
      @UI.lineItem : [{ position : 60, criticality : 'CheckCrit' }]
      CheckCode,
      Currency
}

⑦ 접근 제어 — 집계 이전에 권한을 건다

회사코드 권한을 집계 단계의 뷰에 겁니다. 드릴다운이나 합계에서만 권한을 확인하면 합계에서 뺄셈으로 다른 회사 숫자를 짐작할 수 있기 때문입니다.

" ─── DCL : ZC_ProvUnwindCheck ───────────────────────────────────
@EndUserText.label : '충당부채 풀림 점검 - 회사코드 권한'
@MappingRole : true
define role ZC_ProvUnwindCheck {
  grant select on ZC_ProvUnwindCheck
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

화면이 부르는 서비스는 소비 뷰 하나를 노출합니다. 바인딩을 게시하면 OData V2 주소가 생기고, 그 주소를 화면 설정의 서비스 경로로 바꾸면 운영 연결이 끝납니다.

@EndUserText.label : '충당부채 풀림 범주 점검 서비스'
define service ZUI_ProvUnwindCheck {
  expose ZC_ProvUnwindCheck as ProvCheck;
}

" Service Binding : ZUI_ProvUnwindCheck_O2  (OData V2 - UI)
"   게시 후 서비스 활성화 확인: /IWFND/MAINT_SERVICE 또는 바인딩 게시 화면

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의입니다.

운영 데이터로 갈 때

전표가 수천만 건이면 집계는 화면이 아니라 데이터베이스에서 이뤄져야 합니다. 이 앱은 충당부채 단위로 읽으므로 대상 건수는 작지만, 원장 읽기는 회계연도 · 회사코드 · 풀림 계정 조건이 반드시 걸리도록 파라미터를 필수로 둡니다. 인덱스는 회사 · 연도 · 계정 순서를 따르고, 응답 시간 기준을 정해 넘으면 조회조건을 좁히라고 안내합니다. 점검 규칙은 월 합계 위에서 돌므로 전표 건수에 비례해 늘어나지 않습니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

점검 규칙과 기준서

도입과 운영