SAP 정부보조금 수익 범주 귀속 점검 — IFRS 18 손익 범주를 보조금 유형과 구성요소로 다시 정해 장부와 견주는 마감 점검

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

정부보조금은 총액만 맞으면 된다고 생각하기 쉽습니다. 그러나 IFRS 18 에서는 같은 금액이 어느 범주에 놓였는가가 영업이익 소계를 바꿉니다. 이자 보전 효익이 영업범주에 있거나, 매각 대상 사업의 지원금이 계속영업에 남아 있으면 숫자는 맞아도 소계는 틀립니다. 이 앱은 보조금 유형과 구성요소로 범주를 다시 정해 장부 기록과 견주고, 다른 건과 옮겨야 할 금액을 마감 전에 한 화면으로 모아 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 총액은 같은데 영업범주 소계가 달랐던 이유

1000 회사의 영업범주는 장부 기준 361,700,000원이지만 규칙으로 다시 정하면 400,950,000원입니다. 총액은 같고 범주만 다릅니다. 차이 -39,250,000원 안에는 연구개발 과제 지원금 86,600,000원 가운데 영업이 아닌 곳에 기록된 몫, 임대용 건물 개보수 보조금, 매각 대상 사업 연구 지원금 19,600,000원 같은 건들이 들어 있습니다. 반대로 재무범주는 장부가 규칙보다 76,850,000원 많습니다.

금액만 보면 “보조금 수익이 7억 5천만 원” 에서 이야기가 끝나지만, 범주로 보면 영업이익 소계에 들어갈 금액이 얼마인가 가 달라집니다. 이 앱은 그 질문에 11건의 목록과 142,750,000원이라는 숫자로 답합니다.

이 앱이 하지 않는 일

이 앱은 회계기준을 해석하거나 분류를 확정하지 않습니다. 회사가 정한 규칙을 기계적으로 적용하고, 규칙으로 정할 수 없는 건은 확인 필요로 남깁니다. 법정 공시용 숫자는 표준 보고서에서 만들고, 이 앱은 그 숫자를 만들기 전에 범주를 바로잡는 마감 점검 도구입니다.

실행 화면

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

처음 열었을 때

화면을 여는 순간 조회가 끝나 있습니다. 조회조건은 회계연도와 회사, 보조금 유형, 구성요소, 기록 범주, 전기일 범위, 보조금 이름, 점검 코드이며 모두 비워 두어도 됩니다. 요약 여섯 칸은 점검 필요 건수, 확인 필요 건수, 범주 이동 필요 금액, 영업범주에 기록된 보조금 수익, 정합성 대사 차이 건수를 먼저 알려 줍니다. 점검 필요 11건이 곧 회계팀이 오늘 열어 볼 목록입니다.

손익 건별 점검

재계산 범주는 사람이 고르는 값이 아니라 규칙이 정합니다. 수익관련(A)과 자산관련(B) 보조금의 수익은 영업범주, 이자 보전 효익(C)은 재무범주, 투자자산 관련(D)은 투자범주, 중단영업 사업(E)은 중단영업입니다. 복합 목적(M)은 목적별로 나눈 근거를 봐야 하므로 범주를 단정하지 않고 확인 필요로 남깁니다.

점검 코드로 조회

A01은 수익관련 · 자산관련 보조금이 영업범주 밖에 있는 경우, A02는 이자 보전 효익이 재무범주 밖에 있는 경우, A03은 투자자산 관련 보조금이 투자범주 밖에 있는 경우, A05는 범주가 비어 있는 경우, A06은 중단영업 사업의 보조금이 중단영업 밖에 있는 경우입니다. 코드별 건수가 곧 원인별 건수라서, 어느 계정 매핑부터 고쳐야 하는지 한눈에 갈립니다.

행을 눌러 본 상세

상세는 별도 화면으로 넘어가지 않고 대화상자로 뜹니다. 위에는 보조금 이름과 유형, 구성요소, 전기일, 기록 범주, 재계산 범주, 점검 결과가 있고 아래에는 같은 보조금의 모든 손익 건이 있습니다. 보조금 하나가 두 개 범주에 걸쳐 기록된 경우에도 한 번에 맞춰 볼 수 있습니다.

범주별 합계

1000 회사는 영업범주 장부 361,700,000원에 재계산 400,950,000원으로 -39,250,000원, 재무범주는 +76,850,000원 차이가 납니다. 범주를 옮겨도 총액은 같으므로 차이 열의 합계는 언제나 0이어야 하고, 화면이 이 등식을 대사 결과 탭에서 매번 확인합니다. 2000 회사는 범주 미지정 8,800,000원 한 건만 어긋납니다.

이연수익 상각 재계산

7건 가운데 6건은 장부와 같고, G10005 에너지 효율 설비 보조금 한 건만 재계산 45,000,000원에 장부 46,250,000원으로 1,250,000원이 어긋나 점검 필요(A04)로 뜹니다. 교부액 360,000,000원을 72개월로 나눠 9개월을 곱한 값이 45,000,000원이기 때문입니다. 범주 점검과는 별개로 금액 자체의 점검을 둔 이유입니다.

