SAP 위험회피수단 명목금액·평균가격 공시 점검 — IFRS 7, 만기구간별 명목금액과 가중평균 가격을 공시 초안·원장과 맞춘다

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

결산 때마다 주석 담당자가 받는 질문은 같습니다. 위험회피수단의 명목금액이 만기 구간별로 얼마인가, 평균 가격은 얼마로 적었나, 그 숫자가 원장과 맞는가. IFRS 7(K-IFRS 제1107호)은 위험회피회계를 적용하는 회사에게 위험회피수단의 명목금액을 시기별로 나눠 보이고(23B), 해당하면 평균 가격이나 환율까지 적도록 요구합니다. 장부금액·재무상태표 표시 항목·비효과 금액 같은 24A·24C 항목도 함께 요구되니, 한 표를 채우는 데 거래 시스템·원장·엑셀 초안이 모두 불려 나옵니다. 이 앱은 그 세 곳의 숫자를 한 화면에서 다시 계산해 맞춰 보는 점검 도구입니다.

판단은 회사와 감사인의 몫입니다. 위험회피회계를 적용할 수 있는지는 IFRS 9(K-IFRS 제1109호)의 요건이 정하고, 이 앱은 그 판단을 대신하지 않습니다. 앱이 하는 일은 “공시에 적을 숫자가 원천과 같은가” 를 기계적으로 가려내는 데까지입니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 5건이 가려진 이유

기준월 202412 의 위험회피관계는 18건, 재계산한 명목금액 합계는 981억(98,100,000,000원)입니다. 공시 초안은 986억이라 5억 많습니다. 합계만 보면 “5억 차이” 한 줄이지만, 건별로 내려가 보면 이유가 다섯 갈래로 갈립니다.

다섯 건은 자료에 일부러 심은 예외입니다. 앱이 이런 차이를 가려내는지 보여 주기 위한 것이라, 숫자가 실제 회사의 것은 아닙니다. 그리고 이 다섯 건은 앱이 스스로 계산해 맞춰 보는 정합성 대사(차이 0건)와는 별개입니다 — 정합성 대사는 “내 계산끼리 맞는가”, 점검 필요는 “내 계산이 초안·원장과 맞는가” 를 가립니다.

도입하면 달라지는 것

주석 준비 시간 — 구간별 합계 · 평균 가격 · 장부금액 대조를 엑셀에서 손으로 하던 일이 조회 한 번으로 줄어듭니다. 검토자와의 문답 — “이 숫자 어디서 나왔나” 에 산식 줄(건당 12줄)을 열어 답합니다. 감사 대응 — 점검 코드와 대사 12줄이 CSV 로 남아 같은 설명을 다시 만들지 않습니다. 다음 결산 — 기준월만 바꿔 같은 점검을 되풀이합니다.

이런 회사에 맞습니다

위험회피회계를 적용하는 파생상품을 여러 건 운용하면서 공시 초안을 엑셀로 만드는 회사, 거래 시스템·원장·주석 초안이 서로 다른 사람의 손에 있는 회사, 감사인이 만기구간별 명목금액과 평균 가격의 근거를 요청하는 회사에 맞습니다. 위험회피수단이 한두 건뿐이면 효과가 작습니다. 한편 위험회피 지정 요건과 효과성 평가를 점검하려면 같은 시리즈의 위험회피회계 요건·효과성 점검과 해외사업장 순투자 위험회피 점검 글을 보시면 됩니다.

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

만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸습니다. 건수는 모두 이 자료의 건수입니다.

대사 결과 12줄 가운데 내 계산끼리 맞춰 보는 정합성 대사 7줄은 전부 차이 0건이고, 공시 초안·원장과 맞추는 장부 점검 대사 5줄에서만 차이가 한 건씩 나옵니다(위 다섯 건). 화면 쪽은 서비스를 실제로 불러 날짜 조건(지정일 이상·이하)이 7건과 11건으로 갈리고 합이 18건인지, 정렬·건수 제한·전체 건수가 맞는지까지 확인했습니다.

도입 후 쓰는 순서

