공급업체가 보낸 청구서를 AI가 읽었습니다. 공급업체명, 품목, 수량, 단가와 합계도 정확히 뽑았습니다. 그런데 회계 담당자는 지급을 승인하지 못합니다.
발주서에는 100개를 주문했다고 되어 있지만 입고 기록에는 80개만 들어왔고, 청구서에는 100개가 적혀 있기 때문입니다.
이 상황에서 OCR은 실패하지 않았습니다. AI도 문서를 틀리게 읽지 않았습니다. 문제는 문서 세 장이 서로 다른 말을 하고 있다는 데 있습니다.
매입 청구서 자동화가 어려운 지점은 입력이 아니라 판단입니다. 청구서를 읽는 기술보다 왜 금액이 다른지, 지금 지급해도 되는지, 누가 예외를 승인할지를 설계하는 데 더 많은 운영 지식이 필요합니다.
청구서 한 장만 보면 지급 가능 여부를 알 수 없습니다
매입 업무에는 보통 세 가지 기록이 등장합니다.
- 발주서(PO): 무엇을 얼마에 사기로 약속했는가
- 입고 기록 또는 검수 기록: 무엇이 입고·검수됐는가
- 공급업체 청구서: 공급업체가 무엇을 얼마로 청구했는가
세 기록을 비교하는 것을 일반적으로 3-way matching이라고 부릅니다. Microsoft Dynamics 365의 매입 청구서 매칭 문서도 공급업체 청구서, 발주서와 제품 입고 정보를 대조하는 과정으로 설명합니다. Oracle Payables 역시 청구서 검증 과정에서 2-way, 3-way와 4-way matching을 구분합니다.
물건을 구매하는 회사라면 입고 기록이 기준이 될 수 있습니다. 서비스 계약이라면 입고증 대신 작업 완료 확인, 검수 승인, 마일스톤이나 작업시간 기록이 필요합니다. 문서 이름보다 중요한 기준은 회사가 인수를 인정한 근거가 있는지입니다.
금액이 다른 이유를 먼저 분류해야 합니다
금액 불일치는 모두 오류가 아닙니다. 정상적인 업무에서도 여러 이유로 숫자가 달라집니다.
일부만 입고됐습니다
100개를 발주했지만 80개가 먼저 들어오고 나머지 20개가 다음 주에 올 수 있습니다. 공급업체가 100개 전체를 먼저 청구했는지, 입고분만 청구하기로 했는지 계약과 지급 조건을 봐야 합니다.
자동화 시스템에는 부분 입고, 미입고, 초과 입고가 서로 다른 상태로 존재해야 합니다. 수량이 다르다는 이유만으로 같은 오류 코드에 넣으면 담당자가 원인을 다시 조사해야 합니다.
단가 외 비용이 붙었습니다
발주 단가에는 없던 운송비, 포장비나 별도 비용이 청구서에 포함될 수 있습니다. 반대로 약속한 할인이나 선지급 공제가 빠졌을 수도 있습니다.
AI는 추가 비용의 이름과 위치를 찾아줄 수 있습니다. 그 비용이 허용되는지는 계약, 발주 조건과 회사 정책이 결정해야 합니다.
청구 시점이 먼저 왔습니다
공급업체 청구서는 도착했지만 입고나 검수 처리가 아직 끝나지 않았을 수 있습니다. 이때 자동화가 바로 지급 오류를 선언하면 정상 청구서가 예외로 쌓입니다.
청구서 수신과 지급 가능 사이에 입고 대기, 검수 대기와 담당자 확인 상태가 필요합니다. 기다려야 하는 문서와 잘못된 문서를 구분해야 예외 대기열이 정리됩니다.
발주번호가 없거나 잘못 적혔습니다
공급업체가 발주번호를 누락하거나 예전 번호를 적는 경우가 있습니다. AI가 공급업체, 품목, 금액과 날짜를 보고 후보 발주서를 추천할 수는 있습니다. 그러나 확신이 낮은 연결을 자동 확정하면 다른 발주 건에 청구서를 붙일 위험이 있습니다.
후보를 찾는 일과 공식 기록을 연결하는 일은 분리해야 합니다.
허용 오차는 AI가 정하는 값이 아닙니다
소수점 반올림이나 작은 운송비처럼 회사가 허용할 수 있는 차이가 있습니다. 모든 차이를 사람이 확인하면 자동화의 의미가 줄어듭니다. 반대로 차이가 작다는 이유로 전부 통과시키면 반복적인 과청구를 놓칠 수 있습니다.
허용 오차는 한 개의 비율로 끝내기 어렵습니다.
- 공급업체별 계약 조건
- 품목별 단가 민감도
- 수량과 금액 중 어느 값이 다른지
- 운송비·세금·할인 같은 차이의 유형
- 같은 공급업체에서 같은 예외가 반복되는지
- 최종 지급을 승인하는 담당자의 권한
공급업체와 계좌번호, 통화, 발주번호처럼 잘못 연결되면 피해가 큰 값은 금액 차이가 작아도 자동 통과시키면 안 됩니다. 반올림처럼 설명 가능한 차이는 승인된 범위 안에서 자동 처리할 수 있습니다.
AI는 예외 사유를 설명할 수 있지만, 회사가 감수할 오차를 대신 결정할 수는 없습니다.
중복 청구는 파일 이름으로 찾을 수 없습니다
같은 청구서가 이메일과 공급업체 포털로 각각 들어오거나, 담당자가 다시 전달할 수 있습니다. 파일 이름이 달라도 동일한 청구일 수 있습니다.
중복 여부를 확인할 때는 여러 단서를 함께 봅니다.
- 공급업체 ID
- 청구서 번호
- 청구일과 금액
- 연결된 발주번호
- 원본 파일의 해시
- 이메일 Message-ID와 수신 경로
- 이미 처리된 취소·재발행 문서인지 여부
청구서 번호가 같다고 곧바로 중복이라고 단정할 수도 없습니다. 공급업체가 번호 체계를 바꿨거나 취소 후 다시 발행한 문서일 수 있습니다. 시스템은 중복 의심 상태를 만들고 기존 문서와 비교할 근거를 함께 보여줘야 합니다.
AI가 맡을 일과 규칙이 맡을 일을 나눕니다
매입 청구서 자동화에서 AI가 잘할 수 있는 일은 다음과 같습니다.
- 서로 다른 형식의 청구서에서 필드 추출
- 공급업체명과 품목 설명의 표기 차이 해석
- 연결 가능성이 높은 발주서 추천
- 불일치 사유 분류와 담당자용 요약
- 원문에서 판단 근거가 있는 위치 표시
반면 다음 업무는 명시적인 규칙과 권한으로 처리하는 편이 안전합니다.
- 수량·단가·합계 계산
- 허용 오차 판정
- 승인 한도와 결재 순서
- 공급업체 계좌 변경
- 중복 지급 차단
- 회계 상태 변경과 실제 송금
특히 계좌 변경 요청은 청구서나 이메일 내용만 믿고 자동 반영하면 안 됩니다. 회사가 정한 별도 확인 절차와 승인자가 필요합니다.
예외 대기열에는 ‘틀렸다’보다 다음 행동이 보여야 합니다
좋지 않은 예외 화면에는 빨간색 오류와 청구서 원본만 나옵니다. 담당자는 발주서와 입고 기록을 다시 찾아 원인을 조사해야 합니다.
좋은 예외 대기열은 다음 정보를 한 화면에 모읍니다.
- 청구서 원본과 AI가 읽은 값
- 발주서·입고 기록의 비교 값
- 일치한 항목과 다른 항목
- 예상되는 불일치 사유
- 금액 차이와 지급 영향
- 확인해야 할 담당자
- 승인, 반려, 입고 대기, 공급업체 문의 같은 다음 행동
- 누가 어떤 값을 수정했는지 보여주는 이력
자동화의 성과는 사람이 예외를 보지 않게 만드는 것이 아닙니다. 사람이 예외를 봤을 때 조사 시간을 줄이고, 같은 판단을 반복 가능하게 만드는 것입니다.
처리 상태를 지급 여부 하나로 줄이지 않습니다
청구서가 들어온 뒤의 상태를 미지급과 지급 완료로만 나누면 무엇이 막혔는지 알 수 없습니다.
다음과 같이 처리 단계를 분리할 수 있습니다.
수신 → 값 추출 → 발주서 후보 연결 → 입고·검수 대조 → 예외 검토 → 지급 승인 → 회계 반영 → 지급 완료
각 단계에는 담당자와 완료 조건이 있어야 합니다. 지급 승인이 끝났더라도 회계 반영이 실패할 수 있고, 회계에 반영됐더라도 송금이 완료되지 않을 수 있습니다. 상태를 나누면 AI 에이전트가 임의로 다음 단계까지 건너뛰는 것도 막을 수 있습니다.
작은 범위에서 예외 유형부터 수집합니다
처음부터 모든 공급업체와 모든 문서 형식을 자동화하면 예외의 종류를 파악하기 어렵습니다. 형식과 발주 흐름이 비교적 일정한 공급업체나 품목군 하나를 고르는 편이 낫습니다.
최근 청구서를 정상 건만 모으지 말고 다음 사례를 함께 포함합니다.
- 부분 입고
- 단가 변경
- 추가 비용
- 발주번호 누락
- 중복 제출
- 취소와 재발행
- 서비스 검수 대기
그다음 자동 통과율만 보지 말고 사람의 수정 횟수, 예외가 대기한 시간, 잘못 연결된 발주서, 중복 지급 차단과 공급업체 문의 횟수를 함께 봅니다.
AI 정확도가 높아도 지급 판단에 필요한 예외를 놓치면 운영 자동화로 보기 어렵습니다.
주문 입력과 매입 청구서 자동화는 서로 반대편에 있습니다
이전에 쓴 AI가 주문서를 읽었다고 바로 ERP에 넣으면 안 됩니다는 고객이 보낸 주문서를 회사의 매출 주문으로 확정하는 문제를 다뤘습니다.
이번 문제는 반대편입니다. 회사가 공급업체에게 주문한 내용과 입고·검수된 내용, 공급업체가 요구한 금액을 비교해 돈을 지급할지 결정합니다.
두 업무 모두 문서를 읽는 AI로 시작하지만, 끝에는 다른 책임이 있습니다. 고객 주문 입력은 잘못된 출고와 매출 약속을 막아야 하고, 매입 청구서 자동화는 잘못된 비용과 중복 지급을 막아야 합니다.
OCR은 시작점입니다. 운영 자동화는 문서가 서로 다를 때 멈추고, 이유를 보여주며, 올바른 사람에게 다음 행동을 넘길 때 완성됩니다.
MOSH는 발주서, 입고 기록과 청구서가 현재 어디에서 만들어지고 어떤 예외를 사람이 처리하는지부터 살펴봅니다. 매입 청구서 자동화를 검토하고 있다면 최근 정상 청구서뿐 아니라 지급이 멈췄던 사례의 처리 흐름도 함께 정리해 보내주세요.
참고한 공개 자료
#매입자동화 #청구서AI #AccountsPayable #3WayMatching #ERP자동화