변동예산 대비 실적 차이 점검 — 관리회계, 정적 예산에 가려진 초과 지출을 조업도 기준으로 다시 찾는 월마감 화면

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

월마감 시 코스트센터 비용 분석은 정적 예산만으로는 실제 초과 지출 원인을 파악하기 어렵습니다. 이 솔루션은 실제 조업도를 반영한 변동예산으로 실적을 재검토하고, 비용 차이를 조업도 영향과 순수한 지출 초과로 분해하여 정확한 의사결정을 지원합니다.

핵심 포인트 일곱 가지

사례로 보는 효과

3월 기계 가공부 전력비는 정적 예산 기준 총차이율이 -6.54%로 한도 이내였지만, 실제 조업도를 반영한 변동예산 기준으로는 지출 차이율이 14.0%이며 지출 차이는 615,624원으로 확인되었습니다. 이처럼 정적 예산에 가려져 있던 6건의 초과 지출 후보를 찾아냅니다.

도입하면 달라지는 것

• 비용 초과 원인 규명이 명확해집니다.
• 월마감 전 검토 시간이 단축됩니다.
• 가려진 지출 문제점을 사전에 발견합니다.
• 불필요한 보고서 작성 및 검토가 줄어듭니다.

이런 회사에 맞습니다

월마감 시 코스트센터 비용 통제 및 분석에 어려움을 겪는 관리회계, 재무 부서와 CFO에게 적합합니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 그래서 화면을 만들기 전에 대사식 여덟 개를 먼저 세우고 자료 전수에 돌렸습니다.

여덟 대사식 모두 차이 건수 0건입니다(검사 1,201건). 이와 별도로 판정 기준에 걸리는 건을 일부러 넣었습니다. 가려진 초과 6건 · 지출 초과 6건 · 고정비 이탈 3건(비용요소 점검 필요 15건)과 조업도 영향 8건이며, 코스트센터 · 월 합계 4건과 비용 성격 · 월 합계 1건도 합계 기준 3%를 넘습니다. 이 건들은 대사 차이가 아니라 점검 대상이라 차이 건수에 넣지 않았습니다.

실행 화면

아래 화면은 가상의 코스트센터 6곳(프레스 가공부 · 기계 가공부 · 조립부 · 도장부 · 사출부 · 포장·출하부)과 가상의 비용요소 8개로 만든 검증용 샘플 데이터(2026년 1~6월)를 실제로 조회한 모습입니다. 비용요소 · 코스트센터 · 월 288행이고, 실제 고객사 값이 아닙니다.

처음 열었을 때

열면 자동으로 한 번 조회해, 조회조건 아래에 요약 지표와 코스트센터별 집계 표가 한꺼번에 나옵니다.

맨 위 조회조건은 회계연도 · 전기 월 시작/종료 · 코스트센터 · 비용 성격 · 점검 결과 여섯 칸이고 기본값은 2026년 전체입니다. 6개월 합계는 정적 예산 1,708.4 · 변동예산 1,704.6 · 실적 1,719.3(이상 백만 원)입니다. 조업도 차이는 -3.9, 지출 차이는 +14.8, 지출 차이율은 0.87%입니다. 합계로는 작아 보여도 점검 필요 항목이 15건, 그중 가려진 초과가 6건이라는 점이 이 화면이 보여 주려는 것입니다. 표는 코스트센터 · 월마다 조업률과 두 예산, 실적, 차이를 한 줄에 둡니다.

점검 필요 항목만 좁혀 보기

두 번째 탭에서 점검 결과를 점검 필요로 두면 비용요소 단위의 후보 15건만 남습니다.

행마다 비용 성격(변동 · 준변동 · 고정), 정적 예산 기준 총차이율, 변동예산 기준 지출 차이율, 점검 코드와 점검 내용이 있습니다. 같은 15건이라도 코드가 다릅니다. 가려진 초과(MSK1) 6건은 총차이율이 한도 안인데 지출 차이율만 높고, 지출 초과(SPN1) 6건은 두 값이 모두 높으며, 고정비 이탈(FIX1) 3건은 고정 예산에서 5% 넘게 벗어난 항목입니다. 코드를 보면 먼저 확인할 일이 갈립니다.

행을 눌러 차이를 분해하기

표의 행을 누르면 그 항목의 차이가 어디서 왔는지 한 창에서 읽습니다.

