ERP 카드사 연동 전표 자동화 — 데이터 흐름과 실패 케이스

ERP 카드사 연동 전표 자동화는 카드사 매입 데이터를 ERP 회계 전표로 변환·기표하는 흐름입니다. 매입 API·법인카드 CMS·은행계좌 3축 데이터 소스와 자동 전표 실패 4가지 케이스, 셋업 전 점검 체크리스트를 정리합니다.

ERP 카드사 연동 전표 자동화란 — 작동 원리

ERP 카드사 연동 전표 자동화는 카드사에서 발생한 매입·승인 데이터를 ERP로 자동 수신해 계정과목·거래처·부가세 구분을 붙여 회계 전표로 기표하는 흐름입니다. 담당자가 매월 카드사 홈페이지에서 이용내역서를 내려받아 엑셀로 정리하고 계정과목을 붙여 ERP에 다시 입력하던 3단계 작업이, 카드 승인 시점에 실시간으로 임시 전표까지 넘어오는 하나의 파이프라인으로 바뀝니다.

실무에서 이 자동화의 가치는 단순 시간 절감이 아니라 계정과목 매핑 규칙의 표준화에 있습니다. 사람이 붙이던 계정과목은 담당자·시점·해석에 따라 흔들리지만, 자동 매핑은 가맹점 코드·업종 코드·금액 규칙을 조합해 같은 지출은 같은 계정과목으로 계상됩니다. 결산 시 계정과목 재분류·과세 검토 시간을 상당 부분 줄일 수 있는 배경입니다.

"법인카드 처리가 사실 어려운 게 아닌데 시간이 가장 많이 쓰이고 번거로운 작업이에요. 짜잘한 것들을 사용하다 보니까 하루에도 몇십 건 몇백 건 이렇게 이루어질 수가 있어서요." — 반도체 기업 재무회계팀 팀장

지출 건수가 늘어날수록 자동화의 상대 이득이 커집니다. 다만 자동 기표가 무조건 정답을 만들어주지는 않습니다. 뒤에서 살펴볼 4가지 실패 케이스가 그대로 남으면 자동화의 절반 이상이 사후 검수·수정으로 되돌아가기 때문에, 도입 전에 데이터 소스와 매핑 규칙을 어떻게 설계할지가 결정적입니다. ERP 자체 도입 검토 단계라면 회계프로그램 선택 전 확인할 5가지 기준에서 다룬 연동·확장성 기준을 함께 살펴보는 것이 유용합니다.

카드사 데이터 소스 3가지와 ERP 전표 매핑 흐름

카드사 데이터를 ERP로 끌어오는 경로는 크게 3가지입니다. 어느 소스를 쓰느냐에 따라 실시간성·커버리지·예외율이 다르고, 실무에서는 하나만 쓰기보다 조합해서 씁니다.

실무 조합은 매입 API 또는 CMS로 개별 승인 건 데이터를 확보하고, 은행계좌 소스로 실제 대금 지급 시점을 대조하는 방식입니다. 개별 건 데이터가 있어야 계정과목·거래처·부가세를 붙일 수 있고, 은행계좌 소스는 결제일 기준 미지급금 계상·현금 흐름 확인용 보조 채널입니다.

데이터가 ERP로 들어온 뒤에는 4단계 매핑을 거쳐 전표가 생성됩니다.

• 1단계 · 원본 수신 — 카드사 매입 API 또는 CMS에서 승인번호·가맹점명·업종코드·금액·부가세액 원본 데이터를 임시 테이블로 수신합니다.
• 2단계 · 계정과목 매핑 — 가맹점명·업종코드 기반으로 사전 등록된 규칙에 따라 계정과목을 붙입니다(예: 식음료 업종 → 복리후생비·접대비, 주유소 → 차량유지비).
• 3단계 · 거래처 매핑 — 사업자등록번호가 있으면 거래처 마스터와 조인해 거래처 코드를 자동 부여합니다.
• 4단계 · 부가세 구분 — 계정과목·업종에 따라 매입세액 공제/불공제, 접대비 여부를 자동 태깅합니다.

4단계 모두 성공한 건만 확정 전표 후보가 되고, 하나라도 매칭에 실패한 건은 대기 큐로 빠져 담당자 검수를 기다립니다. 자동화율은 이 대기 큐 비율이 얼마나 낮은지로 실질적으로 결정됩니다.

"사람이 했을 때는 5분 정도 걸리는 거를, 클라우드 툴은 클릭 몇 번이면 바로 연동이 돼서 확인이 가능하니까요. 카드사에서 ERP 연계로 끌어온 다음에 계정 과목만 빨리 입력해서 회계 전표 처리할 수 있게 하는 거예요." — 반도체 기업 재무회계팀 팀장