대사 결과

R01~R03은 건별 손익 금액 합계 755,150,000원이 보조금별 · 범주별 장부 · 범주별 재계산 합계와 같은지, R04는 범주별 장부 분해의 합이 보조금별 손익 합계와 같은지, R05는 장부와 재계산의 차이 합이 0인지, R06은 이연수익 상각 건의 합 347,750,000원이 장부 상각액과 같은지 봅니다. 이 여섯 식이 맞아야 점검 결과를 믿고 읽을 수 있습니다. 참고 대사는 어긋남이 일부러 들어간 자리라서 차이 건수가 0이 아닌 것이 정상입니다.

자료 구성 — 이 화면의 숫자가 나온 곳

점검한 손익은 53건, 보조금은 18건(1000 회사 10건 · 2000 회사 8건), 이연수익 상각 대상은 7건입니다. 점검 필요 11건의 내역은 A01 두 건, A02 세 건, A03 세 건, A05 한 건, A06 두 건이고, 확인 필요는 A09 세 건입니다. 상각액이 어긋난 한 건은 A04 입니다. 이들은 모두 점검 기능을 보여 주려고 의도적으로 넣은 예외 건이며, 그 밖의 손익 39건은 장부와 재계산이 같습니다(A00).

SAP 표준 기능 확장 포인트

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

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

표의 거래 코드는 릴리스와 구성에 따라 다르므로 실제 도입 전 사내 환경에서 한 번 확인해야 합니다. 이 앱은 표준 거래를 없애지 않고, 대사와 감사 대응은 표준 거래가 맡도록 둡니다.

이 앱이 제안하는 마감 순서

OData 서비스 계약

화면과 서비스는 아래 계약으로만 만납니다. 엔티티셋 다섯 개와 함수 하나이며, 운영에서는 같은 계약 위에 CDS 뷰와 서비스 바인딩을 올립니다.

CDS 구성

이 사례의 화면은 서비스 엔진이 돌려주는 자료를 읽습니다. 운영에서는 같은 계약을 ACDOCA 와 보조금 마스터 위의 CDS 뷰가 채웁니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스 · 환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다. 보조금 번호와 유형은 Grants Management 를 쓰는 환경과 쓰지 않는 환경이 다르므로 ZGRANT_MASTER 라는 고객 테이블을 가정했습니다.

뷰 레이어 구성

① 유형 · 구성요소 → 범주 매핑 표

회사의 분류 정책이 이 표에 있습니다. 운영 전환에서 가장 먼저 합의해야 하는 항목이며, 복합 목적(M)은 일부러 범주를 비워 확인 필요로 흘립니다.

@EndUserText.label : '정부보조금 유형·구성요소 → 손익 범주'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED      " SM30 뷰를 함께 만든다
define table zgrant_catmap {
  key mandt      : mandt not null;
  key grant_type : abap.char(1) not null;    " A 수익관련 B 자산관련 C 이자보전 D 투자자산 E 중단영업 M 복합
  key comp_type  : abap.char(1) not null;    " G 보조금수익 S 이연수익상각 B 그밖
  valid_from     : abap.dats;
  exp_cat        : abap.char(3);             " OPR INV FIN DSC — M 유형은 비워 둔다
  need_confirm   : abap.char(1);             " X = 규칙으로 정할 수 없어 확인 필요
}

② 손익 건 기본 뷰

ACDOCA 에서 보조금 번호가 붙은 손익 라인을 읽어 장부 기록 범주를 붙입니다. 장부 범주를 어디서 읽을지(계정 → 범주 매핑인지, 별도 필드인지)는 회사마다 다르므로 합의해야 하는 두 번째 항목입니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '보조금 손익 건 (장부 기록 범주)'
define view entity ZI_GrantLine
  as select from acdoca as a
  inner join zgrant_master as m
    on  m.bukrs   = a.rbukrs
    and m.grantno = a.zz_grantno             " 확인 : 보조금 번호를 담는 필드 이름
{
  key a.rldnr                        as Rldnr,
  key a.rbukrs                       as Bukrs,
  key a.gjahr                        as Gjahr,
  key a.belnr                        as Belnr,
  key a.docln                        as Docln,
      m.grantno                      as GrantNo,
      m.grant_type                   as GrantType,
      a.zz_comp_type                 as CompType,   " 확인 : 구성요소 필드
      a.budat                        as PostDate,
      @Semantics.amount.currencyCode : 'Waers'
      a.hsl                          as Amount,
      a.rhcur                        as Waers,
      a.zz_pl_cat                    as BookedCat   " 확인 : 장부 범주(없으면 계정 매핑으로)
}
where a.rldnr = '0L'

③ 재계산 범주와 점검 코드

매핑을 붙여 재계산 범주를 정하고, 장부와 다르면 코드를 답니다. 이 뷰가 점검의 심장입니다. A09 는 매핑에서 need_confirm 이 켜진 건이고 이동 필요 금액은 계산하지 않습니다.

