SAP 금융자산 신용위험 등급별 총장부금액 점검 — IFRS 7·IFRS 9, 등급·Stage 별 충당금과 주석 공시 금액이 장부와 맞는지 결산 전에 다시 계산해 대조한다

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

결산 때마다 같은 일이 반복됩니다. 금융자산의 신용위험 등급별 총장부금액을 주석에 적어야 하는데, 그 숫자는 어느 Stage 로 분류했는가와 손실충당금을 얼마로 쌓았는가에 매달려 있고, 이 두 가지는 담당자의 엑셀과 장부에 따로 놓여 있습니다. 이 앱은 노출 한 건 한 건을 등급과 연체일수 기준으로 다시 분류하고 다시 계산해, 장부와 주석 숫자가 그 결과와 맞는지를 결산 전에 한 화면에서 확인하게 합니다.

근거는 두 기준서입니다. IFRS 7 ‘금융상품: 공시’(K-IFRS 제1107호)는 신용위험 등급별 총장부금액과 12개월 · 전체기간 기대신용손실의 구분을 공시하도록 요구하고, IFRS 9(K-IFRS 제1109호)는 신용위험이 유의적으로 증가했는지에 따라 Stage 를 나누어 손실충당금을 측정하게 합니다. 이 앱은 점검 도구입니다. 등급 체계와 Stage 판단, 최종 공시 판단은 회사와 감사인이 하며, 앱은 그 판단이 장부에 일관되게 반영됐는지를 대조할 뿐입니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 9건 중 3건이 Stage 였습니다

이 사례 자료는 금융자산 44건 · 총장부금액 751억 3천만 원입니다(모두 가상 자료입니다). 합계만 보면 장부 손실충당금 9억 8,340만 원은 별 이상이 없어 보입니다. 그런데 노출을 다시 분류하자 9건이 점검 대상으로 걸렸습니다. 이 가운데 3건은 장부 Stage 가 산출 Stage 보다 한 단계 낮았습니다 — 예컨대 연체 45일인 5등급 대여금 18억 5천만 원은 장부에 Stage 1 로 올라 있었습니다.

나머지 6건은 등급이 높은데 연체가 길거나(G01), 장부 충당금이 다시 계산한 값과 다르거나(L01), 주석 총장부금액이 명세와 다른(A01) 건입니다. 코드마다 “결산 전에 누가 무엇을 고쳐야 하는지” 가 달라, 담당 부서로 건을 나눠 주기도 쉽습니다.

도입하면 달라지는 것

• 결산 마감 전 점검 — 주석 초안이 나오기 전에 Stage · 충당금 · 주석 금액의 어긋남을 건 단위로 알 수 있습니다.
• 감사인과의 대화 — “이 숫자는 이렇게 다시 계산해 맞췄다” 는 대사 결과를 보여 줄 수 있어 질의 왕복이 줄어듭니다.
• 분기마다 같은 틀 — 기준 연월만 바꾸면 같은 점검이 돌아, 해마다 피벗을 새로 짜지 않습니다.
• 건 단위 담당 지정 — 점검 코드가 S01 · G01 · L01 · A01 로 나뉘어 재무회계 · 리스크 · 영업관리 중 누가 볼 건인지 갈립니다.

이런 회사에 맞습니다

대여금 · 매출채권 · 채무증권 · 대출약정 같은 금융자산이 여러 종류로 섞여 있어 주석 작성이 엑셀 중심인 회사, 신용위험 등급과 Stage 를 장부 밖 표로 관리해 장부와 따로 놀 위험이 있는 재무회계팀, 감사인의 신용위험 공시 질의에 건 단위 근거를 내야 하는 회계 조직에 맞습니다. 반대로 금융업처럼 수십만 건 · 모형 기반 PD·LGD 로 충당금을 산출하는 곳은 이 앱의 단순한 손실률표로는 맞지 않아, 모형 산출값을 읽어 오는 방식으로 바꿔야 합니다(확장 포인트 참고).

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

점검 도구가 틀리면 점검할 이유가 없습니다. 그래서 만드는 쪽에서 먼저 독립된 산식으로 전수 검증했습니다. 아래는 이 사례 자료의 결과입니다.

