경영회의에서 “예산이 얼마 남았습니까?”라는 질문이 나오면 의외로 여러 답이 나올 수 있다.
연초 예산은 100억원인데 실제 지출은 70억원이니 30억원이 남았다는 답이 있을 수 있다.
하지만 이미 발주한 금액이 25억원 있다면 실제로 새로 사용할 수 있는 금액은 5억원에 가까울 수 있다.
이 차이는 숫자가 틀려서 생기는 것이 아니라 Plan, Budget, Commitment, Actual이 서로 다른 상태의 돈이기 때문에 발생한다.
Plan은 미래를 설명하고 Budget은 사용권한을 통제한다
둘 다 미래금액이지만 목적이 다르다.
Plan은 조직이 앞으로 무엇을 할 것으로 예상하는지 표현하는 management expectation에 가깝다.
Budget은 특정 객체가 얼마까지 사용할 수 있는지 통제하기 위한 승인금액으로 사용할 수 있다.
예를 들어 영업부의 내년 예상 출장비가 5억원이라고 계획했다고 해서 반드시 5억원 전체의 지출권한이 자동 승인됐다는 뜻은 아니다.
Forecast는 Plan의 수정본과도 다르다
연초 계획이 100억원인데 상반기 이후 실제 사업상황을 보니 연말에 115억원이 들 것으로 예상된다고 하자.
Forecast는 115억원으로 바뀔 수 있다.
그렇다고 Budget도 자동으로 115억원이 되는 것은 아니다.
경영진이 추가 예산 15억원을 승인하지 않았다면:
- Forecast = 115억원
- Budget = 100억원
이 동시에 존재할 수 있다.
이 차이가 바로 향후 예산초과 위험을 보여주는 management signal이다.
Actual만 보고 남은 예산을 계산하면 늦다
예산 100억원, Actual 70억원이라고 하자.
단순 계산에서는:
100 – 70 = 30억원
이 남는다.
하지만 이미 발주됐으나 아직 invoice가 오지 않은 Commitment가 25억원이라면 실질 available amount는:
100 – 70 – 25 = 5억원
으로 볼 수 있다.
구매요청과 PO가 예산소비에 제대로 반영되지 않으면 월말 P&L이 나오기 전까지 과다구매를 발견하지 못할 수 있다.
Budget Control의 목적은 초과를 보고하는 것이 아니라 초과 전에 개입하는 것이다
월말 보고서에서 “예산을 10억원 초과했습니다”라고 알려주는 것은 분석이다.
통제는 그보다 앞에서 작동해야 한다.
SAP의 Availability Control 개념은 actual/commitment posting이 발생하는 과정에서 사용 가능한 예산과 비교해 tolerance에 따라 warning 또는 error 같은 action을 취할 수 있도록 설계한다.
즉 예산통제의 질문은:
“얼마 초과했는가?”가 아니라 “이 transaction을 지금 허용해야 하는가?”
다.
모든 초과를 Error로 막는 것도 좋은 통제는 아니다
예산을 1원이라도 넘으면 transaction을 막도록 하면 엄격해 보인다.
하지만 실제 업무에서는:
- 환율변동
- 가격상승
- 긴급수선
- 법적 의무지출
- 월말 time lag
등이 발생한다.
통제가 지나치게 경직되면 사용자는:
- 다른 Cost Center에 비용을 넣거나
- PO를 쪼개거나
- 사후에 예산을 형식적으로 늘리는
우회행동을 할 수 있다.
좋은 Availability Control은 zero tolerance가 아니라 business risk에 맞는 tolerance와 escalation을 갖는다.
예산을 너무 상세하게 쪼개면 관리비가 커진다
모든 G/L account마다 예산을 별도로 관리하면 정확해 보인다.
그러나 호텔비·항공료·교통비 각각의 예산을 별도로 통제하면 한 항목은 남고 다른 항목은 부족해 불필요한 transfer가 반복될 수 있다.
SAP의 Cost Center Budget Availability Control도 account group 개념을 사용해 여러 비용계정을 하나의 예산그룹으로 관리할 수 있는 구조를 제공한다.
따라서 예산 granularity는 회계계정의 상세도와 반드시 같을 필요가 없다.
예산구조는 책임단위와 의사결정권한을 따라야 한다
Cost Center A와 B가 같은 팀장의 통제 아래 있고 실제로 하나의 예산 pool을 공유한다면 별도의 작은 예산을 각각 만드는 것보다 budget-carrying structure를 이용하는 방식이 더 현실적일 수 있다.
반대로 각 Cost Center manager에게 독립된 책임을 부여하려면 budget도 분리돼야 한다.
예산구조는 시스템 convenience가 아니라 누가 지출결정을 책임지는가를 반영해야 한다.
Original Budget와 수정예산을 구분해야 성과평가가 가능하다
연초 100억원을 승인받았는데 연중 20억원을 추가 승인해 최종 Current Budget가 120억원이 됐다고 하자.
실제 지출이 115억원이면 current budget 대비 5억원 절감이다.
그러나 original budget 대비로는 15억원 초과다.
두 숫자는 각각 다른 질문에 답한다.
- Current Budget 대비: 최종 승인범위 안에서 집행했는가?
- Original Budget 대비: 연초 예상과 실제 사업이 얼마나 달라졌는가?
따라서 예산 증액으로 variance를 지워버리면 planning quality 분석을 잃는다.
예산 변경도 Transaction History다
SAP는 budget change를 line item 형태로 기록할 수 있다.
Original Budget, Supplement, Return, Transfer 같은 변화를 추적하면 현재 예산액만 보고서는 알 수 없는 경영정보가 생긴다.
예를 들어 매년 특정 Cost Center가 하반기에 반복적으로 Supplement를 요구한다면:
- 초기예산이 구조적으로 낮거나
- scope가 계속 변경되거나
- 지출통제가 약하거나
- 계획 driver가 잘못됐을
가능성을 분석할 수 있다.
예산보고는 다섯 숫자를 한 화면에서 보는 것이 좋다
| 지표 | 질문 |
|---|---|
| Original Budget | 처음 무엇을 승인했는가? |
| Current Budget | 변경 후 지금 승인된 금액은? |
| Commitment | 이미 미래지출로 예약된 금액은? |
| Actual | 이미 발생한 비용은? |
| Available | 추가로 사용할 수 있는 금액은? |
여기에 Forecast를 별도로 놓으면 “사용 가능한 예산”과 “연말 예상비용”을 동시에 볼 수 있다.
예산초과 원인은 금액이 아니라 Driver까지 내려가야 한다
인건비가 5억원 초과했다고 하자.
원인은:
- 인원수 증가
- 평균단가 증가
- 채용시점 변화
- 조직이동
- 계획되지 않은 overtime
등일 수 있다.
따라서 예산 variance는:
Price × Quantity × Timing × Scope
의 변화로 분해하면 다음 계획의 품질까지 개선할 수 있다.
결론
SAP 예산관리를 하나의 “예산입력 화면”으로 생각하면 중요한 부분을 놓친다.
Plan은 기대, Budget은 승인, Commitment는 예정된 소비, Actual은 발생한 비용, Forecast는 현재 시점의 미래전망이다.
이 다섯 숫자를 구분해야 Availability Control이 의미를 가진다.
좋은 예산통제는 월말에 초과를 발견하는 것이 아니라 구매와 비용발생 시점에 남은 자원을 보여주고, 필요한 경우 transaction이 실행되기 전에 경영판단을 요구하는 것이다.