// 업무 자동화
이커머스 PG 정산 ↔ 은행 입금 대사 자동화
PG 정산서와 은행 실입금을 매주 대조하던 시간을 줄입니다. 일자별 자동 대사 후 차이 난 줄만 확인합니다.
PG 정산서에 적힌 금액과 은행 통장에 실제로 들어온 금액은 매번 조금씩 다릅니다. 수수료, 부분 취소, 다음 영업일 이월이 섞이기 때문입니다. 마켓플레이스나 정산 서비스를 운영한다면, 셀러마다 이 차이를 매주 엑셀에 펼쳐 놓고 일자별로 맞추는 시간이 그대로 운영 부담이 됩니다. 은행 입금 수집을 headless로 자동화하면 대사 시간이 줄고, 화면에는 차이 난 몇 줄만 표시됩니다.
이 글은 셀러 정산을 자기 서비스 안에서 처리하는 플랫폼 개발자·운영자를 위한 글입니다. 코드는 거의 없습니다.
누가, 언제 겪는 일인가
여러 PG로 결제를 받는 마켓플레이스나 셀러 정산 서비스가 매주, 매월 겪습니다.
- 빈도: 보통 주 1회(지난주 정산이 다 들어온 월요일). 월정산도 같은 구조입니다.
- 현재 방식: 여러 PG사 관리자에서 정산서를 내려받고, 은행 입금 내역을 따로 받아 일자·금액을 눈으로 맞춥니다.
- 방치 비용: 미정산·이체 누락을 늦게 발견하면 한 주가 지나 추적이 어려워집니다. 정산서 표기(
A페이·(주)A페이·APAY)가 은행 적요와 달라 매칭이 깨지면 그만큼 셀러 문의와 야근이 늘어납니다.
어디까지 자동화되나
은행 입금 수집과 일자별 매칭은 자동, 차이의 원인 판단만 사람이 합니다. 수집된 데이터는 정산 서비스 안으로 전달되어 셀러별 대사 결과로 다시 표시됩니다.
| 단계 | 현재 (수기) | headless 도입 후 |
|---|---|---|
| 은행 입금 수집 | 은행 로그인·다운로드 | 자동 |
| PG 정산서 정규화 | PG마다 다른 양식 수기 정리 | 자동 (PG별 양식 정규화) |
| 일자별 매칭 | 엑셀 VLOOKUP·정렬 | 자동 (PG·금액·일자 3키) |
| 차이 추리기 | 전부 사람 | 자동 (차이 난 줄만 CSV) |
| 차이 원인 판단 | 사람 | 사람 (남는 일) |
매칭은 세 상태로 나옵니다. 금액·일자가 맞으면 OK입니다. ±2 영업일 안에서 1원이라도 어긋나면 GAP(수수료·부분취소 가능성)입니다. 3 영업일 안에 대응 입금이 없으면 MISSING(다음 영업일 이월 가능성)입니다. OK는 조용히 넘어가고, GAP·MISSING만 담당자 앞에 쌓입니다.
한 주가 대사되는 과정
지난주 정산을 예로 들어 보겠습니다. 결과 CSV에는 차이 난 줄만 남습니다.
입금일,PG,PG정산액,은행실입금,차이,상태,비고
2026-04-29,A페이,1840200,1839200,-1000,GAP,수수료·부분취소 가능성
2026-04-30,A페이,920000,0,-920000,MISSING,다음 영업일(5/2) 확인차이가 없으면 헤더만 있는 빈 CSV가 나옵니다. "이번 주 차이 없음"을 1초에 확인합니다. 숫자는 예시입니다.
까다로운 건 PG 표기 변형입니다. 같은 PG가 은행 적요에 매주 다르게 찍혀도, 한 번 확정한 변형이 규칙에 쌓여 다음 주부터 자동으로 잡힙니다. 첫 2주는 사람이 PG 관리자와 은행 명세를 한 번씩 대조해 자동 결과와 차이가 0인지 확인하고, 그 뒤 정기 일정으로 넘깁니다.
비용과 ROI
추정이라 자기 거래량으로 바꿔 보면 됩니다.
- 시간: PG 3곳·주 1회 기준, 수집·대사가 주 2~4시간. 자동화 후 차이 줄만 보는 데 주 10~20분입니다.
- 금액: 미정산을 한 주 늦게 잡으면 추적 비용이 커집니다. 조기 발견으로 줄어드는 손실이 요금을 넘는 경우가 많습니다.
- 요금: headless는 데이터 수집 요청 단위 과금입니다. 주 1회 은행 수집이면 슬롯이 작습니다. 현재 가격은 요금 페이지에서 확인합니다.
도입하는 법
경로 1 - 개발자에게 요청. 아래를 그대로 전달합니다.
매주 월요일 지난주(월~일) 은행 입금
bank.transactions.cb.v1을 받아서, 우리가 받아 둔 PG 정산서 폴더와 PG·금액·일자로 매칭하고, 차이 난 줄만 CSV와 슬랙으로 보내줘. 은행 자격증명 1개 콘솔에 등록할게.
경로 2 - 낮은코드. 은행 수집 한 줄은 이 정도입니다.
# 지난주 은행 입금 받기 (CLI 예시) - --provider 는 은행 한 곳씩
h6s fetch bank.transactions.cb.v1 --provider CB_KB --from "$LAST_MON" --to "$LAST_SUN" --save bank.jsonlPG 정산서는 PG 관리자에서 받아 지정 폴더에 두고, 매칭 규칙(±2 영업일·1원 허용오차)을 한 번 합의해 고정합니다. 자연어 에이전트로 같은 흐름을 부르는 방법은 Slack에서 자연어로 어제 매출 묻기와 결이 같습니다.
안전한가
은행 자격증명은 봉투 암호화로 저장하고 수집 시점에만 메모리에서 복호화합니다. 등록 후 평문은 남지 않습니다. 자격증명은 워크스페이스 안에만 있어 밖에서 보이지 않습니다. PG 정산서는 운영자가 받아 두는 파일이라 자격증명과 분리됩니다. 키 관리 모델은 보안 페이지에 있습니다.
도입 체크리스트
- 대사할 PG 목록·은행 1줄로 정리
- 매칭 규칙 합의 - 일자 폭(±2 영업일)·금액 허용오차
- PG 정산서를 어디에 둘지 폴더 약속
- 첫 2주 수기 대조로 자동 결과 검증
- 매주 월요일로 일정 고정
자주 막히는 곳
| 증상 | 원인 | 대응 |
|---|---|---|
| GAP가 늘 −수수료만큼 | 정산서가 수수료 차감 전 금액 | 정상입니다. 수수료 룰을 매칭에 한 번 반영하면 OK로 정리됩니다 |
| MISSING이 다음 주 OK로 바뀜 | 주말·휴일 이월 입금 | 정상입니다. ±영업일 창 안이면 자동 매칭됩니다 |
| 적요 매칭 실패율 30%↑ | PG 표기 변형 미등록 | 사람이 확정한 변형이 규칙에 쌓여 다음 주 줄어듭니다 |
| 같은 PG·일자 후보 2건 | 부분 정산 분할 입금 | 큰 금액 우선 매칭, 작은 차이는 "검토" 표시됩니다 |
| 은행 0건 | 휴일이면 정상 | 영업일인데 0건이면 자격증명·계좌를 확인합니다 |
더 읽기
- 이 흐름을 마켓플레이스 정산에 본격적으로 엮는 방법: 마켓플레이스 정산 연동 시나리오
- 매출 세금계산서까지 같이 맞춰야 한다면: 은행 입금과 매출 세금계산서, 매월 사람 손 없이 대사
- 1인 운영이라 부가세까지 직접 한다면: 1인 사장의 분기 부가세, 클릭 없이 자료 준비
- 다른 자동화 사례: 활용 사례 모음