SAP 기능별 비용 배분 기준 점검 — IFRS 18, 공통비를 기능에 나눈 기준이 동인과 맞는지·기준을 바꿨다면 사유와 전기 비교금액이 정리됐는지 장부와 견줘 보는 결산 화면

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

영업비용을 기능별로 표시하는 회사에서 결산 때 가장 설명하기 어려운 숫자가 여러 기능이 함께 쓴 공통비입니다. 건물 임차료, 정보시스템 운영비, 인사·총무 지원비는 어느 한 기능의 비용이 아니어서 면적, 사용자 수, 인원 같은 동인으로 나누는데, 그 동인 수량은 해마다 바뀌는데 장부의 배분율은 전기 것을 그대로 쓰는 일이 흔합니다. 배분 기준을 바꾼 해에는 전기 비교금액을 새 기준으로 다시 만들고 사유를 남겨야 하는데, 이 일도 엑셀과 담당자의 기억에 기대어 처리됩니다. 이 앱은 공통비 풀을 한 화면에 모아, 동인 수량으로 다시 계산한 배분율이 장부와 같은지, 기준을 바꿨다면 비교금액 재작성과 변경 사유가 남아 있는지를 풀 단위로 다시 계산해 보여 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 합계는 맞는데 기능은 어긋난 풀 네 개

사례 자료는 가상의 두 회사(1000·2000)가 가진 공통비 풀 16개입니다. 풀 금액 합계는 7,130백만 원이고 기능별 직접비 22,180백만 원을 더한 영업비용은 29,310백만 원입니다. 장부 배분액 합계도 재계산 배분액 합계도 7,130백만 원으로 풀 금액과 정확히 같아서, 총액만 보면 아무 문제가 없습니다. 그런데 풀 단위로 가르면 이야기가 달라집니다.

• 배분율 재계산 차이(A03) 4개 — 인사·총무 지원비(회사 1000)는 장부와 재계산이 최대 12.17%p, 공통 설비 감가상각비(회사 2000)는 37.50%p 다릅니다. 이 풀 하나에서만 재배분 필요 금액이 153.8백만 원입니다.
• 기준 변경 뒤 비교금액 미재작성(A01) 2개 — 배분 기준을 바꿨는데 전기 비교금액이 새 기준으로 다시 만들어지지 않았습니다. 전력·수도 공통비(1000)와 물류센터 운영비(2000)입니다.
• 변경 사유 미기재(A02) 1개 — 본사 건물 임차료(1000)는 인원 수에서 사용 면적으로 기준을 바꾸고 비교금액도 다시 만들었지만 변경 사유가 남아 있지 않습니다.
• 동인 적정성 확인(A09) 2개 — 사내 복지시설 운영비를 매출액 비례로 나눈 두 풀은 회사가 동인의 적정성을 먼저 판단해야 합니다.

영업비용 합계 줄은 두 회사 모두 차이가 0입니다. 그래서 합계만 맞춰 보던 방식으로는 놓칩니다. 회사 1000만 봐도 매출원가는 장부가 재계산보다 111.1백만 원 적고, 판매비·관리비·연구개발비는 각각 54.7백만 원·11.4백만 원·45.0백만 원 많아 한쪽이 줄면 다른 쪽이 늘어 서로 상쇄합니다. 기능별 손익을 보는 사람에게는 이 어긋남이 그대로 숫자가 됩니다. 한편 허용 범위 안의 작은 차이(전력·수도 공통비 2000, 0.30%p)는 정상으로 두어 점검 대상이 불어나지 않게 했습니다.

도입하면 달라지는 것

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

이런 회사에 맞습니다

영업비용을 기능별로 표시하면서 공통비 풀이 여러 개이고 배분 기준을 해마다 손보는 회사, 배부 결과를 엑셀로 다시 계산해 확인하는 재무보고·관리회계 조직, 그리고 감사인에게 기능별 배분의 근거를 풀 단위로 설명해야 하는 회사에 맞습니다. 반대로 공통비가 거의 없거나 영업비용을 기능별로 나누어 보이지 않는 회사라면 이 앱의 값은 크지 않습니다.

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

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

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

도입 후 쓰는 순서