화면 쪽은 브라우저 자동화로 따로 확인했습니다 — 기준 연월을 직전 분기(202606)로 바꿔도 같은 점검이 도는지, 점검 필요 필터가 9건만 남기는지, 등급 평가일 범위를 9월로 좁히면 14건이 되는지 등입니다.

사용 방법

1. 기준 연월(예: 202609)을 고르고 조회를 누릅니다. 입력란에서 Enter 를 눌러도 됩니다. 위쪽 지표 여섯 칸이 채워집니다.
2. 필요하면 금융자산 유형 · 신용위험 등급 · 산출 Stage · 등급 평가일(시작~종료) · 점검 코드 · 점검 결과로 범위를 좁힙니다. 조건은 서비스에 필터로 전달되어 서버에서 걸러진 건만 내려옵니다.
3. 노출 명세 탭에서 점검 결과가 “점검 필요” 인 행을 찾습니다. 점검 코드와 점검 내용을 읽으면 무엇이 왜 다른지 압니다.
4. 행을 누르면 노출별 상세가 열려 장부 Stage 와 산출 Stage 로 충당금을 어떻게 다시 계산했는지 봅니다.
5. 등급 × Stage 매트릭스 · Stage 이동표로 합계와 이동 후보를 보고, 대사 결과 탭에서 숫자 자체가 맞는지를 확인합니다.
6. 필요한 범위는 CSV 내려받기로 받아 담당자별로 나눠 줍니다. 초기화를 누르면 조건이 처음 상태로 돌아갑니다.

실행 화면

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

처음 열었을 때

조회조건은 한 줄로 끝납니다. 기준 연월만 필수이고 금융자산 유형 · 신용위험 등급 · 산출 Stage · 등급 평가일 · 점검 코드 · 점검 결과는 좁히고 싶을 때만 씁니다. 조회 · 초기화 버튼은 조건 줄 맨 오른쪽에 있습니다. 표는 장부 Stage 와 산출 Stage 를 나란히 두어, 둘이 다른 행이 한눈에 걸러집니다.

점검 필요 건 찾기

점검 코드는 한 노출에 하나만 붙습니다. 여러 가지가 겹치면 S01 → G01 → L01 → A01 순으로 가장 앞선 것을 붙이고, 점검 내용 칸에 무엇이 왜 다른지를 문장으로 적습니다. 이 사례 자료에서는 S01 3건 · G01 2건 · L01 2건 · A01 2건, 모두 9건입니다. 나머지 35건은 점검 코드 I00(이상 없음)입니다.

주석 표의 재료

이 탭의 합계는 노출 명세 탭의 합계와 같아야 합니다. 그 등식을 대사 결과 탭이 매번 다시 잽니다. 주석 공시 총장부금액 칸은 회사가 이미 만들어 둔 주석 숫자를 그대로 읽어 온 것이라, 명세에서 모은 값과 어긋나는 등급 · Stage 칸은 “점검 필요 건수” 에 잡힙니다.

옮겨야 할 후보마다 장부 충당금과 산출 충당금, 그리고 그 차이(추가로 쌓아야 하는 충당금)를 함께 적습니다. Stage 1→2 두 건은 장부 9,210만 원에 산출 3억 6,840만 원이라 2억 7,630만 원이, Stage 2→3 한 건은 7,590만 원이 모자랍니다. 간편법 14건은 이동이 없고 반올림 차이 569만 원만 남습니다.

이 화면의 숫자를 믿을 수 있는가

앞 네 개는 차이가 0 이어야 정상입니다. 뒤 두 개는 “차이가 있다” 가 곧 점검 결과라서, 202609 에서는 주석 공시 쪽이 2건(최대 5,000만 원), 충당금 쪽이 5건(최대 1억 6,650만 원) 나옵니다. 어긋남이 어디서 나는지는 대사 번호 → 점검 코드로 거슬러 올라가 확인합니다.

건 단위로 들여다보기

