FB03 전표 흐름 확인은 전표 간 연결 구조를 이해하는 핵심 기능으로, Reference, Clearing, Reversal 필드를 기반으로 원전표와 후속 전표를 추적하는 분석 방법입니다. S/4HANA에서는 ACDOCA까지 함께 확인해야 정확한 흐름 파악이 가능합니다.
FB03 전표 흐름 확인은 ‘이 전표가 어디서 시작되어 어디까지 이어졌는지’가 막히는 순간 가장 먼저 찾게 되는 기능입니다. 실제 운영에서 가장 답답한 순간이 이런 때예요. MM에서 들어온 것 같은데 FI 전표만 보이고, AR/AP 상계는 끝났다고 하는데 잔액은 남아 있고, SD Billing에서 넘어온 매출 전표가 맞는지 사용자가 물어보는데 연결이 한눈에 안 보일 때가 있죠. 이런 분께 특히 도움이 됩니다. FI 운영 담당자라면 사용자 문의 대응 속도를 높일 수 있고, 주니어 컨설턴트라면 전표 구조를 이해하는 눈이 생기며, 시니어라면 인터페이스나 정산 이슈를 훨씬 빨리 좁혀갈 수 있습니다.
이 글은 S/4HANA 기준으로 설명하되, ECC 6.0과의 차이도 함께 짚겠습니다. 다만 핵심은 조회 방법 자체보다, 원전표 역추적과 후속 전표 연결 확인이 어떤 논리로 만들어지는지 이해하는 데 있습니다.
FB03은 단순히 전표를 보는 화면이 아니라, 전표 사이의 관계를 읽어내는 출발점입니다. 현장에서는 이 기능을 잘 쓰는 사람과 못 쓰는 사람의 장애 분석 속도가 정말 크게 차이납니다.
FB03 전표 흐름 확인의 구조: Reference Document와 Clearing Document를 읽는 법
많은 분들이 FB03을 “전표 표시 T-code” 정도로만 생각하시는데, 실무에서는 그렇게 보면 절반만 보는 겁니다. FB03 전표 흐름 확인의 본질은 문서 간 관계 모델을 읽는 데 있어요. 쉽게 말하면, 전표 하나를 고립된 종이 한 장으로 보는 게 아니라, 앞뒤 문서와 연결된 파일철로 보는 겁니다. 보통 흐름은 다음처럼 이어집니다.
-
-
원전표 생성
-
FI 전표 생성
-
후속 전표 발생
-
-
- Clearing Document
-
- Reversal Document
-
- Settlement/배부/정산 전표
이 연결의 핵심은 필드입니다. 현장에서 정말 자주 보는 필드는 아래와 같아요.
| 구분 | 주요 테이블-필드 | 실무 해석 |
|---|---|---|
| 원전표 추적 | BKPF-AWTYP |
어떤 업무에서 왔는지 보여주는 참조 유형 |
| 원전표 추적 | BKPF-AWKEY |
실제 원전표 번호 성격의 추적 키 |
| 상계 추적 | BSEG-AUGBL |
어떤 상계전표로 클리어링됐는지 |
| 상계 일자 | BSEG-AUGDT |
상계가 실제로 일어난 날짜 |
| 역분개 추적 | BKPF-STBLG |
어떤 전표가 이 전표를 역분개했는지 |
예를 들어 AWKEY는 그냥 “참조값”이 아닙니다. 실제 프로젝트에서는 MM 문서번호, SD Billing 번호, 외부 인터페이스 키가 들어가면서 원전표 역추적의 생명줄 역할을 합니다. 반대로 이 값이 비어 있거나 엉뚱하게 들어가면, FB03에서 흐름이 끊긴 것처럼 보이는 경우가 많습니다. AUGBL도 마찬가지예요. 사용자는 “왜 잔액이 안 맞죠?”라고 묻지만, 실제로는 상계전표 번호를 따라가 보면 Partial인지 Residual인지가 바로 드러나는 경우가 많습니다.
왜 SAP가 이런 구조를 만들었느냐고요? 이유는 단순합니다. FI 혼자 돌아가지 않기 때문입니다. MM, SD, CO, AA, TR과 연결되면서 자동전표가 계속 생기는데, 나중에 감사 대응이나 내부통제에서 “이 숫자가 어디서 왔는가”를 설명할 수 있어야 하거든요. 그게 바로 Audit Trail입니다.

