SAP 변동리스료 구분·인식 점검 — IFRS 16, 리스료를 고정분과 변동분으로 다시 나눠 장부와 맞춰 보는 월마감 화면

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

리스 계약에 변동리스료가 섞여 있으면 월마감 때마다 같은 질문이 나옵니다. 이번 달 낸 리스료 가운데 리스부채를 줄인 몫은 얼마이고, 비용으로 털어야 할 몫은 얼마인가. 고정이면 계약서 한 줄로 끝나지만, 매출에 연동하거나 최소보장이 붙으면 매달 다시 나눠야 합니다. 지금은 이 계산이 엑셀 한 장과 담당자의 기억에 걸려 있고, 장부와 어긋나도 어느 달부터인지 찾는 데 하루가 갑니다. 이 앱은 그 계산을 계약·월 단위로 다시 해서 장부와 나란히 놓고, 어긋난 곳만 골라 보여 줍니다.

핵심 포인트 여섯 가지

누가 어떻게 쓰는가

쓰는 사람은 세 부류입니다. 결산 담당자는 월마감 전에 점검 필요만 걸러 보며 전표 수정 대상을 정합니다. 리스 회계 담당자는 최소보장이 있는 계약에서 어디까지를 고정으로 볼지 판단 근거를 찾습니다. 감사 대응 담당자는 구조별 집계와 월별 합계로 공시에 필요한 ‘변동리스료 비용’ 의 흐름을 설명합니다. 세 부류 모두 같은 숫자를 보므로, 회의에서 “내 엑셀은 다르다” 는 말이 줄어듭니다.

이 앱이 하지 않는 일

분명히 해 둘 것이 있습니다. 이 앱은 회계처리를 확정하지 않습니다. 최소보장 리스료를 실질 고정으로 볼지, 지수 연동분을 어떻게 다룰지는 회사와 감사인이 판단할 몫이고, 이 화면은 그 판단을 할 때 필요한 숫자를 계약·월 단위로 모아 줍니다. 또 지수·요율 연동 변동리스료는 리스부채에 포함되는 별도 논점(재측정)이라 이 화면의 대상이 아닙니다.

샘플 데이터에 대해

화면과 숫자는 모두 검증용 가상 데이터입니다. 리스 계약 10건(고정 3 · 최소보장+매출연동 4 · 매출연동 2 · 사용량연동 1)을 1~9월로 만든 88행이며, 실제 고객사의 계약·계정·금액은 쓰지 않았습니다. 실제 도입에서는 계약 조건과 매출·사용 실적, 장부 계정 매핑을 고객 환경에서 받아 같은 모양으로 채웁니다.

실행 화면

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

처음 열었을 때

화면을 열면 회계연도 2026 으로 한 번 자동 조회합니다. 조회 버튼은 조건 영역 오른쪽 끝에 있고, 회계연도 칸에서 Enter 를 눌러도 조회됩니다. 숫자를 읽는 순서는 요약 → 계약별 구분 표입니다. 요약에서 ‘비중’ 이 한 줄로 보이므로 변동분이 전체 리스료에서 얼마나 되는지 먼저 감이 잡힙니다.

점검할 곳만 추리기

88행 가운데 8행만 남습니다. 이 8건은 점검 동작을 보이려고 샘플에 의도적으로 넣은 것이며 V01 3건, V02 3건, V03 2건입니다. 화면은 원인을 단정하지 않고 “어디를 확인하라” 까지만 적습니다. 원인 판단은 계약 조건과 회계처리를 보는 사람의 몫입니다.

한 계약을 열어 보기

고정분 재계산과 장부 리스부채 반영액, 변동분 재계산과 장부 변동리스료 비용을 한 줄에서 비교합니다. 한 계약의 아홉 달을 위아래로 훑으면 어느 달에서 장부가 어긋나기 시작했는지 바로 보입니다.

달별로 보기

점검 필요 계약이 있는 달이 어디인지 먼저 찾는 자리입니다. 월별 합계 탭에는 계약·리스료 구조 조건이 적용되지 않고 회계연도와 기간만 따릅니다. 월 단위 대사식(R02, R05)이 이 탭의 합계를 계약별 합계와 맞춰 봅니다.

구조별로 보기

고정 계약은 변동분이 0이고, 매출연동과 사용량연동은 지급 전액이 변동분입니다. 최소보장+매출연동은 둘이 섞여 있어 구조마다 비중이 크게 갈립니다. 어느 구조에서 점검 필요가 몰리는지 한눈에 보입니다.

