SAP 파생상품 손익 범주 배분 점검 — IFRS 18, 위험회피수단 손익이 영업·투자·재무 중 어디에 놓여야 하는지 계약마다 다시 따져 원장과 맞춰본다

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

IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익계산서 항목을 영업·투자·재무 범주로 나누도록 요구합니다. 시행은 2027년 1월 1일 이후 개시하는 회계연도부터이고 조기 적용이 허용되며 비교기간은 다시 작성합니다. 결산 담당자가 지금 부딪히는 질문은 구체적입니다. 파생상품 손익이 올해 어느 범주에 놓였는가, 위험회피수단으로 쓴 계약은 위험회피대상이 속한 범주를 따랐는가, 목적이 분명하지 않은 계약은 무엇으로 보아야 하는가. 이 질문은 준비하는 입장에서 미리 점검해 둘수록 부담이 줄어듭니다.

지금 방식은 대체로 이렇습니다. 자금 부서의 파생상품 계약 목록과 위험관리 문서를 한쪽에 두고, 총계정원장 개별항목(FAGLL03)에서 파생상품 손익 계정의 줄을 내려받아 엑셀에서 계정을 범주로 붙인 뒤 눈으로 맞춰 봅니다. 계약이 수십 건만 되어도 어느 계약의 어느 줄이 어느 범주 계정에 계상됐는지 추적하기 어렵고, 합계가 맞아도 범주가 어긋난 건은 합계 대사에서 드러나지 않습니다.

이 앱은 계약마다 기대 범주를 규칙으로 정하고, 원장 줄이 놓인 장부 범주와 나란히 놓아 어긋난 계약만 점검 필요로 걸러 줍니다. 판단 자료가 모자라 기대 범주를 정하지 못한 계약은 확인 필요로 따로 모읍니다. 최종 판단은 회사와 감사인이 하며 이 화면은 그 판단 앞의 조회·점검을 돕는 도구입니다.

계정 이름만 보아서는 계약의 목적이 보이지 않는다

같은 통화선도라도 위험회피수단으로 지정된 계약, 지정은 없지만 환위험 관리가 문서로 남은 계약, 목적이 확인되지 않는 계약은 기대하는 범주가 다릅니다. 계정 이름은 결과일 뿐이어서 계정만 보면 이 차이가 지워집니다. 화면은 지정 여부, 위험관리 문서화 여부, 위험회피대상 범주를 계약 행에 함께 두어 기대 범주가 어떤 근거로 정해졌는지 보이게 합니다.

합계가 맞아도 범주가 어긋나 있을 수 있다

평가손익과 실현손익을 더한 값이 원장과 맞는지는 합계 대사로 확인합니다. 그러나 한 계약의 손익 전부가 재무범주 계정에 계상돼 합계는 맞는데 위험회피대상은 영업범주인 경우는 합계 대사를 그대로 통과합니다. 그래서 대사 결과 탭은 합계 사이의 등식(정합성 대사)과 범주 일치 여부(장부 점검 대사)를 나눠 보여 줍니다.

판단 자료가 모자란 계약을 숨기지 않는다

위험관리 문서에서 위험회피대상의 범주를 확인할 수 없는 계약은 기대 범주를 억지로 정하지 않고 확인 필요로 표시합니다. 이런 계약이 몇 건인지, 손익이 얼마인지가 범주별 집계의 별도 줄에 남기 때문에 나머지 범주의 합계를 흐리지 않고 후속 확인 대상으로 넘길 수 있습니다.

한 계약의 평가손익과 실현손익이 갈라지는 경우

같은 계약의 평가손익은 영업범주 계정에, 실현손익은 재무범주 계정에 계상되는 일이 있습니다. 화면은 이런 계약을 별도 점검 코드로 걸러 평가·실현 계상 계정을 같은 범주로 맞출지 확인하게 합니다.

사용 방법

