SAP 고객 금융 이자수익 범주 점검 — 할부·대여 이자가 영업·투자·재무 중 맞는 범주에 놓였는지 정책표로 다시 따지기

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

분기 결산에서 고객 금융 손익은 늘 같은 질문을 남깁니다. 이 이자수익은 영업범주인가 투자범주인가, 이 자금조달 이자비용은 재무범주인가 영업범주인가, 그 숫자가 다시 계산한 값과 맞는가. IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)는 손익을 영업 · 투자 · 재무 범주 등으로 나누도록 요구하고, 고객에게 금융을 제공하는 일이 주된 사업활동인 회사에는 그 손익이 어디에 놓이는지가 영업이익이라는 소계를 직접 움직입니다. 이 앱은 그 세 질문을 한 화면에 붙여, 회사가 정한 정책표로 범주를 다시 정하고 이자 금액을 다시 계산해 장부와 견줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 12건, 2억 6천만 원이 움직입니다

이 자료의 가상 회사 두 곳에는 계약 20건과 분기별 손익 건 60건이 있습니다. 장부만 보면 모두 이자 손익으로 잘 기록된 것처럼 보입니다. 정책표로 다시 정하면 12건이 점검 필요로 걸리고, 그 건들의 범주 이동 필요 금액은 합쳐 259백만 원입니다. 회사 1000 은 73.5백만 원(6건), 회사 2000 은 185.5백만 원(6건)입니다. 별도로 3건(98.7백만 원)은 대여가 판매와 이어진 것인지 확정되지 않아 확인 필요로 남고, 이자 재계산에서는 2건이 허용 범위를 넘는 차이(+18,400원, −7,300원)로 걸립니다.

가장 흔한 어긋남은 두 가지입니다. 고객 금융이 주된 사업활동인 사업부의 할부 이자가 투자범주나 재무범주에 기록된 경우(회사 1000 의 세 건), 그리고 판매와 분리된 고객 대여금 이자가 영업범주에 기록된 경우(회사 2000 의 세 건)입니다. 둘 다 계정만 보면 이자수익이라 문제가 보이지 않고, 계약의 성격을 알아야 어긋남이 드러납니다.

도입하면 달라지는 것

• 결산 준비 — 범주 재분류 엑셀과 별도 대사표가 한 화면의 점검 결과로 대체됩니다.
• 회의의 주제 — “이 건은 어느 범주인가”를 매번 새로 논쟁하지 않고, 정책표의 어느 행을 바꿀지를 이야기합니다.
• 감사 대응 — 정책 근거 문장과 건별 비교가 한 화면에 있어 설명 자료를 따로 만들지 않습니다.
• 애매한 건의 가시성 — 판단이 보류된 건이 영업범주 속에 묻히지 않고 확인 필요로 따로 보입니다.

이런 회사에 맞습니다

S/4HANA(ACDOCA)를 쓰면서 할부금융 · 리스성 대여 · 고객 대여금 이자를 다루는 제조 · 유통 · 서비스 회사, 고객 금융이 한 사업부의 주된 사업활동인 그룹사, 그리고 IFRS 18 적용에 앞서 손익 범주 정책을 점검해 보려는 재무회계팀에 맞습니다. 고객 금융이 사업의 전부인 금융회사는 별도 요구사항이 있으므로 이 앱의 정책표를 그대로 쓰기 어렵습니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 전수로 돌렸습니다. 아래는 이 사례 데이터의 결과입니다.

여섯 가지 대사식이 모두 차이 0 입니다. 다섯 식은 합계가 맞물리는지, 한 식은 건수가 맞물리는지를 봅니다. 의도적으로 넣은 예외(점검 필요 12건 · 확인 필요 3건 · 이자 재계산 차이 2건)는 대사 차이가 아니라 점검 결과입니다 — 대사는 화면의 산수가 맞는지를, 점검은 장부가 정책과 맞는지를 보기 때문입니다. 화면 쪽은 이와 별도로 브라우저 자동화로 돌려 확인했습니다.

도입 후 쓰는 순서

