청구서를 AI가 다 읽었는데, 왜 지급은 자동으로 못 할까요?

공급업체 청구서를 AI가 읽었습니다. 거래처명, 품목, 수량, 단가와 합계도 정확합니다. 그런데 회계 담당자는 지급을 승인할 수 없습니다.

발주서에는 100개를 주문했다고 적혀 있고, 창고에는 80개만 입고됐으며, 청구서는 100개분이 왔기 때문입니다.

이때 OCR은 틀리지 않았습니다. 서로 다른 세 기록을 정확히 읽었을 뿐입니다. 이제 필요한 일은 인식이 아니라 판단입니다. 20개가 아직 오지 않은 것인지, 입고 처리가 늦은 것인지, 계약상 전액 선청구가 가능한지 확인해야 합니다.

매입 청구서 자동화의 어려움은 여기서 시작됩니다. 문서를 읽는 속도보다 숫자가 다른 이유를 설명하고, 지급을 멈추고, 해결할 사람에게 넘기는 구조가 더 중요합니다.

청구서만 읽어서는 지급 여부를 알 수 없습니다

물품 구매에는 보통 세 가지 기록이 남습니다.

1. 발주서: 무엇을 몇 개, 얼마에 사기로 했는가
2. 입고·검수 기록: 실제로 무엇을 인수했는가
3. 청구서: 공급업체가 무엇을 얼마로 청구했는가

세 기록을 대조하는 방식을 3-way matching이라고 부릅니다. 발주서에는 약속이, 입고 기록에는 실제 인수가, 청구서에는 지급 요청이 담겨 있습니다. 세 문서가 맞아야 주문하고 받은 만큼 지급할 수 있습니다.

서비스 구매도 원리는 같습니다. 물류 입고증 대신 작업 완료 확인서, 마일스톤 승인이나 담당자의 검수 기록이 필요합니다. 문서 이름보다 중요한 것은 회사가 인수를 인정한 근거입니다.

문서에서 값을 가져온 뒤 청구 수량이 입고 수량과 맞는지 확인하고, 완료·대기·실패 상태에 따라 다음 워크플로로 보내는 구조입니다.[1] 값을 읽었다와 지급 조건을 충족했다는 다른 상태입니다.

금액 차이는 오류 하나로 묶을 수 없습니다

발주 금액과 청구 금액이 다르다고 모두 잘못된 청구서는 아닙니다. 같은 20만 원 차이라도 이유에 따라 다음 행동이 달라집니다.

• 부분 입고: 나머지 물량이 들어올 때까지 기다리거나, 입고분만 먼저 지급합니다.
• 단가 변경: 변경된 견적과 발주 승인이 있는지 확인합니다.
• 운송비·부대비용: 계약상 별도 청구가 가능한 항목인지 봅니다.
• 할인·선급금: 약속한 할인이나 이미 지급한 금액이 반영됐는지 확인합니다.
• 입고 처리 지연: 물건은 도착했지만 창고 기록이 아직 올라오지 않았는지 확인합니다.
• 발주번호 누락: 거래처·품목·금액을 바탕으로 후보 발주서를 찾되, 담당자가 연결을 확정합니다.

모두 금액 불일치로만 표시하면 회계 담당자는 발주서, 창고 기록과 계약서를 다시 찾아야 합니다. 자동화가 문서 입력은 줄였지만 조사 업무는 그대로 남습니다.

예외 화면에는 금액이 다르다는 경고보다 이유를 판단할 근거가 보여야 합니다. 어느 품목의 수량이나 단가가 다른지, 차액은 얼마인지, 현재 입고 대기인지 계약 확인이 필요한지, 누가 다음 행동을 해야 하는지가 함께 나와야 합니다.

AI는 이유를 찾고, 회사 규칙은 지급을 결정합니다

생성형 AI는 형식이 다른 청구서를 읽고, 표기가 다른 거래처명과 품목을 연결하며, 관련 가능성이 높은 발주서를 추천하는 데 유용합니다.

그러나 추천과 결정은 분리해야 합니다. 저는 다음과 같이 역할을 나눕니다.

AI가 운송비 차이로 보입니다라고 설명할 수는 있습니다. 그 운송비를 허용할지는 계약과 회사 정책이 결정합니다. AI가 발주서 후보를 찾을 수는 있지만, 확신이 낮은 연결을 공식 기록으로 확정해서는 안 됩니다.

이 구분은 AI의 역할을 줄이는 것이 아닙니다. 사람이 문서를 찾고 비교하는 시간을 AI가 줄이고, 돈이 나가는 결정은 재현 가능한 규칙과 승인 기록으로 남기는 방식입니다.

자동화율보다 ‘어디서 멈췄는지’가 먼저 보여야 합니다

청구서 상태를 미지급과 지급 완료로만 나누면 담당자는 무엇이 막혔는지 알 수 없습니다. 적어도 다음 단계는 구분해야 합니다.

수신 → 값 추출 → 발주서 연결 → 입고·검수 대조 → 예외 확인 → 지급 승인 → 회계 반영 → 지급 완료

