SAP 미개시 리스 약정 공시 점검 — IFRS 16, 계약은 맺었지만 아직 시작하지 않은 리스의 약정을 주석에 맞게 밝혔는지 기준 금액과 견줘 보는 결산 화면

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

결산 때 주석 담당자가 가장 늦게 받는 자료가 “계약은 했지만 아직 시작하지 않은 리스”입니다. 이 계약들은 아직 리스부채로 인식되지 않기 때문에 원장에 흔적이 없고, 계약 관리 파일이나 구매·총무 부서의 메일에만 남아 있습니다. 그래서 주석의 약정 공시는 해마다 누군가의 기억과 엑셀에 기대어 채워집니다. 이 앱은 그 계약 목록을 한 화면에 모아, 주석에 적은 금액이 기준 약정액과 같은지, 이미 개시된 계약의 공시가 남아 있지는 않은지, 개시일이 지났는데 리스부채가 잡혔는지를 계약 단위로 다시 계산해 보여 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 공시가 비어 있던 계약 네 건

사례 자료는 가상의 두 회사(1000·2000)가 가진 계약 28건입니다. 보고기간말 현재 개시 전이라 약정 공시 대상인 계약의 기준 약정액은 합계 19,543백만 원, 주석에 적힌 공시 금액은 20,197백만 원으로 총액만 보면 654백만 원 더 많이 적혀 있어 큰 문제가 없어 보입니다. 그런데 계약 단위로 가르면 이야기가 달라집니다.

• 공시 누락(P01) 4건 — 약정은 맺었는데 공시 금액이 0입니다. 기준 약정액은 합쳐 1,838백만 원입니다.
• 금액 차이(P02) 4건 — 기준 942백만 원인데 372백만 원만 들어간 식으로, 리스 기간 전체가 아니라 일부만 반영됐을 가능성이 있습니다.
• 개시 후 공시 잔존(P03) 2건 — 이미 개시됐는데 공시가 2,820백만 원 남아 있어, 그 금액이 총액을 부풀리고 있었습니다.
• 보고기간 후 체결 공시(P05) 2건 — 결산 뒤에 맺은 계약 242백만 원이 약정으로 들어가 있었습니다.

총액이 비슷해 보이던 이유는 부풀려진 공시와 빠진 공시가 서로 상쇄했기 때문입니다. 합계만 맞춰 보던 방식으로는 이 상쇄를 알 수 없고, 계약 단위로 기준과 공시를 견주어야 드러납니다. 화면의 “구간별 차이 절댓값 합”은 이 상쇄를 풀어 5,470.8백만 원으로 보여 줍니다.

도입하면 달라지는 것

• 주석 초안 점검 — 합계만 맞추던 일이 계약 단위 확인으로 바뀌고, 상쇄된 오류가 드러납니다.
• 담당 부서와의 대화 — “이 계약이 빠졌습니다”를 계약번호와 금액으로 바로 말할 수 있습니다.
• 해석이 갈리는 계약의 분리 — 회사가 판단할 계약은 확인 필요로 분리되어, 판단 근거를 남기는 일이 따로 관리됩니다.
• 다음 결산으로 이어지는 기준 — 같은 규칙으로 매번 계산하므로 담당자가 바뀌어도 결과가 같습니다.

이런 회사에 맞습니다

부동산·차량·설비 리스 계약이 여러 건이고 개시 전 계약이 해마다 몇 건씩 걸쳐 있는 회사, 약정 공시를 엑셀과 계약서 확인으로 채우고 있는 재무보고 조직, 그리고 감사인에게 약정 공시의 근거를 계약 단위로 설명해야 하는 회사에 맞습니다. 반대로 개시 전 계약이 거의 없다면 이 앱의 값은 크지 않습니다.

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

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

정합성 대사 여섯 건은 모두 차이 0입니다. 참고 대사의 차이 12건은 점검 화면이라 일부러 넣은 예외 계약이며, 정합성 대사의 차이 건수와 섞이지 않게 구분해 둡니다.

도입 후 쓰는 순서