예를 들어 연체 45일인 5등급 대여금 18억 5천만 원은 Stage 1 로 장부에 올라 있고(손실률 3%, 5,550만 원), 연체 30일 초과이므로 산출은 Stage 2 입니다(손실률 12%, 2억 2,200만 원). 차이 1억 6,650만 원이 한 화면에서 보입니다. 계산 구분은 ‘장부 Stage 적용’ 과 ‘산출 Stage 적용’ 두 줄입니다.

좁은 화면

이 화면은 표가 넓어 열이 많습니다. 좁은 창에서는 표가 가로로 스크롤됩니다. 점검 건수를 확인하는 정도는 휴대폰으로도 되지만, 대사 결과를 놓고 따져 보는 일은 넓은 화면에서 하시길 권합니다.

조회조건과 결과 컬럼

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

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

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

기대신용손실을 SAP 안에서 산출하는 방법은 회사마다 다릅니다. 전용 솔루션을 쓰는 회사, 사내 모형 서버에서 산출값을 받아 오는 회사, 엑셀로 손실률표를 관리하는 회사가 섞여 있습니다. 이 앱은 산출 방식과 상관없이 결과(등급 · Stage · 충당금)만 읽어 다시 맞춰 보는 자리에 둡니다.

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

1. 등급 체계를 회사 기준으로 바꾼다. 이 사례는 1~5등급과 부도(D)입니다. 회사의 내부 등급이 10단계라면 등급 표를 갈아 끼우고, Stage 규칙의 임계(연체일수 30일 · 90일, 5등급)도 회사 정책에 맞춥니다.
2. 손실률표를 모형 산출값으로 교체한다. 이 사례는 Stage × 등급별 고정 손실률표입니다. 운영에서는 모형에서 나온 PD · LGD · EAD 로 계산한 충당금을 읽어 오고, 이 앱은 그 값을 “다시 계산한 값” 으로 쓰지 않고 “비교 대상” 으로 둡니다.
3. 신용위험의 유의적 증가 기준을 정리한다. 연체 30일 초과를 추정 기준으로 쓰되, 그 반증 여부와 정성 기준(워치리스트 · 구조조정 등)을 어떻게 반영할지는 회사 정책입니다. 이 앱은 정해진 기준을 일관되게 적용했는지만 봅니다.
4. 주석 숫자의 원천을 연결한다. 주석 공시 총장부금액을 어디서 가져올지(주석 초안 파일 · 결산 시스템 · 연결 패키지)를 정해 서비스가 읽도록 합니다.
5. 집계를 CDS 로 내린다. 이 사례는 노출 44건이라 브라우저가 들고 있어도 되지만, 운영 데이터에서는 서비스에서 “필터를 건 만큼만” 읽는 구조가 맞습니다. 앱은 이미 모든 조건을 서비스 필터로 보냅니다.
6. 권한을 건다. 회사코드와 거래 상대방 범위 권한을 DCL 로 걸어, 볼 수 없는 노출이 합계에 섞이지 않게 합니다.

CDS 구성

이 사례의 화면은 노출 88건(두 보고기간)을 브라우저가 들고 묶습니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일이 판정과 집계를 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 원천 테이블 이름과 권한 객체는 자리만 잡아 두었습니다.

뷰 레이어 구성

① 등급 · Stage 기준 테이블

이 점검의 모든 판정이 이 표에서 갈립니다. 연체일수 임계와 Stage 별 손실률을 코드가 아니라 데이터로 두어, 정책이 바뀌어도 개발자를 부르지 않게 합니다. 운영 전환에서 가장 먼저 합의할 항목입니다.

@EndUserText.label : '신용위험 등급 · Stage 손실률 기준'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zfi_crd_rate {
  key client     : abap.clnt not null;
  key valid_from : abap.dats not null;   " 적용 시작일 — 정책이 바뀌어도 과거 숫자가 흔들리지 않게
  key grade      : abap.char(2) not null; " G1 ~ G5, GD(부도)
  key stage      : abap.char(1) not null; " 1 · 2 · 3 · S(간편법)
  loss_rate      : abap.dec(7,4);         " 손실률(%) — 모형 산출값으로 바꿀 때는 이 열을 대체
  dpd_stage2     : abap.int2;             " 연체일수 임계 — Stage 2 (예: 30)
  dpd_stage3     : abap.int2;             " 연체일수 임계 — Stage 3 (예: 90)
}

