신규 거래처 등록 전에 확인할 정보와 증빙 체크리스트

등록 목적

사업자등록증 한 장으로 거래처 등록이 끝날까?

사업자등록증은 상호, 사업자등록번호, 대표자와 사업장 같은 기본정보를 확인하는 자료이지만 계약 상대방과 실제 지급계좌, 세금계산서 수신정보까지 모두 보증하지는 않습니다. 신규 거래처 등록은 계약·발주·증빙·지급에 사용할 기준정보를 만드는 과정입니다. 처음 잘못 입력된 정보는 이후 세금계산서 오류나 다른 계좌 송금으로 반복될 수 있습니다.

등록 범위는 거래 유형에 맞춰 조정합니다. 단발성 소액 구매와 장기 공급계약의 확인항목은 같을 필요가 없지만, 사업자번호와 계약 당사자, 지급요청의 진위는 기본적으로 교차 확인할 필요가 있습니다. 거래처가 보낸 한 이메일의 첨부파일만으로 등록과 지급승인을 동시에 끝내기보다 입력·검토·승인 단계를 구분합니다.

기본 정보

상호·사업자번호·대표자는 어디까지 맞춰 볼까?

사업자등록증에서 등록번호, 법인명 또는 상호, 대표자, 사업장 소재지와 업태·종목을 확인하고 계약서·견적서·발주서의 당사자와 비교합니다. 브랜드명과 법인명이 다를 수 있으므로 화면에 보이는 서비스명만 등록하지 않습니다. 본점과 지점 중 실제 계약·세금계산서 발급 주체가 어디인지도 구분합니다.

사본의 발급일이 오래됐거나 정보가 서로 다르면 거래처에 최신 자료를 요청하고 필요한 경우 정부의 사업자 관련 증명·상태 확인 경로를 이용합니다. 개인사업자의 주민등록번호나 대표자 개인 연락처처럼 거래에 불필요한 개인정보는 수집 범위를 제한합니다. 확인일과 확인한 문서 버전을 등록 기록에 남깁니다.

• 사업자등록번호·법인명 또는 상호·대표자
• 본점·지점과 실제 계약·발급 주체
• 계약서·발주서·청구서의 당사자 일치
• 확인일·자료버전·개인정보 최소수집

지급계좌

거래처 계좌는 어떤 경로로 확인할까?

통장사본의 예금주와 계약 상대방의 법인명 또는 상호를 비교하고, 계좌를 보낸 담당자가 기존 계약 연락처와 일치하는지 확인합니다. 명의가 다른 경우 대표자 개인계좌인지, 수금대행이나 채권양도처럼 다른 근거가 있는지 별도 서류와 승인으로 검토합니다. 계좌번호 형식이 맞는다는 사실만으로 수취 권한이 확인되는 것은 아닙니다.

첫 거래와 계좌 변경 요청은 메일 회신만으로 처리하지 않고 등록된 대표번호나 기존 담당자에게 독립적으로 확인합니다. 급한 지급을 재촉하거나 메일 주소가 미세하게 다른 경우에는 지급을 보류하고 확인 경로를 바꿉니다. 전체 계좌번호와 통장사본의 접근권한은 지급·검토 담당자에게 필요한 범위로 제한합니다.

증빙 정보

세금계산서 발급·수신 정보는 무엇을 등록할까?

공급자와 공급받는 자의 사업자등록번호, 상호·대표자, 공급가액·세액과 작성일자 등 세금계산서의 필수 정보를 실제 계약과 비교합니다. 수신 이메일은 회계 공용주소와 담당자 주소를 구분하고 담당자 퇴사 시에도 자료가 유실되지 않는 경로를 사용합니다. 거래처가 면세사업자이거나 증빙 종류가 다른 거래라면 적용 서류를 별도로 확인합니다.

전자세금계산서는 발급기한과 전송기한이 연결되므로 월말 뒤 한꺼번에 연락하기보다 거래 발생 시점에 회사 마감일을 공유할 필요가 있습니다. 역발행이나 위수탁 발급처럼 처리 주체가 다른 경우에는 역할과 승인절차가 계약 또는 등록 메모에 드러나야 합니다. 수정세금계산서가 생기면 원본과 수정본이 같은 거래처 코드에서 추적되어야 합니다.

