SAP 사용권자산·리스부채 재무상태표 표시 점검 — IFRS 16, 별도 표시했는지·합산했다면 주석에 밝혔는지·표시 항목 합계가 계약과 맞는지 한 화면에서

개발 배경 — 이 앱을 사용해야 하는 이유

리스 회계의 재무상태표 표시는 숫자를 맞추는 일이 아니라 어디에 놓았는가를 확인하는 일입니다. 사용권자산과 리스부채는 별도 항목으로 표시하거나, 다른 항목에 합산했다면 그 항목을 주석에 밝히는 것이 IFRS 16 리스(K-IFRS 제1116호)의 요구이고, 임대·시세차익 목적의 사용권자산은 투자부동산 정의에 해당할 수 있는지도 따져야 합니다. 그런데 결산에서는 이 확인이 계정 잔액 조회, 주석 자료, 계약 목록으로 흩어져 있어 “금액은 맞는데 위치와 공시는 맞는지”가 마지막에 몰립니다.

이 앱은 계약 한 건마다 장부에 놓인 표시 위치와 회사 표시 정책·보유 목적으로 정한 점검 기준 위치를 나란히 두고, 합산해 표시했다면 주석에 밝혔는지, 리스부채의 유동·비유동 합이 잔액과 같은지를 한 표에 보여 줍니다. 그리고 표시 항목별 합계가 계약별 합계와 맞는지를 대사식으로 매번 검산합니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 합계는 맞는데 위치가 다른 계약

샘플 데이터에서 사용권자산 표시 항목 합계와 계약별 합계는 26,601백만 원으로 같습니다. 그런데 계약 단위로 내려가면 임대 목적의 상가 전대 계약과 투자 목적 토지 계약, 임대용 사옥 일부 전대 계약 세 건의 사용권자산이 투자부동산이 아닌 항목에 놓여 있어 점검 코드 P01 로 나옵니다(실제 장부에서는 보유 목적과 정의 해당 여부 확인 필요). 합계 대사만 봤다면 지나쳤을 지점입니다. 한편 리스부채는 두 계약에서 유동과 비유동의 합이 잔액과 15백만 원, 22백만 원 달라 P05 로 나옵니다.

도입하면 달라지는 것

• 결산 막판 질의 — 어느 계약의 표시 위치와 주석 공시를 먼저 볼지 미리 정해 둘 수 있습니다.
• 확인 순서 — 총액이 아니라 점검 코드별로 계약을 추려 열어 볼 수 있습니다.
• 설명 자료 — 판정 규칙과 대사 결과가 화면에 있어 감사 질의에 같은 자료로 답합니다.

이런 회사에 맞습니다

리스 계약이 건물·차량·설비·IT 장비·토지로 여러 유형에 걸쳐 있고, 회사코드마다 표시 정책이 다른 그룹사를 결산하는 재무회계팀에 맞습니다. 계약을 RE-FX 등으로 관리하면서 장부의 표시 위치를 별도로 점검하고 싶은 경우에도 출발점이 됩니다.

사용 방법

1. 회계연도를 확인하고 필요하면 회사·기초자산 유형·보유 목적·장부 표시·전기일 기간·계약명·점검 코드·점검 결과를 고른 뒤 조회를 누릅니다(Enter 도 됩니다).
2. 요약 숫자에서 점검한 계약 수와 표시 항목 이동 검토, 확인 필요, 주석 공시 점검 건수를 봅니다.
3. 점검 코드를 골라 다시 조회해 해당 계약만 추립니다.
4. 탭을 오가며 재무상태표 표시 항목, 기초자산 유형별 합계, 대사 결과를 확인합니다.
5. 계약 행을 눌러 보유 목적·표시 항목·전표 라인을 확인합니다.
6. 필요하면 현재 탭을 CSV 로 내려받습니다.

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

이 화면의 데이터는 모두 가상의 검증용 샘플이며, 실제 고객사의 계약·금액은 쓰지 않았습니다.

이와 별도로 리스부채의 유동과 비유동 합이 잔액과 다른 계약 2건(최대 22백만 원)은 화면 동작을 보이려고 의도적으로 넣은 예외이며, 대사 차이 건수와 섞지 않고 참고 대사로 따로 셉니다. 점검·확인 대상 12건(P01 3·P02 2·P03 2·P04 1·P05 2·P09 2)도 같은 이유로 넣은 예외입니다.