상세 창은 위에서부터 정적 예산 → 조업도 차이 → 변동예산 → 지출 차이 → 실적 순서로 한 문장에 놓고, 같은 코스트센터 · 월의 비용요소 명세를 아래에 둡니다. 조업도 차이가 큰데 지출 차이가 작으면 일이 적거나 많았다는 뜻이고, 지출 차이가 크면 단가나 사용량을 확인하라는 뜻입니다. 점검 필요 행은 어떤 조건에 걸렸는지 문장으로 같이 나옵니다.

비용 성격별로 모아 보기

세 번째 탭은 비용을 변동비 · 준변동비 · 고정비로 나눠 월별로 합칩니다.

성격 · 월 18행이고, 변동비는 조업도 차이가 크게 나타나고 고정비는 조업도 차이가 0입니다. 합계 지출 차이율이 3%를 넘으면 점검 필요(합계)로 표시하는데, 이 자료에서는 3월 변동비(3.85%) 한 건이 해당합니다. 개별 비용요소는 한도 안인데 합쳐서 보면 한 방향으로 쏠려 있는 경우를 잡는 용도입니다.

월별 추이

네 번째 탭은 6개월을 한 줄씩 놓고 조업률이 흔들린 달과 차이가 커진 달을 봅니다.

월 조업률은 1월 97.25%, 2월 95.57%, 3월 95.12%, 4월 100.08%, 5월 104.50%, 6월 101.98%입니다. 조업률이 낮았던 2~3월에는 조업도 차이가 -319만 원, -385만 원으로 음수이고, 5월에는 +336만 원입니다. 지출 차이는 1월을 빼면 모두 양수여서 일의 양과 별개로 지출이 변동예산을 웃돌았다는 점이 보입니다. 비용요소 점검 필요 건수가 가장 많은 달은 3월과 6월(각 4건)이며, 월 행을 눌러 그 달의 명세를 열 수 있습니다.

대사 결과

마지막 탭은 숫자를 믿어도 되는지 확인하는 자리입니다.

여덟 대사식마다 검사 건수 · 좌변 · 우변 · 차이 건수 · 최대 차이가 나옵니다. 검사는 모두 1,201건이고 차이는 0건입니다. 차이 건수 칸은 0이면 정상색, 0이 아니면 경고색으로 바뀌며, 그 숫자는 원천을 확인하라는 신호가 됩니다.

화면 뒤에서 일어나는 일

1. 조회조건을 필터 객체로 바꿔 서비스의 비용요소 · 코스트센터 · 비용 성격 · 월 집계 엔티티를 각각 조회합니다.
2. 서비스가 비용요소마다 정적 예산(고정 예산 + 변동비율 × 계획 조업도)과 변동예산(같은 식에 실제 조업도)을 계산해 내려줍니다.
3. 총차이를 조업도 차이와 지출 차이로 가르고, 지출 차이율과 총차이율로 점검 코드를 정합니다.
4. 코스트센터 · 비용 성격 · 월 집계는 비용요소 금액을 더한 뒤 차이율을 합계 금액으로 다시 계산합니다.
5. 화면은 받은 값을 표에 놓고, 대사 탭은 같은 식으로 다시 검산한 결과를 보여 줍니다.

판정 규칙과 사용자 조치

한 비용요소 행은 정적 예산 기준 총차이율과 변동예산 기준 지출 차이율을 모두 갖고, 두 값의 조합으로 상태가 정해집니다. 금액 하한은 30만 원이며 이보다 작은 차이는 비율이 커도 올리지 않습니다.

원인은 단정하지 않습니다. 화면은 분류 · 집계 · 대사를 돕는 점검 도구이며, 점검 필요는 확인할 후보를 알려 주는 표시일 뿐 잘못이라는 뜻이 아닙니다.

산출식

정적 예산   = 고정 예산 + 변동비율 × 계획 조업도
변동예산   = 고정 예산 + 변동비율 × 실제 조업도   (고정비는 변동비율 0 이므로 두 예산이 같다)
총차이     = 실적 − 정적 예산 = 조업도 차이 + 지출 차이
조업도 차이 = 변동예산 − 정적 예산
지출 차이   = 실적 − 변동예산
지출 차이율 = 지출 차이 ÷ 변동예산 × 100
총차이율   = 총차이 ÷ 정적 예산 × 100
조업률     = 실제 조업도 ÷ 계획 조업도 × 100

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

