ERP 오픈 API로 판매 전표 넣기: 왜 사람 승인 단계를 두는가

국내 클라우드 ERP 중에는 오픈 API로 판매 전표를 저장할 수는 있어도, 공개된 API가 입력과 조회뿐이라 수정·삭제는 할 수 없는 곳이 있습니다. 이런 ERP에서는 한 번 잘못 들어간 전표를 사람이 ERP 화면에서 고쳐야 합니다. 그래서 ERP 연동의 중심은 보내기 전 검사와 사람의 승인 버튼입니다. 인증키를 고객사의 최고 관리자 계정으로만 발급하는 ERP도 있어서, 키 관리는 고객사가 맡는 것이 자연스럽습니다.

ERP 오픈 API로 무엇을 할 수 있나요?

열려 있는 기능과 사용료는 ERP마다 다릅니다. 국내 클라우드 ERP 한 곳의 공식 안내를 예로 들면, API 사용에 추가 비용이 없다고 밝히고 제공 범위를 아래처럼 적어 두었습니다.

이 ERP는 상세 문서를 로그인해야 열 수 있게 해 두었고, 공개된 예제 기준으로 판매 입력 한 번에 여러 줄을 담아 보낼 수 있습니다. 공개된 연동 사례를 보면 호출 순서는 회사의 접속 영역을 조회하고, 회사코드·사용자 ID·인증키로 로그인해 세션을 받은 뒤, 그 세션으로 판매 저장을 호출하는 흐름입니다. 다른 ERP를 쓴다면 같은 항목(제공 범위, 사용료, 상세 문서, 로그인 방식)을 그 ERP의 안내에서 확인하면 됩니다.

조회 쪽에 품목과 재고현황이 있다는 점도 쓸모가 있습니다. 전표를 보내기 전에 품목이 실제로 등록돼 있는지, 출하할 창고에 재고가 있는지를 시스템이 먼저 확인할 수 있기 때문입니다.

인증키 발급과 보관은 회사 몫

ERP에 따라서는 API 인증키를 회사의 최고 관리자 계정(마스터 ID)으로만 발급할 수 있습니다. 이런 경우 외주 업체가 스스로 발급받을 수 없고, 회사가 발급해서 넘겨줘야 합니다. 처음에는 테스트용 키로 정상 호출을 확인한 뒤 운영용 키로 바꾸는 순서를 거칩니다.

회사 입장에서 이 구조는 장점입니다. 키의 주인이 회사이므로 업체와 계약이 끝나면 키를 새로 발급해 이전 키를 쓸 수 없게 만들 수 있습니다. 키를 어디에 보관하는지, 누가 볼 수 있는지는 계약 전에 업체에 물어볼 항목입니다. 개인정보와 함께 확인할 내용은 자동화 업체에 맡길 때 확인할 개인정보 항목에 따로 정리했습니다.

키 관리에서 실제로 자주 막히는 지점은 사람입니다. 키를 발급할 수 있는 계정을 가진 사람이 대표 한 명뿐이면 키를 다시 발급해야 할 때마다 대표 일정에 맞춰야 합니다. 발급 담당자와 예비 담당자를 미리 정하고, 키를 바꾸는 순서를 한 장짜리 문서로 받아 두면 담당자가 바뀌어도 연동이 멈추지 않습니다.

TIP인증키를 메신저나 메일 본문으로 주고받지 마세요. 업체가 지정한 보관 장소에 회사 담당자가 직접 입력하게 하고, 입력이 끝나면 대화 기록에서 키를 지웁니다.

판매 저장은 되고 수정·삭제는 안 되는 이유와 대응

판매 수정·삭제 API를 열지 않은 이유를 설명한 공식 자료는 찾지 못했습니다. 확실한 것은 결과입니다. 시스템이 잘못된 품목코드나 단가로 전표를 저장하면 되돌리는 일은 경리 담당자에게 돌아옵니다. 해당 전표를 찾아 지우고 다시 입력해야 하고, 이미 재고나 매출 집계에 반영됐다면 확인할 곳이 더 늘어납니다.