자동 전표 생성이 실패하는 4가지 케이스와 예외 처리

일반적으로 자동 전표 매핑이 100% 성공하는 조직은 거의 없다고 알려져 있습니다. 실무에서 반복적으로 걸리는 실패 유형은 4가지로 좁혀지고, 각 유형별 예외 처리 방침을 사전에 설계해두면 대기 큐를 안정적으로 관리할 수 있습니다.

1. 계정과목 미분류 — 신규 가맹점·복합 업종

사전 등록된 가맹점명·업종 코드 규칙에 없는 신규 가맹점이 사용되면 계정과목을 붙일 수 없습니다. 신생 카페·소규모 온라인몰·간판만 바뀐 가맹점이 대표 사례입니다. 예외 처리는 두 갈래입니다. 첫째, 대기 큐에 빠진 건을 담당자가 첫 승인 시 계정과목을 지정하면 가맹점 마스터에 규칙을 자동 등록해 다음부터 자동 처리합니다. 둘째, 복합 업종(예: 편의점 안 카페)은 우선 계정과목(복리후생비) → 담당자 확인 요청 태그를 붙여 흘려보내고, 월말에 일괄 재분류합니다.

2. 거래처 매칭 실패 — 사업자번호 미확보·개인사업자 이름 표기

가맹점 데이터에 사업자등록번호가 빠져 있거나 개인사업자 상호가 대표자명으로 표기된 경우가 대표적입니다. 이런 건은 거래처 마스터에서 자동 조인이 되지 않아 거래처 미지정 상태로 대기 큐에 남습니다. 예외 처리는 월 1회 사업자번호 일괄 조회 API를 돌려 사후 매칭하거나, 정기 사용 가맹점 상위 20~30곳 수준을 담당자가 사전에 마스터에 등록해두는 방식이 일반적입니다. 소액·비정기 지출은 거래처 미지정 상태 그대로 결산해도 무리는 없지만, 정기 지출은 반드시 매칭해두어야 결산·세무조정 시 검증이 수월해집니다.

3. 부가세 구분 오류 — 접대비·비영업용 승용차·복리후생비 경계

매입세액 불공제 대상은 부가가치세법 제39조에 따라 접대비·비영업용 승용차 관련 매입·면세사업 관련 매입 등으로 구분됩니다. 자동 매핑 규칙은 가맹점·계정과목 기준으로만 판정하기 때문에, 같은 식당에서 발생한 지출이 회식(복리후생비)인지 접대(접대비)인지는 시스템이 판정할 수 없습니다. 실무 처리는 계정과목까지는 자동으로 붙이되 부가세 구분은 담당자가 월말에 배치 확인하도록 워크플로를 설계합니다. 카드사 데이터에 지출목적 입력 필드가 있는 경우(카드사 앱에서 사용자가 입력) 이 값을 함께 수신해 자동 판정 정확도를 높일 수 있습니다.

4. 마감 처리 충돌 — 이미 확정된 월에 뒤늦게 들어온 승인 건

매입 API·CMS 소스 모두 승인 시점에서 확정 데이터까지 일반적으로 1~5일 수준의 지연이 발생하는 것으로 알려져 있습니다. 월말 마지막 날 승인된 건이 다음 달 초에 데이터로 들어오면 회계 마감이 이미 종료된 경우 자동 기표가 실패합니다. 예외 처리 방침은 두 가지입니다. 하나는 승인일 기준 소급 전표를 허용해 전월 마감을 한 번 되돌리는 방식, 다른 하나는 수취일 기준 당월 전표로 처리하고 결산 시 조정 분개를 넣는 방식입니다. 회사 회계 정책에 따라 사전에 결정해두어야 마감 스트레스가 반복되지 않습니다. 결산 과부하 이슈는 회계 월말 야근 원인 정리에서 별도로 다룹니다.

임팩트플로우는 B2B SaaS 매칭 플랫폼으로, 기업에 최적화된 회계·ERP 자동화 솔루션을 연결합니다. 카드사 조합·매입 규모·기존 ERP 스택을 파악해 후보를 좁혀드립니다.

연동 셋업 전 반드시 확인할 체크리스트

ERP·카드사 연동을 계약 단계에서 확인하지 않으면 도입 후 반년까지도 대기 큐가 줄지 않는 경우가 잦습니다. 셋업 착수 전에 다음 4가지 항목을 재무팀·정보시스템팀·벤더가 함께 확정해두어야 합니다.

1. 계정과목 코드 매핑 사전 정의

