SAP 법인카드 청구현황 조회 — 청구서 한 장에서 카드별 출금까지
카드사가 보내 준 월 청구내역을 카드별로 묶어 출금 규모를 먼저 잡고, 명세에서 금액 구성을 확인하는 화면입니다.
소개 영상블로그 목차 순서대로 · 자막 포함
주요 재생 지점
도입 포인트 — 이 앱을 사용해야 하는 이유
법인카드 청구 명세는 국내외 사용분에 따른 복잡한 금액 구성으로 수작업 검증 시 오류 위험이 높고, 집계와 명세 간 데이터 불일치를 파악하기 어렵습니다. 이 앱은 청구금액 구성의 정합성을 자동으로 판정하고, 다단계 대사 및 의심 거래 식별 기능을 통해 법인카드 정산 업무의 정확성과 효율성을 극대화합니다.
핵심 포인트 여섯 가지
| 핵심 포인트 | 고객이 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 청구금액 구성 정합성 판정 | 앱은 '총 청구금액 = 결제원금 + 봉사료 + 환가료 - 청구할인' 산식과 국내/해외 건별 부가세, 환가료 산정 기준을 기반으로 금액 구성의 정합성을 점검합니다. 7종의 규칙(C01, C02, C05 등)을 통해 금액 불일치 가능성을 식별합니다. | 청구서 금액 구성이 복잡하여 수작업으로 각 항목의 산식 일치 여부를 검증하기 어렵고 오류 발생 가능성이 있습니다. |
| ② 다단계 집계-명세 간 일치 대사 | 카드별 집계 합계와 청구 명세 총합계(R01), 총 청구금액과 구성 항목 합계(R02), 명세의 청구일/결제일과 헤더 정보(R03) 등 3종의 대사식을 통해 데이터 계층 간 정합성을 검증합니다. | 집계와 명세 데이터 간의 불일치를 찾아내기 위해 수작업으로 여러 데이터를 교차 확인하여 시간 소모가 큽니다. |
| ③ 가맹점 사업자번호 유효성 검증 | 국내 가맹점의 사업자번호가 10자리 숫자인지 확인하고, 가중치(1·3·7·1·3·7·1·3·5)를 이용한 검증번호 일치 여부를 판정(C03)하여 가맹점 정보의 신뢰성을 확인합니다. | 가맹점 사업자번호의 형식 오류나 유효성 검사를 수작업으로 처리하여 오류가 발생하거나 확인에 시간이 걸립니다. |
| ④ 의심 거래 자동 분류 및 식별 | 주말/공휴일 사용(특정 업종 제외, C06) 및 동일 카드·가맹점·사용일 분할 결제 의심(합계 50만 원 이상, C07) 등 2가지 규칙을 적용하여 확인이 필요한 거래를 자동으로 식별합니다. | 잠재적 문제 거래나 특이 사항을 수동으로 찾아야 하므로 시간이 많이 소요되고 중요한 거래를 놓칠 수 있습니다. |
| ⑤ 카드사 원본 데이터 정합성 유지 | 카드사 전송 레이아웃의 매출관리번호(DEMA_COLL)를 건별 고유 키로 유지하여, 앱 내 데이터와 카드사 원본 데이터(28개 항목)를 언제든 대조하고 검증할 수 있도록 지원합니다. | 카드사 원본과 시스템 데이터 간의 불일치 발생 시 원인을 추적하는 데 어려움이 있어 문제 해결이 지연될 수 있습니다. |
| ⑥ SAP 표준 정산 기능 확장 | SAP 표준의 적재, 전표 입력, 계정 라인 조회 기능을 보완하여 청구월·카드 단위 집계, 가맹점 정보 기반 매입세액 공제 판단 지원, 정산 중심 재구성 등 법인카드 정산 업무에 필요한 기능을 제공합니다. | SAP 표준 기능만으로는 법인카드 정산에 필요한 심층적인 집계, 가맹점 정보 확인, 정산 중심의 데이터 분석이 어렵습니다. |
사례로 보는 효과
이 앱은 5매의 카드에서 발생한 96건의 청구 명세를 통합 관리하며, 28개 항목을 상세하게 분석하여 정산 업무의 효율성을 높입니다. 7종의 점검 규칙 및 3종의 대사식 로직이 독립 재계산 검증 결과와 전체 일치하여 높은 신뢰도를 확인했습니다.
도입하면 달라지는 것
- 수작업 검증 및 대사 업무 감소
- 법인카드 정산 데이터의 신뢰성 향상
- 잠재적 의심 거래 조기 식별 및 대응
- SAP 표준 환경 내 업무 효율성 극대화
이런 회사에 맞습니다
법인카드 사용량이 많아 수동 정산에 어려움을 겪는 기업, 재무·회계 부서에서 법인카드 청구 내역의 정확성과 투명성을 높이고자 하는 팀, SAP 환경에서 법인카드 정산 업무 효율화를 원하는 회사에 적합합니다.
업무 점검 — 앱이 직접 다시 계산하는 규칙
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
실행 화면
실제 화면 5종 둘러보기
청구월만 넣고 조회하면 카드별 집계와 전체 명세가 함께 나옵니다 → 사용 구분으로 해외 건만 걸러 보고 → 카드 행을 선택해 그 카드의 명세로 좁혀 들어갑니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
사용 방법
- 청구 연월을 YYYYMM 형식(예: 202608)으로 넣습니다. 기본값은 시스템 일자의 전월이며, 6자리가 아니면 조회를 중단하고 안내합니다.
- 카드를 지정하지 않고 조회하면 그 달에 청구된 전체 카드가 집계로 나옵니다. 여기서 출금 규모를 먼저 잡습니다.
- 사용 구분을 해외로 바꾸면 환가료가 붙은 건만 남습니다. 국내 건과 정산 성격이 달라 따로 보는 편이 빠릅니다.
- 카드별 집계에서 카드 행을 선택하면 조회조건의 Card No 가 채워지고 명세가 그 카드로 좁혀집니다.
- 조회조건 입력필드에서 Enter 를 눌러도 바로 조회됩니다. 청구월을 바꿔 가며 훑을 때 손이 마우스로 가지 않습니다.
- 결과는 집계 CSV 와 명세 CSV 두 가지로 내려받습니다. UTF-8 BOM 이 붙어 엑셀에서 한글이 깨지지 않습니다.
청구금액 구성 판정
판정의 뼈대는 식 하나입니다. 카드사가 청구한 금액은 결제원금에 부대비용을 더하고 할인을 뺀 값입니다.
총 청구금액 = 결제원금 + 봉사료 + 환가료 − 청구할인
TOTAL SETT_PRIN CHARGE INTEREST SALE_AMT
국내 (FORE_USE = N) 결제원금 = 공급가액 + 부가세 환가료 없음
해외 (FORE_USE = Y) 결제원금 = 현지 액면금액 × 환율 부가세 없음, 환가료 발생
승인금액 CACL_AMT = 해외는 현지 액면금액, 국내는 결제원금| 구분 | 통화 | 부가세 | 환가료 | 결제원금 산출 |
|---|---|---|---|---|
국내 FORE_USE = N | KRW | 공급가액의 10% | 없음 | 공급가액 + 부가세 |
해외 FORE_USE = Y | USD · JPY · EUR | 없음 | 원금의 일정률 | 현지 액면금액 × 환율 (10원 단위) |
금액이 맞지 않으면 무엇을 의심하나
총 청구금액이 식과 어긋나면 카드사 전송 파일에서 부대비용 항목이 누락됐거나, 할부·분할 청구 건이 섞여 원금이 나뉘어 들어온 경우입니다. 해외 건이라면 환율 적용 시점(승인일·매입일·청구일)이 달라 현지 액면금액 × 환율과 결제원금이 벌어지기도 합니다. 명세에서 해당 매출관리번호를 찾아 전송내역키로 원본을 대조합니다.
카드 청구 처리 5단계
카드 한 건은 사용에서 결제까지 아래 순서로 흘러갑니다. 이 화면이 다루는 지점은 4단계이며, 앞 단계의 값이 그대로 따라 들어옵니다.
| 단계 | 처리 | 이 화면과의 관계 |
|---|---|---|
| 1. 사용 | 카드 사용일에 가맹점에서 결제 | 카드사용 일자(USEDATE) · 가맹점 정보 |
| 2. 승인 | 카드사 승인 처리, 승인번호 발급 | 승인번호(ACKNO) · 승인금액(CACL_AMT) |
| 3. 매입 | 가맹점 매입 접수, 매출관리번호 부여 | 매출관리번호(DEMA_COLL) — 건별 고유 키 |
| 4. 청구 | 월 단위로 묶어 법인에 청구 | 이 화면의 조회 기준 — 청구월 · 청구일자 |
| 5. 결제 | 지정 계좌에서 출금 | 결제은행 · 결제계좌 · 결제일자(SETT_DATE) |
승인과 매입 사이에 시차가 있어 사용일이 전월이어도 청구는 이번 달에 잡힐 수 있습니다. 그래서 조회 기준은 사용월이 아니라 청구월입니다.
조회조건
| 필드 | 필수 | 설명 |
|---|---|---|
회사코드 Bukrs | 필수 | 변경 못함. 로그인 사용자 → 사번 → 사원 Vendor 순으로 기본값 결정 |
청구 연월 Billmon | 필수 | YYYYMM. 기본값은 시스템 일자 전월 |
카드번호 CardNum | 선택 | 카드 목록에서 선택. 비우면 전체 카드 |
사용 구분 ForeUse | 선택 | 전체 / 국내 / 해외 |
회사코드는 변경할 수 없습니다. 기본값은 로그인 사용자 ID로 사번을 찾고(USR21 · ADCP), 그 사번으로 사원 Vendor 의 회사코드를 찾아(LFB1) 채우는 순서로 결정됩니다.
결과 컬럼
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
SAP 표준 기능 확장 포인트
SAP 표준 기능 매핑
카드 데이터 적재와 전표 생성은 표준이 담당합니다. 이 화면은 적재된 청구내역을 읽어 카드별 집계와 가맹점 관점을 더해 확장합니다.
| 표준 | 역할 | 이 화면에서의 확장 |
|---|---|---|
| 카드사 인터페이스 | 전송 파일 수신 · 청구내역 테이블 적재 | 적재된 내역을 청구월 · 카드 단위로 모아 집계 관점 제공 |
FB60 · F-43 | 카드 비용 전표 입력 | 전표 입력 전에 청구 구성과 가맹점 정보를 확인하는 단계 |
FBL3N 관점 | G/L 계정 라인아이템 조회 | 계정 라인 나열 대신 카드 × 사용 구분으로 집계해 정산 중심으로 재구성 |
USR21 · ADCP · LFB1 | 사용자 · 사번 · 사원 Vendor | 회사코드 기본값 결정 경로 |
| 부가세 신고 연계 | 매입세액 집계 | 가맹점 사업자번호 · 업종 · 부가세를 명세에 표시해 공제 대상 판단 지원 |
도입 시 확인이 필요한 부분
카드사 전송 레이아웃은 카드사마다 다릅니다. 항목명과 자릿수, 해외 건의 환율 적용 기준이 달라지므로 실제 도입 때는 인터페이스 규격서와 수신 주기를 함께 확인해 적재 테이블 구조를 정합니다. 법인카드 사용자 등록과 조회 권한 범위(재무팀 · 카드 사용자 본인)도 프로젝트 표준에 맞춰 조정합니다.
CDS 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
자주 묻는 질문
자주 묻는 질문
조회 기준이 사용월이 아니라 청구월인 이유는?
카드 사용과 카드사 청구 사이에는 승인·매입 처리 시차가 있습니다. 월말에 쓴 건은 다음 달 청구서에 실릴 수 있어 사용월로 조회하면 실제 출금될 금액과 맞지 않습니다. 결제 계좌에서 빠져나갈 금액을 확인하는 화면이므로 카드사가 확정한 청구월을 기준으로 잡았습니다.
해외 건에 부가세가 없는데 정상인가요?
정상입니다. 국내 가맹점 결제는 공급가액에 부가세가 붙어 매입세액공제 대상이 되지만, 해외 사용분은 국내 부가세 과세 대상이 아닙니다. 대신 원화 환산 과정에서 환가료가 붙습니다. 두 금액은 성격이 달라 집계에서도 각각 표시합니다.
카드별 집계를 따로 둔 이유는?
청구 명세는 카드사 레이아웃을 그대로 담아 28개 컬럼입니다. 이것만 펼치면 어느 카드에서 얼마가 나왔는지 읽으려고 좌우로 훑어야 합니다. 위에 집계를 두면 출금 규모를 한눈에 잡고, 확인이 필요한 카드만 골라 명세로 내려갈 수 있습니다.
가맹점 사업자번호와 업종명은 왜 표시하나요?
매입세액공제 대상 여부와 비용 계정을 판단하는 근거이기 때문입니다. 접대성 업종이나 공제 제외 업종은 같은 금액이라도 처리가 달라집니다. 전표를 입력하기 전에 업종과 가맹점을 확인하면 부가세 신고 단계에서 되돌아오는 일이 줄어듭니다.
SAP 표준 기능과 어떻게 이어지나요?
카드사 전송 파일 수신과 적재는 기존 인터페이스가 담당하고 결과는 청구내역 테이블에 그대로 남습니다. 이 화면은 그 데이터를 청구월과 카드 단위로 모아 구성 항목별 집계와 가맹점 관점을 얹은 조회 전용 화면이며, 비용 전표 생성은 표준 트랜잭션이 담당합니다.