1. 회계연도(필수)와 필요하면 회사·기능·현재 배분 기준·기준 변경·기준 확정일 구간을 골라 조회를 누릅니다. 공통비 풀 이름 칸에서 Enter 를 눌러도 됩니다.
2. 맨 위 요약 여섯 칸으로 점검 규모를 봅니다. 점검 필요 풀 수는 서비스의 함수로 따로 받아 옵니다.
3. 풀별 표에서 점검 필요와 확인 필요 풀을 훑고, 행을 눌러 기준 이력과 기능별 배분 내역을 확인합니다.
4. 기능별 배분 상세 탭에서 재계산과 장부 배분율이 어디서 갈리는지, 기능별 비용 합계 탭에서 기능마다 얼마나 어긋났는지 봅니다.
5. 대사 탭에서 정합성 대사 여섯 건이 0인지 확인한 뒤, 참고 대사의 차이 풀을 담당 부서와 확인합니다.
6. 현재 탭의 결과는 CSV 로 내려받아 결산 점검 근거로 보관합니다.

실행 화면

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

처음 열었을 때

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

조건으로 좁히기

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

풀 안을 들여다보기

장부 배분율이 전기 배분율과 같은데 재계산과 다르면 동인 자료를 갱신하지 않고 전기 비율을 그대로 쓴 풀일 가능성이 큽니다. 이 탭은 그 의심을 숫자로 확인하는 자리입니다.

공통비는 기능 사이에서 옮겨질 뿐 총액은 그대로라 합계 줄은 늘 0입니다. 어긋남은 기능 줄에서 서로 반대 방향으로 나타나므로 합계 줄만 보면 놓칩니다.

대사와 상세

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

왜 이 풀이 점검 필요인지 동인 수량부터 배분액까지 설명할 수 있어야 담당자가 숫자를 믿습니다. 풀 안에서 기능별 차이를 합하면 0이라는 점은 대사 005 가 매번 확인합니다.

조회조건 한눈에 보기

점검 코드

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

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

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

OData 구성

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

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

이 앱이 하지 않는 것

• 동인이 적정한지, 어떤 기준으로 나눌지 판단하지 않습니다. 코드는 점검 신호이고 판단은 회사와 감사인의 몫입니다.
• 배부 전표를 만들거나 장부 금액을 고치지 않습니다. 이 앱은 조회·점검 전용입니다.
• 기준서 문단번호를 인용하지 않습니다. 원문을 확인하기 전에는 적지 않는다는 원칙입니다.

CDS 구성

이 사례의 화면은 공통비 풀 16개와 기능별 배분 64줄을 서비스가 들고 계산합니다. 데모라서 되는 일이고, 운영 데이터에서는 공통비 풀과 동인 통계 값을 CDS 로 모아 같은 모양으로 내려 줍니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 정책 테이블

허용 오차와 점검 대상 기준을 코드가 아니라 설정으로 둡니다. 운영 전환에서 가장 먼저 합의해야 하는 항목입니다.

" 공통비 배분 점검 정책 (투명 테이블 스케치)
@EndUserText.label : '공통비 배분 점검 정책'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table cost_alloc_policy {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key gjahr      : gjahr not null;
  rate_tol       : abap.dec(5,2);       " 허용 배분율 차이(%p) — 사례는 0.50
  sale_basis_chk : abap.char(1);        " 매출액 비례 풀을 확인 필요로 둘지 — 회사 판단
}

② 공통비 풀 원천 뷰

풀 금액과 배분 기준 이력을 읽는 자리입니다. 공통비를 어디서 관리하느냐에 따라 이 뷰만 달라집니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '공통비 풀 원천'
define view entity CostPoolSrc
  as select from cost_pool_master as m       " 확인 필요 : 실제 풀 관리 객체 이름
{
  key m.gjahr       as Gjahr,
  key m.bukrs       as Bukrs,
  key m.pool_code   as PoolCode,
      m.pool_name   as PoolName,
      m.basis_code  as BasisCode,            " 현재 배분 기준
      m.prev_basis  as PrevBasisCode,        " 전기 배분 기준
      m.restate_flg as RestateFlag,          " 비교기간 재작성 — 확인 필요
      m.reason_flg  as ReasonFlag,           " 변경 사유 기록 — 확인 필요
      m.basis_date  as BasisDate,            " 기준 확정일
      @Semantics.amount.currencyCode : 'Waers'
      m.pool_amt    as PoolAmt,
      m.waers       as Waers
}

③ 동인 수량 원천 뷰