1. 회계연도(필수)와 필요하면 회사·기초자산 유형·개시 시기 구간·약정일 기간을 골라 조회를 누릅니다. 계약명 칸에서 Enter 를 눌러도 됩니다.
2. 맨 위 요약 일곱 칸으로 점검 규모를 봅니다. 공시 누락·금액 차이 계약 수는 서비스의 함수로 따로 받아 옵니다.
3. 계약별 표에서 점검 필요와 확인 필요 계약을 훑고, 행을 눌러 연도별 일정을 확인합니다.
4. 개시 시기 구간별·유형별 합계 탭에서 어디에 몰려 있는지 봅니다.
5. 대사 탭에서 정합성 대사 여섯 건이 0인지 확인한 뒤, 참고 대사의 차이 계약을 담당 부서와 확인합니다.
6. 현재 탭의 결과는 CSV 로 내려받아 주석 초안 점검 근거로 보관합니다.

실행 화면

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

처음 열었을 때

약정 공시 점검은 “어느 계약이 문제인가”를 찾는 일이라 표가 맨 앞에 있습니다. 점검 필요는 주황, 확인 필요는 파랑, 정상은 초록 상태 표시로 구분해 한눈에 훑을 수 있게 했습니다.

조건으로 좁히기

조회조건의 “전체”는 서버로 보내지 않는 조건입니다. 값을 고른 칸만 $filter 로 나가므로 서버가 받는 질의가 짧고, 조건을 풀면 곧바로 전체로 돌아옵니다.

합계로 보기

공시가 비어 있는 약정이 곧 개시되는 계약인지 먼 미래의 계약인지에 따라 대응 순서가 달라집니다. 구간별 합계가 계약별 합계와 맞는지는 대사 탭에서 다시 확인합니다.

금액이 큰 유형이 아니라 점검 계약 수가 많은 유형을 먼저 보는 용도입니다. 같은 유형에서 반복되면 계약 등록 절차나 공시 수작업의 문제일 가능성이 큽니다.

대사와 상세

정합성 대사는 모두 차이 0이어야 하고, 참고 대사의 차이는 점검 대상 그 자체입니다. 둘을 섞지 않으려고 구분(정합성/참고)을 컬럼으로 따로 두었습니다.

기준 약정액이 왜 그 금액인지 일정으로 설명할 수 있어야 공시 담당자가 숫자를 믿습니다. 일정 합계가 총 고정 리스료와 같은지는 대사 001 이 매번 확인합니다.

조회조건 한눈에 보기

점검 코드

한 계약에 둘 이상 해당하면 우선순위가 높은 코드 하나만 표시합니다.

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

기존 거래를 없애지 않고 이 앱과 나란히 두는 것이 안전합니다. 이 앱이 가리킨 계약을 표준 거래에서 확인하는 순서입니다.

OData 구성

화면은 서비스 정의(manifest)에 선언된 OData V2 서비스 하나만 바라봅니다. 서비스 경로는 앱 안에서 상대 경로로만 쓰고, 엔티티셋 다섯 개와 함수 하나를 내보냅니다.

조회조건은 $filter 로만 보내고, 정렬·페이징은 $orderby·$top·$skip, 총건수는 $inlinecount=allpages 로 받습니다. 약정일 같은 날짜 조건은 서비스가 직접 비교하며, “전체”를 뜻하는 별도 코드값은 서버로 보내지 않습니다.

이 앱이 하지 않는 것

• 약정에 해당하는지, 어느 금액을 공시할지 판단하지 않습니다. 코드는 점검 신호이고 판단은 회사와 감사인의 몫입니다.
• 주석 문구를 만들거나 공시 금액을 고치지 않습니다. 이 앱은 조회·점검 전용입니다.
• 기준서 문단번호를 인용하지 않습니다. 원문을 확인하기 전에는 적지 않는다는 원칙입니다.

CDS 구성

이 사례의 화면은 계약 28건과 일정 147줄을 서비스가 들고 계산합니다. 데모라서 되는 일이고, 운영 데이터에서는 계약 마스터와 원장 라인을 CDS 로 모아 같은 모양으로 내려 줍니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 정책 테이블

보고기간말과 구간 경계를 코드가 아니라 설정으로 둡니다. 운영 전환에서 가장 먼저 합의해야 하는 항목입니다.

" 리스 약정 공시 점검 정책 (투명 테이블 스케치)
@EndUserText.label : '약정 공시 점검 정책'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table lease_cmt_policy {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key gjahr      : gjahr not null;
  period_end     : abap.dats;           " 보고기간말
  near_months    : abap.int2;           " 가까운 구간 경계(개월) — 사례는 3
  far_months     : abap.int2;           " 먼 구간 경계(개월) — 사례는 12
  cancel_rule    : abap.char(1);        " 개시 전 해지 가능 계약 처리 — 확인 필요(회사 판단)
}