ECC와 S/4HANA의 Universal Journal 차이
| 항목 | ECC 6.0 | S/4HANA |
|---|---|---|
| 전표 구조 중심 | BKPF + BSEG |
BKPF + ACDOCA(Universal Journal) |
| 라인아이템 조회 | BSEG 중심 | ACDOCA 중심 |
| 흐름 논리 | Reference / Clearing / Reversal | 동일 |
| 분석 방식 | 전통 테이블 중심 | 통합 라인아이템 병행 분석 |
S/4HANA 변경사항으로는 라인아이템이 Universal Journal(ACDOCA)로 통합되었지만, FB03 전표 흐름 확인의 논리 자체는 바뀌지 않았습니다. 즉, 전표 간 관계는 그대로이고 조회 포인트만 더 넓어진 것입니다. 그래도 S/4HANA로 오면서 테이블은 바뀌었지만 사고방식은 그대로입니다. 이걸 이해하면 ECC 경험이 있는 분도 S/4HANA에서 훨씬 빠르게 적응할 수 있습니다.
FB03 전표 흐름 확인이 만들어지는 IMG 설정: OBYC, VKOA, 자동상계 점검
여기서 중요한 말씀 하나 드릴게요. FB03 자체는 조회 트랜잭션입니다. 하지만 조회가 잘 되느냐는 결국 앞단의 설정과 데이터 품질에 달려 있습니다. 실제 현장에서는 “FB03이 이상하다”기보다, 전표 흐름이 제대로 생성되도록 하는 설정이 빠진 경우가 훨씬 많아요.
| 구분 | T-code / App | 용도 |
|---|---|---|
| 전표 표시 | FB03 |
FI 전표 및 후속 전표 확인 |
| 수동 상계 | F-03 |
Open item 수동 clearing |
| 자동 상계 | F.13 |
자동상계 실행 |
| 계정별 라인 조회 | FBL3N |
G/L line item 분석 |
| AP 조회 | FBL1N |
Vendor line item 분석 |
| AR 조회 | FBL5N |
Customer line item 분석 |
| 테이블 조회 | SE16N |
BKPF/BSEG/ACDOCA 확인 |
| Fiori | Manage Journal Entries 등 | S/4HANA 전표 분석 보조 |