② 노출 명세 뷰

금융자산 한 건을 한 행으로 만드는 기본 뷰입니다. 원천(채권 · 대여금 · 증권 · 약정)이 여럿이면 union 으로 한 모양에 맞춥니다. 연체일수는 미결 만기일에서 보고기간말까지의 일수로 계산합니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '신용위험 노출 명세'
define view entity ZI_CrdExposure
  as select from zfi_crd_exp as e         " 원천 — 환경에 맞게 교체(채권/대여금/증권 union)
{
  key e.period                           as Period,      " 보고기간말 YYYYMM
  key e.exp_id                           as ExpId,
      e.exp_name                         as ExpName,
      e.asset_type                       as AssetType,   " L 대여금 · R 매출채권 · B 채무증권 · C 약정
      e.grade                            as Grade,
      e.past_due                         as PastDue,     " 연체일수
      e.review_date                      as ReviewDate,  " 등급 평가일
      e.stage_book                       as StageBook,   " 장부 Stage
      @Semantics.amount.currencyCode : 'Currency'
      e.gross_amt                        as GrossAmt,
      @Semantics.amount.currencyCode : 'Currency'
      e.allow_amt                        as AllowAmt,    " 장부 손실충당금
      @Semantics.amount.currencyCode : 'Currency'
      e.note_gross                       as NoteGross,   " 주석 공시 총장부금액
      e.currency                         as Currency
}

③ 산출 Stage 판정

규칙을 한 곳에서만 정의하는 뷰입니다. 매출채권은 간편법(S), 부도이거나 연체 90일 초과면 Stage 3, 연체 30일 초과이거나 5등급이면 Stage 2, 나머지는 Stage 1. 화면이 아니라 이 뷰가 판정하므로 CSV · 서비스 · Fiori 가 모두 같은 Stage 를 봅니다.

@EndUserText.label : '산출 Stage 판정'
define view entity ZI_CrdStageCalc
  as select from ZI_CrdExposure as x
{
  key x.Period,
  key x.ExpId,
      x.StageBook,
      case
        when x.AssetType = 'R'                     then 'S'   " 간편법
        when x.Grade = 'GD' or x.PastDue > 90     then '3'
        when x.PastDue > 30 or x.Grade = 'G5'     then '2'
        else '1'
      end                                          as StageCalc,   " ← 기준 테이블의 임계로 바꾸는 자리
      x.GrossAmt,
      x.AllowAmt
}

④ 충당금 재계산 뷰

산출 Stage 와 등급으로 손실률을 붙여 충당금을 다시 계산하고 장부와의 차이를 만듭니다. 화면의 상세 창에 나오는 두 줄(장부 Stage 적용 · 산출 Stage 적용)이 이 뷰의 결과입니다.

@EndUserText.label : '충당금 재계산'
define view entity ZI_CrdEclCalc
  as select from ZI_CrdStageCalc as s
    inner join   ZI_CrdExposure  as x on  x.Period = s.Period
                                      and x.ExpId  = s.ExpId
    left outer join zfi_crd_rate as r on  r.grade = x.Grade
                                      and r.stage = s.StageCalc
                                      " and r.valid_from <= 보고기간말 — 유효기간 조건은 환경에 맞게
{
  key s.Period,
  key s.ExpId,
      s.StageBook,
      s.StageCalc,
      s.GrossAmt,
      s.AllowAmt                                                    as AllowBook,
      cast( s.GrossAmt * coalesce( r.loss_rate, 0 ) / 100
            as abap.curr(15,2) )                                    as AllowCalc,
      s.AllowAmt - cast( s.GrossAmt * coalesce( r.loss_rate, 0 ) / 100
                         as abap.curr(15,2) )                       as AllowDiff
}

⑤ 점검 코드 부여