@EndUserText.label : '보조금 손익 건 점검 (재계산 범주·코드)'
define view entity ZI_GrantLineChk
  as select from ZI_GrantLine as l
  left outer join zgrant_catmap as c
    on  c.grant_type = l.GrantType
    and c.comp_type  = l.CompType
{
  key l.Bukrs, key l.Gjahr, key l.GrantNo, key l.Belnr, key l.Docln,
      l.GrantType, l.CompType, l.PostDate, l.Amount, l.BookedCat,
      c.exp_cat                                   as ExpectCat,
      case
        when c.need_confirm = 'X'                 then 'A09'   " 복합 목적 — 확인 필요
        when l.BookedCat is initial               then 'A05'   " 범주 미지정
        when l.BookedCat = c.exp_cat              then 'A00'
        when l.GrantType in ('A','B')             then 'A01'   " 영업이어야 하는데 아님
        when l.GrantType = 'C'                    then 'A02'   " 재무이어야 하는데 아님
        when l.GrantType = 'D'                    then 'A03'   " 투자이어야 하는데 아님
        when l.GrantType = 'E'                    then 'A06'   " 중단영업이어야 하는데 아님
        else 'A00'
      end                                         as CheckCode,
      case
        when c.need_confirm = 'X' or l.BookedCat = c.exp_cat then 0
        else l.Amount
      end                                         as MoveAmt
}

④ 범주별 합계 큐브

장부와 재계산을 같은 키에 올려 놓아야 차이가 한 번에 나옵니다. 장부 열과 재계산 열을 따로 만들면 키가 어긋나 합이 틀립니다.

@Analytics.dataCategory : #CUBE
@EndUserText.label : '보조금 손익 범주 큐브'
define view entity ZI_GrantCatCube
  as select from ZI_GrantLineChk
{
  key Bukrs, key Gjahr,
  key BookedCat                      as Cat,
      sum(Amount)                    as BookAmt,
      count(*)                       as LineCnt,
      sum(case when CheckCode in ('A01','A02','A03','A05','A06') then 1 else 0 end) as FlagCnt
}
group by Bukrs, Gjahr, BookedCat
" 재계산 금액 열(ExpAmt)은 ExpectCat 기준으로 같은 방식으로 집계한 뷰를 union 한다.
" 이 union 이 어긋나면 대사식 R05 (장부 − 재계산 합 = 0) 가 먼저 알려 준다.

⑤ 이연수익 상각 재계산

범주 점검과 따로 금액을 점검합니다. 정액 상각을 가정한 단순식이며, 자산을 중간에 취득했다면 MonthsYr 에 그 사실이 반영돼야 합니다.

@EndUserText.label : '이연수익 상각 재계산'
define view entity ZI_GrantAmortChk
  as select from zgrant_master as m
  association [0..*] to ZI_GrantLine as _line
    on  _line.GrantNo  = m.grantno
    and _line.CompType = 'S'
{
  key m.bukrs, key m.gjahr, key m.grantno,
      m.grant_amt                                          as GrantAmt,
      m.use_months                                         as UseMonths,
      m.months_yr                                          as MonthsYr,
      cast( m.grant_amt * m.months_yr / m.use_months as abap.curr(15,0) ) as CalcAmort,
      sum( _line.Amount )                                  as BookAmort,
      cast( sum( _line.Amount ) - ( m.grant_amt * m.months_yr / m.use_months )
            as abap.curr(15,0) )                           as DiffAmt
}
where m.use_months > 0
group by m.bukrs, m.gjahr, m.grantno, m.grant_amt, m.use_months, m.months_yr

⑥ 권한 정의(DCL)

집계를 읽는 자리에 회사코드 권한을 걸어야 개별 건으로 내려가도 같은 범위만 보입니다. 점검 결과 전용 권한 객체를 따로 두는 회사도 있습니다.

@EndUserText.label : '보조금 손익 건 — 회사코드 권한'
@MappingRole : true
define role ZI_GRANTLINE {
  grant select on ZI_GrantLine
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩

화면이 부르는 이름은 grantcat_srv 입니다. 서비스 정의에서 엔티티셋 이름을 계약대로 노출하고, 바인딩은 OData V2 UI 로 만듭니다.

@EndUserText.label : '정부보조금 수익 범주 귀속 점검'
define service ZUI_GRANTCAT_O2 {
  expose ZC_GrantLineChk    as LineSet;
  expose ZC_GrantChk        as GrantSet;
  expose ZI_GrantCatCube    as CatSet;
  expose ZI_GrantAmortChk   as AmortSet;
  expose ZC_GrantReconChk   as ReconSet;
}
" 서비스 바인딩 : 유형 OData V2 - UI, 이름 grantcat_srv
" FlagCount(Gjahr, Bukrs) 는 ABAP 클래스(IF_SADL_EXIT_*)로 구현하고 Edm.Int32 를 돌려준다.

운영 작업 목록

자주 묻는 질문

도입 상담과 데모에서 받을 만한 질문들을 24개로 정리했습니다.