대응은 단순합니다. 보내기 전에 걸러내는 것입니다. 시스템은 전표 초안을 만들어 승인 화면에 띄우고, 담당자가 확인 버튼을 누른 전표만 ERP로 보냅니다. 자동화가 빨라지는 지점은 입력 단계이고, 승인은 사람이 쥐고 있는 구조입니다.

보내기 전 검사 항목: 거래처코드, 품목코드, 단가, 창고

승인 화면은 모든 칸을 똑같이 보여주지 않습니다. 틀리기 쉬운 칸을 먼저 검사하고 문제 있는 전표를 위로 올립니다.

필수 항목은 회사마다 다를 수 있습니다. 입력 화면 항목을 회사별로 바꿀 수 있는 ERP도 있기 때문입니다. 연동을 시작할 때 고객사의 판매 입력 화면 설정을 먼저 확인하는 이유입니다.

검사 기준값은 처음부터 정답을 알 수 없습니다. 단가 차이를 몇 %부터 표시할지, 수량이 평소의 몇 배면 표시할지는 첫 2~3주 동안 표시된 전표와 실제로 고친 전표를 비교하며 조정합니다. 표시가 너무 많으면 담당자가 결국 다 넘기게 되고, 너무 적으면 검사가 의미를 잃습니다.

연동을 맡기기 전에 회사가 준비할 것

업체와 처음 이야기할 때 아래 자료가 있으면 범위와 검사 규칙을 빠르게 정할 수 있습니다. 개인정보가 들어 있는 칸은 지우거나 바꿔서 넘깁니다.

이 중 가장 값진 자료는 최근 정정 기록입니다. 품목코드를 잘못 고르는 실수가 많은 회사와 단가를 잘못 넣는 실수가 많은 회사는 검사 화면의 순서가 달라야 하기 때문입니다.

연동 진행 순서

처음부터 운영 데이터에 API로 바로 저장하는 방식은 권하지 않습니다. 아래 순서로 단계마다 확인하고 넘어갑니다.

1. 테스트키로 호출 확인: 인증키 발급 담당자가 테스트용 키를 발급하고, 업체는 판매 전표 몇 건을 테스트 환경에 넣어 필수 항목과 오류 메시지를 확인합니다.
2. 검사 화면만 먼저 운영: 발주서를 읽어 초안을 만들고 승인 화면에 띄우되, 결과는 엑셀로 내려받아 담당자가 ERP의 엑셀 일괄 업로드로 올립니다. 이 기간에 검사 기준을 다듬습니다.
3. 병행 비교: 같은 발주서를 기존 방식과 시스템 초안으로 각각 만들어 차이를 봅니다. 차이가 나는 줄은 매칭표나 검사 규칙 쪽 원인을 찾아 고칩니다.
4. 운영키로 전환: 오류가 드물어지면 운영용 키를 발급받아 승인된 전표만 API로 저장합니다.
5. 전송 기록 점검: 매일 보낸 건수, ERP가 거부한 건수, 사람이 나중에 고친 건수를 남겨 한 달에 한 번 같이 봅니다.

TIP2단계에서 담당자가 엑셀로 직접 올리는 기간을 몇 주라도 거치면, API로 넘어간 뒤에 생기는 오류가 어디서 틀렸는지 훨씬 빨리 드러납니다.

자주 생기는 실패와 대응

연동이 멈추거나 잘못 들어가는 원인은 대체로 정해져 있습니다.

• ERP가 저장을 거부함: 필수 항목이 비었거나 코드가 없을 때입니다. 거부 사유를 그대로 승인 화면에 돌려주고, 담당자가 고친 뒤 다시 보낼 수 있게 합니다.
• 같은 전표가 두 번 들어감: 전송 중 연결이 끊겨 다시 보내면 생길 수 있습니다. 발주서 번호와 줄 번호로 전송 기록을 남기고, 이미 보낸 전표는 다시 보내지 않게 막습니다.
• 새 거래처·새 품목: ERP에 아직 등록되지 않은 코드가 들어오면 승인 불가로 묶어 두고, 등록이 끝난 뒤 다시 검사합니다.
• 판매 입력 화면 설정을 바꿈: 회사가 입력 항목을 추가하거나 필수로 바꾸면 기존 전송이 거부될 수 있습니다. 설정을 바꾸기 전에 업체에 알리는 규칙을 정해 둡니다.
• 담당자 퇴사·키 재발급: 키를 바꿨는데 연동에 반영하지 않으면 그날부터 전송이 멈춥니다. 키 교체 절차 문서가 여기서 쓰입니다.