무엇으로 만들었나

앱 정보

실행 화면

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

처음 열었을 때와 조건으로 좁히기

회계연도 2026 으로 자동 조회되어 계약 30건이 한 표에 나옵니다. 요약의 “표시 항목 이동 검토”는 4건으로, 점검 코드가 P01 또는 P04 인 계약 수를 함수로 받아 옵니다. 점검 필요는 장부 표시와 기준 표시가 달라 보이거나 주석 공시·잔액에서 확인할 것이 있다는 뜻이고, 판단은 회사가 합니다. 조회 버튼은 조회조건 영역의 오른쪽 끝에 있습니다.

임대나 시세차익 목적의 사용권자산이 투자부동산이 아닌 항목에 놓인 계약만 추려집니다. 계약명 칸에 글자를 넣고 Enter 를 눌러도 같은 방식으로 조회됩니다. “전체”로 둔 조건은 서버로 보내지 않으므로, 조건을 비우고 조회하면 처음 상태로 돌아갑니다.

표시 항목과 유형별 합계

사용권자산 별도 표시, 유형자산·투자부동산·기타자산에 합산된 사용권자산, 리스부채 별도 표시, 차입금·기타부채에 합산된 리스부채 줄이 회사별로 나옵니다. 두 금액이 다르면 어느 항목에서 어느 항목으로 옮겨 볼지 가늠할 수 있습니다. 합계 줄의 차이는 0이며, 실제 이동 여부는 회사가 판단합니다.

표시 이동 필요액은 장부 표시와 기준 표시가 다른 계약의 사용권자산 합계입니다. 건수로 세는 이동 검토(P01·P04)와 달리 주석 공시 점검 건(P02)의 계약도 위치가 다르면 금액에 들어가므로 두 숫자를 함께 봅니다.

대사 결과와 계약 상세

정합성 대사 6건은 모두 차이 0건입니다. 리스부채의 유동과 비유동 합이 잔액과 다른 계약 2건은 의도적 예외로 참고 대사에 따로 나오며, 최대 차이는 22백만 원입니다.

아래 전표 라인은 계정별로 사용권자산 원가·감가상각누계·리스부채 유동·비유동 네 줄로 나뉩니다. 점검 필요 계약은 점검 내용을 읽고 표시 위치를 회사가 판단하며, 전표 번호로 FB03 에서 원전표를 열어 확인합니다.

좁은 화면

휴대폰이나 좁은 창에서도 요약 숫자와 탭을 그대로 쓸 수 있습니다. 기능은 같고 배치만 달라집니다.

화면 뒤에서 일어나는 일

화면은 조회조건을 $filter 로 만들어 OData 서비스에 보내고, 서비스는 계약별 장부 표시와 기준 표시를 견주어 점검 코드를 정해 돌려줍니다. 요약 숫자는 그 응답과 함수 호출 결과를 컨트롤러 한 곳에서 모아 계산하므로 탭마다 숫자가 달라지지 않습니다.

점검 판정 규칙 — 판정 조건 → 결과 상태 → 사용자 조치

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

처리 단계와 대사식

1. 보유 목적과 회사 표시 정책으로 계약마다 사용권자산·리스부채의 점검 기준 표시를 정합니다.
2. 장부 표시와 기준 표시, 주석 공시 여부, 유동·비유동 합을 견주어 점검 코드를 정합니다.
3. 표시 항목별·유형별로 금액을 모으고 합계 줄을 만듭니다.
4. 아래 7식으로 합계가 맞는지 확인합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건이 위아래로 쌓이고 요약 숫자가 줄바꿈되며, 표는 가로로 넘겨 봅니다. 탭·상세 팝업·CSV 는 그대로 동작합니다.

파일 구성

index.html · Component.js · manifest.json
controller/  Main.controller.js 등
view/        Main.view.xml · DetailDialog.fragment.xml
model/       formatter.js · ErrorHandler.js
css/ · i18n/
odata/       서비스 정의(metadata) · 서비스 구현 · 엔티티셋별 데이터
media/       소개 영상

SAP 표준 기능 확장 포인트

표준 실행과 결산 보고는 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다.

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

T-code 별 연계 지점

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