기능별 동인 수량과 장부에 실린 배분액을 읽습니다. 동인 통계 값을 어디서 가져오는지는 회사마다 다릅니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '기능별 동인 수량과 장부 배분'
define view entity CostDriverSrc
  as select from cost_driver_stat as d       " 확인 필요 : 동인 통계 값 구성
  inner join cost_alloc_booked    as b
    on  b.gjahr = d.gjahr and b.bukrs = d.bukrs
    and b.pool_code = d.pool_code and b.func_code = d.func_code
{
  key d.gjahr      as Gjahr,
  key d.bukrs      as Bukrs,
  key d.pool_code  as PoolCode,
  key d.func_code  as FuncCode,
      d.driver_qty as DriverQty,
      @Semantics.amount.currencyCode : 'Waers'
      b.booked_amt as BookedAmt,
      b.waers      as Waers
}

④ 재계산 배분 뷰

동인 수량으로 배분율과 배분액을 다시 계산합니다. 창 함수로 풀 합계를 한 번에 구합니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '동인 재계산 배분'
define view entity CostAllocExpect
  as select from CostDriverSrc as a
  inner join     CostPoolSrc   as p
    on  p.Gjahr = a.Gjahr and p.Bukrs = a.Bukrs and p.PoolCode = a.PoolCode
{
  key a.Gjahr, key a.Bukrs, key a.PoolCode, key a.FuncCode,
      a.DriverQty,
      " 재계산 배분율 = 동인 수량 / 풀 동인 합계 (소수 둘째 자리)
      cast( a.DriverQty * 100.0
            / sum( a.DriverQty ) over( partition by a.Gjahr, a.Bukrs, a.PoolCode )
            as abap.dec(9,2) )                          as ExpectRate,
      @Semantics.amount.currencyCode : 'Waers'
      a.BookedAmt,
      p.PoolAmt,
      a.Waers
      " 원 단위 나머지 조정(가장 큰 나머지 순서)은 서비스에서 처리 — 확인 필요
}

⑤ 점검 계산 뷰

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

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '공통비 배분 점검 계산'
define view entity CostPoolCheck
  as select from CostPoolSrc as p
  inner join cost_alloc_policy as t on t.bukrs = p.Bukrs and t.gjahr = p.Gjahr
  association [0..1] to CostRateGap as _g
    on _g.Gjahr = p.Gjahr and _g.Bukrs = p.Bukrs and _g.PoolCode = p.PoolCode
{
  key p.Gjahr, key p.Bukrs, key p.PoolCode,
      p.BasisCode, p.PrevBasisCode,
      _g.MaxRateDiff,
      case
        when p.BasisCode <> p.PrevBasisCode and p.RestateFlag = 'N'       then 'A01'
        when p.BasisCode <> p.PrevBasisCode and p.ReasonFlag  = 'N'       then 'A02'
        when _g.MaxRateDiff > t.rate_tol                                       then 'A03'
        when p.BasisCode = 'SALE' and t.sale_basis_chk = 'X'               then 'A09'
        else 'A00'
      end as CheckCode
}

⑥ 기능 집계 뷰

기능별 직접비와 배분액을 모아 장부 합계와 재계산 합계를 만듭니다. 화면이 아니라 DB 에서 모읍니다.

@Analytics.dataCategory : #CUBE
@EndUserText.label      : '기능별 비용 합계'
define view entity CostFuncTotal
  as select from CostAllocExpect as e
  inner join     func_direct_cost as d
    on d.gjahr = e.Gjahr and d.bukrs = e.Bukrs and d.func_code = e.FuncCode
{
  key e.Gjahr,
  key e.Bukrs,
  key e.FuncCode,
      @Semantics.amount.currencyCode : 'Waers'
      max( d.direct_amt )                          as DirectAmt,
      @Semantics.amount.currencyCode : 'Waers'
      sum( e.BookedAmt )                           as AllocBooked,
      @Semantics.amount.currencyCode : 'Waers'
      sum( cast( e.PoolAmt * e.ExpectRate / 100 as abap.curr(18,0) ) ) as AllocExpect,
      e.Waers
}
group by e.Gjahr, e.Bukrs, e.FuncCode, e.Waers

⑦ 권한

회사코드 권한을 집계를 읽는 자리에 걸어 두어 합계에서 빼는 방식으로 다른 회사 숫자가 새지 않게 합니다.

@EndUserText.label : '공통비 배분 점검 권한'
@MappingRole : true
define role CostPoolCheckRole {
  grant select on CostPoolCheck
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

창 함수와 형 변환 문법은 릴리스마다 다를 수 있어 확인이 필요합니다. 위 코드는 구조를 보여 주는 스케치입니다.

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

자주 묻는 질문

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

계산과 판정

범위와 한계

도입과 운영