1. 조회조건 입력 — 필수는 회계연도(4자리, 기본 2026)입니다. 회사, 거래일 시작·종료, 위험, 위험회피 지정, 계약명 일부, 기대 범주, 점검 코드, 점검 결과는 선택이며 비워 두면 조건이 적용되지 않습니다.
2. 조회 — 조건 입력란 맨 오른쪽의 조회 버튼을 누르거나 입력란에서 Enter 를 누릅니다. 화면이 열릴 때 한 번 자동 조회됩니다.
3. 요약 지표 확인 — 계약 수, 손익 합계, 범주별 기대 손익, 다른 범주 계상액, 점검 필요·확인 필요 계약 수, 정합성 대사 차이 건수를 봅니다.
4. 탭 이동 — 계약별 명세 → 범주별 집계 → 위험별 집계 → 대사 결과 순서로 살펴봅니다.
5. 계약 행 클릭 — 기대 범주의 근거와 원장 줄별 계상 내역이 상세 창으로 열립니다.
6. CSV 내려받기 — 우측 위 버튼으로 현재 탭을 UTF-8 CSV 로 저장합니다. 조회조건이 그대로 반영됩니다.

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

화면의 숫자는 만드는 쪽에서 먼저 대사식을 세워 검증용 샘플 데이터 전체에 대해 돌렸습니다. 샘플은 계약 40건과 원장 131줄이며 모두 가상의 자료입니다.

정합성 대사 다섯 건은 모두 차이가 없습니다. 아래 두 건은 일부러 어긋나게 만든 장부 점검 대사이며, 이렇게 나오는 것이 정상 동작입니다.

무엇으로 만들었나

실행 화면

처음 열었을 때와 점검 필요 계약 좁히기

화면은 열리자마자 한 번 조회해 40건 전체를 보여 줍니다. 여기서 조건 하나만 바꾸면 확인할 계약만 남습니다.

위쪽 파란 안내 문구는 이 화면이 점검 도구이고 최종 판단은 회사와 감사인이 한다는 점을 먼저 밝힙니다. 조회 버튼은 조건 입력란 맨 오른쪽에 있고 입력란에서 Enter 를 눌러도 조회됩니다. 화면이 열릴 때 한 번 자동 조회되므로 기본값(2026, 전체)으로 40건 전체의 손익 합계 24.8백만 원과 영업·투자·재무범주의 기대 손익이 바로 보입니다. 표에는 계약마다 기대 범주와 장부 범주가 나란히 놓입니다.

점검 결과 조건을 점검 필요로 두고 조회하면 40건 가운데 6건이 남고 요약 지표의 점검 필요 계약도 6으로 바뀝니다. 표시되는 점검 코드와 점검 내용은 어떤 규칙에 걸렸는지를 설명하는 문장입니다. 차이가 있다는 뜻일 뿐 잘못으로 단정하는 표시가 아니며, 각 건이 정당한지는 계약 문서와 회사 정책으로 확인해야 합니다.

범주와 위험으로 모아 보기

계약별 명세를 범주와 위험 두 축으로 다시 모아 어디에 어긋남이 몰려 있는지 읽습니다.

범주별 집계 탭은 회사 두 곳을 각각 영업범주·투자범주·재무범주·확인 필요 네 줄로 보여 줍니다. 차이 열은 장부 손익에서 기대 손익을 뺀 값이라 한 회사 안에서 더하면 0이 됩니다. 지정은 있었으나 대상 범주를 정하지 못한 계약은 확인 필요 줄로 따로 모여 다른 범주 합계를 흐리지 않습니다.

위험별 집계 탭은 같은 40건을 환율위험·이자율위험·상품가격위험·주가위험으로 나눠 다시 모읍니다. 지정 계약 수와 점검 필요 계약 수를 함께 보여 주므로 어느 위험 쪽에서 범주 어긋남이 몰리는지 읽을 수 있습니다. 합계는 계약별 명세 탭의 합과 같아야 하며 대사 결과 탭에서 이를 검산합니다.

계약 한 건의 근거와 대사