대사로 마무리

정합성 대사 R01~R05 는 차이 0건이어야 하고, E01~E03 은 의도적으로 넣은 예외 건수(3·3·2)입니다. 두 부류를 섞지 않고 따로 세어, 대사 차이가 ‘0건’ 이라는 말이 예외 8건과 모순되지 않게 했습니다.

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

요구사항 매핑

IFRS 16 리스(K-IFRS 제1116호)는 2019-01-01 이후 개시하는 회계연도부터 적용됩니다. 아래는 이 화면이 도와주는 요구사항과 대응 기능입니다. 문단번호는 원문 확인 전이라 적지 않았습니다.

확장하는 방향 세 가지

운영에 올릴 때 손이 가는 확장은 대체로 셋입니다. 첫째, 연동 기준액(매장 매출·설비 사용량)을 받아 오는 원천을 고객 환경에 맞게 잇는 일입니다. 둘째, 장부 금액을 가져오는 계정 매핑입니다. 어느 계정이 리스부채 상환이고 어느 계정이 변동리스료 비용인지를 정해야 합니다. 셋째, 점검 허용 폭입니다. 샘플은 1,000원이지만 운영에서는 통화 단위와 회사 정책에 맞춰 조정합니다. 세 가지 모두 서비스 쪽 설정이어서 화면은 고치지 않습니다.

CDS 구성

이 사례의 화면은 샘플 88행을 브라우저가 받아 보여 줍니다. 데모라서 되는 일이고, 운영 데이터에서는 재계산과 대사를 CDS 로 내립니다. 아래는 그때 만드는 뷰를 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 계약 조건 뷰

재계산의 출발점입니다. 최소보장액과 연동률은 계약서에서 오므로 RE-FX 를 쓰는 환경이면 계약 조건 항목에서, 아니면 별도 관리표에서 받아 옵니다. 어느 쪽이든 이 뷰 하나로 모아 두면 아래 계산 뷰가 바뀌지 않습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '리스 계약 조건'
define view entity ZI_LeaseRentTerm
  as select from lease_term_source          // 계약 조건 원천 — RE-FX 조건 또는 관리표 (환경별 확인 필요)
{
  key LeaseContract,
      CompanyCode,
      RentType,                             // FIX 고정 · MGR 최소보장+매출연동 · TURN 매출연동 · USE 사용량연동
      @Semantics.amount.currencyCode: 'Currency'
      MinRent,                              // 월 고정액 또는 최소보장액
      @Semantics.quantity.unitOfMeasure: 'PctUnit'
      TurnRatePct,                          // 연동률(%)
      Currency,
      StartDate, EndDate
}

② 장부 실적 뷰

ACDOCA 에서 두 종류의 금액을 계약·월로 모읍니다. 리스부채 상환으로 전기된 금액과 변동리스료 비용 계정 금액입니다. 어떤 계정이 어느 쪽인지는 운영에서 확정하는 항목이라 매핑 테이블을 둡니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '리스료 장부 반영액'
define view entity ZI_LeaseRentBook
  as select from I_JournalEntryItem as je
    inner join   lease_acct_map     as mp               // 계정 → 부채 상환 / 변동 비용 (운영에서 확정)
      on mp.GLAccount = je.GLAccount
{
  key je.CompanyCode,
  key je.FiscalYear,
  key substring( je.PostingDate, 5, 2 )          as Period,
  key je.LeaseContractRef                        as LeaseContract,    // 계약 참조 필드 (환경별 확인 필요)
      @Semantics.amount.currencyCode: 'Currency'
      sum( case mp.Role when 'LIAB' then je.AmountInCompanyCodeCurrency else 0 end ) as BookLiab,
      @Semantics.amount.currencyCode: 'Currency'
      sum( case mp.Role when 'VAR'  then je.AmountInCompanyCodeCurrency else 0 end ) as BookVar,
      je.CompanyCodeCurrency                     as Currency
}
group by je.CompanyCode, je.FiscalYear, substring( je.PostingDate, 5, 2 ),
         je.LeaseContractRef, je.CompanyCodeCurrency

③ 고정분·변동분 계산 뷰

화면이 하던 계산을 DB 로 옮긴 자리입니다. 규칙은 세 줄입니다. 연동 계산액 = 기준액 × 연동률, 지급 대상 = 구조별로 정한 값, 변동분 = 지급 대상 − 고정분.

