SAP 부담금 인식시점 점검 — IFRIC 21, 조건이 채워지기 전엔 부채가 아니다
의무발생사건이 실제로 발생했는지부터 확인해야, 부담금 부채 인식 시점이 맞습니다
IFRIC 해석서 제21호 부담금(K-IFRS 제2121호)은 부담금 부채를, 그 부담금을 부과하는 법령이 정한 의무발생사건이 실제로 발생하는 시점에 전액 인식하도록 합니다. 의무발생사건이 특정 기준일의 자산 보유나 연간 매출액 임계값 도달처럼 시점이 분명한 사건이라면, 그 시점 이전에는 아무리 관련 활동이 이미 진행 중이더라도 부채를 기간에 걸쳐 안분해 미리 인식하지 않습니다. 문제는 이 원칙이 실무 감각과는 다소 어긋난다는 점입니다 — "어차피 낼 돈이니 미리 쌓아두자"는 접근이 오히려 기준서 위반이 될 수 있습니다.
표준 원장·전표 구조를 그대로 이어받아, 관리 중인 부담금별로 의무발생사건 도달여부를 확인하고 도달한 항목만 부과기준액×요율로 인식대상액을 산정해 GL 인식액과 대사하는 화면을 OpenUI5로 확장했습니다. 도달 전 선인식과 도달 후 미인식·과소인식을 함께 가려내며, 판정 결과는 항상 "점검 필요"로 표시해 담당자가 직접 경위를 확인하도록 안내합니다. 실제 구동 화면 3종을 함께 공개합니다.
SAP 표준 기능을 그대로 이어받은 부분
- GL 인식액 확인 — 부담금 관련 계정의 라인아이템 조회는 표준 총계정원장 구조를 그대로 활용
- 전표 원천 — 전기일·전표번호는 표준 전표 헤더 구조를 그대로 사용
- 표준 화면 — 총계정원장 라인아이템 조회(FBL3N) · 전표 조회(FB03)
| 항목 | 내용 |
|---|---|
| 업무 영역 | 재무회계(FI) · 결산 |
| 관련 기준서 | IFRIC 해석서 제21호 부담금(K-IFRS 제2121호) |
| Namespace | zui5.levycheck |
| 셸 구조 | 조회조건 영역(우측 조회) + 명세/집계 2탭, 상세 Dialog |
| 화면 수 | 조회 화면 1개(2탭) + 상세 다이얼로그 |
| SAP 표준 T-code | FBL3N · FB03 · FAGLL03 |
| 데이터 연동 방식 | OData 서비스 — 화면은 조회 전용, 조건은 $filter 로 전달 |
| 성격 | 조회·대사형 — 최종 회계처리 판단은 회사·감사인 몫 |
| 테마 | sap_horizon 단일 적용 |
실제 화면 3종 둘러보기
회사코드·회계연도·부담금 유형·점검결과를 넣고 조회하면 부담금 명세가 뜹니다 → 유형별 집계 탭에서 합계를 확인하고 → 행을 클릭하면 산정 근거가 다이얼로그로 열립니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
조작 방법
- 회사코드 · 회계연도 · 부담금 유형 · 점검결과를 지정합니다. "전체"를 선택한 조건은 조회에서 빠집니다.
- 회계연도 입력 필드에서 Enter 키를 누르거나 조회조건 영역 오른쪽 끝의 조회 버튼을 누르면 재조회됩니다. 초기화 버튼은 조건을 기본값으로 되돌립니다.
- "부담금 명세" 탭의 행을 클릭하면 산정 근거 상세 다이얼로그가 열립니다.
- "유형별 집계" 탭에서는 같은 조회조건으로 회사코드·부담금 유형별 합계를 확인합니다.
인식시점 판정 로직
부담금은 의무발생사건이 실제로 발생하는 시점에 전액을 인식하며, 기간에 걸쳐 안분해 인식하지 않습니다. 이 화면은 의무발생사건 도달여부와 GL 인식액을 대사해 점검이 필요한 항목을 가려냅니다.
| 판정 조건 | 결과 상태 | 사용자 조치 |
|---|---|---|
| 의무발생사건 도달 + 인식대상액과 GL 인식액 일치(차이 0) | 정상 | 별도 조치 불필요 |
| 의무발생사건 도달 + 인식대상액과 GL 인식액 불일치(차이 ≠ 0) | 점검 필요 | 전기 내역을 확인해 차이 원인을 파악 |
| 의무발생사건 미도달 + GL 인식액 0 초과 | 점검 필요 | 조기 인식 여부를 확인 — 도달 전 인식은 원칙적으로 인정되지 않음 |
| 의무발생사건 미도달 + GL 인식액 0 | 정상 | 별도 조치 불필요 |
이 화면이 대신 정하지 않는 것
의무발생사건의 정확한 해석(어느 시점이 진정한 의무발생사건인지)은 개별 부담금의 근거 법령마다 다를 수 있습니다. 이 화면은 등록된 의무발생사건 유형·도달일을 기준으로 대사만 수행하는 점검 도구이며, 법령 해석과 최종 회계처리 판단은 회사와 감사인이 합니다.
인식대상액 산출 절차
| 단계 | 내용 |
|---|---|
| 1단계 | 회사코드·회계연도·부담금 유형별로 관리 중인 부담금 항목을 나열 |
| 2단계 | 부담금별 의무발생사건 유형과 도달일을 확인 |
| 3단계 | 의무발생사건에 도달한 항목만 부과기준액×요율로 인식대상액을 산정(미도달 항목은 0) |
| 4단계 | 산정된 인식대상액을 GL 인식액과 대사해 차이를 계산 |
| 5단계 | 차이와 도달여부 조합에 따라 정상/점검 필요로 구분 표시 |
조회조건
| 필드 | 필수 | 설명 |
|---|---|---|
| 회사코드 | 선택 | 전체 선택 시 조건 미전달 |
| 회계연도 | 필수 | 4자리 연도, Enter 키로 바로 조회 |
| 부담금 유형 | 선택 | 환경개선부담금·폐기물부담금·교통유발부담금·대기배출부과금 중 선택 |
| 점검결과 | 선택 | 정상/점검 필요/점검 필요(조기 인식 소지) 중 선택 |
결과 컬럼
| 컬럼 | 설명 |
|---|---|
| 부담금ID · 부담금 명칭 | 부담금 항목 식별자와 명칭 |
| 회사코드 · 부담금 유형 | 관리 회사코드와 부담금 유형 분류 |
| 의무발생사건 유형 · 도달여부 | 법령상 인식 시점을 정하는 사건의 유형과 결산일 현재 도달 여부 |
| 부과기준액 · 요율 | 인식대상액 산정의 기초가 되는 기준액과 적용 요율 |
| 인식대상액 | 부과기준액×요율로 계산한, 도달 시 인식해야 할 금액 |
| GL 인식액 · 차이 | 원장에 실제로 기표된 인식액과 인식대상액과의 차이 |
| 점검결과 | 정상 / 점검 필요 판정 상태 |
SAP 표준 기능 매핑
| SAP 표준 T-code | 연관 기능 |
|---|---|
FBL3N | 총계정원장 라인아이템 조회 |
FB03 | 전표 조회 |
FAGLL03 | 총계정원장(신) 라인아이템 조회 |
IFRS 요구사항 매핑표
| 기준서 | 요구사항 | 대응 기능 | 원천 데이터 |
|---|---|---|---|
| IFRIC 해석서 제21호 부담금(K-IFRS 제2121호) | 의무발생사건 인식 원칙 — 법령이 정한 의무발생사건이 발생하는 시점에 부채를 전액 인식하고 안분 인식하지 않음 | 의무발생사건 도달여부 확인, 인식대상액 산정 | 부담금 관련 전표, 부담금 기준정보 |
| IFRIC 해석서 제21호 부담금(K-IFRS 제2121호) | 인식대상액과 실제 기표액의 대사 | GL 인식액 대사, 차이 산출 및 점검결과 표시 | 부담금 관련 계정 라인아이템 |
도입 시 확인이 필요한 부분
개별 부담금의 근거 법령과 의무발생사건 해석, 세부 시행일·경과규정은 회사가 직접 확인해야 합니다.
참고 CDS 뷰
운영 서비스로 연결할 때를 가정해 새로 스케치한 조회 뷰 예시입니다(운영 반영 시 권한 체크를 추가해야 합니다).
@AbapCatalog.sqlViewName: 'ZCDSLEVYIT'
define view C_LevyLiabilityItem
as select from bkpf
inner join bseg
on bseg.bukrs = bkpf.bukrs
and bseg.belnr = bkpf.belnr
and bseg.gjahr = bkpf.gjahr
{
key bkpf.bukrs as CompanyCode,
key bkpf.gjahr as FiscalYear,
bkpf.belnr as DocNo,
bkpf.budat as PostingDate,
sum(bseg.dmbtr) as GLRecognizedAmount
}
// 인식대상액(부과기준액×요율)은 부담금 기준정보와 결합해 별도 산출
OpenUI5 구성
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 골격 | sap.m.Page + 조회조건 Panel + 명세/집계 IconTabBar |
| 조회조건 | sap.m.Select · sap.m.Input — 우측 끝에 조회 버튼, Enter 키로 즉시 재조회 |
| 부담금 명세 | sap.ui.table.Table(컬럼 10개 초과) — 행 클릭 시 상세 다이얼로그 |
| 유형별 집계 | sap.m.Table(소량 데이터) |
| 상세 | sap.m.Dialog — 선택 행의 산정 근거와 재계산 버튼 |
| 공통 처리 | 전역 오류 처리기(ErrorHandler) |
서비스 경로는 manifest.json 의 dataSources 에 상대 경로로 선언한 OData 모델을 그대로
바인딩하며, 조회조건은 sap.ui.model.Filter 로 조립해 서버에는 필터 조건으로만 전달합니다. "전체"를
선택할 때는 해당 필터를 아예 생성하지 않습니다.
파일 구성
| 경로 | 역할 |
|---|---|
index.html | OpenUI5 부트스트랩 — sap_horizon |
Component.js | 컴포넌트 초기화, 전역 오류 처리기 연결 |
manifest.json | 앱 디스크립터 — zui5.levycheck · OData dataSources · ko 로케일 |
view/Main.view.xml | 조회조건 + 명세/집계 탭 |
view/DetailDialog.fragment.xml | 산정 근거 상세 다이얼로그 |
controller/Main.controller.js | 조회·필터 조립·다이얼로그 로직 |
controller/BaseController.js | 공통 CSV 다운로드 |
model/ErrorHandler.js | 전역 오류 처리 |
model/formatter.js | 금액·요율·점검상태 서식 |
i18n/i18n_ko.properties | ko 로케일 리소스 |
검증 환경 구성 상세는 이 글에서 다루지 않습니다. 운영 전환 시에는 화면과 판정 로직은 그대로 두고 데이터 계층만 실제 서비스 호출에 맞추면 됩니다.
검증 결과
화면 구성에 쓴 데이터는 항목별 차이 합계와 집계별 차이 합계가 항상 일치하도록 구성했습니다.
| 검증 항목 | 결과 |
|---|---|
| 정합성 대사 — 항목별 차이 합계 = 집계별 차이 합계 | 일치 |
| 표시 금지 검사 — 커스텀 프로그램ID·앱 식별자·출처 표현 검출 | 0건 |
| 화면 렌더링 — 실브라우저에서 조회 → 탭 전환 → 행 클릭 상세까지 실동작 후 캡처 | 3/3 |
| 조회 버튼 위치 · sap_horizon 테마 적용 · Enter 키 조회 | 확인 |
| OData 계약 — 동사 경로 미사용, $filter·$orderby 로만 조회조건 전달 | 확인 |
부담금 항목과 금액은 모두 검증용으로 구성한 가상 데이터입니다.
자주 묻는 질문
IFRIC 제21호 부담금은 언제부터 적용되나요?
IFRIC 해석서 제21호 부담금은 2014년 1월 1일 이후 개시하는 회계연도부터 적용되어 왔으며, K-IFRS 에도 동일하게 도입되어 있습니다. 개별 회사의 최초 적용 시점 등 세부 경과규정은 원문 확인이 필요합니다.
"점검 필요"로 표시된 항목은 반드시 잘못된 것인가요?
아닙니다. 이 화면은 의무발생사건 도달여부와 GL 인식액의 차이를 기계적으로 가려내는 조회·점검 도구이며, 점검결과는 확인이 필요한 항목을 알리는 표시일 뿐입니다. 최종적인 회계처리 판단은 회사와 감사인이 수행합니다.
의무발생사건에 아직 도달하지 않은 부담금도 화면에 표시되나요?
예. 향후 의무발생사건 도달이 예상되는 항목도 함께 표시해 GL 인식액이 선반영되지 않았는지 점검할 수 있도록 합니다.
조회조건에서 "전체"를 선택하면 어떻게 처리되나요?
"전체"를 선택한 조건은 서버로 전달하는 조회조건에서 제외됩니다. 코드값 "전체"를 그대로 보내지 않고, 해당 조건 자체를 만들지 않는 방식으로 처리합니다.