SAP 사용권자산 손상 점검 — IFRS 16·IAS 36, 회수가능액과 손상차손·손상 후 상각액이 장부와 맞는지 결산 전에 다시 계산해 대조한다

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

리스로 들여온 사무실·창고·차량·설비는 장부에 사용권자산으로 남습니다. 그런데 영업소를 닫기로 했거나 창고가 비었거나 사업장을 분리하기로 하면, 이 자산도 일반 자산처럼 손상 징후를 봐야 합니다. 결산 때마다 같은 세 질문이 돌아옵니다. 징후가 있는 자산은 어느 것인가, 회수가능액은 얼마로 잡았나, 그래서 손상차손과 이후 상각액은 장부와 맞나. 이 앱은 세 답을 한 화면에 모아 장부와 나란히 놓습니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 25건 중 9건, 장부 손상차손이 9.4억 많다

가상 리스 계약 25건(건물·부동산 12, 차량 4, 설비·장비 9)과 사용가치 현금흐름 76행으로 돌렸습니다. 산출 손상차손 합계는 34.2억, 장부 손상차손 합계는 43.6억이라 차이가 +9.4억입니다. 점검 필요 9건은 모두 이 자료에 의도적으로 넣은 예외이며, 어떻게 걸리는지를 보여 주기 위한 것입니다.

R019 를 풀어 보면 이렇습니다. 장부금액 17.25억, 순공정가치 10.35억, 리스료 지급을 뺀 현금흐름의 사용가치 14.82억입니다. 회수가능액은 둘 중 큰 14.82억이라 손상차손은 2.43억이어야 하는데, 장부는 리스료가 섞인 현금흐름으로 사용가치를 9.62억으로 낮춰 구한 뒤 순공정가치를 회수가능액으로 잡아 6.90억을 인식했습니다. 합계만 보면 “손상이 났다”로 끝나지만, 구성 요소를 펼치면 이 차이가 리스료 한 줄에서 나왔다는 것이 보입니다.

도입하면 달라지는 것

• 결산 전 점검 — 징후 자산 선별, 회수가능액 재계산, 장부 대조가 한 화면에서 끝나 엑셀 취합이 줄어듭니다.
• 감사 대응 — 사용가치의 연차별 현금흐름과 할인계수가 그대로 남아 “이 금액은 어떻게 나왔나”에 바로 답합니다.
• 손상 후 상각 — 손상차손만 맞추고 상각액을 그대로 두는 실수를 I04 로 잡습니다.
• 검사 기록 관리 — 징후는 있는데 검사한 기록이 없는 자산이 목록에 남지 않습니다.

이런 회사에 맞습니다

사무실·창고·차량·설비를 다수 리스하고 사용권자산을 자산 서브원장으로 관리하는 회사, 폐쇄·분리·유휴 같은 징후가 생길 때마다 엑셀로 손상 계산을 새로 짜던 재무회계팀, 그리고 손상 입력값(공정가치·할인율·현금흐름)을 통제된 숫자로 남겨야 하는 결산 조직에 맞습니다.

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

점검 도구에서 가장 비싼 질문은 “이 계산 맞아?” 입니다. 그래서 대사식을 먼저 세우고 샘플 데이터 전체에 돌렸습니다. 앞쪽 일곱 가지는 앱 안의 계산이 서로 맞는지를 보는 정합성 대사, 뒤쪽 세 가지는 장부와 견주는 장부 점검 대사입니다. 두 묶음은 건수를 따로 셉니다.

정합성 대사는 모두 차이 0 이고, 08~10 의 차이가 곧 점검 필요 9건에서 나온 숫자입니다. 화면 쪽은 브라우저 자동화로 따로 확인했습니다 — 조회조건마다 요청이 실제로 걸러지는지, 검토 기준일의 날짜 필터가 맞게 먹는지, 서비스 연결이 끊겼을 때 사용자 메시지가 뜨는지를 확인했습니다.

사용 방법

1. 기준 연월(보고기간말 6자리)을 입력하고 필요하면 자산 유형·손상 징후·산출 회수가능액 기준·검토 기준일·점검 코드·점검 결과로 좁힙니다. 화면을 처음 열면 기본 조건으로 한 번 자동 조회됩니다.
2. 위쪽 KPI 여섯 가지 — 자산 건수, 점검 필요 건수, 산출·장부 손상차손 합계, 차이, 정합성 대사 차이 건수 — 가 같은 조건으로 다시 계산됩니다.
3. 사용권자산 명세에서 점검 결과가 ‘점검 필요’인 줄을 찾고, 행을 눌러 장부금액부터 회수가능액·손상차손·월 상각액과 연차별 현금흐름을 한 창에서 봅니다.
4. 사용가치 현금흐름 탭에서 징후 자산의 연차별 현금흐름·참고용 리스료·할인계수·현재가치를 확인합니다.
5. 유형별 집계로 건물·차량·설비 단위의 차이를 보고, 대사 결과에서 정합성과 장부 점검이 각각 몇 건 어긋났는지 확인합니다.
6. 보고 있는 탭은 CSV로 내려받아 검토 자료에 붙이고, 검토 요청용 .pptx 는 이 글 왼쪽의 ‘검토용 자료 다운로드’로 받습니다.