변경 관리

등록 후 정보가 바뀌면 기존 값을 덮어써도 될까?

상호, 대표자, 주소, 담당자와 계좌가 바뀌면 변경 전 정보를 삭제하기보다 적용일과 변경사유, 요청자·검증자·승인자를 남깁니다. 과거 거래의 증빙은 당시 정보와 연결되어야 하므로 현재 마스터 정보로 일괄 덮어쓰면 예전 지급과 세금계산서를 설명하기 어려워질 수 있습니다. 변경 시점 이전과 이후의 거래 범위를 구분합니다.

특히 계좌 변경은 신규 등록과 같은 수준으로 검증합니다. 기존 메일 대화가 탈취됐을 가능성까지 고려해 별도 공식 연락처로 재확인하고, 변경 직후 첫 지급은 금액·예금주·승인자를 다시 확인합니다. 사용하지 않는 거래처는 삭제보다 비활성화해 과거 전표 연결과 재등록 중복을 방지합니다.

가상 사례

첫 송금 직전에 다른 계좌를 요청한 사례

신규 공급업체가 계약서에는 A 법인 명의 계좌를 적었지만 첫 청구서 이메일에서 대표자 개인 명의 B 계좌로 지급해 달라고 요청한 사례를 가정할 수 있습니다. 메일 서명과 담당자 이름이 기존 자료와 같아도 명의와 계좌가 바뀌었으므로 지급을 보류하고 공식 대표번호와 계약 담당자에게 사유를 확인합니다.

거래처가 정당한 사유와 위임자료를 제공하더라도 회사의 지급정책과 승인기준을 충족하는지 검토합니다. 최종적으로 A 계좌를 사용한다면 B 요청은 폐기하지 않고 검증 결과와 함께 사건기록으로 남깁니다. 예외적으로 B 계좌를 승인한다면 적용 거래, 기간과 승인자를 명확히 해 이후 모든 지급으로 자동 확대되지 않게 합니다.

권한 분리

등록자·승인자·지급자는 어떻게 역할을 나눌까?

정보를 입력한 사람이 계좌 변경과 지급까지 단독으로 완료하면 오타나 사칭 요청을 독립적으로 발견하기 어렵습니다. 소규모 조직에서도 입력 후 다른 담당자가 사업자번호, 명의와 근거자료를 확인하고 지급 승인 때 청구서와 등록정보를 재대조하는 단계를 둘 수 있습니다. 시스템 권한 분리가 어렵다면 서면 또는 전자 승인기록으로 보완합니다.

승인자는 모든 문서를 처음부터 다시 읽기보다 위험항목을 명확히 볼 수 있어야 합니다. 신규 거래처 여부, 계좌 명의 불일치, 변경 요청, 고액 첫 거래와 예외 승인 여부를 표시합니다. 반려된 등록 건은 사유와 필요한 추가자료를 남기고 수정본이 어느 항목을 바꿨는지 추적합니다.

정기 점검

등록된 거래처 정보는 언제 다시 확인할까?

거래가 재개된 휴면 거래처, 오랫동안 지급이 없던 거래처와 계약 갱신 시점에는 현재 정보의 재확인이 필요합니다. 반송된 세금계산서 메일, 예금주 불일치와 담당자 변경은 마스터 정보 점검의 신호가 될 수 있습니다. 중복 사업자번호와 비활성 거래처, 승인되지 않은 변경 건은 정기 점검 대상입니다.

검토 결과는 확인일과 다음 검토 예정일, 변경 여부로 남깁니다. 사용하지 않는 계좌나 연락처를 화면에서 숨기더라도 과거 거래와의 연결은 유지합니다. 거래처 자료의 보존기간과 접근권한은 세법상 장부·증명서류 보존 의무와 회사의 개인정보·보안정책을 함께 고려합니다.