> AX 사례 · 경영지원

법인카드 전표의 부가세·간이과세자 확인과 사용자별 사용금액 정리

사업자번호로 간이과세를 가리려 했는데, 절반은 판매자 번호가 아니었습니다.

01 · BACKGROUND

배경

법인카드 전표를 검토합니다. 사용자가 올린 카드 전표를 증빙과 카드사 금액에 맞춰 확인하고, 복리후생비·소모품비는 영수증으로 부가세와 간이과세자 여부를 판단한 뒤 사용자별 사용금액을 정리해 보고합니다.

02 · PROBLEM

핵심 문제

복리후생비·소모품비 영수증을 한 장씩 열어 부가세 금액과 간이과세자 여부를 판단하는 데 시간이 오래 걸렸고, 사용자별 카드 사용금액도 카드사 홈페이지에서 따로 모아야 했습니다.

03 · CAUSES

구조적 원인

  1. 01플랫폼으로 결제한 건은 전표의 가맹점 사업자번호가 결제대행사 번호여서, 실제 판매자는 영수증을 열어야 알 수 있었습니다.
  2. 02전표의 과세유형 칸이 거의 모두 같은 값으로 채워져 있어, 간이과세자 여부를 가려내는 데 쓸 수 없었습니다.
  3. 03같은 비용도 팀에 따라 계정코드 계열이 달라, 다른 팀 코드가 섞여 들어가도 눈에 띄지 않았습니다.

04 · SOLUTION

해결 과정

아래 사례는 실제 참가자의 업무를 적용한 프로젝트 결과를 바탕으로 합니다.
단, 업무 데이터 등의 보안을 위하여 이미지는 AI를 활용하여 제작하였습니다.

사업자번호만 조회하면 간이과세자를 가릴 수 있을까?

법인카드 전표를 검토하는 담당자가 사전 설문에 적은 아이디어는 꽤 구체적이었습니다.

공공데이터포털의 사업자 상태 조회 API에 가맹점 사업자번호를 넣어, 간이과세자인지 자동으로 판단하자는 것이었습니다.

매달 사용자들이 올린 카드 전표를 보면서, 복리후생비·소모품비는 영수증을 하나하나 열어 부가세를 확인하고 간이과세자인지 따지는 일입니다.

간이과세자 여부에 따라 부가세 처리가 달라지니 건너뛸 수도 없습니다.

저희도 처음엔 좋은 방법이라고 봤습니다. 번호 한 줄이면 끝나니까요.

그런데 함께 받은 7월 MIS 전표를 살펴보니, 조회할 번호부터 문제였습니다.

89건 중 40건, 번호의 주인이 판매자가 아니다

89건

40건

13건

7월 법인카드 사용

쿠팡·네이버·카카오 같은
플랫폼 결제

네이버 결제인데
사업자번호가 모두 같은 줄

플랫폼으로 결제하면 전표의 가맹점 사업자번호에는 실제 판매자가 아니라 결제대행사 번호가 찍힙니다. 네이버로 결제한 13건은 물건을 산 곳이 제각각인데도 번호가 모두 같았습니다.

이 번호로 조회하면 결제대행사가 간이과세자인지만 나옵니다.

법인카드 전표의 부가세·간이과세자 확인과 사용자별 사용금액 정리 이미지 1

과세유형 칸도 기대와 달랐습니다. 89건 중 88건이 같은 값 '01'이었고, 나머지 1건은 비어 있었습니다. 이 칸으로는 간이과세자를 가려낼 수 없었습니다.

담당자도 설문에 이렇게 적어 두었습니다.

"PG사 결제는 판매자 정보의 사업자를 조회"

전표를 확인해 보니 이게 예외가 아니라 절반에 가까운 일이었습니다. 플랫폼 결제는 영수증이나 주문 내역에 적힌 판매자 정보를 따로 읽어야 합니다.

부가세를 1/11로 맞춰 보면 어긋나는 7건

두 번째 아이디어는 사용자가 첨부한 영수증과 MIS에 들어간 부가세를 맞춰 보는 것이었습니다. 저희는 먼저 결제금액의 1/11과 부가세 칸을 비교해 봤습니다.

어긋난 줄

건수

부가세 칸

상품권·기프티콘

4건

0원

여러 품목을 한 번에 결제한 건

3건

1/11보다 적음 (면세 품목이 섞인 것으로 보임)

나머지 82건은 1/11과 맞았습니다. 그렇다고 82건이 다 맞다고 볼 수는 없습니다.

영수증상 부가세가 따로 없는 가맹점이어도 전표에는 1/11이 그대로 들어가 있을 수 있거든요.

1/11 비교는 '이상한 줄 찾기'까지만. 맞다는 판단은 영수증을 봐야 한다.