실행 화면

실제 브라우저에서 sap_horizon 테마로 렌더링한 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있습니다. 숫자는 모두 같은 검증용 샘플 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 연 화면 — 조건·KPI·명세가 한 화면에

화면을 열자마자 기본 조건으로 한 번 조회하므로 빈 표를 보고 시작하지 않습니다. 기준 연월은 필수라 모든 탭이 같은 보고기간말로 읽히고, 위쪽 KPI 는 지금 걸린 조건으로 다시 계산됩니다. 결산 담당자가 가장 먼저 보는 건 ‘점검 필요 몇 건, 차이 얼마’ 한 줄이기 때문에 표보다 위에 두었습니다.

점검 필요만 보기 — 9건

필터는 서비스에 $filter 로 넘어가고 KPI 도 같은 필터로 다시 읽습니다. 그래서 표와 KPI 가 서로 다른 범위를 말할 일이 없습니다. 점검 코드까지 좁히면 같은 유형의 어긋남만 모아 볼 수 있습니다.

산출과 장부 — 손상차손·월 상각액 비교

장부와 산출이 다른 칸은 값을 바로 읽을 수 있게 같은 줄에 나란히 두었습니다. 회수가능액 기준은 순공정가치·사용가치·산정 불요(징후 없음) 세 값으로 표시해 I03 이 왜 걸렸는지 눈으로 따라갈 수 있습니다.

사용가치 현금흐름 — 합계의 출처

사용가치는 ‘현금흐름 × 할인계수’의 합이라, 어느 해의 어느 숫자가 들어갔는지 펼쳐 두지 않으면 설명할 수 없습니다. 리스료 지급은 참고용 열로 따로 보여 주되 합계에는 넣지 않습니다. 현재가치는 원 단위로 반올림해 대사식이 1원도 어긋나지 않도록 했습니다.

유형별 집계 — 건물·차량·설비

합계를 유형으로 묶어 보면 차이가 어디에 몰려 있는지가 보입니다. 이 자료에서는 건물에서 +7.3억, 설비에서 +2.2억이 나고 차량은 차이가 없습니다. 유형별 합계는 명세 합계와 같아야 해서 대사 06 으로 매번 확인합니다.

대사 결과 — 정합성과 장부 점검 분리

‘계산이 맞는가’와 ‘장부가 맞는가’를 한 숫자로 섞으면 어느 쪽 문제인지 알 수 없어서 건수를 따로 셉니다. 앞 묶음이 0 이어야 뒤 묶음의 차이를 믿고 읽을 수 있습니다.

자산 상세 — 한 건을 끝까지

감사인이 묻는 순서대로 위에서 아래로 읽히게 두었습니다. 장부금액에서 시작해 어느 쪽 값이 회수가능액이 되었는지, 손상차손은 얼마인지, 손상 후 월 상각액은 얼마인지를 같은 창에서 확인합니다.

화면 뒤에서 일어나는 일

여기부터는 목차에 올리지 않은 상세입니다. 화면이 어떤 규칙으로 판정하고 계산하는지를 적었습니다.

점검 코드 — 위에서 아래로 먼저 걸리는 하나

화면은 ‘오류’나 ‘위반’으로 단정하지 않고 점검 필요로만 표시합니다. 판단은 회사와 감사인이 하고, 이 화면은 어디를 다시 보라는 신호만 줍니다.

산출 순서

1. 장부금액(손상 전) = 취득원가 − 상각누계액 − 손상누계액(전기말)
2. 순공정가치 = 공정가치 − 처분부대원가 (징후 자산만)
3. 사용가치 = Σ(연차별 사용 현금흐름 × 할인계수). 할인계수는 1 ÷ (1 + 세전 할인율)^연차 을 소수 여섯 자리로 둔 값이고 현재가치는 원 단위로 반올림합니다. 리스료 지급은 넣지 않습니다.
4. 회수가능액 = 순공정가치와 사용가치 중 큰 금액 (같으면 사용가치)
5. 손상차손 = 장부금액 − 회수가능액, 0 미만이면 0. 징후가 없는 자산은 0
6. 손상 후 월 상각액 = (장부금액 − 손상차손) ÷ 잔여 상각개월, 원 단위 반올림

조회조건과 $filter 대응