가맹점 업종 코드 → 계정과목 매핑 규칙을 사용 실적 상위 80% 수준의 가맹점 기준으로 사전 등록하는 것이 일반적으로 권장됩니다. 업계에서는 대체로 최근 6개월 카드 이용내역서를 기준으로 상위 100~200곳의 계정과목을 지정하면 초기 자동화율 70% 이상이 확보되는 것으로 알려져 있습니다. 나머지 롱테일은 대기 큐를 통해 점진적으로 학습됩니다.

2. 거래처 마스터 정비

정기 지출 가맹점(사무실 임대·통신·SaaS 구독·주기적 배달)은 사업자등록번호와 거래처 코드를 마스터에 사전 등록합니다. 카드 매입 데이터에는 사업자번호가 부정확하게 들어오는 경우가 많아, 거래처 마스터의 상호·사업자번호 매칭 조건을 완전 일치가 아닌 주요 토큰 일치로 설정해두는 것이 실무적으로 안전합니다.

3. 부가세 구분 기준 문서화

매입세액 공제/불공제 판정 기준을 계정과목별 default 값과 예외 처리 룰로 문서화합니다. 복리후생비는 공제, 접대비는 불공제가 원칙이지만 실무에서는 담당자별 판정이 흔들리는 지점입니다. 판정 근거를 문서로 남겨두면 세무조사·회계감사 시 소명 자료로도 활용할 수 있습니다.

4. 마감 정책·소급 전표 허용 여부 확정

결산일 이후 들어오는 승인 데이터를 승인일 기준 소급 전표로 처리할지, 수취일 기준 당월 전표로 처리할지 결정합니다. 소급을 허용하면 승인일 기준 정확성이 높지만 마감 재작업이 반복됩니다. 실무에서는 월 5일까지 들어오는 전월 승인 건은 소급 허용, 이후는 당월 조정 분개 정책을 많이 씁니다. 카드 지출 규모가 크지 않다면 거래 데이터 분할 처리 실무 이슈에서 정리한 배치 처리 원칙을 참고할 수 있습니다.

자주 묻는 질문

API 연동은 카드 승인 시점부터 승인번호·가맹점·금액 원본 데이터가 실시간에 가깝게 ERP로 들어오는 방식이고, 파일 업로드는 담당자가 카드사 홈페이지에서 이용내역 엑셀을 내려받아 ERP에 업로드하는 방식입니다. API 연동은 실시간성·데이터 완전성이 높은 반면 카드사·ERP 간 연동 계약과 초기 세팅 리소스가 필요합니다. 파일 업로드는 초기 진입은 쉽지만 담당자 수작업이 남고 파일 포맷이 카드사별로 달라 매핑 관리가 번거로운 편입니다.

계정과목이 자동 매핑된 뒤에도 부가세 공제/불공제 판정은 담당자 확인이 필요한 경우가 많습니다. 접대비·비영업용 승용차 관련 매입처럼 계정과목만으로 불공제가 확정되는 항목은 자동 태깅이 가능하지만, 같은 식당에서 발생한 지출이 회식(공제)인지 접대(불공제)인지는 시스템이 판정할 수 없습니다. 실무에서는 계정과목까지는 자동 매핑하고 부가세 구분은 월말 배치 검수로 처리하는 방식을 많이 씁니다.

회사 회계 정책에 따라 두 가지 방식이 있습니다. 소급 전표를 허용하는 조직은 전월 마감을 되돌려 승인일 기준으로 원 전표를 생성한 뒤 마감을 재확정합니다. 소급을 허용하지 않는 조직은 수취일 기준으로 당월 전표로 처리하고, 결산 시 전월귀속으로 조정 분개를 넣습니다. 카드 매출채권·매입채무 규모가 크지 않다면 후자가 실무 부담이 덜한 편입니다.

대부분의 ERP는 소액 건 묶음 처리를 지원합니다. 계정과목·거래처·부가세 구분이 같은 승인 건을 일별 또는 주별로 합산해 하나의 전표로 계상하는 방식입니다. 다만 법인세법 시행령의 지출 증빙 요건상 건별 승인 자료는 반드시 보관해야 합니다. 묶음 전표를 사용하더라도 원본 승인 데이터가 임시 테이블에 그대로 남는 구조여야 세무조사 시 소명 리스크가 없습니다.

ERP 카드사 연동 전표 자동화는 데이터 소스 조합·매핑 규칙 사전 설계·예외 처리 방침이 성패를 결정합니다. 임팩트플로우는 B2B SaaS 매칭 플랫폼으로, 기업에 최적화된 회계·ERP 자동화 솔루션을 연결합니다. 카드사 조합·매입 규모·기존 ERP 스택을 파악해 후보를 좁혀드립니다.