1. 회계연도(필수)를 입력하고 회사 · 금융 유형 · 주된 사업활동 · 기록 범주 · 전기일 · 고객 이름 · 점검 코드 · 점검 결과는 필요한 것만 고른 뒤 조회를 누릅니다.
2. 위쪽 요약에서 점검 필요 · 확인 필요 · 범주 이동 필요 금액을 먼저 봅니다.
3. 손익 건별 점검 탭에서 점검 결과를 점검 필요로 걸러 기록 범주와 재계산 범주를 견줍니다.
4. 행을 눌러 같은 계약의 분기별 건을 비교하고, 어느 정책 행이 적용됐는지 범주 정책표 탭에서 확인합니다.
5. 이자 재계산 근거 탭에서 금액 차이가 난 건을 봅니다.
6. 대사 결과 탭에서 화면의 합계가 서로 맞는지 확인하고, 필요하면 CSV 로 내려받습니다.

실행 화면

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

처음 열었을 때

화면을 열면 2026 으로 자동 조회되어 첫 화면부터 숫자가 차 있습니다. 위쪽 요약은 점검한 손익 건수 · 점검 필요 · 확인 필요 · 범주 이동 필요 금액 · 이자 재계산 차이 건수 · 정합성 대사 차이 건수 여섯 칸이고, 그 아래로 탭 여섯 개가 이어집니다. 조회조건은 회사 · 금융 유형 · 주된 사업활동 · 기록 범주 · 전기일 · 고객 이름 · 점검 코드 · 점검 결과이며 전체를 고르면 그 조건은 질의에서 빠집니다.

손익 건을 범주로 견주기

핵심 화면입니다. 같은 이자수익이라도 사업부가 고객 금융을 주된 사업활동으로 하는지, 대여가 판매와 이어져 있는지에 따라 정책표가 가리키는 범주가 다릅니다. 기록 범주와 재계산 범주가 다르면 그 건의 금액이 이동 필요 금액으로 잡히고 코드와 점검 내용이 붙습니다. 이 자료에서는 60건 가운데 12건이 점검 필요로 걸립니다.

한 건만 보면 맥락이 없습니다. 상세 창은 같은 계약의 1~3분기 건을 위아래로 놓아 어느 분기부터 범주가 어긋났는지 보여 줍니다. 계약의 금융 유형 · 주된 사업활동 · 판매 연계 같은 속성도 함께 적혀 있어 정책표의 어느 행이 적용됐는지 따라가기 쉽습니다.

범주별 합계와 이자 재계산

범주를 옮기면 소계가 얼마나 움직이는지가 한눈에 보입니다. 회사 1000 은 투자·재무·범주 미지정으로 기록된 금액이 영업범주로 돌아가야 하고, 회사 2000 은 영업범주로 기록된 분리 대여금 이자가 투자범주로 가야 합니다. 판단 보류 행은 회사가 판매 연계 여부를 확정하기 전까지 비워 두는 칸입니다.

범주가 맞아도 금액이 틀릴 수 있습니다. 손익 건마다 기간 평균 원금 · 연 이자율 · 일수를 적고 같은 산식으로 다시 계산해 장부 이자와 비교합니다. 차이가 허용 범위(1,000원)를 넘으면 점검 필요로 걸립니다. 산식은 컬럼에 그대로 적혀 있어 현업이 손으로 검산할 수 있습니다.

정책표와 대사

재계산의 기준은 코드가 아니라 이 표입니다. 정책이 바뀌면 이 표만 고치면 되도록 분리해 두었습니다. 근거 문장이 함께 있어 감사인에게 왜 이 건이 투자범주인지를 설명할 때 그대로 인용할 수 있습니다.

화면이 보여 주는 숫자가 서로 맞는지를 화면이 스스로 검산합니다. 계약별 합계와 건별 합계, 범주별 합계와 건별 합계, 재계산 범주 합계와 장부 범주 합계가 맞물리는지 매번 다시 잽니다. 범주를 옮겨도 합계는 변하지 않아야 한다는 사실이 R04 에 들어 있습니다.

SAP 표준 기능 확장 포인트

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

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