현금흐름·유형별 집계·대사 결과 탭은 기준 연월만 조건으로 걸립니다. 정렬은 컬럼 머리글이 $orderby 로, 총건수는 $inlinecount 로 전달됩니다.

파일 구성

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 장부를 만드는 일은 표준이 하고, 그 장부가 손상 요구사항과 맞는지 조회·점검하는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

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

리스 계약을 별도 리스 회계 기능으로 관리하는 경우의 전용 거래는 환경에 따라 달라 확인 필요입니다. 이 글은 사용권자산이 자산 서브원장의 자산으로 관리되는 경우를 기준으로 합니다.

기준서 요구사항과 이 앱의 대응

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

CDS 구성

이 사례의 화면은 검증용 샘플 25건을 OData 서비스에서 받아 그립니다. 운영으로 올릴 때는 그 서비스를 CDS 뷰 위에 세웁니다. 아래는 그때 만드는 뷰를 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 자산 기준 뷰

가장 아래 뷰입니다. 장부금액을 여기서 한 번만 계산하고 위의 모든 뷰가 이 값을 씁니다. S/4HANA 에서 연도별 값 테이블이 호환 뷰인지는 환경마다 달라 확인이 필요합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '사용권자산 기준'
define view entity ZI_RouAsset
  as select from anla as a
    inner join anlc as c on  c.bukrs = a.bukrs
                         and c.anln1 = a.anln1
                         and c.anln2 = a.anln2
{
  key a.bukrs,
  key a.anln1,
  key a.anln2,
  key c.gjahr,
      a.anlkl                        as AssetClass,   // 자산 분류 → 건물/차량/설비 매핑은 확인 필요
      c.kansw                        as CostAmt,      // 누적 취득원가
      c.knafa                        as AccDep,       // 누적 정상 상각
      c.kaafa                        as AccImp,       // 누적 비계획 상각(전기말 손상)
      c.kansw - c.knafa - c.kaafa    as CarryAmt      // 대사 01
}

② 평가 입력 뷰

공정가치·처분부대원가·할인율·검사 수행 여부는 SAP 표준 필드에 없습니다. 회사가 입력한 평가 기록을 읽는 뷰이고, 누가 언제 입력했는지를 함께 남기는 것을 권합니다.

@EndUserText.label: '손상 평가 입력'
define view entity ZI_RouEval
  as select from zrou_eval
{
  key bukrs, key anln1, key anln2, key gjahr,
      ind_yn      as IndYn,        // 손상 징후 여부 — 회사 판단
      test_yn     as TestYn,       // 손상검사 실시 여부
      fair_val    as FairVal,      // 공정가치
      disp_cost   as DispCost,     // 처분부대원가
      rate        as Rate,         // 세전 할인율(%)
      rem_months  as RemMonths,    // 잔여 상각개월 — 상각 영역에서 산출할지는 확인 필요
      pay_incl_yn as PayInclYn,    // 장부 현금흐름에 리스료 포함 여부
      changed_by  as ChangedBy,
      changed_at  as ChangedAt
}

③ 할인계수 — 테이블 함수

할인계수 1 ÷ (1+r)ⁿ 에는 거듭제곱이 필요한데 CDS 뷰에는 그 함수가 없습니다. 그래서 SQLScript 로 구현한 테이블 함수로 뺍니다. 소수 여섯 자리로 자르는 이유는 화면의 반올림 규칙과 맞추기 위해서입니다.

define table function ZTF_RouDisc
  with parameters p_clnt : abap.clnt
  returns {
    mandt : abap.clnt; bukrs : bukrs; anln1 : anln1; anln2 : anln2;
    year_no : abap.int1; disc : abap.dec(9,6);
  }
  implemented by method zcl_rou_disc=>get;

" AMDP 구현 스케치
METHOD get BY DATABASE FUNCTION FOR HDB LANGUAGE SQLSCRIPT
  OPTIONS READ-ONLY USING zrou_cf zrou_eval.
  RETURN SELECT cf.mandt, cf.bukrs, cf.anln1, cf.anln2, cf.year_no,
         ROUND( 1 / POWER( 1 + ev.rate / 100, cf.year_no ), 6 ) AS disc
         FROM zrou_cf AS cf
         INNER JOIN zrou_eval AS ev
            ON ev.bukrs = cf.bukrs AND ev.anln1 = cf.anln1 AND ev.anln2 = cf.anln2
         WHERE cf.mandt = :p_clnt;
ENDMETHOD.

④ 현금흐름·현재가치 뷰

현금흐름에 할인계수를 곱해 현재가치를 만듭니다. 리스료 지급은 열로만 두고 합계에는 넣지 않습니다. 반올림은 행 단위로 원 단위까지 하고, 합계는 반올림된 행의 합입니다.