각 단계에는 완료 조건과 담당자가 필요합니다. 입고 수량이 부족하면 대조 단계에서 기다리고, 승인 한도를 넘으면 결재 담당자에게 넘어가며, 회계 반영이 실패하면 실제 송금으로 진행하지 않아야 합니다.

자동화된 거래는 곧바로 확정되지 않고 초안으로 만들어집니다. 줄 단위 차이는 검토 대상으로 표시되고, 승인은 회사가 설정한 기존 워크플로를 따릅니다.[2] 자동화는 단계를 없애는 일이 아니라, 정상 건은 빠르게 통과시키고 예외가 제자리에 멈추게 하는 일에 가깝습니다.

중복과 계좌 변경은 금액 차이보다 먼저 멈춥니다

같은 청구서가 이메일과 공급업체 포털로 각각 들어올 수 있습니다. 전달 과정에서 파일명이 바뀌거나, 취소 후 새 문서가 발행되기도 합니다. 파일명 하나만 비교해서는 중복을 찾기 어렵습니다.

중복 후보는 거래처, 청구서 번호, 금액, 발주번호, 발행일과 원본 파일 정보를 함께 비교해야 합니다. 기존 문서와 무엇이 같은지 보여준 뒤 담당자가 중복·취소·재발행 여부를 구분할 수 있어야 합니다.

공급업체의 입금 계좌가 바뀐 경우는 더 엄격합니다. 청구서나 이메일에 새 계좌가 적혀 있다는 이유만으로 거래처 원장을 바꾸거나 송금해서는 안 됩니다. 기존에 등록한 연락 수단으로 변경 사실을 별도 확인하고, 변경 승인자와 시점을 기록해야 합니다.[3]

작은 금액 차이는 승인된 오차 안에서 통과할 수 있습니다. 반면 거래처 식별, 계좌, 통화처럼 잘못 연결됐을 때 손실이 큰 값은 금액과 관계없이 멈춰야 합니다. 허용 오차를 단일 비율 하나로 설계하면 안 되는 이유입니다.

첫 도입 목표는 자동 지급률이 아닙니다

처음부터 모든 공급업체와 청구서 형식을 자동화하면 실패 원인을 구분하기 어렵습니다. 거래가 반복되고 발주·입고 기록이 비교적 정리된 공급업체 한두 곳부터 시작하는 편이 좋습니다.

시험 자료에는 정상 청구서만 넣지 않습니다.

• 부분 입고와 입고 지연
• 단가 변경과 추가 비용
• 선급금·할인 미반영
• 발주번호 누락
• 중복 제출
• 취소와 재발행
• 계좌 변경 요청
• 서비스 검수 대기

그다음 몇 퍼센트를 자동 지급했는가보다 다음 값을 먼저 봅니다.

• 예외 한 건의 원인을 찾는 데 걸린 시간
• 잘못 연결한 발주서와 거래처 수
• 사람이 수정한 항목과 수정 이유
• 승인 대기 시간이 길어진 단계
• 중복 지급을 실제로 차단했는지
• 담당자가 근거를 보고 같은 결정을 반복할 수 있는지

저라면 첫 단계에서 자동 송금까지 열지 않습니다. AI가 값을 읽고 발주·입고 기록을 대조해 지급 가능한 초안을 만들되, 실제 승인은 사람이 하도록 둡니다. 예외 유형과 회사 규칙이 쌓인 뒤 설명 가능한 정상 건부터 자동 통과 범위를 넓힙니다.

OCR이 끝낸 일과 아직 남은 일을 나눠야 합니다

청구서의 값을 정확히 읽었다면 OCR의 일은 끝났습니다. 그러나 회사가 주문한 것, 실제로 받은 것과 공급업체가 청구한 것이 맞는지 판단하는 일은 남아 있습니다.

매입 청구서 자동화의 핵심은 모든 문서를 곧바로 지급하는 데 있지 않습니다. 정상 건은 빠르게 통과시키고, 다른 건은 이유와 다음 행동을 갖춘 채 정확한 단계에서 멈추게 해야 합니다.

그래서 구축 전에 OCR 정확도만 묻기보다 세 가지를 먼저 정해야 합니다. 어떤 차이를 자동으로 허용할지, 어떤 값이 바뀌면 반드시 멈출지, 멈춘 청구서를 누가 어떤 근거로 해결할지입니다.

이 기준이 정리돼야 AI가 사람의 입력뿐 아니라 조사 시간을 줄일 수 있습니다. 지급 자동화는 청구서를 읽는 기능이 아니라, 회사의 구매·검수·승인 규칙을 운영 가능한 흐름으로 만드는 일입니다.

출처

• [1] https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/auto-vendr-invc-process — Microsoft Learn, Automated vendor invoicing processes overview(2026년 8월 16일 확인)
• [2] https://www.intacct.com/ia/docs/en_US/help_action/Purchasing/Using_Purchasing/Automation/faq-automated-transactions-for-po.htm — Sage Intacct, AP Automation with Purchasing FAQs(2026년 8월 16일 확인)
• [3] https://www.ic3.gov/CrimeInfo/BEC — FBI Internet Crime Complaint Center, Business Email Compromise(2026년 8월 16일 확인)