한 구매 상황을 가정해 보겠습니다. 발주서에는 100개를 주문했다고 적혀 있습니다. ERP의 입고 기록은 80개이고, 공급업체가 보낸 청구서는 100개입니다. AI는 세 문서의 숫자를 모두 정확히 읽었습니다.

그런데 지급은 멈춥니다. 나머지 20개가 아직 도착하지 않은 것인지, 이미 도착했지만 창고가 기록하지 않은 것인지, 계약상 먼저 청구할 수 있는 물량인지 알 수 없기 때문입니다. 회계 담당자는 결국 창고와 구매 담당자에게 연락해 사실부터 다시 찾습니다.

이 장면에서 부족한 것은 더 좋은 청구서 AI가 아닙니다. 회사가 실제로 무엇을 받았는지 제때 남긴 기록입니다.

AI가 모르는 것은 청구서 밖에 있습니다

PO 기반 구매에서는 발주서, 입고 기록, 청구서를 대조하는 3-way matching을 사용할 수 있습니다. 발주서는 무엇을 얼마에 사기로 했는지, 입고 기록은 무엇을 실제로 받았는지, 청구서는 공급업체가 무엇의 대금을 요청하는지 보여 줍니다.[1]

세 숫자를 맞추면 차이는 찾을 수 있습니다. 하지만 대조 결과가 100 대 80이라고 해서 남은 20개의 행방까지 밝혀지는 것은 아닙니다. 대조 시스템은 기록 사이의 차이를 발견했을 뿐, 창고에서 일어난 사실이나 계약의 예외를 새로 만들지 못합니다.

모든 매입 청구서가 세 문서를 필요로 하는 것도 아닙니다. 발주서 없이 처리하는 비용이 있을 수 있고, 회사 정책에 따라 2-way matching이나 다른 승인 절차를 쓸 수 있습니다. 서비스 구매에는 물류 입고증 대신 작업 완료 확인, 마일스톤 승인 또는 검수 기록이 필요합니다. 문서 이름은 달라도 질문은 같습니다.

우리 회사는 이 상품이나 서비스를 받았다고 무엇으로 확정합니까?

이 답이 없다면 AI가 청구서를 완벽하게 읽어도 지급 근거는 완성되지 않습니다.

미입고와 미기록은 전혀 다른 문제입니다

100개 중 80개만 실제로 왔다면 구매 담당자는 잔여 납품 일정을 공급업체와 확인해야 합니다. 100개가 모두 왔지만 ERP에는 80개만 등록됐다면 창고 또는 검수 담당자가 원본 기록을 바로잡아야 합니다. 계약상 100개 선청구가 허용됐다면 구매 조건을 근거로 예외를 승인해야 합니다.

세 경우 모두 화면에 보이는 숫자는 같습니다. 해결할 사람과 다음 행동은 완전히 다릅니다.

SAP S/4HANA의 청구서 지급 보류 안내는 발주·입고 기록과 청구가 다르면 구매 부서, 입고 부서 또는 공급업체에 연락해 원인을 확인하도록 설명합니다. 설정된 허용 범위를 넘은 청구서는 회계 문서에 반영돼도 지급이 보류될 수 있고, 그 사이 공급업체의 현금 할인 기간이 지나갈 수도 있습니다.[2]

지급이 멈춘 것 자체는 자동화 실패가 아닙니다. 근거 없는 지급을 막는 통제가 작동한 결과일 수 있습니다. 문제는 그다음입니다. 회계팀은 물건을 받지 않았고, 납품 조건을 합의하지도 않았습니다. 그런데 모든 차이가 회계팀의 받은편지함으로 모이면, 회계 담당자가 회사 곳곳을 돌아다니며 원본 사실을 복원해야 합니다.

AI가 관련 발주서와 대화를 찾아 주고, 입고 기록 누락 가능성을 제안할 수는 있습니다. 그래도 20개를 실제로 받았다고 확정할 권한은 입고·검수 책임자에게 있어야 합니다. 지급 자동화는 경고를 띄우는 데서 끝나는 것이 아니라, 사실을 바꿀 수 있는 사람에게 근거와 기한이 붙은 일로 넘겨야 이어집니다.

저라면 지급 자동화보다 인수 기록부터 만듭니다

입고·검수 기록이 며칠씩 늦거나 자주 빠지는 회사라면 자동 지급 프로젝트부터 시작하지 않겠습니다. AI를 붙이면 정상 청구서가 빨라지는 대신, 근거가 없는 청구서가 더 빠르게 보류 목록에 쌓일 가능성이 큽니다.

먼저 한 공급업체의 한 구매 흐름에서 인수 사실을 남기는 순간을 정합니다. 물건이라면 검수 완료 시점에 수량과 담당자를 기록하고, 서비스라면 완료 산출물이나 마일스톤을 누가 승인했는지 남깁니다. 수정이 생기면 원래 기록을 덮는 데서 끝내지 않고 무엇이 왜 바뀌었는지 연결합니다.

그다음에 AI가 청구서를 읽고 이 기록들과 연결하게 합니다. 기록이 모두 있고, 이미 지급한 선급금이나 별도 정산 조건까지 확인됐으며, 회사의 허용 범위 안에 있는 건은 지급 가능 상태까지 자동으로 보낼 수 있습니다. 인수 기록이 없거나 늦었다면 AI가 수량을 추측하지 않고, 사실 확인 담당자에게 확인을 요청해야 합니다. 답이 오면 그 근거가 청구서 예외와 함께 남아야 합니다.

ServiceNow의 Accounts Payable Operations 문서는 AI 에이전트를 반복적인 청구 문의 대응과 non-PO 청구서의 비즈니스 오너 추천에 배치합니다.[3] 다만 제품이 비즈니스 오너를 추천할 수 있다는 사실과, 회사가 실제 책임자를 정해 둔 것은 다릅니다. 시스템을 사기 전에 인수 사실의 소유자를 먼저 정해야 합니다.

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

처음부터 청구서 몇 퍼센트를 자동 처리했는가만 보면 정상 건의 속도 뒤에 오래 묵은 예외가 가려집니다. 저는 먼저 네 가지를 보겠습니다. 청구서가 도착했을 때 발주·인수 기록이 이미 연결된 비율, 실제 인수부터 기록까지 걸린 시간, 나중에 수량이나 검수 결과가 수정된 건수, 멈춘 청구서가 사실 확인 담당자에게 넘어가 사실이 확정되기까지 걸린 시간입니다.

이 값이 안정돼야 자동 처리 범위를 넓힐 수 있습니다. 입고 기록이 계속 늦는데 AI가 정상으로 분류하는 비율만 높다면, 자동화가 아니라 근거 없는 통과에 가까워집니다. 반대로 차이를 정확히 멈추고 사실 확인 담당자가 빠르게 사실을 확정한다면 보류 건도 제대로 설계된 자동화의 일부입니다.

청구서 AI는 존재하는 기록을 빠르게 읽고 연결할 수 있습니다. 회사가 남기지 않은 인수 사실까지 책임질 수는 없습니다. 그래서 매입 자동화의 첫 버튼은 지급이 아니라 입고·검수 확인이어야 합니다.

출처

  • 매입자동화
  • 청구서AI
  • AccountsPayable
  • 3WayMatching
  • ERP자동화