계약을 눌러 기대 범주의 근거를 확인하고, 마지막으로 대사 결과 탭에서 숫자가 맞는지 검산합니다.

계약별 명세에서 한 행을 누르면 열리는 상세 창입니다. 위쪽에는 위험회피 지정 여부, 위험관리 문서화 여부, 위험회피대상 범주로부터 기대 범주가 어떻게 정해졌는지가 적히고, 아래 표에는 평가손익 줄과 실현손익 줄이 어느 계정(영업·투자·재무)에 얼마씩 계상됐는지 나옵니다. 계정 범주가 기대 범주와 다른 줄은 다른 범주 계상액 열에 같은 금액이 표시됩니다.

대사 결과 탭은 R01에서 R05까지 정합성 대사(합계 사이의 등식)와 R06·R07 장부 점검 대사를 구분해 보여 줍니다. 정합성 대사는 모두 차이 0이어야 정상이고, 장부 점검 대사의 차이 건수는 점검 필요와 확인 필요 계약 수와 맞아야 합니다. 요약 지표의 정합성 대사 차이 건수가 0인 이유가 여기에 있습니다.

화면 뒤에서 일어나는 일

계약 1건마다 아래 순서로 기대 범주를 정하고 장부 범주와 비교합니다. 해당하면 점검 필요 또는 확인 필요와 코드를 표시합니다. 규칙의 세부는 회사의 위험관리 정책과 감사인의 판단으로 달라질 수 있어 확인 필요입니다.

1. 계약의 평가손익과 실현손익을 더해 손익 합계를 만듭니다.
2. 지정 여부·위험관리 문서화 여부·위험회피대상 범주로 기대 범주를 정합니다.
3. 원장 줄의 계정이 속한 범주로 장부 범주를 정하고, 기대 범주와 다른 줄의 금액을 더해 다른 범주 계상액을 만듭니다.
4. 회사·범주·위험별로 집계하고 대사식으로 검산합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

이번 점검에서는 넓은 화면(가로 1600픽셀)에서만 화면을 확인했습니다. 좁은 화면과 휴대폰에서의 표시는 확인 필요입니다.

파일 구성

index.html · readme.html
Component.js · manifest.json
controller/  BaseController.js · Main.controller.js
view/        Main.view.xml · DetailDialog.fragment.xml
model/       formatter.js · ErrorHandler.js
css/         style.css
i18n/        i18n_ko.properties
odata/<서비스 폴더>/  metadata.xml · service.js · json/
media/       intro.mp4 · intro_poster.jpg

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 기존에 쓰던 표준 화면을 없애는 것이 아니라 그 옆에서 범주 관점의 점검을 맡습니다.

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

T-code 별 연계 지점

운영 전환 때 기존 리포트를 없앨 필요는 없습니다. 법정·공시 숫자는 계속 표준 거래와 보고서에서 만들고, 이 앱은 결산 전에 범주 분류가 계획대로인지 미리 점검하는 자리로 쓰는 것이 안전합니다.

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

이 앱의 집계는 아래 CDS 구성에서 보듯 뷰 레이어로 만들 수 있어 표준 분석 쿼리나 Fiori 분석 앱과 같은 스택 위에 놓입니다. 표준 분석 앱이 이미 같은 분류를 제공하는지는 사용 중인 릴리스에 따라 달라 확인 필요이며, 그런 경우에도 이 앱은 계약 단위의 기대 범주 비교라는 점검 관점을 맡습니다.

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

요구사항 매핑표

CDS 구성

아래는 화면이 보여 주는 값을 S/4HANA 위에서 만들 때의 CDS 구성 스케치입니다. 뷰 이름과 필드 매핑은 이 글의 설명용이며, 표준 CDS 뷰 연결과 계정 범주 매핑은 사용하는 시스템에서 확인이 필요합니다. 표준 원천은 총계정원장 줄(ACDOCA), 계정 마스터(SKA1), 금융거래(VTBFHA · VTBFHAPO)를 씁니다.

