채권 잔액은 어디에 기록되는가 — 개념 배경
SAP FI에서 고객에게 송장을 전기하면 회계 담당자는 두 곳에서 그 금액을 확인할 수 있습니다. 하나는 거래처별 상세가 남는 보조원장(Subledger), 즉 고객 계정이고, 다른 하나는 재무제표의 원천인 총계정원장(General Ledger)입니다. 그런데 전표를 입력할 때 총계정원장 계정을 직접 지정한 적이 없는데도 외상매출금 계정 잔액은 정확히 늘어나 있습니다. 이 자동 연결을 담당하는 장치가 바로 재조정계정(Reconciliation Account, 대체계정)입니다.
이 글은 SAP S/4HANA(온프레미스 2023 기준, ECC 6.0에도 개념 동일)를 배경으로, 고객 보조원장 잔액이 재조정계정을 통해 총계정원장에 반영되는 구조를 단계별로 해부하고, 왜 이 계정에는 직접 전기가 시스템 차원에서 차단되어 있는지를 회계적·기술적 근거로 설명합니다. 중급 수준의 FI 전기 경험(FB70, FB01 등)이 있다면 따라오기에 충분합니다.
보조원장과 총계정원장의 이중 기록 구조 — 동작 원리
비유하자면 보조원장은 "거래처별 가계부"이고 총계정원장은 "회사 전체의 결산 장부"입니다. 재조정계정은 이 둘을 잇는 자동 집계 파이프입니다. 고객 마스터의 회사코드 데이터(테이블 KNB1의 AKONT 필드)에는 재조정계정이 하나 지정되어 있고, 고객 앞으로 전기되는 모든 전표 라인은 이 계정으로 자동 미러링됩니다.
흐름을 도식으로 정리하면 다음과 같습니다.
- 전기 시점: 사용자는 고객 번호만 입력 → 시스템이
KNB1-AKONT를 조회 → 해당 라인의 G/L 계정(BSEG-HKONT)에 재조정계정을 자동 기입 - 보조원장 관점: 고객별 미결항목(FBL5N)으로 조회 가능
- 총계정원장 관점: 같은 라인이 재조정계정 잔액(FAGLB03)으로 집계
중요한 점은 두 장부가 별도의 두 번 전기가 아니라는 것입니다. ECC 시절에도 하나의 전표 라인(BSEG)이 고객 번호와 G/L 계정을 동시에 갖는 구조였고, S/4HANA에서는 유니버설 저널(ACDOCA) 한 테이블 안에 고객 필드(KUNNR)와 계정 필드(RACCT)가 같은 행에 공존합니다. 즉 보조원장과 총계정원장은 같은 데이터를 다른 관점으로 자른 것이며, 재조정계정은 그 관점 전환의 축입니다. 이 설계 덕분에 두 장부가 어긋날 여지가 원천적으로 줄어듭니다.
재조정계정 마스터 설정 뜯어보기 — 계정 구조 상세
가상의 회사 한빛전자(회사코드 4100)가 국내 외상매출금용 재조정계정 1103000을 만든다고 가정하겠습니다. 트랜잭션 FS00에서 계정을 생성할 때 결정적인 필드는 Control Data 탭에 있습니다.
- Recon. Account for Account Type(테이블
SKB1-MITKZ): 여기에D(고객)를 지정하는 순간 이 계정은 재조정계정이 됩니다. 공급업체용이면K, 자산이면A를 씁니다. 이 필드가 채워진 계정은 전표 입력 화면에서 직접 지정할 수 없게 됩니다. - Line Item Display: 일반적으로 재조정계정은 라인아이템 표시를 켜지 않습니다. 상세 내역은 고객 계정에서 보는 것이 원칙이고, 계정 자체는 잔액 집계 역할만 하기 때문입니다(S/4HANA에서는 ACDOCA 덕분에 기술적으로는 항상 라인 조회가 가능하지만 설계 의도는 동일합니다).
- Sort Key:
031(고객 번호)을 지정하면 할당(Assignment) 필드에 고객 번호가 채워져 분석이 편해집니다. - Field Status Group: 재조정계정용 그룹(예: G067 계열)을 지정해 전기 화면 필드 제어를 일관되게 유지합니다.
고객 쪽에서는 BP 트랜잭션(BP, 역할 FI 고객)의 회사코드 데이터에서 이 계정을 연결합니다. 실무에서는 국내 채권/해외 채권/관계사 채권처럼 재무제표 표시 구분이 필요한 단위로 재조정계정을 나누는 것이 일반적입니다. 예를 들어 한빛전자는 1103000(국내), 1103100(수출), 1103200(관계사)로 분리해 각 고객 그룹에 배정할 수 있습니다.
고객 송장 한 건이 흘러가는 경로 — 전기 프로세스
미래유통(고객 번호 30021)에 부가세 포함 1,100,000원짜리 송장을 FB70으로 전기하는 순간을 따라가 보겠습니다.
- 사용자는 고객 30021, 매출 계정
4101000, 세금 코드만 입력합니다. - 시스템이
KNB1에서 30021의 재조정계정1103000을 읽어 차변 라인에 자동 배정합니다. - 생성된 전표 라인은 개념적으로 다음과 같습니다: 차변 고객 30021(G/L 1103000) 1,100,000 / 대변 매출 4101000 1,000,000 / 대변 부가세예수금 100,000.
- ACDOCA에는 첫 라인이
KUNNR=30021,RACCT=1103000,KOART=D로 기록됩니다. FBL5N에서 고객으로 조회해도, FAGLB03에서 계정 1103000으로 조회해도 같은 행이 잡힙니다. - 이후 입금(F-28)으로 반제하면 같은 재조정계정에 대변 라인이 생기며 잔액이 줄어듭니다.
선수금 같은 특수 거래는 한 단계가 더 있습니다. 특별 G/L 지시자(Special G/L Indicator)를 쓰면 기본 재조정계정 대신 대체 계정(예: 선수금 계정 2105000)으로 라우팅되는데, 이 매핑은 고객의 경우 트랜잭션 OBXR에서 정의합니다. 즉 "고객 앞 전기 = 재조정계정 자동 결정"이라는 원칙은 유지하되, 거래 성격에 따라 어느 재조정계정이냐만 달라지는 구조입니다.
직접 전기가 막히는 이유 — 회계적·기술적 근거
FB01에서 계정 1103000을 직접 입력하면 시스템은 "이 계정은 재조정계정으로 설정되어 직접 전기할 수 없다"는 오류를 냅니다. 단순한 제약이 아니라 구조를 지키는 안전장치입니다.
회계적 근거: 재조정계정 잔액은 정의상 "모든 소속 고객 잔액의 합"이어야 합니다. 만약 고객 지정 없이 총계정원장에만 금액을 직접 넣을 수 있다면, 그 순간부터 FBL5N의 고객 잔액 합계와 재무상태표의 외상매출금이 어긋나고, 어느 거래처의 채권인지 추적 불가능한 금액이 생깁니다. 결산 시 채권 실사·조회서 발송·연령분석(Aging)이 모두 무너지며, 감사 관점에서도 대사 불능 잔액은 중대한 결함으로 다뤄지는 것이 일반적입니다.
기술적 근거: 전기 로직은 SKB1-MITKZ가 채워진 계정이 라인에 직접 입력되면 전표 검증 단계에서 오류를 발생시키도록 설계되어 있습니다. 반대로 고객 번호가 입력된 라인은 반드시 재조정계정을 경유하도록 강제됩니다. 이 양방향 강제 덕분에 "고객 라인 = 재조정계정 라인"이라는 불변식(invariant)이 데이터 차원에서 보장되고, 별도의 야간 배치나 수동 대사 없이도 두 장부가 항상 일치합니다. 외화 채권의 기말 환산(FAGL_FCV)이나 대손 설정 같은 평가성 전기가 필요할 때는 재조정계정을 직접 건드리는 대신 인접한 조정 계정(Adjustment Account)을 별도로 두고 그쪽에 전기하는 방식이 권장됩니다.
직접 해보기 — 보조원장·총계정원장 대사 검증 자동화
구조상 항상 일치해야 하지만, 마이그레이션 직후나 재조정계정 교체 이력이 있는 시스템에서는 검증 리포트를 갖춰 두면 유용합니다. 3단계로 만들어 보겠습니다.
1단계 — 기본 검증 리포트. 재조정계정의 GL 잔액과 고객 라인 합계를 비교합니다.
REPORT zfi_ar_recon_check.
PARAMETERS: p_bukrs TYPE bukrs DEFAULT '4100',
p_hkont TYPE hkont DEFAULT '0001103000'.
START-OF-SELECTION.
" 고객 관점: 해당 재조정계정에 물린 고객 라인 합계
SELECT SUM( hsl ) FROM acdoca
WHERE rbukrs = @p_bukrs
AND racct = @p_hkont
AND koart = 'D'
AND kunnr <> ''
INTO @DATA(lv_subledger).
" GL 관점: 계정 전체 잔액
SELECT SUM( hsl ) FROM acdoca
WHERE rbukrs = @p_bukrs
AND racct = @p_hkont
INTO @DATA(lv_gl).
IF lv_subledger = lv_gl.
WRITE: / '대사 일치:', lv_gl.
ELSE.
WRITE: / '차이 발생:', lv_gl - lv_subledger.
ENDIF.
2단계 — 실무형 개선. 차이가 나면 원인 라인을 찾아 애플리케이션 로그(BAL)에 남기고, 마감 담당자에게 후속 조치를 넘기도록 확장합니다. 핵심은 고객 번호가 비어 있는 라인(마이그레이션 잔액, 프로그램 오류 흔적)을 잡아내는 것입니다.
IF lv_subledger <> lv_gl.
SELECT belnr, gjahr, hsl FROM acdoca
WHERE rbukrs = @p_bukrs
AND racct = @p_hkont
AND kunnr = '' " 고객 없는 라인 = 의심 전표
INTO TABLE @DATA(lt_orphan)
UP TO 100 ROWS.
LOOP AT lt_orphan INTO DATA(ls_o).
MESSAGE e001(zfi_recon)
WITH ls_o-belnr ls_o-gjahr INTO DATA(lv_msg).
" BAL 로그 적재 후 마감 체크리스트에 연동
ENDLOOP.
ENDIF.
3단계 — 프로덕션 수준. 상시 모니터링은 리포트보다 CDS 뷰로 노출해 Fiori 분석 앱이나 결산 대시보드에 연결하는 편이 성능과 재사용성 면에서 낫습니다. 접근 제어(@AccessControl)로 회사코드 권한 체크를 걸어 보안도 확보합니다.
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'AR 재조정계정 고객별 잔액'
define view entity ZC_HB_ARReconBalance
as select from acdoca
{
key rbukrs,
key racct,
key kunnr,
@Semantics.amount.currencyCode: 'rhcur'
sum( hsl ) as Balance,
rhcur
}
where koart = 'D'
group by rbukrs, racct, kunnr, rhcur
이 뷰를 재조정계정별로 집계해 GL 잔액과 나란히 놓으면, 마감 때마다 수작업 엑셀 대사를 하지 않아도 됩니다. 운영 반영 전에는 대량 데이터 기준 실행계획을 확인하고, 테스트 시스템에서 기간별 결과를 표준 대사 리포트와 교차 검증하는 절차를 권장합니다.
자주 만나는 함정 — 삽질 노트
Q1. 운영 중인 고객의 재조정계정을 바꾸면 기존 잔액은 어떻게 되나요? KNB1-AKONT를 변경해도 기존 미결항목은 옛 계정에 그대로 남고, 변경 이후 전기분만 새 계정으로 갑니다. 그 결과 한 고객의 채권이 두 계정에 걸쳐 표시되므로, 변경 전 미결항목을 반제하거나 재무제표 버전에서 두 계정을 함께 표시하는 등의 정리 계획이 필요합니다.
Q2. FBL5N 합계와 GL 잔액이 다르게 보입니다. 먼저 특별 G/L 거래(선수금 등)가 별도 재조정계정으로 빠져 있는지 확인하세요. FBL5N에서 특별 G/L 항목 포함 여부와, 조회 기준일(미결항목 키일자 vs 전기일)이 GL 잔액 조회 조건과 같은지 맞추면 대부분 해소됩니다.
Q3. 기말 외화 평가 금액을 재조정계정에 넣으려는데 전기가 안 됩니다. 정상 동작입니다. 평가 차이는 재조정계정이 아니라 평가용 조정 계정(직접 전기가 허용된 일반 계정)에 전기하도록 계정 결정을 구성하는 것이 표준적인 접근입니다.
Q4. 마이그레이션 때 초기 채권 잔액은 어떻게 올리나요? GL에 직접 업로드하는 것이 아니라 고객별 미결항목으로 이관 전표를 전기해 재조정계정 잔액이 자동으로 만들어지게 해야 합니다. 이관용 임시 상대계정을 쓰고, 완료 후 앞서 만든 검증 리포트로 대사를 확인하는 순서를 권장합니다.
핵심 한 줄
재조정계정은 고객 보조원장과 총계정원장을 실시간으로 묶는 축이며, 고객 라인은 반드시 이 계정을 경유하고 이 계정에는 직접 전기가 차단됩니다. 이 두 가지 강제 덕분에 "고객 잔액 합계 = 재무제표 채권 금액"이라는 등식이 항상 성립합니다.
더 파볼 주제
- 공급업체(계정 유형 K) 채무 구조와 재조정계정 차이
- 특별 G/L 지시자별 대체 재조정계정 설계
- 외화 채권 기말 평가와 조정 계정 구성
- ACDOCA 기반 결산 대사 자동화
댓글 0
아직 댓글이 없습니다.