define view entity ZI_RouCf
  as select from zrou_cf as cf
    inner join ZTF_RouDisc( p_clnt: $session.client ) as d
      on  d.bukrs = cf.bukrs and d.anln1 = cf.anln1
      and d.anln2 = cf.anln2 and d.year_no = cf.year_no
{
  key cf.bukrs, key cf.anln1, key cf.anln2, key cf.year_no,
      cf.op_cash                                  as OpCash,     // 사용 현금흐름(리스료 제외)
      cf.lease_pay                                as LeasePay,   // 참고용 — 합계에 넣지 않음
      d.disc                                      as DiscFactor,
      cast( round( cf.op_cash * d.disc, 0 ) as abap.dec(18,0) ) as PvAmt
}

⑤ 회수가능액 뷰

순공정가치와 사용가치 중 큰 금액을 고릅니다. 같으면 사용가치로 표시합니다. 징후가 없는 자산은 이 뷰에서 값을 만들지 않습니다.

define view entity ZI_RouRec
  as select from ZI_RouAsset as a
    inner join ZI_RouEval as e on e.bukrs = a.bukrs and e.anln1 = a.anln1
                              and e.anln2 = a.anln2 and e.gjahr = a.gjahr
    left outer join ( select from ZI_RouCf
                      { key bukrs, key anln1, key anln2,
                        sum( PvAmt ) as ViuAmt }
                      group by bukrs, anln1, anln2 ) as v
      on v.bukrs = a.bukrs and v.anln1 = a.anln1 and v.anln2 = a.anln2
{
  key a.bukrs, key a.anln1, key a.anln2, key a.gjahr,
      a.CarryAmt,
      e.FairVal - e.DispCost                               as FvlcdAmt, // 대사 02
      v.ViuAmt,                                                          // 대사 03
      case when ( e.FairVal - e.DispCost ) > v.ViuAmt
           then ( e.FairVal - e.DispCost ) else v.ViuAmt end as RecAmt,  // 대사 04
      e.IndYn, e.TestYn, e.RemMonths
}
where e.IndYn = 'Y'   // 징후 자산만. 징후 없는 자산 합류 방식은 확인 필요

⑥ 점검 판정 쿼리

손상차손과 손상 후 월 상각액을 산출하고 I00~I05 를 위에서 아래 순서로 먼저 걸리는 하나만 붙입니다. 장부 손상차손의 원천(비계획 상각 증가분)은 환경별로 달라 확인 필요입니다.

define view entity ZC_RouCheck
  as select from ZI_RouRec as r
{
  key r.bukrs, key r.anln1, key r.anln2, key r.gjahr,
      r.CarryAmt,
      r.RecAmt,
      case when r.CarryAmt > r.RecAmt
           then r.CarryAmt - r.RecAmt else 0 end                       as ImpExp,   // 대사 05
      division( r.CarryAmt - case when r.CarryAmt > r.RecAmt
           then r.CarryAmt - r.RecAmt else 0 end, r.RemMonths, 0 )    as DepExp,   // 대사 07
      case
        when r.IndYn = 'Y' and r.TestYn = 'N'        then 'I01'
        // I02: 장부 현금흐름에 리스료 포함 — 평가 입력의 PayInclYn 과 장부 사용가치 비교
        // I03: 손상차손 불일치(위 사유 아님)
        // I04: 손상차손 일치, 월 상각액 불일치
        // I05: 징후 없음인데 장부 손상차손 > 0  (징후 없는 자산 합류 후 판정)
        else 'I00'
      end                                                              as CheckCode
}

⑦ 접근 제어(DCL)

손상 점검 결과는 회사코드별로 담당이 갈립니다. 집계를 읽는 뷰에도 접근 제어를 걸어야 합계로 다른 회사 숫자가 새지 않습니다.

@EndUserText.label: '사용권자산 접근 제어'
@MappingRole: true
define role ZI_ROUASSET {
  grant select on ZI_RouAsset
    where ( bukrs ) = aspect pfcg_auth( F_ANLA_BUK, BUKRS, ACTVT = '03' );
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

운영 데이터로 갈 때 — 자산이 수만 건이면

이 사례는 자산 25건, 현금흐름 76행입니다. 운영에서는 자산 수가 늘어도 사용가치를 다시 구하는 대상은 징후 자산뿐입니다. 대부분의 자산은 징후가 없으므로 계산량은 전체 자산 수가 아니라 징후 자산 수를 따라갑니다.

한 가지 더. 검토 기준일처럼 날짜 조건은 서비스 쪽에서 실제로 걸러야 합니다. 이 앱의 샘플 서비스는 날짜 $filter 를 직접 처리하도록 만들었고, 운영 서비스에서도 같은 조건을 CDS 쪽 where 로 내려야 화면이 받는 행 수가 줄어듭니다.

자주 묻는 질문

도입 상담과 검토 자리에서 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

기준서와 범위

도입과 운영