EBS를 오래 다룬 사람이 SAP FI 테이블을 처음 열면 대체로 두 번 놀랍니다.
첫 번째는 “이렇게 단순하다고?” 입니다. XLA만 해도 테이블이 열 개 넘게 얽혀 있었는데, SAP FI 전표는 사실상 두 개입니다.
두 번째는 “왜 조인이 이렇게 지저분하지?” 입니다. 전표 하나를 특정하는 데 컬럼이 세 개, 라인까지 가면 네 개가 필요합니다.
이 글은 그 두 번의 놀람을 순서대로 풀어 나갑니다.
목차
1. SAP 전표 테이블은 두 개다
EBS SAP
────────────────────── ─────────────────
GL_JE_BATCHES (배치) (없음)
GL_JE_HEADERS (헤더) → BKPF (전표 헤더)
GL_JE_LINES (라인) → BSEG (전표 항목)EBS의 배치(Batch) 계층이 SAP에는 없습니다. EBS는 Journal Import가 여러 전표를 배치로 묶어 넘기고 배치 단위로 전기했지만, SAP은 전기가 실시간이라 묶을 이유가 없습니다.
5편에서 말한 “EBS 3계층 / SAP 1계층”이 여기서 눈에 보이는 형태로 나타납니다.
2. 복합키 첫 번째 함정
EBS는 전표를 JE_HEADER_ID 하나로 특정합니다. 서로게이트 키 하나면 끝입니다.
SAP은 다릅니다.
BKPF 키: BUKRS (회사코드) + BELNR (전표번호) + GJAHR (회계연도)
BSEG 키: BUKRS + BELNR + GJAHR + BUZEI (항목번호)전표번호는 회사코드별·연도별로 다시 시작합니다. 그래서 BELNR = '1900000123' 만으로는 전표가 특정되지 않습니다. 회사코드 1000의 2026년 전표와 회사코드 2000의 2025년 전표가 같은 번호를 가질 수 있습니다.
실무에서 이게 왜 중요한가
sql
-- 잘못된 조인 — 데이터가 뻥튀기됩니다
SELECT * FROM bkpf b
JOIN bseg s ON s.belnr = b.belnr;
-- 올바른 조인
SELECT * FROM bkpf b
JOIN bseg s
ON s.bukrs = b.bukrs
AND s.belnr = b.belnr
AND s.gjahr = b.gjahr;GJAHR를 빠뜨리는 실수가 압도적으로 많습니다. 개발 환경에서는 데이터가 1~2년치뿐이라 안 걸리고, 운영에서 터집니다. 조인 조건 세 개를 세트로 외우세요.
참고: 실제 SAP 테이블에는
MANDT(클라이언트) 컬럼이 맨 앞에 하나 더 있습니다. ABAP Open SQL에서는 자동으로 붙지만, 외부에서 직접 접근할 때는 명시해야 합니다.
3. BKPF 테이블 필드 EBS와 나란히 보기
| BKPF | 의미 | EBS 대응 |
|---|---|---|
BUKRS | 회사코드 | (Ledger + OU 조합) |
BELNR | 전표번호 | JE_HEADER_ID (개념적) |
GJAHR | 회계연도 | PERIOD_YEAR |
MONAT | 전기 기간 | PERIOD_NUM |
BLART | 전표유형 | JE_CATEGORY (유사) |
BLDAT | 증빙일자 | 송장일자 |
BUDAT | 전기일자 | GL_DATE / ACCOUNTING_DATE |
CPUDT | 입력일자 | CREATION_DATE |
USNAM | 입력자 | CREATED_BY |
XBLNR | 참조 (16자) | REFERENCE_1~10 |
BKTXT | 전표헤더텍스트 (25자) | DESCRIPTION |
WAERS | 전표통화 | CURRENCY_CODE |
KURSF | 환율 | CURRENCY_CONVERSION_RATE |
STBLG | 역분개 전표번호 | REVERSED_JE_HEADER_ID |
TCODE | 생성 트랜잭션 | JE_SOURCE (유사) |
AWTYP / AWKEY | 원천 참조 | GL_IMPORT_REFERENCES |
날짜가 세 개인 이유
EBS는 사실상 GL_DATE 하나로 살았습니다. SAP은 셋을 구분합니다.
BLDAT— 증빙에 찍힌 날짜 (거래처 세금계산서 발행일)BUDAT— 회계적으로 인식하는 날짜 (기간 결정)CPUDT— 시스템에 입력한 날짜 (자동 기록, 수정 불가)
인터페이스 설계에서 이 셋의 매핑을 명시하지 않으면 반드시 사고가 납니다. 5편의 “날짜 3종 혼동” 항목이 바로 이것입니다.
AWTYP / AWKEY — SAP의 드릴다운
EBS에서 GL 전표 라인으로부터 원 거래를 찾으려면 GL_IMPORT_REFERENCES → XLA_AE_LINES → XLA_DISTRIBUTION_LINKS → AP_INVOICE_DISTRIBUTIONS_ALL 이렇게 다리를 네 번 건너야 했습니다(2편 참조).
SAP은 필드 두 개로 끝냅니다.
AWTYP = 'RMRP' ← 원천 유형 (MM 송장검증)
AWKEY = '5100001234 2026' ← 원천 문서 키| AWTYP | 원천 |
|---|---|
BKPF | FI에서 직접 입력 |
RMRP | MM 송장검증 (MIRO) |
VBRK | SD 청구 |
MKPF | 자재 문서 |
이건 SAP 구조가 우월해서라기보다, 회계 변환 계층이 없기 때문입니다. EBS는 거래와 회계가 별개라 다리가 필요했고, SAP은 거래가 곧 회계라 참조 하나면 됩니다.
4. BSEG 테이블 필드 라인 항목의 세계
여기가 진짜 본론입니다.
| BSEG | 의미 | 비고 |
|---|---|---|
BUZEI | 항목번호 | 001, 002, … |
KOART | 계정유형 | S/D/K/A/M |
SHKZG | 차대 지시자 | S=차변, H=대변 |
DMBTR | 현지통화 금액 | 항상 양수 |
WRBTR | 전표통화 금액 | 항상 양수 |
DMBE2 | 제2현지통화 금액 | 그룹통화 등 |
HKONT | G/L 계정 | 총계정원장 계정 |
SAKNR | 입력한 G/L 계정 | 조정계정 전기 시 HKONT와 다름 |
LIFNR | 공급업체 | KOART=’K’일 때 |
KUNNR | 고객 | KOART=’D’일 때 |
KOSTL | 코스트센터 | |
PRCTR | 이익센터 | |
AUFNR | 오더 | |
MWSKZ | 세금코드 | |
ZUONR | 지정 (18자) | 정렬/조회 키로 활용 |
SGTXT | 항목텍스트 (50자) | |
AUGBL / AUGDT | 상계전표 / 상계일자 | 미결항목 관리 |
UMSKZ | 특별원장 지시자 | 선급금 등 |
ZFBDT / ZTERM | 기산일 / 지급조건 |
KOART — 계정유형이라는 개념
EBS에는 없던 개념입니다. 라인이 어떤 종류의 원장에 전기되는지를 나타냅니다.
| KOART | 의미 | 채워지는 필드 |
|---|---|---|
S | G/L 계정 | HKONT |
K | 공급업체 (Kreditor) | LIFNR |
D | 고객 (Debitor) | KUNNR |
A | 자산 | ANLN1 |
M | 자재 | MATNR |
4편에서 본 SAP의 “계정유형별 기간 마감(OB52)”이 바로 이 KOART 기준입니다. EBS가 모듈별로 닫았다면 SAP은 이 다섯 글자 기준으로 닫습니다.
SHKZG — 두 번째 함정
EBS 개발자가 가장 많이 틀리는 지점입니다.
EBS: ACCOUNTED_DR = 1000000, ACCOUNTED_CR = NULL ← 컬럼 두 개
SAP: DMBTR = 1000000, SHKZG = 'S' ← 금액 하나 + 지시자DMBTR은 차변이든 대변이든 항상 양수입니다. 금액의 부호로 차대를 판단하려는 코드는 100% 틀립니다.
sql
-- 차대변 합계 검증 (EBS 스타일로 변환)
SELECT SUM(CASE WHEN shkzg = 'S' THEN dmbtr ELSE 0 END) AS total_dr,
SUM(CASE WHEN shkzg = 'H' THEN dmbtr ELSE 0 END) AS total_cr
FROM bseg
WHERE bukrs = :bukrs AND belnr = :belnr AND gjahr = :gjahr;인터페이스에서 EBS 금액을 SAP으로 보낼 때도 마찬가지입니다. 음수 금액을 그대로 보내지 말고 부호를 뒤집어 SHKZG로 표현해야 합니다. 5편에서 언급한 원칙이 여기서 나온 것입니다.
통화 세 개
WRBTR(전표통화) / DMBTR(현지통화) / DMBE2(제2현지통화)를 혼동하면 외화 거래에서 금액이 전부 어긋납니다.
- 리포트에서 “우리 돈으로 얼마” →
DMBTR - 거래처와 대사 →
WRBTR+WAERS - 그룹 연결 →
DMBE2
5. 조정계정 은 EBS에 없는 구조
4편에서 “SAP은 보조부와 GL이 구조적으로 어긋날 수 없다”고 했습니다. 그 장치가 조정계정(Reconciliation Account) 입니다.
작동 방식은 이렇습니다.
공급업체 마스터 (LFB1)
AKONT = '0021010000' ← 이 업체의 조정계정
│
▼
공급업체에 전기하면 (KOART='K')
BSEG.LIFNR = '0000100234' ← 보조부 정보
BSEG.HKONT = '0021010000' ← 총계정원장 계정이 자동으로 채워짐같은 한 줄이 보조부이면서 동시에 총계정원장 항목입니다. 따로 넘기는 과정이 없으니 어긋날 수가 없습니다.
EBS와 대조해 보면 차이가 선명합니다.
| EBS | SAP | |
|---|---|---|
| 보조부 잔액 | AP_LIABILITY_BALANCE | BSEG (KOART=’K’) |
| 총계정 잔액 | GL_BALANCES | 같은 BSEG 행의 HKONT |
| 연결 방식 | 배치 전송 | 동일 레코드 |
| 대사 작업 | 필수 | 구조적으로 불필요 |
그리고 중요한 제약이 있습니다. 조정계정에는 직접 전기할 수 없습니다. 반드시 공급업체/고객을 통해야 합니다.
전환 프로젝트에서 이 제약이 자주 문제가 됩니다. EBS에서는 미지급금 계정에 수동 분개를 넣던 관행이 있는데, SAP에서는 그 전표가 거부됩니다. 프로세스 자체를 바꿔야 합니다.
6. 특별원장 — 선급금은 여기 있다
3편에서 EBS 선급금을 다뤘습니다. 선급 송장 → 지급 → 적용의 3단계였죠. SAP은 완전히 다른 메커니즘을 씁니다.
BSEG.UMSKZ = 'A' ← 특별원장 지시자 (선급금)UMSKZ가 채워진 행이 특별원장 항목입니다. 그리고 이때 HKONT에는 공급업체 마스터의 조정계정이 아니라 대체조정계정(Alternative Reconciliation Account) 이 들어갑니다.
일반 매입 전기: UMSKZ = '' → HKONT = 0021010000 (매입채무)
선급금 전기: UMSKZ = 'A' → HKONT = 0013010000 (선급금)대체계정 매핑은 T074 테이블에 설정되어 있습니다.
| UMSKZ | 일반적 용도 |
|---|---|
A | 선급금 (Down Payment) |
F | 선급금 요청 (통계전기) |
실제 사용 지시자와 계정 매핑은 프로젝트마다 다릅니다.
T074를 조회해 해당 시스템의 설정을 확인하세요.
EBS 선급금과 비교
| EBS | SAP | |
|---|---|---|
| 표현 방식 | 송장 유형 PREPAYMENT | 특별원장 지시자 UMSKZ |
| 계정 분리 | 배분의 계정으로 구분 | 대체조정계정으로 자동 분리 |
| 적용 | Apply Prepayment (배분 추가) | 상계(Clearing) 또는 대체전기 |
| 재무제표 표시 | 계정 설정에 의존 | 구조적으로 분리 |
전환 시 핵심 결정: 선급금 성격이 여러 개(계약금/보증금/전도금)라면 지시자를 몇 개 만들고 각각 어떤 대체계정을 붙일지 초기에 확정해야 합니다. 운영 중에 추가하는 것은 가능하지만, 이미 전기된 과거 데이터는 소급 적용되지 않습니다.
7. 미결항목 관리 — AUGBL의 세계
EBS는 송장의 지급 여부를 payment_status_flag와 AP_INVOICE_PAYMENTS_ALL로 관리했습니다.
SAP은 상계(Clearing) 라는 단일 개념으로 처리합니다.
미결 상태: BSEG.AUGBL = '' (아직 상계 안 됨)
상계 완료: BSEG.AUGBL = '2000001234' ← 상계전표번호
BSEG.AUGDT = '2026-08-01'그리고 미결/상계 항목을 빠르게 조회하기 위한 인덱스 테이블들이 있습니다.
| 테이블 | 내용 |
|---|---|
BSIK | 공급업체 미결 항목 |
BSAK | 공급업체 상계완료 항목 |
BSID / BSAD | 고객 미결 / 상계완료 |
BSIS / BSAS | G/L 미결 / 상계완료 |
상계가 일어나면 항목이 BSIK에서 BSAK로 이동합니다.
S/4HANA에서는 이 구조가 바뀌었습니다. 이들은 물리 테이블이 아니라 호환성을 위한 뷰이고, 실제 데이터는 뒤에서 설명할
ACDOCA에 있습니다. 신규 개발이라면 표준 CDS 뷰를 쓰는 편이 낫습니다.
8. S/4HANA와 ACDOCA 를 알고 시작해야 할 변화
S/4HANA는 Universal Journal(ACDOCA) 이라는 단일 라인 항목 테이블을 도입했습니다. 기존에 흩어져 있던 것들이 한곳에 모였습니다.
ECC: BSEG (FI) + FAGLFLEXA (신총계정) + COEP (CO) + ANEP (FA) + ...
↓
S/4: ACDOCA실무적으로 알아야 할 점입니다.
BKPF/BSEG는 여전히 존재합니다. 사라지지 않았습니다.- 다만 진실의 원천(single source of truth)은
ACDOCA입니다. - FI와 CO가 한 테이블에 있으므로 FI-CO 대사 작업이 사라집니다.
GL_BALANCES같은 집계 테이블 개념이 약해집니다. 실시간 집계가 기본입니다.BSEG는 ECC에서 클러스터 테이블이었지만 S/4에서는 투명 테이블입니다. 기존의 “BSEG는 느리다”는 통념이 더 이상 그대로 적용되지 않습니다.
리포트나 인터페이스를 새로 만든다면 ACDOCA 또는 표준 CDS 뷰를 기준으로 삼으세요. BSEG를 직접 읽는 코드는 호환은 되지만 권장 경로가 아닙니다.
9. EBS 출신이 자주 하는 실수 체크리스트
| 실수 | 결과 | 교정 |
|---|---|---|
GJAHR 없이 조인 | 데이터 중복 | 3키 세트로 조인 |
| 금액 부호로 차대 판단 | 전부 차변으로 인식 | SHKZG 확인 |
HKONT만 보고 공급업체 판단 | 조정계정만 보임 | KOART + LIFNR 확인 |
WRBTR과 DMBTR 혼용 | 외화 건 금액 오류 | 용도별 구분 |
| 전표번호 유일성 가정 | 다른 회사코드 건 섞임 | BUKRS 필수 |
| 조정계정에 직접 전기 시도 | 전표 거부 | 공급업체 경유 |
UMSKZ 무시 | 선급금이 미지급금으로 집계 | 특별원장 항목 분리 |
BSIK만 조회 | 상계된 과거 건 누락 | BSAK도 함께 |
10. 한 장 요약
| 개념 | Oracle EBS | SAP FI |
|---|---|---|
| 전표 헤더 | GL_JE_HEADERS | BKPF |
| 전표 라인 | GL_JE_LINES | BSEG |
| 배치 | GL_JE_BATCHES | 없음 |
| 전표 키 | JE_HEADER_ID | BUKRS+BELNR+GJAHR |
| 차대 표현 | ACCOUNTED_DR / _CR | DMBTR + SHKZG |
| 회계 계층 | 거래 → XLA → GL | 전기 즉시 확정 |
| 원천 추적 | GL_IMPORT_REFERENCES 외 3단계 | AWTYP + AWKEY |
| 보조부 연결 | 배치 전송 후 대사 | 조정계정 (동일 레코드) |
| 선급금 | 송장 유형 PREPAYMENT | 특별원장 UMSKZ |
| 미결 관리 | payment_status_flag | AUGBL (상계전표) |
| 기간 마감 | 모듈별 | 계정유형(KOART)별 |
| 통합 원장 | GL_BALANCES | ACDOCA (S/4) |
마치며
SAP FI 전표 구조를 처음 볼 때 낯선 것들 — 복합키, SHKZG, 조정계정, 특별원장 — 은 사실 전부 하나의 설계 철학에서 나옵니다.
회계 정보는 전기하는 순간 확정되고, 그 이후로 흩어지지 않는다.
EBS가 유연성을 위해 거래와 회계를 분리하고 규칙 엔진(XLA)을 둔 반면, SAP은 일관성을 위해 그 둘을 붙여 놓았습니다. 어느 쪽이 낫다기보다, 트레이드오프가 다른 것입니다.
그리고 전환 프로젝트에서 우리가 하는 일은 결국 “유연한 쪽에서 일관된 쪽으로 데이터를 옮기는 것”입니다. 그 방향에서는 정보가 줄어드는 게 아니라 합쳐집니다. 합쳐질 때 무엇이 잃어버려지는지를 아는 것이 설계자의 몫입니다.