① 기준 연월을 넣고 조회합니다. ② 위쪽 요약에서 점검 필요 건수를 봅니다. ③ 점검 결과를 ‘점검 필요’ 로 고르거나 점검 코드를 골라 해당 건만 모읍니다. ④ 행을 눌러 산식 상세를 열고 어느 줄에서 갈렸는지 확인합니다. ⑤ 원인을 정리해 초안 또는 원장을 바로잡고, 같은 기준월로 다시 조회해 점검 필요가 줄었는지 봅니다. ⑥ 대사 결과 탭과 CSV 를 증빙으로 남깁니다.

실행 화면

실제로 돌아가는 화면 6종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 이 자료는 가상의 회사 데이터이며, 위험회피관계 이름 끝에 ‘(가상)’ 이 붙어 있습니다.

처음 열었을 때

맨 위에는 이 화면이 IFRS 7 공시 요구사항을 원장과 맞춰 보는 점검용이라는 안내가 있고, 그 아래 조회조건 일곱 개(기준 연월 · 위험 유형 · 위험회피 유형 · 지정일 시작과 종료 · 점검 코드 · 점검 결과)와 요약이 놓입니다.

요약 여덟 칸이 한 줄에 놓입니다. 건수 · 재계산 명목금액 · 초안 명목금액 · 둘의 차이 · 원장 순장부금액 · 원장과 재계산의 차이 · 점검 필요 건수 · 정합성 대사 차이 건수. 맨 오른쪽 ‘정합성 대사 차이 0’ 은 내 계산이 스스로 맞는다는 뜻이고, 그 왼쪽 ‘점검 필요 5’ 가 초안·원장과 다른 건입니다. 두 숫자를 나란히 둔 이유는, 앱을 믿어도 되는지와 데이터를 의심해야 하는지를 한눈에 갈라 보기 위해서입니다.

구간별 · 위험 유형별 · 위험회피 유형별

탭 다섯 개가 같은 자료를 다섯 방향으로 잘라 보여 줍니다. 탭 머리에 건수가 먼저 적혀 있어 눌러 보지 않아도 얼마나 되는지 압니다 — 명세 18, 구간 32, 위험 유형 3, 위험회피 유형 3, 대사 12.

위험회피관계 18건이 구간으로 펼쳐져 32줄이 됩니다. 한 건이 한 줄이 아니라 구간 수만큼 줄을 가진다는 점이 공시 형태(구간별 프로파일)와 같습니다. 가중평균의 재료인 ‘명목금액 × 가격’ 열이 함께 있어, 평균 가격이 어디서 나왔는지 열 하나로 따라갈 수 있습니다. 가격이 비어 있는 구간은 이 탭에서 확인 필요로 표시됩니다.

외환위험 9건은 재계산 가중평균 1,331.4023 과 초안 1,331.5827 이 0.1804 다르고 명목금액도 5억 다릅니다. 이자율위험은 평균금리 3.4245 로 초안과 같지만 순장부금액(원장과 +37,500,000)과 비효과(+12,800,000)가 달라 점검 필요가 2건입니다. 상품가격위험은 4건 모두 맞습니다. 위험 유형마다 가격의 단위(원/달러, %, 원/단위)가 달라 평균 가격을 위험 유형을 넘어 합치지 않고 따로 구합니다.

현금흐름 위험회피 10건은 순장부금액 차이 +37,500,000 과 비효과 차이 +12,800,000 이 모두 여기서 나옵니다. 공정가치 위험회피 6건은 전부 맞고, 순투자 위험회피 2건은 명목금액 5억이 갈립니다. 같은 18건을 위험 유형으로 묶느냐 위험회피 유형으로 묶느냐에 따라 문제가 어디 몰려 있는지가 달리 보입니다.

한 건을 풀어 보기

요약과 집계는 “어디가 다른가” 를 말하고, 산식 상세는 “왜 다른가” 를 말합니다.

결과가 “맞지 않는다” 에서 끝나지 않도록 산식 줄을 열어 둡니다. 구간별 명목금액을 더하는 줄, 가격과 곱하는 줄, 가격이 적힌 구간만 모아 나누는 줄, 자산에서 부채를 빼는 줄, 수단 변동에서 대상 변동을 빼는 줄이 차례로 놓입니다. 검토자가 계산기를 두드릴 필요 없이 줄 하나씩 확인합니다.