1) Document Type 설정
SPRO > Financial Accounting > Financial Accounting Global Settings > Document > Document Types > Define Document Types
문서유형은 단순 분류가 아닙니다. 번호범위, 문서 카테고리, 역분개 허용 방식에 영향을 줍니다. 실제 프로젝트에서 문서유형 설계가 정교하지 않으면, 후속 전표 연결 확인은 되더라도 운영자가 어떤 전표가 어떤 성격인지 구분하기 어려워집니다.
2) Open Item Clearing 설정
SPRO > Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Open Item Clearing
여기서는 자동상계와 수동상계의 기반이 만들어집니다. F.13 자동상계가 기대대로 안 되면 AUGBL이 생성되지 않거나 사용자가 생각하는 방식으로 연결되지 않을 수 있어요. 특히 지급런, 자동지급, DME 파일과 이어지는 AP 운영에서는 이 부분이 잔액 이슈의 출발점이 되는 경우가 많습니다.
3) Reference 필드와 Field Status
SPRO > Financial Accounting > Financial Accounting Global Settings > Document > Line Item > Define Field Status Variants
Reference, Assignment 같은 필드를 가볍게 보면 안 됩니다. 인터페이스에서 값을 보내더라도 화면/필드 상태가 막혀 있거나 관리가 엉성하면 나중에 원전표 역추적이 거의 불가능해집니다. 현장에서 자주 마주치는 상황이에요. 전표는 쌓이는데, 나중에 “이게 어디서 온 거죠?”를 아무도 설명 못 하는 경우 말이죠.
4) 모듈 연계 설정: OBYC, VKOA
| 연계 구분 | 설정 | 영향 |
|---|---|---|
| MM → FI | OBYC |
GR/IR, 재고, 소비 등 자동전표 생성 |
| SD → FI | VKOA |
Billing 기반 매출/채권 전표 생성 |
| AP 자동지급 | 자동지급 설정 + DME | 지급런 이후 clearing 흐름 형성 |
MM에서 온 전표는 OBYC, SD Billing에서 온 전표는 VKOA가 흔히 핵심입니다. 사용자는 FB03에서 결과만 보지만, 컨설턴트는 “왜 이 전표가 그렇게 만들어졌는지”를 앞단 설정에서 봐야 합니다.
전표 흐름이 끊기는 대표 원인
- Reference 미입력 또는 인터페이스 미전달
- Clearing 미실행 또는 자동상계 조건 불일치
- 문서유형/필드 상태 설정 부적합
- MM/SD 연계 설정 오류
- S/4HANA 전환 후 ACDOCA 분석 미흡
부가 설명: 조회 화면에서 문제를 찾기보다, 흐름이 만들어지는 조건을 먼저 보는 습관이 중요합니다. 그게 운영 이슈를 반복하지 않게 만드는 가장 현실적인 방법입니다.
FB03 전표 흐름 확인 실무 추적 방법: SE16N과 ACDOCA까지 보는 루틴
이제 가장 실무적인 부분으로 가보겠습니다. 제가 운영 지원할 때 후배들에게 늘 이야기하는 분석 루틴이 있어요. “FB03에서 안 보이면 끝”이 아니라, FB03 → FBL*N → SE16N → ACDOCA 순서로 좁혀가라는 겁니다.
기본 확인 루트
-
FB03에서 대상 전표 조회 -
메뉴 Environment > Document Environment > Follow-on Documents 확인
-
연결이 불명확하면
FBL3N,FBL1N,FBL5N으로 계정 기준 조회 -
SE16N에서BKPF,BSEG,ACDOCA직접 확인 -
AWKEY,AUGBL,STBLG로 원인 확정
| 단계 | 확인 대상 | 핵심 필드/포인트 | 해석 |
|---|---|---|---|
| 1 | FB03 | Follow-on Documents | 후속 전표 존재 여부 |
| 2 | BKPF | AWTYP, AWKEY |
원전표 역추적 |
| 3 | BSEG | AUGBL, AUGDT |
상계 여부 및 상계전표 |
| 4 | BKPF | STBLG |
역분개 연결 확인 |
| 5 | ACDOCA | 통합 라인아이템 | S/4HANA 상세 검증 |

예전에 운영중에 전기처리된 내용이 어디서 왔는지 찾아야 하는 케이스가 있었는데요. 외부 인터페이스 전표는 정상 생성됐는데 AWKEY가 비어 있어서 사용자는 “후속 전표가 없다”고 느꼈습니다. 그런데 FBL3N으로 계정 흐름을 따라가고 ACDOCA까지 보니 숫자는 다 맞았어요. 문제는 연결 정보가 빠진 것이었습니다. 즉, 논리적 흐름은 있는데 물리적 추적 키가 빈 상태였던 거죠.
또 하나 놓치기 쉬운 건 CO나 AA 전표입니다. 이쪽은 항상 FI 사용자가 기대하는 방식으로 “딱 떨어지는 연결”이 보이지 않을 수 있어요. 그래서 논리적 연결과 물리적 연결을 구분해야 합니다. BKPF에 직접 키가 없어도, 정산 규칙이나 원장 라인 흐름으로 이어지는 경우가 있습니다.
전표 추적은 화면 클릭 기술이 아니라, 어떤 필드를 근거로 어느 단계까지 내려가 볼지 아는 분석 루틴입니다. 이 루틴이 잡히면 장애 대응 속도가 확실히 빨라집니다.
FB03 전표 흐름 확인 트러블슈팅: F5 263, Clearing mismatch 원인별 해결
전표 흐름이 안 보일 때는 감으로 보면 안 됩니다. 원인을 유형별로 나눠야 빨라요.
| 증상/에러 | 발생 원인 | 확인 포인트 | 해결 방법 |
|---|---|---|---|
| Follow-on 문서가 안 보임 | Reference 없음 | BKPF-AWTYP, BKPF-AWKEY |
인터페이스 매핑 점검, 원전표 키 재검토 |
| 상계가 안 보임 | Clearing 미실행 | BSEG-AUGBL, AUGDT |
F-03 수동상계 또는 F.13 자동상계 재실행 |
| 잔액이 남음 | Partial/Residual 혼동 | FBL1N/FBL5N open item 상태 |
상계 방식 재확인 후 재처리 |
| 역분개 연결 안 보임 | Reversal 문서 미확인 | BKPF-STBLG |
원전표/역전표 양방향 조회 |
F5 263 |
존재하지 않는 문서 참조 | 회사코드, 문서번호, 연도 | BKPF 직접 조회 후 인터페이스 재처리 |