엑셀 일괄 업로드와 API, 언제 무엇을 쓰나

API 없이도 판매 전표를 한꺼번에 넣는 길이 있습니다. 판매 입력 화면에서 양식을 내려받아 작성하고 붙여넣거나 올리는 엑셀 일괄 업로드 메뉴를 둔 ERP가 있습니다(제품마다 이름이 다릅니다). 올릴 때 오류가 난 줄과 사유를 보여 주는 제품도 있습니다.

엑셀 일괄 업로드는 담당자가 붙여넣고 오류를 보고 저장하는 과정 자체가 승인 단계가 됩니다. 인증키도 필요 없습니다. 처음 도입할 때는 이 방식으로 시작해 매칭과 검사 규칙을 다듬고, 건수가 많아지고 오류가 드물어지면 API 저장으로 넘어가는 순서가 안전합니다.

발주서에서 초안을 만드는 앞 단계는 거래처 발주서를 ERP 판매 전표로 글을, 팩스나 PDF로 오는 발주서는 팩스·PDF 발주서 OCR 글을 참고하시면 됩니다.

가상 사례: 월 전표 1,300건 부품 유통사

가상 사례 아래는 이해를 돕기 위해 만든 예시 회사입니다. 실제 고객 사례가 아닙니다.

직원 80명인 산업용 부품 유통사입니다. 경리 3명이 한 달에 판매 전표 약 1,300건을 ERP에 입력합니다. 손으로 입력하다 생기는 오입력을 월 15건(약 1.2%)으로 가정합니다.

도입 전 오입력은 월말 대사나 거래처 문의로 뒤늦게 발견됩니다. 담당자가 전표를 찾아 지우고 다시 넣는 데 건당 10분이 걸린다고 보면 15건 × 10분 = 월 150분이 정정에 들어갑니다.

진행 첫 3주는 승인 화면에서 초안을 확인한 뒤 엑셀로 내려받아 ERP의 엑셀 일괄 업로드로 올렸습니다. 이 기간에 단가 차이 표시 기준을 두 번 조정했고, 매칭표에 없던 거래처 품명 40여 개를 담당자가 확정했습니다. 오류가 드물어진 뒤 운영용 키를 발급받아 승인된 전표만 API로 저장했습니다.

도입 후 승인 화면이 품목코드 불일치와 단가 차이를 먼저 보여주므로 같은 실수를 ERP로 보내기 전에 잡아냅니다. 검사에 걸린 전표는 보내기 전에 고치면 되니, ERP 안에서 지우고 다시 넣는 월 150분의 정정 작업이 줄어드는 구조입니다.

숫자는 예시입니다. 실제 효과는 오입력이 주로 어디서 생기는지에 따라 달라지므로, 도입 전에 최근 정정 기록을 몇 주 모아 보는 것이 출발점입니다.

승인 화면 설계 체크리스트

• 확인 버튼을 누르기 전에는 ERP에 아무것도 저장되지 않는다
• 문제 있는 전표가 목록 맨 위에 온다
• 원본 발주서와 초안을 한 화면에 나란히 볼 수 있다
• 같은 발주서로 이미 보낸 전표는 다시 보낼 수 없다
• 누가 언제 승인했는지 기록이 남는다
• ERP가 저장을 거부하면 사유를 그대로 보여주고 다시 보낼 수 있다
• 인증키는 회사가 발급하고, 바꾸거나 끊는 방법을 문서로 받아 둔다

루코 웍스 데모와 진단

루코 웍스의 발주서 → ERP 판매 전표 데모에서 확인 필요 줄 표시와 승인 후 입력 흐름을 볼 수 있습니다. 지금 쓰는 판매 입력 양식과 최근 정정 사례를 보여주시면 엑셀 업로드로 시작할지, API까지 갈지 진단에서 함께 정합니다. 승인 화면까지 갖춘 업무 하나의 구축은 300만 원에서 시작하며, 구성은 가격 안내에 적어 두었습니다.