표준 CDS 분석 쿼리나 Fiori 분석 앱은 계정 중심의 집계에 강합니다. 이 앱은 계약을 한 줄로 보고 점검 코드를 붙이는 점검 화면이라 그 옆에서 같은 원천을 다른 관점으로 읽습니다. 어느 표준 분석 앱을 함께 쓸지는 회사 환경에 따라 달라 확인 필요입니다.

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

요구사항 매핑표

합산 표시의 적정성과 공시의 충분성은 이 화면이 판단하지 않습니다. 기준서 문단번호는 원문 확인 전이라 적지 않았습니다.

CDS 구성

장부 금액은 표준 저널 항목 CDS 뷰 위에서 가져오고, 계약 속성과 표시 매핑은 회사별 설정 테이블에서 읽어 계약 단위로 펼칩니다. 아래 코드는 구조를 보이기 위한 스케치이며 이름은 예시입니다. 확인하지 못한 설정 값은 “확인 필요”입니다.

뷰 레이어 구성

① 매핑 테이블 — 계정과 표시 항목, 회사 표시 정책

표시 위치는 코드가 아니라 데이터로 정합니다. 계정이 새로 생기거나 회사의 표시 정책이 바뀌면 이 두 테이블만 고칩니다. 운영에서는 이 값을 회계팀이 관리해야 하므로 변경 권한과 이력이 중요합니다.

" ─────────────────────────────────────────────
" ZLBS_ACCTMAP : 계정 → 재무상태표 표시 항목
" 역할  : 사용권자산·리스부채 계정이 어느 표시 항목에 놓이는지 정한다
" 이유  : 계정이 늘어도 뷰를 고치지 않고 행만 추가하려고
" ─────────────────────────────────────────────
@EndUserText.label : '리스 표시 항목 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
define table zlbs_acctmap {
  key mandt   : mandt not null;
  key racct   : racct not null;       " 계정
  item_code   : abap.char(3);         " RSP / PPE / IVP / OTA / LSP / BOR / OTL
  side        : abap.char(1);         " A 사용권자산  L 리스부채
}

@EndUserText.label : '회사별 표시 정책'
define table zlbs_policy {
  key mandt   : mandt not null;
  key bukrs   : bukrs not null;
  rou_policy  : abap.char(1);         " S 별도 표시  M 기초자산 항목에 합산
  liab_policy : abap.char(1);         " S 별도 표시  M 차입금에 합산
}

② 차원 — 표시 항목

화면의 재무상태표 표시 항목 탭과 대사가 같은 목록을 쓰도록 차원 뷰를 따로 둡니다. 항목 코드는 매핑 테이블의 값과 같아야 하며, 이름은 화면 언어에 맞춰 텍스트 뷰로 분리하는 방식이 일반적입니다.

" ZI_LeaseBsItem : 표시 항목 차원 — 화면 표와 대사가 같은 목록을 쓴다
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'ItemCode'
define view entity ZI_LeaseBsItem
  as select distinct from zlbs_acctmap
{
  key item_code as ItemCode,
      side      as ItemSide
}

③ 큐브 — 계약별 장부 금액

장부 금액은 표준 저널 항목 뷰에서 계정 라인을 모아 계약 단위로 만듭니다. 계약 번호를 어느 필드에서 가져올지(오더·참조 필드 등)는 회사마다 달라 확인 필요이며, 통화 필드를 금액에 묶어 두어야 합계가 통화 혼합 없이 계산됩니다.

" ZI_LeaseBsContractCube : 계약별 사용권자산·리스부채 장부 금액
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
define view entity ZI_LeaseBsContractCube
  as select from I_JournalEntryItem as j
    inner join   zlbs_acctmap       as m on m.racct = j.GLAccount
{
  key j.CompanyCode,
  key j.FiscalYear,
  key j.ReferenceDocument      as ContractNo,   " 계약 번호 출처는 확인 필요
  key m.item_code              as BsItem,
      m.side                   as Side,
      j.CompanyCodeCurrency,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      sum( j.AmountInCompanyCodeCurrency ) as BookAmount,
      max( j.PostingDate )     as PostingDate
}
where j.Ledger = '0L'
group by j.CompanyCode, j.FiscalYear, j.ReferenceDocument, m.item_code, m.side,
         j.CompanyCodeCurrency