F5 263은 현장에서 꽤 자주 만납니다. 사용자는 “문서가 없다”고 하지만, 실제로는 회사코드가 다르거나 회계연도가 다르거나, 참조한 문서번호 자체가 잘못된 경우가 많아요. 이럴 때는 무조건 BKPF를 먼저 봐야 합니다. 존재하지 않는 건지, 잘못 참조한 건지 구분해야 하니까요.
그리고 clearing mismatch는 정말 많이 헷갈립니다. Partial clearing는 일부만 상계하고 나머지를 남기는 개념이고, Residual clearing는 기존 오픈아이템을 정리하고 새 잔액 항목을 만드는 개념입니다. 사용자는 둘 다 “상계했다”고 말하지만, FI 입장에서는 결과가 완전히 달라요. 잔액이 남는 구조를 이해하지 못하면 계속 같은 문의가 반복됩니다.
우리가 FB03에서 조회를 하고 해당 전표가 어떻게 흘러서 왔는지 전표 흐름이 안 보이는 문제의 상당수는 시스템 버그보다 데이터 연결 키, 상계 처리 방식, 인터페이스 매핑에서 발생합니다. 그래서 원인별로 보는 습관이 중요합니다.
FB03 전표 흐름 확인 실무 팁: 원전표 역추적을 빠르게 끝내는 체크포인트
- FB03만 믿지 마세요. 화면에서 안 보이면
SE16N과ACDOCA까지 바로 내려가야 합니다.
- AWKEY는 설계 품질입니다. 인터페이스, 배치, 사용자 업로드 프로그램에서 이 값을 어떻게 채우는지 꼭 검증하세요.
- AUGBL이 있으면 상계는 일어났다는 뜻이지만, 방식이 Partial인지 Residual인지는 별도 확인해야 합니다.
- OBYC, VKOA는 흐름의 출발점입니다. MM/SD 쪽 설정 문제를 FI 화면에서만 찾으려 하면 시간이 오래 걸립니다.
- Document Splitting 사용 시 S/4HANA에서는 라인 해석이 더 중요해집니다.
- SAP 버전에 따라 동작이 다를 수 있으니 SAP Help Portal 확인을 권장합니다.
빠른 사람은 T-code를 많이 아는 사람이 아니라, 어떤 문제를 어떤 필드로 확인할지 바로 떠올리는 사람입니다. 그 차이가 결국 실무 숙련도입니다.
FB03 전표 흐름 확인 마무리: 후속 전표 연결 확인은 분석 능력입니다
핵심만 3줄로 정리해보겠습니다.
- FB03 전표 흐름 확인은 단순 조회가 아니라
Reference + Clearing + Reversal구조를 읽는 일입니다.
- 원전표 역추적의 핵심은
BKPF-AWTYP,BKPF-AWKEY이고, 후속 전표 연결 확인의 핵심은AUGBL,STBLG입니다.
- S/4HANA에서는
ACDOCA(Universal Journal)까지 함께 봐야 분석 속도와 정확도가 올라갑니다.
솔직히 말씀드리면, 전표 흐름은 기능이 아니라 분석 능력입니다. 당시에도 “FB03에서 안 보이면 시스템 문제다”라는 말이 있었지만 실제로는 설정, 상계 방식, 인터페이스 키 누락이 더 많았습니다. 여러분도 비슷한 이슈를 겪으셨다면 댓글로 사례를 나눠주세요. 현장에서 자주 막히는 패턴은 서로 공유할수록 훨씬 빨리 해결됩니다. 다음에 읽으면 좋은 글로는 FBL3N 기반 전표 추적 방법, 그리고 Partial vs Residual Clearing 구조 정리를 추천드립니다.
참고 출처
- SAP Help Portal – Document Display / Document Environment
- SAP Help Portal – Accounting Document Structure
- SAP Help Portal – SAP S/4HANA Universal Journal (
ACDOCA)
- SAP Help Portal – Financial Accounting Configuration Guide