대사 결과

마지막 탭이 앱 전체의 성적표입니다. 증빙으로 남길 때는 이 탭과 CSV 를 함께 보관합니다.

좌변 · 우변 · 검사 건수 · 차이 건수 · 최대 차이가 줄마다 있습니다. 01~07 은 차이가 모두 0건입니다. 11(초안 명목금액) 5억, 12(초안 평균가격) 1.3833, 13(원장 순장부금액) 37,500,000, 14(원장 비효과) 12,800,000, 15(평균가격 미기재) 1건이 각각 한 건씩 남습니다. 번호를 01~07 과 11~15 로 띄운 것은 두 성격의 대사를 눈으로 섞지 않기 위해서입니다.

조건을 좁히는 법

점검 코드로 걸면 같은 이유로 걸린 건만 모이고, 점검 결과를 ‘점검 필요’ 로 고르면 정상 건이 빠집니다. 지정일은 시작과 종료를 따로 넣어 범위로 걸 수 있습니다 — 서비스는 이 두 조건을 ‘이상 · 이하’ 로 풀어 and 로 묶습니다. 같은 필드에 두 조건을 각각 필터로 넣으면 UI5 가 or 로 묶어 버리는 일이 있어서, 두 조건을 한 묶음으로 만들어 보냅니다.

화면 안에서 지키는 원칙은 세 가지입니다. 금액 단위는 원이고 명목금액은 원 환산 기준입니다. 숫자는 서비스가 주는 그대로 쓰고 화면이 다시 계산하지 않습니다. 오류는 서비스 연결 안내로 쉽게 풀어 보여 줍니다.

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

이 앱이 표준 거래를 대신하지는 않지만, 점검 결과를 본 사람은 곧바로 표준 거래로 내려가 원인을 확인합니다. 연결 지점은 다음과 같습니다.

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

이 앱의 점검은 “구간으로 나누고, 가격으로 가중하고, 원장과 빼는” 세 동작이라 CDS 뷰로 내리기에 알맞습니다. 구간 배분은 뷰의 case 식으로, 가중평균은 sum 두 개의 비율로, 원장 대조는 ACDOCA 집계와의 join 으로 만듭니다. 쿼리 뷰로 열어 두면 표준 Fiori 앱과 Analysis for Office 가 같은 숫자를 그대로 띄웁니다. 이 앱이 부르는 OData 서비스의 역할을 쿼리 뷰가 이어받는 구조입니다.

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

CDS 구성

이 사례의 화면은 위험회피관계 18건과 구간 32줄을 서비스가 만들어 주는 값으로 보여 줍니다. 데모라서 되는 일이고, 운영에서는 구간 배분 · 가중평균 · 원장 대조를 CDS 로 내려 DB 에서 계산합니다. 아래는 그때 만드는 뷰를 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 만기구간 매핑 테이블

구간 경계는 회사가 정합니다. 보고기준일에서 잔존만기를 재서 어느 구간에 넣을지 정하는 표이므로, 공시 형태가 바뀌어도 코드를 고치지 않게 테이블에 둡니다.

@EndUserText.label : '위험회피 만기구간 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zhdd_bucket {
  key mandt    : mandt not null;
  key bucket   : abap.char(1) not null;   " 1 · 2 · 3
  text         : abap.char(30);           " 1년 이하 · 1년 초과 5년 이하 · 5년 초과
  from_months  : abap.int2;               " 하한(개월, 초과)
  to_months    : abap.int2;               " 상한(개월, 이하) — 마지막 구간은 9999
}

② 위험회피관계 기본 뷰

거래 시스템의 위험회피관계 지정 정보를 한 행으로 모읍니다. 원천 테이블은 Treasury 사용 여부와 릴리스에 따라 다르므로 아래는 자리만 잡았습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '위험회피관계 기본'
define view entity ZI_HdgRelation
  as select from zhdd_relation as r          " 확인: 환경의 위험회피관계 지정 원천으로 교체
{
  key r.bukrs        as CompanyCode,
  key r.hedge_id     as HedgeId,
      r.hedge_name   as HedgeName,
      r.hedge_type   as HedgeType,           " C 현금흐름 · F 공정가치 · N 순투자
      r.risk_type    as RiskType,            " X 외환 · I 이자율 · M 상품가격
      r.instr_type   as InstrType,           " F 선물환 · S 스왑 · C 통화스왑 · D 상품파생
      r.desig_date   as DesigDate,
      r.end_date     as EndDate,
      r.exposure_amt as ExposureAmt,         " 위험회피대상 노출금액(원)
      r.bs_line      as BsLine               " 재무상태표 표시 항목(24A)
}