④ 판정 — 점검 코드

점검 코드의 우선순위는 case 문의 순서로 고정합니다. 판정 순서를 화면이 아니라 뷰에 두면 어느 화면에서 열어도 같은 결과가 나옵니다. 기준 표시는 보유 목적과 회사 정책에서 파생한 값이며, 목적이 비어 있으면 판단하지 않고 P09 로 보냅니다.

" ZI_LeaseBsCheck : 점검 코드 판정 (우선순위 = 앞선 when 이 이긴다)
define view entity ZI_LeaseBsCheck
  as select from ZI_LeaseBsContractBase as c      " 계약 속성 + 장부·기준 표시 (생략)
{
  key c.CompanyCode, key c.FiscalYear, key c.ContractNo,
  case
    when c.PurposeFlag = 'R' and c.BsRou <> 'IVP'                      then 'P01'
    when c.LiabAmount <> c.LiabCurrent + c.LiabNonCurrent              then 'P05'
    when c.BsRou in ('PPE','OTA') and c.DiscRou  = ' '                 then 'P02'
    when c.BsLiab in ('BOR','OTL') and c.DiscLiab = ' '                then 'P03'
    when c.PurposeFlag <> 'R' and c.BsRou <> c.ExpRou                  then 'P04'
    when c.PurposeFlag = 'C'                                           then 'P09'
    else 'P00'
  end as CheckCode
}

⑤ 쿼리 — 조회조건과 화면 노출 필드

화면이 받는 필드와 필터 가능한 필드를 소비 뷰에서 한 번 정하면 서비스와 화면이 같은 계약을 봅니다. 회계연도와 회사코드는 필수 조건으로 두어 대용량에서도 범위를 좁히게 합니다.

" ZC_LeaseBsContractQuery : 화면 계약
@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
@Search.searchable: true
define view entity ZC_LeaseBsContractQuery
  as projection on ZI_LeaseBsCheck
{
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key CompanyCode,
  @Consumption.filter: { mandatory: true, selectionType: #SINGLE }
  key FiscalYear,
  key ContractNo,
  @Search.defaultSearchElement: true
  ContractName,
  @Consumption.filter.selectionType: #SINGLE
  CheckCode,
  @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
  RouAmount,
  @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
  LiabAmount
}

⑥ 권한 — 회사코드 단위 DCL

권한은 화면에서 숨기지 않고 집계 단계에서 겁니다. 드릴다운에만 걸면 합계로 다른 회사의 숫자가 새어 나갑니다. 권한 오브젝트와 필드 매핑은 회사 보안 설계에 따르며 확인 필요입니다.

@EndUserText.label: '리스 표시 점검 — 회사코드 권한'
@MappingRole: true
define role ZC_LeaseBsContractQuery {
  grant select on ZC_LeaseBsContractQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩 — OData V2 로 노출

화면이 바라보는 서비스는 서비스 정의에서 노출할 뷰를 정하고 바인딩으로 게시해 만듭니다. 서비스를 활성화한 뒤 앱 선언의 서비스 주소를 이 서비스로 바꾸면 화면은 그대로 동작합니다.

@EndUserText.label: '리스 표시 점검 서비스'
define service ZUI_LeaseBsCheck {
  expose ZC_LeaseBsContractQuery as ContractSet;
  expose ZC_LeaseBsStmtQuery     as StmtSet;
  expose ZC_LeaseBsClassQuery    as ClassSet;
  expose ZC_LeaseBsReconQuery    as ReconSet;
  expose ZC_LeaseBsDetailQuery   as DetailSet;
}
" 서비스 바인딩 ZUI_LeaseBsCheck_O2 : 바인딩 유형 OData V2 - UI, 게시 후 활성화

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

계약 단위 조회는 서버 페이징으로 충분한 규모가 많습니다. 전표 라인이 대용량이면 집계 뷰를 미리 만들어 두고 회계연도·회사코드를 필수 조건으로 두며, 전표 라인은 계약을 고른 뒤에만 읽도록 합니다. 응답 시간 기준은 실측 뒤에 정하는 것이 맞아 확인 필요입니다.

자주 묻는 질문

도입을 검토하실 때 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 판정

화면과 조작

표준 연계와 기준서

도입과 운영