② 계약 원천 뷰

계약 마스터를 읽는 자리입니다. 리스 계약을 어디서 관리하느냐에 따라 이 뷰만 달라집니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '리스 계약 원천'
define view entity LeaseCmtContract
  as select from lease_contract_src as c      " 확인 필요 : 실제 계약 마스터 이름
{
  key c.bukrs        as Bukrs,
  key c.contract_no  as ContractNo,
      c.contract_name as ContractName,
      c.asset_class  as AssetClass,
      c.sign_date    as SignDate,            " 체결일
      c.comm_date    as CommDate,            " 개시 예정일
      c.term_months  as TermMonths,          " 리스 기간(개월)
      @Semantics.amount.currencyCode : 'Waers'
      c.monthly_amt  as MonthlyAmt,          " 월 고정 리스료
      c.cancel_flag  as CancelFlag,          " 개시 전 해지 가능 — 확인 필요
      c.waers        as Waers
}

③ 점검 계산 뷰

기준 약정액과 점검 코드를 정하는 핵심 뷰입니다. 우선순위는 화면의 판정 규칙과 같아야 합니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '약정 공시 점검 계산'
define view entity LeaseCmtBase
  as select from LeaseCmtContract as k
  inner join lease_cmt_policy     as p on p.bukrs = k.Bukrs
  association [0..1] to lease_cmt_disc as _d              " 주석 공시 관리 — 확인 필요
    on _d.bukrs = k.Bukrs and _d.contract_no = k.ContractNo
{
  key p.gjahr        as Gjahr,
  key k.Bukrs,
  key k.ContractNo,
      k.SignDate,
      k.CommDate,
      @Semantics.amount.currencyCode : 'Waers'
      k.MonthlyAmt * k.TermMonths                   as TotalAmt,

      " 기준 약정액 : 보고기간말 이전 체결 AND 개시 전 AND 해지 불가
      @Semantics.amount.currencyCode : 'Waers'
      case when k.SignDate <= p.period_end
            and k.CommDate >  p.period_end
            and k.CancelFlag = 'N'
           then k.MonthlyAmt * k.TermMonths
           else 0 end                               as ExpoAmt,

      @Semantics.amount.currencyCode : 'Waers'
      coalesce( _d.disc_amt, 0 )                    as DiscAmt,

      case
        when k.CancelFlag = 'Y' and k.CommDate > p.period_end then 'P09'
        when k.SignDate > p.period_end and coalesce( _d.disc_amt, 0 ) > 0 then 'P05'
        when k.CommDate <= p.period_end and coalesce( _d.disc_amt, 0 ) > 0 then 'P03'
        when k.SignDate <= p.period_end and k.CommDate > p.period_end
             and coalesce( _d.disc_amt, 0 ) = 0 then 'P01'
        else 'P00'                                  " P02·P04 는 금액·부채 인식 비교가 더 필요 — 생략
      end                                           as CheckCode,
      k.Waers
}

④ 구간 집계 뷰

@Analytics.dataCategory : #CUBE
@EndUserText.label      : '개시 시기 구간별 합계'
define view entity LeaseCmtBucket
  as select from LeaseCmtBase as b
{
  key b.Gjahr,
  key b.Bukrs,
  key case
        when b.ExpoAmt = 0 and b.DiscAmt > 0 then 'C9'   " 약정 대상 아님(공시 잔존)
        when months_between( b.CommDate, $session.system_date ) <= 3  then 'C1'
        when months_between( b.CommDate, $session.system_date ) <= 12 then 'C2'
        else 'C3'
      end as BucketCode,
      count( * )                          as ItemCnt,
      @Semantics.amount.currencyCode : 'Waers'
      sum( b.ExpoAmt )                    as ExpoAmt,
      @Semantics.amount.currencyCode : 'Waers'
      sum( b.DiscAmt )                    as DiscAmt,
      b.Waers
}
group by b.Gjahr, b.Bukrs, b.Waers

구간 경계는 설정 테이블의 값으로 바꾸고, 날짜 함수 이름은 환경마다 다를 수 있어 확인이 필요합니다. 위 코드는 구조를 보여 주는 스케치입니다.

⑤ 권한

@EndUserText.label : '약정 공시 점검 권한'
@MappingRole : true
define role LeaseCmtBaseRole {
  grant select on LeaseCmtBase
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

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

자주 묻는 질문

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

계산과 판정

범위와 한계

도입과 운영