뷰 레이어 구성

① 계정 범주 매핑 테이블

계정이 어느 범주에 속하는지는 이 테이블 한 곳에서 정합니다. 이 값이 틀리면 뒤의 모든 비교가 틀리므로 운영 시작 전에 회계팀과 가장 먼저 확정해야 합니다.

" ─────────────────────────────────────────────
" ZDERIV_ACCTMAP : 파생상품 손익 계정 → 범주 매핑
" 역할  : 계정이 영업(OPR)·투자(INV)·재무(FIN) 중 어디인지 보관
" 이유  : 계정체계는 회사마다 달라 데이터로 둔다
" ─────────────────────────────────────────────
@EndUserText.label : '파생상품 손익 계정 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zderiv_acctmap {
  key mandt    : mandt not null;
  key ktopl    : ktopl not null;
  key saknr    : saknr not null;
  cat          : abap.char(3);   " OPR / INV / FIN
  item_type    : abap.char(2);   " FV 평가 / RL 실현
}

② 계약 차원 — 기대 범주를 정하는 곳

지정 여부, 위험관리 문서화 여부, 위험회피대상 범주로 기대 범주를 정하는 규칙을 이 뷰 한 곳에 둡니다. 화면과 서비스가 같은 규칙을 쓰므로 판정이 갈라지지 않습니다.

" ─────────────────────────────────────────────
" ZI_DerivInstr : 계약 차원 (기대 범주 판정)
" 이유  : 규칙을 한 곳에 둬 화면·서비스가 같은 값을 쓴다
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'InstrNo'
define view entity ZI_DerivInstr
  as select from vtbfha as h
{
  key h.rfha                       as InstrNo,
      h.rbukrs                     as CompanyCode,
      cast( ' ' as abap.char(1) )  as DesigFlag,     " 지정 여부 (확장 필드, 확인 필요)
      cast( ' ' as abap.char(1) )  as RiskDoc,       " 위험관리 문서화 (확인 필요)
      cast( '   ' as abap.char(3) ) as HedgedCat,     " 위험회피대상 범주 (확인 필요)
      case
        when DesigFlag = 'Y'                       then HedgedCat
        when RiskDoc   = 'Y' and HedgedCat <> ''   then HedgedCat
        when RiskDoc   = 'Y'                       then 'UNK'
        else 'OPR'
      end                          as ExpCat
}

③ 원장 줄 기본 뷰 — 줄마다 계정 범주 붙이기

원장 줄에 매핑 테이블의 범주를 붙여 줄 단위로 기대 범주와 비교합니다. 다른 범주 계상액은 이 뷰에서 줄마다 정해집니다.