define view entity ZI_LeaseRentSplit
  as select from ZI_LeaseRentTerm as t
    inner join   lease_basis_month as b                 // 월별 매출·사용 실적 (원천은 환경별 확인 필요)
      on b.LeaseContract = t.LeaseContract
{
  key t.LeaseContract,
  key b.ReportMonth                                                  as Period,
      t.RentType,
      b.Basis,
      cast( b.Basis * t.TurnRatePct / 100 as abap.dec(15,0) )        as TurnCalc,
      case t.RentType
        when 'FIX'  then t.MinRent
        when 'MGR'  then greatest( t.MinRent, cast( b.Basis * t.TurnRatePct / 100 as abap.dec(15,0) ) )
        else             cast( b.Basis * t.TurnRatePct / 100 as abap.dec(15,0) )
      end                                                            as PayCalc,
      case when t.RentType = 'TURN' or t.RentType = 'USE'
           then 0 else t.MinRent end                                 as FixedCalc   // 변동분 = PayCalc - FixedCalc
}

④ 점검 뷰

장부와 재계산의 차이를 허용 폭과 견주어 점검 코드를 붙입니다. 허용 폭을 파라미터로 받으면 회사 정책이 바뀔 때 뷰를 고치지 않아도 됩니다.

define view entity ZI_LeaseRentCheck
  with parameters p_tol : abap.dec(15,0)               // 허용 폭 — 샘플 1,000
  as select from ZI_LeaseRentSplit as s
    left outer join ZI_LeaseRentBook as k
      on k.LeaseContract = s.LeaseContract and k.Period = s.Period
{
  key s.LeaseContract, key s.Period,
      s.FixedCalc, s.PayCalc - s.FixedCalc            as VarCalc,
      k.BookLiab - s.FixedCalc                        as DiffLiab,
      k.BookVar  - ( s.PayCalc - s.FixedCalc )        as DiffVar,
      case
        when k.BookLiab - s.FixedCalc >  $parameters.p_tol then 'V01'   // 부채 반영이 고정분보다 큼
        when k.BookLiab - s.FixedCalc < -$parameters.p_tol then 'V03'   // 부채 반영이 고정분보다 작음
        when abs( k.BookVar - ( s.PayCalc - s.FixedCalc ) ) > $parameters.p_tol then 'V02'
        else 'OK'
      end                                             as CheckCode
}

⑤ 월별·구조별 집계 뷰

합계를 따로 만들되 같은 점검 뷰를 읽게 합니다. 그래야 “계약별 합계 = 월별 합계 = 구조별 합계” 대사가 구조적으로 맞고, 어긋나면 진짜 데이터 문제로 드러납니다.

define view entity ZI_LeaseRentMonth
  with parameters p_tol : abap.dec(15,0)
  as select from ZI_LeaseRentCheck( p_tol : $parameters.p_tol )
{
  key Period,
      sum( FixedCalc )                              as FixedCalc,
      sum( VarCalc )                                as VarCalc,
      sum( case CheckCode when 'OK' then 0 else 1 end ) as NeedCnt
}
group by Period

⑥ OData 로 노출하는 서비스 정의

화면이 바라보는 서비스입니다. 엔티티셋 이름과 키가 화면의 바인딩과 정확히 같아야 하며, 날짜 칸은 $filter 에서 날짜 형식으로 비교되도록 Edm.DateTime 으로 둡니다.

@EndUserText.label: '변동리스료 점검 서비스'
define service varlease_srv {
  expose ZC_LeaseRentQuery  as ContractSet;   // 키 Gjahr · Period · ContractNo
  expose ZI_LeaseRentMonth  as MonthSet;
  expose ZI_LeaseRentType   as TypeSet;
  expose ZI_LeaseRentRecon  as ReconSet;
}

⑦ 권한(DCL)

권한은 집계를 읽는 자리에 겁니다. 상세 행에만 걸면 전사 합계에서 자기 몫을 빼서 남의 회사코드 금액을 알아낼 수 있기 때문입니다.

@EndUserText.label: '리스료 점검 권한'
@MappingRole: true
define role ZI_LEASERENTBOOK {
  grant select on ZI_LeaseRentBook
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 전환에서 정할 항목

자주 묻는 질문

리스 회계 기준

화면과 숫자

데이터와 SAP 연계

도입과 운영