IFRS 18 요구사항 매핑

기준서 문단 번호는 적지 않고 요구사항의 이름으로만 대응합니다. 번역 · 개정에 따라 번호가 달라질 수 있어서입니다. 이 표는 화면이 어떤 질문에 답하는지를 정리한 것이며 기준서 해석을 대신하지 않습니다.

T-code 별 연계 지점

운영에 올릴 때 “기존 조회를 없애야 하느냐”는 질문이 꼭 나옵니다. 대부분은 없애지 않고 둡니다 — 대사와 감사 대응은 표준 거래가 맡는 편이 안전합니다.

CDS 구성

이 사례의 화면은 분기별 손익 건 60건을 그대로 읽습니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일은 정책 적용과 집계를 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰를 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 범주 정책 테이블

모든 점검이 이 표에서 갈립니다. 어느 조합이 영업이고 어느 조합이 투자인지를 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 정책이 바뀌어도 과거 기간의 점검 결과가 흔들리지 않게 하기 위해서입니다.

"  정책 테이블 — 범주 정책 (투명 테이블)
"  운영에서는 회사의 회계정책 문서에 있는 표를 그대로 옮겨 담는다.
"  코드에 박지 않는 이유 : 정책은 바뀌고, 바뀔 때마다 개발자를
"  부르게 만들면 점검 결과가 금방 낡는다.
@EndUserText.label : '고객 금융 손익 범주 정책'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zinstl_policy {
  key mandt      : mandt not null;
  key pol_no     : abap.char(3) not null;   " P01 ...
  main_act       : abap.char(1);            " Y 주된 사업활동 / N 아님
  fin_type       : abap.char(1);            " I 할부판매 / L 대여 / D 연체 / K 차입
  link_sale      : abap.char(1);            " Y 연계 / N 분리 / ? 미확정 / - 해당 없음
  expect_cat     : abap.char(3);            " OPR / INV / FIN / CNF(판단 보류)
  basis          : abap.char(120);          " 정책 근거 문장
  valid_from     : abap.dats;
  valid_to       : abap.dats;
}

② 계약 속성 뷰

정책표의 세 열(주된 사업활동 · 금융 유형 · 판매 연계)이 어디서 오는지가 도입의 두 번째 질문입니다. 계약 관리 데이터의 위치는 회사마다 달라 확인 필요로 두었습니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '고객 금융 계약 속성'
define view entity ZI_InstlContract
  as select from zinstl_contract as c           " 확인 필요 : 계약 속성의 실제 원천
  association [0..1] to I_Customer as _Cust
    on _Cust.Customer = $projection.Customer
{
  key c.bukrs        as CompanyCode,
  key c.cont_no      as ContractNo,
      c.kunnr        as Customer,
      _Cust.CustomerName,
      c.seg_no       as Segment,               " 사업부
      c.main_act     as MainAct,               " 주된 사업활동 여부 — 사업부 단위로 회사가 정한다
      c.fin_type     as FinType,
      c.link_sale    as LinkSale,
      @Semantics.amount.currencyCode : 'Currency'
      c.principal    as Principal,
      c.rate         as Rate,                  " 연 이자율(%)
      c.waers        as Currency,
      _Cust
}

③ 손익 건 뷰 — 정책 적용