표는 가로로 스크롤되고, 조회조건은 줄바꿈되어 배치됩니다. 데스크톱 화면을 기준으로 설계했으며 태블릿에서도 사용할 수 있습니다. 한 줄에 놓이던 요약 지표는 폭에 맞춰 여러 줄로 나뉩니다.

파일 구성

화면 선언 · 컴포넌트   manifest.json · Component.js · index.html
뷰                    Main.view.xml · DetailDialog.fragment.xml
컨트롤러              Main.controller.js · BaseController.js
모델 보조             formatter.js · ErrorHandler.js
OData 서비스          metadata.xml · service.js · json 파일(엔티티셋별)
문구                  i18n_ko.properties
소개 영상             intro.mp4 · intro_poster.jpg

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 이 절은 표준 화면으로 충분한 일과 이 화면이 더하는 관점을 나란히 놓고, 두 화면의 숫자를 어디서 맞추는지 적습니다.

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

T-code 별 연계 지점

운영으로 옮길 때 기존 표준 보고서를 없앨 필요는 없습니다. 표준은 계획 · 실적의 기록과 감사 대응 근거로 그대로 두고, 이 화면은 월마감 전에 확인할 항목을 먼저 골라내는 용도로 함께 씁니다.

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

S/4HANA 의 분석 쿼리나 Fiori 분석 앱으로도 코스트센터 비용 보고를 만들 수 있습니다. 다만 변동예산은 계획의 고정 · 변동 분리값과 실제 조업도를 함께 읽어야 하므로, 이 화면은 그 계산을 서비스 한 곳에 모으고 판정까지 함께 내려주는 쪽으로 만들었습니다. 표준 분석 쿼리의 계획 · 조업도 쪽 구성은 고객 환경에 따라 달라서 확인 필요로 남깁니다.

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

분석 지표 정의표

CDS 구성

아래는 이 화면이 읽는 데이터를 S/4HANA 에서 어떻게 구성할지 보여 주는 설계 스케치입니다. 표준 CDS 뷰 이름은 확인한 것만 적었고, 계획 · 조업도 쪽 표준 뷰는 확인 필요로 남기고 원천 테이블 기준으로 썼습니다.

뷰 레이어 구성

① 비용 성격 매핑 테이블

어떤 비용요소를 변동비로 볼지는 회사마다 다르고 해마다 바뀝니다. 이 분류를 코드에 박으면 바뀔 때마다 개발 요청이 생기므로 테이블로 뺍니다.

@EndUserText.label : 'Flexible budget - cost nature mapping'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zflx_nature {
  key client    : abap.clnt not null;
  key chartacct : abap.char(4) not null;
  key costelem  : abap.char(10) not null;
  nature        : abap.char(1);   " V 변동 / M 준변동 / F 고정
}

② 코스트센터 차원 뷰

코스트센터 이름이 바뀌어도 한 곳만 고치면 되도록 차원을 따로 둡니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'Cost center dimension'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_FlexBudCostCtr
  as select from I_CostCenter
{
  key ControllingArea,
  key CostCenter,
      _Text[1: Language = $session.system_language].CostCenterName as CostCenterName
}

③ 실적 뷰

전표 라인을 코스트센터 · 비용요소 · 기간으로 합산합니다. 실적이 어디서 나오는지 한 곳에서 보이게 하는 자리입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'Flexible budget actual'
define view entity ZI_FlexBudActual
  as select from I_JournalEntryItem as je
{
  key je.CostCenter                         as CostCtr,
  key je.GLAccount                          as CostElem,
  key je.FiscalYear                         as Gjahr,
  key je.FiscalPeriod                       as Period,
      @Semantics.amount.currencyCode: 'Currency'
      sum(je.AmountInCompanyCodeCurrency)   as ActualCost,
      je.CompanyCodeCurrency                as Currency
}
where je.Ledger = '0L'
  and je.CostCenter <> ''
group by je.CostCenter, je.GLAccount, je.FiscalYear, je.FiscalPeriod, je.CompanyCodeCurrency

④ 계획 · 조업도 뷰