③ 구간 배분 뷰

명목금액을 보고기준일 기준 잔존만기로 구간에 넣습니다. 구간 경계는 ① 의 테이블에서 읽습니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수단 명목금액 구간 배분'
define view entity ZI_HdgNomBucket
  with parameters
    p_keydate : abap.dats
  as select from zhdd_instr_nom as n          " 확인: 수단별 명목금액 원천
    inner join   zhdd_bucket    as b
      on  dats_days_between( $parameters.p_keydate, n.maturity_date ) / 30 >  b.from_months
      and dats_days_between( $parameters.p_keydate, n.maturity_date ) / 30 <= b.to_months
{
  key n.bukrs       as CompanyCode,
  key n.hedge_id    as HedgeId,
  key b.bucket      as Bucket,
      @Semantics.amount.currencyCode: 'Currency'
      sum( n.nominal_amt ) as Notional,
      n.currency    as Currency,
      avg( n.rate as abap.dec(18,4) ) as AvgRate   " 구간 안 평균 가격(없으면 null)
}
group by n.bukrs, n.hedge_id, b.bucket, n.currency

④ 가중평균 가격 뷰

가중평균의 분모는 가격이 적힌 구간의 명목금액입니다. 가격이 빈 구간까지 분모에 넣으면 평균이 실제보다 낮아지므로, 빈 구간은 분모에서 빼고 따로 표시합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '가중평균 가격'
define view entity ZI_HdgAvgPrice
  with parameters p_keydate : abap.dats
  as select from ZI_HdgNomBucket( p_keydate : $parameters.p_keydate )
{
  key CompanyCode,
  key HedgeId,
      sum( Notional )                                   as NomTotal,
      sum( case when AvgRate is not null
                then Notional else 0 end )              as NomPriced,
      cast( sum( case when AvgRate is not null
                      then Notional * AvgRate else 0 end )
            / nullif( sum( case when AvgRate is not null
                                then Notional else 0 end ), 0 )
            as abap.dec(18,4) )                         as AvgCalc,
      sum( case when AvgRate is null and Notional <> 0
                then 1 else 0 end )                     as MissCnt   " B01 대상
}
group by CompanyCode, HedgeId

⑤ 원장 대조 뷰

위험회피관계 번호가 전표 어느 필드에 실리는지는 도입 때 합의해야 합니다. 아래는 배정(ZUONR)에 싣는다고 가정한 스케치입니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '위험회피 원장 장부금액'
define view entity ZI_HdgLedgerBook
  with parameters p_ryear : gjahr, p_poper : poper
  as select from acdoca as a
{
  key a.rbukrs   as CompanyCode,
  key a.zuonr    as HedgeId,                 " 합의: 관계 번호를 싣는 필드
      sum( case when a.racct between '0000115000' and '0000115999'   " 확인: 파생상품 자산 계정
                then a.hsl else 0 end )      as LedgerAsset,
      sum( case when a.racct between '0000255000' and '0000255999'   " 확인: 파생상품 부채 계정
                then a.hsl else 0 end )      as LedgerLiab,
      sum( case when a.racct between '0000780000' and '0000780999'   " 확인: 비효과 손익 계정
                then a.hsl else 0 end )      as LedgerIneff
}
where a.rldnr = '0L'
  and a.gjahr = $parameters.p_ryear
  and a.poper <= $parameters.p_poper
group by a.rbukrs, a.zuonr

⑥ 대사 뷰