점검 코드는 한 노출에 하나만 붙입니다. 겹치면 S01 → G01 → L01 → A01 순으로 앞선 것을 붙입니다. 순서를 뷰 안에 적어 두면 “왜 이 코드가 붙었냐” 가 코드만 읽어도 풀립니다.

@EndUserText.label : '점검 코드'
define view entity ZI_CrdCheck
  as select from ZI_CrdEclCalc as c
    inner join   ZI_CrdExposure as x on x.Period = c.Period and x.ExpId = c.ExpId
{
  key c.Period,
  key c.ExpId,
      case
        when c.StageBook <> c.StageCalc                          then 'S01'  " Stage 불일치
        when x.Grade in ('G1','G2') and x.PastDue > 30           then 'G01'  " 등급 · 연체 불일치
        when abs( c.AllowDiff ) > 1000                           then 'L01'  " 충당금 불일치 (허용오차 1,000)
        when x.NoteGross <> x.GrossAmt                           then 'A01'  " 주석 금액 불일치
        else 'I00'
      end                                                         as CheckCode
}

⑥ 등급 × Stage 매트릭스 · Stage 이동표

주석 표와 이동표를 만드는 집계 뷰입니다. 둘 다 같은 노출 명세에서 나오므로 합계가 갈라질 수 없습니다. 이 사례는 브라우저가 이 집계를 들고 있지만, 운영에서는 이 뷰가 DB 에서 합니다.

@EndUserText.label : '등급 x Stage 매트릭스'
define view entity ZI_CrdGradeMatrix
  as select from ZI_CrdEclCalc as c
    inner join   ZI_CrdExposure as x on x.Period = c.Period and x.ExpId = c.ExpId
{
  key c.Period,
  key x.Grade,
  key c.StageCalc                  as Stage,
      count( * )                   as Cnt,
      sum( c.GrossAmt )            as GrossAmt,
      sum( c.AllowBook )           as AllowAmt,
      sum( x.NoteGross )           as NoteGross
}
group by c.Period, x.Grade, c.StageCalc

" ── 이동표는 같은 구조에서 키만 (StageBook, StageCalc) 로 바꾼다 ──
" key c.StageBook, key c.StageCalc, sum( c.AllowBook ), sum( c.AllowCalc ),
" sum( c.AllowCalc ) - sum( c.AllowBook )  as AllowGap

⑦ 대사 뷰와 권한(DCL)

대사식은 화면이 아니라 서비스가 계산해 내려보내게 합니다. 화면의 탭들이 한 원천에서 나왔는지를 이 뷰가 매번 다시 확인합니다. 권한은 집계를 읽는 자리에 걸어야 뺄셈으로 새지 않습니다.

@EndUserText.label : '대사 — 매트릭스 합계 = 명세 합계'
define view entity ZI_CrdRecon01
  as select from ZI_CrdGradeMatrix as m
{
  key m.Period,
      '01'                                  as ReconNo,
      sum( m.GrossAmt )                     as LeftAmt,
      cast( 0 as abap.curr(15,2) )          as RightAmt    " 명세 합계를 같은 키로 붙이는 자리
}
group by m.Period

" ── 권한 (DCL) ──────────────────────────────────────────────
@EndUserText.label : '신용위험 노출 권한'
@MappingRole : true
define role ZI_CRDEXPOSURE {
  grant select on ZI_CrdExposure
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

운영 데이터로 갈 때 — 노출이 수십만 건이면

이 사례는 노출 44건입니다. 은행처럼 노출이 수십만 건이면 화면이 들고 있는 방식이 먼저 무너집니다. 조회조건을 서비스 필터로 보내는 구조는 이미 지켰으므로, 아래처럼 단계를 나누어 손보면 됩니다.

한 가지 더. 대사 결과는 모든 노출을 한 번 훑어야 나오는 숫자라서 운영에서는 조회 때마다 돌리지 않고 결산 단계마다 한 번 돌려 저장해 두는 편이 낫습니다. 이 앱의 대사 탭은 서비스가 계산해 둔 결과를 읽기만 하는 구조라 그렇게 바꾸어도 화면은 달라지지 않습니다.

자주 묻는 질문

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

Stage 와 충당금

주석 공시

화면과 조작

도입과 운영