고정 예산, 변동비율, 계획 조업도, 실제 조업도를 한 행에 모읍니다. 계획 설계가 고객마다 달라 원천 테이블 이름은 확인 필요로 남기고, 아래는 별도 계획 테이블을 두는 경우의 예입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'Flexible budget plan and activity'
define view entity ZI_FlexBudPlan
  as select from zflx_plan
{
  key costctr   as CostCtr,
  key costelem  as CostElem,
  key gjahr     as Gjahr,
  key period    as Period,
      fixedbud  as FixedBud,     " 고정 예산
      varrate   as VarRate,      " 조업도 1단위당 변동비율
      planact   as PlanAct,      " 계획 조업도
      actact    as ActAct        " 실제 조업도 (활동 수량 집계에서 적재, 원천 확인 필요)
}

⑤ 큐브 — 예산과 차이를 계산하는 자리

정적 예산, 변동예산, 조업도 차이, 지출 차이를 이 뷰에서만 계산합니다. 화면과 CSV 숫자가 어긋나지 않는 이유가 이것입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'Flexible budget cube'
@Analytics.dataCategory: #CUBE
define view entity ZI_FlexBudCube
  as select from ZI_FlexBudPlan as p
    left outer join ZI_FlexBudActual as a
      on  a.CostCtr = p.CostCtr and a.CostElem = p.CostElem
      and a.Gjahr   = p.Gjahr   and a.Period   = p.Period
{
  key p.CostCtr, key p.CostElem, key p.Gjahr, key p.Period,
      cast( p.FixedBud + p.VarRate * p.PlanAct as abap.curr(15,0) ) as StaticBud,
      cast( p.FixedBud + p.VarRate * p.ActAct  as abap.curr(15,0) ) as FlexBud,
      cast( coalesce( a.ActualCost, 0 ) as abap.curr(15,0) )        as ActualCost,
      cast( ( p.VarRate * p.ActAct ) - ( p.VarRate * p.PlanAct )
                                       as abap.curr(15,0) )        as VolVar,
      cast( coalesce( a.ActualCost, 0 ) - ( p.FixedBud + p.VarRate * p.ActAct )
                                       as abap.curr(15,0) )        as SpendVar
}

⑥ 소비 뷰 · 쿼리

화면이 읽는 뷰입니다. 점검 코드를 여기서 정해 서비스가 내려주고, 화면은 보여 주기만 합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Flexible budget query'
@Analytics.query: true
define view entity ZC_FlexBudQuery
  as select from ZI_FlexBudCube
{
  @AnalyticsDetails.query.axis: #ROWS
  key CostCtr,
  key CostElem,
  @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key Gjahr,
  @Consumption.filter.selectionType: #INTERVAL
  key Period,
      StaticBud, FlexBud, ActualCost, VolVar, SpendVar,
      case
        when FlexBud <> 0 and abs( SpendVar ) > 300000
         and SpendVar * 100 > FlexBud * 10 then 'CHECK'
        else 'OK'
      end as CheckStatus
}

⑦ 접근 제어(DCL)

다른 코스트센터의 비용이 보이지 않도록 집계 단계에서 막습니다. 권한 오브젝트와 값은 회사 권한 설계에 맞춰 정합니다.

@EndUserText.label: 'Flexible budget access'
@MappingRole: true
define role ZC_FlexBudQuery {
  grant select on ZC_FlexBudQuery
    where ( CostCtr ) = aspect pfcg_auth( K_CCA, KSTAR, ACTVT = '03' );
}

⑧ 서비스 정의

엔티티셋 이름은 화면이 읽는 것과 같게 노출합니다. 게시는 서비스 바인딩에서 하고, 화면의 선언 파일은 서비스 주소만 바꿉니다.

@EndUserText.label: 'Flexible budget service'
define service ZUI_FlexBud {
  expose ZC_FlexBudQuery as LineSet;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

전표가 많은 회사에서는 실적 뷰의 합산을 데이터베이스에서 끝내고 화면에는 합산된 행만 내려줍니다. 회계연도를 필수로 받고 기간 범위를 조회조건으로 쓰며, 코스트센터와 비용요소에 필요한 인덱스를 확인합니다. 화면은 한 번에 받는 행 수를 제한하고 필요한 만큼만 조회하도록 만들었습니다. 응답 시간 기준은 회사가 정하며, 일반화해서 말하기는 어렵습니다(확인 필요).

자주 묻는 질문

숫자와 산식, 화면과 조작, 점검 기능, 도입과 운영 순서로 27개를 묶었습니다.

숫자와 산식

화면과 조작

점검 기능

도입과 운영