같은 우편료, 계정코드는 두 가지

전표를 훑다가 계정코드에서도 걸리는 줄이 나왔습니다. 같은 팀이 같은 적요 '서류 우편대'로 올린 두 건이 서로 다른 통신비 코드를 쓰고 있었습니다.

같은 팀 전표

통신비 코드

다른 전표 전부

460으로 시작

우체국 '서류 우편대' 1건

422로 시작 (다른 팀들이 쓰는 계열)

계정과목명이 비어 있는 줄도 5건 있었습니다. 생일 상품권과 케이크, 그리고 네이버로 산 비품 1건입니다.

다른 비품은 모두 소모품비였는데 이 한 건만 이름 없는 코드로 들어가 있었습니다.

법인카드 전표의 부가세·간이과세자 확인과 사용자별 사용금액 정리 이미지 2

Claude에게 맡길 일, 사람이 볼 일

그래서 이 업무에서 Claude에게 맡길 일을 다시 나눴습니다.

Claude에게 맡길 일

사람이 볼 일

플랫폼 결제를 골라내고 영수증에서 판매자 사업자번호 읽기

판매자 정보가 영수증에 없는 건 확인

판매자 번호로 사업자 상태 조회 돌리기

간이과세자로 나온 건의 부가세 처리 결정

결제금액 1/11과 부가세 칸을 비교해 안 맞는 줄 목록 만들기

상품권·혼합 품목 판단

같은 팀·같은 적요인데 코드가 다른 줄, 계정명이 빈 줄 표시

계정코드 수정

사용자별 사용금액 합계 초안

보고 금액 확정

교육에서 드린 키트의 신호등에서 금액 확정은 '하면 안 됨'입니다. 부가세와 계정코드 수정도 사람이 합니다.

과정 둘째 날 누락 자료 시험이 이 업무에서 특히 중요합니다.

영수증에 판매자 정보가 없을 때 Claude가 결제대행사 번호를 판매자 번호로 써 버리는지, '확인 필요'로 멈추는지 보는 자리입니다.

다음 달 카드 마감에 달라지는 것

지금은 89건을 위에서부터 한 줄씩 보며 영수증을 열고, 부가세와 간이과세 여부를 판단합니다. 다음 달부터는 Claude가 먼저 전표를 세 묶음으로 나눠 줍니다.

  1. 플랫폼 결제 — 판매자 정보를 따로 읽어야 할 줄

  2. 1/11 불일치 — 상품권·혼합 품목처럼 부가세가 어긋난 줄

  3. 코드 이상 — 같은 적요인데 코드가 다르거나 계정명이 빈 줄

그 목록에 오른 줄의 영수증부터 엽니다. MIS도, 카드사 홈페이지도 그대로입니다. 전표를 엑셀로 내려받아 폴더에 넣으면 시작할 수 있습니다.

결제대행사 번호로 간이과세자를 가렸다면

사업자번호만 조회했다면, 89건 중 40건은 결제대행사를 판매자로 놓고 판단했을 겁니다.

네이버로 산 13건은 물건을 산 곳이 제각각인데도 한 사업자로 묶였겠죠. 부가세 1/11과 어긋난 7건도 그 사이에 섞여 지나갔을 거고요.

번호로 상대방을 조회하는 업무라면, 그 번호가 정말 상대방 것인지 의심해 볼 자리가 꼭 있습니다.

조회 결과가 깔끔하게 나올수록, 번호 자체는 아무도 다시 보지 않습니다.

판매자 번호를 어디서 읽을지, 1/11 비교를 어디까지 믿을지만 정하면 됩니다.

Claude가 89건을 세 묶음으로 먼저 나눠 주니, 영수증은 그 목록에 오른 줄부터 열면 됩니다.

다음 달 카드 전표를 엑셀로 내려받아 오세요.

저희 과정에서 판매자 정보가 빠진 영수증을 일부러 넣어 보고, Claude가 대행사 번호를 판매자로 써 버리는지 멈추는지까지 같이 확인합니다.

번호만 조회했다면 결제대행사를 판매자로 판단했을 40건. 여러분이 조회하는 그 번호가 정말 상대방 것인지, 다음 카드 마감 전에 가려내야 합니다.

본 프로젝트는 솔트룩스x헬로월드랩스의 공동 개발 및 운영 교육 과정을 통해 진행되었습니다.

05 · RESULTS

성과

핵심 성과 지표

카드 전표 89건, 먼저 볼 줄부터 분류

NOW OPEN

놓치기 전에, 지금 모집 중인 교육

전체 교육 과정 →

다음 성과 사례의 주인공은 우리 회사입니다

비슷한 고민이라면, 같은 방법으로 시작할 수 있습니다.