" ─────────────────────────────────────────────
" ZI_DerivLedgerLine : 원장 줄 + 계정 범주
" 이유  : 장부 범주와 다른 범주 계상액의 원천을 줄 단위로 둔다
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@ObjectModel.usageType: { serviceQuality: #C, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_DerivLedgerLine
  as select from acdoca as a
    inner join   zderiv_acctmap as m
      on  m.ktopl = 'YCOA' and m.saknr = a.racct       " 계정과목표는 시스템에 맞게 (확인 필요)
    association [1] to ZI_DerivInstr as _Instr
      on  _Instr.InstrNo = $projection.InstrNo
{
  key a.rldnr                     as Ledger,
  key a.rbukrs                    as CompanyCode,
  key a.gjahr                     as FiscalYear,
  key a.belnr                     as DocumentNo,
  key a.docln                     as LineItem,
      a.racct                     as GlAccount,
      m.cat                       as AcctCat,
      m.item_type                 as ItemType,
      @Semantics.amount.currencyCode: 'Currency'
      a.hsl                       as Amount,
      a.rhcur                     as Currency,
      a.sgtxt                     as InstrNo,            " 계약 번호 연결 방식은 확인 필요
      _Instr.ExpCat               as ExpCat,
      case when m.cat <> _Instr.ExpCat then a.hsl else 0 end as MisAmt,
      _Instr
}

④ 집계 큐브 — 기대 손익과 장부 손익

회사·범주별로 기대 손익과 장부 손익을 한 뷰에서 집계합니다. 범주별 차이의 합이 0이어야 한다는 대사식이 이 뷰의 결과를 검산합니다.

" ─────────────────────────────────────────────
" ZI_DerivCatCube : 회사·범주별 기대/장부 손익 집계
" ─────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #MIXED }
define view entity ZI_DerivCatCube
  as select from ZI_DerivLedgerLine as l
{
  key l.CompanyCode,
  key l.FiscalYear,
  key l.AcctCat                                           as BookCat,
  key l.ExpCat,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( l.Amount )                                     as BookAmt,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( case when l.AcctCat <> l.ExpCat then l.Amount else 0 end ) as MisAmt,
      l.Currency
}
group by l.CompanyCode, l.FiscalYear, l.AcctCat, l.ExpCat, l.Currency

⑤ 분석 쿼리 — 화면이 부르는 필터와 컬럼

화면의 조회조건은 이 뷰의 필터 항목으로만 들어옵니다. 필터를 쓰지 않는 커스텀 파라미터를 두지 않는 것이 서비스 계약의 원칙입니다.

" ─────────────────────────────────────────────
" ZC_DerivCatQuery : 화면용 소비 뷰
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.query: true
@EndUserText.label: '파생상품 손익 범주 점검'
define view entity ZC_DerivCatQuery
  as select from ZI_DerivCatCube
{
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key FiscalYear,
  @Consumption.filter.selectionType: #RANGE
  key CompanyCode,
  @AnalyticsDetails.query.axis: #ROWS
  key BookCat,
  @AnalyticsDetails.query.axis: #ROWS
  key ExpCat,
  @AnalyticsDetails.query.axis: #COLUMNS
  BookAmt,
  @AnalyticsDetails.query.axis: #COLUMNS
  MisAmt
}

⑥ 권한 — 회사코드 단위로 거르기

집계 단계에서 회사코드를 거르지 않으면 드릴다운이나 합계 뺄셈으로 다른 회사의 숫자가 드러날 수 있습니다.

" ─────────────────────────────────────────────
" ZC_DerivCatQuery 접근 제어
" ─────────────────────────────────────────────
@EndUserText.label: '파생상품 범주 점검 권한'
@MappingRole: true
define role ZC_DerivCatQuery {
  grant select on ZC_DerivCatQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

쿼리를 OData V2 로 게시해 화면이 서비스 주소만 알면 되게 합니다. 게시 방법은 시스템 구성에 따라 달라 확인 필요입니다.

" ─────────────────────────────────────────────
" 서비스 정의 : 쿼리를 하나의 서비스로 묶는다
" ─────────────────────────────────────────────
@EndUserText.label: '파생상품 손익 범주 점검 서비스'
define service ZUI_DerivCatCheck {
  expose ZC_DerivCatQuery as CatQuery;
}
" 바인딩은 OData V2 - UI 로 게시한다(Service Binding 화면, 확인 필요)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

운영 데이터로 갈 때

파생상품 계약은 보통 수백 건이지만 원장 줄은 평가 주기만큼 늘어납니다. 회계연도를 필수 조건으로 두고 회사코드와 거래일 범위를 함께 쓰며, 집계는 큐브에서 서비스 쪽으로 밀어 넣어 화면으로 줄 단위 전체를 내려받지 않게 합니다. 응답 시간 기준과 인덱스 설계는 실제 데이터 규모에서 측정해 정하는 것이 맞으며 이번 샘플(계약 40건·원장 131줄)로는 확인하지 못했습니다. 확인 필요입니다.

자주 묻는 질문

도입 검토에서 자주 나오는 질문을 네 묶음으로 적었습니다.

숫자와 산식

화면과 조작

기준서와 판단

도입과 운영