ACDOCA 의 이자 손익 건에 계약 속성을 붙이고 정책표를 매칭해 재계산 범주를 정합니다. 기록 범주는 손익 계정의 범주 매핑에서 읽으며, 매핑의 위치는 확인 필요입니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '고객 금융 손익 건'
define view entity ZI_InstlLine
  as select from acdoca as j
  inner join ZI_InstlContract as k
    on  k.CompanyCode = j.rbukrs
    and k.ContractNo  = j.zuonr                    " 확인 필요 : 계약 번호를 싣는 필드
  left outer join zinstl_policy as p
    on  p.main_act  = k.MainAct
    and p.fin_type  = k.FinType
    and ( p.link_sale = k.LinkSale or p.link_sale = '-' )
    and p.valid_from <= j.budat and p.valid_to >= j.budat
{
  key j.rldnr  as Ledger,
  key j.rbukrs as CompanyCode,
  key j.gjahr  as FiscalYear,
  key j.belnr  as DocNo,
  key j.docln  as DocLine,
      k.ContractNo,
      j.racct  as GlAcct,
      j.budat  as PostDate,
      @Semantics.amount.currencyCode : 'Currency'
      j.hsl    as Amount,
      j.rhcur  as Currency,
      " 기록 범주 : 손익 계정의 범주 매핑 — 확인 필요
      cast( '' as abap.char(3) ) as BookedCat,
      coalesce( p.expect_cat, 'NON' ) as ExpectCat,
      p.pol_no as PolicyNo
}
where j.rldnr = '0L'
  and j.racct between '4710000000' and '4719999999'   " 이자 손익 계정 범위 — 회사 계정 체계에 맞게 확인 필요

④ 이자 재계산 뷰

산식은 한 번만 정의합니다. 원 미만 반올림은 DB 가 아니라 이 뷰에서 정해야 화면 · 배치 · 쿼리가 같은 값을 봅니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '고객 금융 이자 재계산'
define view entity ZI_InstlCalc
  as select from ZI_InstlLine as l
  inner join ZI_InstlContract as k
    on k.CompanyCode = l.CompanyCode and k.ContractNo = l.ContractNo
{
  key l.CompanyCode, key l.FiscalYear, key l.DocNo, key l.DocLine,
      k.ContractNo,
      @Semantics.amount.currencyCode : 'Currency'
      l.Amount                                           as BookAmt,
      " 평균 원금 × 연 이자율(%) ÷ 100 × 일수 ÷ 365 — 일수와 평균 원금의 원천은 확인 필요
      cast( round( k.Principal * k.Rate / 100 * 91 / 365, 0 ) as abap.curr(18,0) ) as CalcAmt,
      l.Currency
}

⑤ 계약별 집계 뷰

계약별 점검 탭의 원천입니다. 기록 범주와 재계산 범주가 다른 건의 금액을 이동 필요 금액으로 모읍니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '계약별 범주 점검 집계'
define view entity ZI_InstlContractAgg
  as select from ZI_InstlLine as l
{
  key l.CompanyCode, key l.FiscalYear, key l.ContractNo,
      @Semantics.amount.currencyCode : 'Currency'
      sum( l.Amount )                                         as IntBook,
      sum( case when l.BookedCat <> l.ExpectCat
                then l.Amount else 0 end )                    as MoveAmt,
      sum( case when l.ExpectCat = 'CNF' then 1 else 0 end )  as ConfCnt,
      count( * )                                              as LineCnt,
      l.Currency
}
group by l.CompanyCode, l.FiscalYear, l.ContractNo, l.Currency

⑥ 범주별 합계 쿼리

범주를 옮겨도 합계는 변하지 않아야 한다는 사실이 대사 R04 에 들어 있습니다. 쿼리는 이 성질을 그대로 보여 줍니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '범주별 합계'
@Analytics.query                  : true
define view entity ZC_InstlCatQuery
  as select from ZI_InstlLine as l
{
  key l.CompanyCode, key l.FiscalYear,
      @AnalyticsDetails.query.axis : #ROWS
      l.BookedCat                                           as BookedCategory,
      @Semantics.amount.currencyCode : 'Currency'
      sum( l.Amount )                                       as BookAmt,
      l.Currency
}
group by l.CompanyCode, l.FiscalYear, l.BookedCat, l.Currency

⑦ 권한 (DCL)

권한은 집계를 읽는 자리에 겁니다. 드릴스루 같은 하위 뷰에만 걸면 전체 합계와 자기 몫의 차이로 남의 숫자가 드러납니다.

@EndUserText.label : '손익 건 접근 제어'
@MappingRole : true
define role ZI_INSTLLINE {
  grant select on ZI_InstlLine
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 전환에서 정해야 할 항목

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문들입니다. 세 묶음으로 나눠 적었습니다.

범주와 정책

금액과 SAP 연계

운영과 도입