재계산 · 초안 · 원장을 한 행에 놓고 점검 코드를 붙입니다. 우선순위는 명목금액 → 평균가격 → 가격 미기재 → 순장부금액 → 비효과 순으로 두었는데, 한 건이 여러 이유로 걸리면 어느 코드를 먼저 보일지는 회사가 정합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '위험회피 공시 대사'
define view entity ZI_HdgRecon
  with parameters p_keydate : abap.dats, p_ryear : gjahr, p_poper : poper
  as select from ZI_HdgAvgPrice( p_keydate : $parameters.p_keydate ) as c
    inner join   zhdd_draft  as d on d.bukrs = c.CompanyCode and d.hedge_id = c.HedgeId
    left outer join ZI_HdgLedgerBook( p_ryear : $parameters.p_ryear,
                                      p_poper : $parameters.p_poper ) as l
                 on l.CompanyCode = c.CompanyCode and l.HedgeId = c.HedgeId
{
  key c.CompanyCode,
  key c.HedgeId,
      c.NomTotal,
      d.nominal_draft                              as DraftNom,
      d.nominal_draft - c.NomTotal                 as NomDiff,
      c.AvgCalc,
      d.avg_draft                                  as AvgDraft,
      d.avg_draft - c.AvgCalc                      as AvgDiff,
      ( l.LedgerAsset + l.LedgerLiab )             as LedgerCarry,
      case
        when d.nominal_draft <> c.NomTotal               then 'N01'
        when abs( d.avg_draft - c.AvgCalc ) > 0.0001     then 'R01'
        when c.MissCnt > 0                               then 'B01'
        else 'I00'
      end                                          as CheckCode
}

⑦ 분석 쿼리와 권한 (DCL)

쿼리 뷰로 열면 표준 Fiori 와 Analysis for Office 가 같은 점검 결과를 띄웁니다. 권한은 쿼리가 아니라 읽는 자리에 걸어야 합니다.

@AccessControl.authorizationCheck: #CHECK
@Analytics.query: true
@EndUserText.label: '위험회피 공시 점검'
define view entity ZC_HdgDisclosureQuery
  with parameters
    @Consumption.derivation: { lookupEntity: 'I_CalendarDate', resultElement: 'CalendarDate' }
    p_keydate : abap.dats,
    p_ryear   : gjahr,
    p_poper   : poper
  as select from ZI_HdgRecon( p_keydate : $parameters.p_keydate,
                              p_ryear   : $parameters.p_ryear,
                              p_poper   : $parameters.p_poper )
{
  @AnalyticsDetails.query.axis: #ROWS    HedgeId,
  @AnalyticsDetails.query.axis: #COLUMNS NomTotal,
  DraftNom, NomDiff, AvgCalc, AvgDraft, AvgDiff, LedgerCarry, CheckCode
}

@EndUserText.label: '위험회피 점검 — 회사코드 권한'
@MappingRole: true
define role ZI_HDGRECON {
  grant select on ZI_HdgRecon
    where CompanyCode = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 시점에 해야 할 일

위 뷰를 만들기 전에 합의가 먼저입니다. 관계 번호를 싣는 원장 필드, 구간 경계의 기준(잔존만기 · 계약 만기), 평균 가격의 정의, 가격이 빈 구간의 처리, 초안의 입수 경로 다섯 가지입니다. 앞의 확장 포인트 표와 같습니다. 합의가 끝나면 기술 작업은 뷰 일곱 벌을 만들고 전송하는 일입니다. 초안 값은 처음에는 엑셀 업로드로 받고, 안정되면 공시 시스템 인터페이스로 바꾸는 순서가 무난합니다.

운영 데이터로 갈 때 — 관계가 수백 건이면

이 자료는 18건이라 화면이 전부 받아도 가볍습니다. 관계가 수백 건, 구간이 수천 줄이 되면 화면은 건수 제한과 정렬을 서비스에 맡기고, 요약과 집계 탭은 DB 에서 미리 집계한 값을 읽게 합니다. 평가 기준일을 바꿔 가며 되풀이 조회하는 일이 많다면 ③ 구간 배분 뷰의 결과를 결산 시점에 물리적으로 쌓아 두는 방법도 있습니다. 그때는 쌓은 값과 뷰 계산 값이 같은지를 대사 행으로 하나 더 두는 것이 안전합니다.

자주 묻는 질문

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

숫자와 산식

화면과 조작

도입과 운영