AP 팀의 66%가 여전히 송장을 수동으로 입력합니다.
그 비율은 줄어들지 않고 오히려 늘고 있습니다.

AP 팀의 66%가 여전히 수작업으로 송장을 입력합니다. 그 비율은 줄어들지 않고 오히려 늘고 있습니다.

IFOL Accounts Payable Automation Trends 2025 보고서는 약 200명의 AP 및 재무 전문가를 대상으로 조사했으며, 이 중 78%가 지급 계정(AP) 업무를 직접 담당하고 있습니다. 그 결과는 일반적인 통념과 맞지 않습니다.

66%는 여전히 송장 데이터를 ERP 또는 재무 시스템에 수작업으로 입력합니다 — 2023년의 60%에서 증가한 수치입니다. 63%는 송장 처리에 주당 10시간 이상을 소비하며, 이는 2024년의 52%에서 늘어난 것입니다. 재무 팀의 73%는 완전히 자동화되지 않았고, 27%는 자동화를 전혀 도입하지 않았습니다.

한편, Vic.ai의 2025 AI Momentum Report에 따르면 AP 전문가의 37%가 여전히 수동 데이터 입력을 가장 큰 골칫거리로 꼽았습니다 — 높은 처리 비용, 느린 승인 프로세스, 그리고 다른 모든 운영상의 문제보다 앞선 수치입니다.

이것은 진보에 대한 이야기가 아닙니다. 겉으로는 해결된 것처럼 보이지만 실제로는 그렇지 않은 문제에 대한 이야기입니다. 자동화 도구는 이미 존재합니다. ROI 사례도 명확합니다. 그렇다면 왜 수동 입력 비율이 증가하고 있을까요?

그 답은 "기업들이 아직 도구를 구매하지 않았기 때문"이 아닙니다. 대부분의 기업이 구매한 도구가 근본적인 문제를 해결하지 못하기 때문입니다. 그리고 근본적인 문제는 데이터 입력이 느리다는 것이 아니라, 모든 송장이 서로 다른 형식으로 도착하며 템플릿 기반 자동화가 바로 그 지점에서 한계에 부딪힌다는 것입니다.

"수동 데이터 입력"이 실제로 매일 어떻게 이루어지는지

AP 업무를 담당하고 있다면 이 섹션은 필요 없을 것입니다. 하지만 CFO, 창업자, 또는 자동화 예산을 승인하면서 문제가 해결되었다고 생각하는 사람이라면 — 이것이 실제로 여러분의 팀이 하고 있는 일입니다.

송장이 공유 받은 편지함에 PDF 첨부 파일로 도착합니다. 누군가 그것을 엽니다. 벤더명, 송장 번호, 송장 일자, 납기일, 품목, 소계, 세금, 합계를 읽습니다. 그 모든 필드를 NetSuite에 입력합니다. 또는 SAP, QuickBooks에 입력합니다. 송장을 구매 주문서와 대조합니다 — 수작업으로, 눈으로 직접 확인하며. 이메일로 승인을 요청합니다. 그런 다음 3일 동안 응답하지 않은 승인자를 찾아다닙니다.

이제 그 작업을 200건에 곱해 보세요. 또는 1,500건, 5,000건 — IFOL 응답자의 36%가 매월 처리하는 물량입니다.

Reddit의 r/Accounting에 게시한 한 AP 전문가는 이렇게 솔직하게 설명했습니다: "저희는 공급업체로부터 매달 약 1,500~2,000건의 송장을 받습니다. AP 자동화가 이제 사실상 해결되었다는 이야기를 계속 듣지만, 저희 프로세스는 여전히: 송장이 PDF 첨부 파일로 공유 받은 편지함에 도착하고, 누군가 각각을 열어 헤더 정보를 NetSuite에 입력하고, PO와 수동으로 대조하고, 이메일로 승인을 요청하고, 무시하는 승인자를 찾아다닙니다. NetSuite에 내장된 OCR 기능을 시도해 봤지만 모든 기계 공장과 원자재 공급업체가 서로 다른 형식으로 송장을 보내기 때문에 송장의 절반은 제대로 인식하지 못합니다."

이 게시물은 200개 이상의 추천과 같은 경험을 공유하는 수십 개의 댓글을 받았습니다. 이들은 소규모 기업이 아닙니다. 매달 수백에서 수천 건의 송장을 처리하는 중견 제조업체, 유통업체, 서비스 기업이며 — 입력 작업을 하는 사람은 데이터 입력 사무원이 아니라 훈련된 회계사입니다.

Ardent Partners의 2025년 연구에 따르면 수동 처리 송장 1건당 비용은 $15.97이며, 최고 수준의 자동화 처리는 $2.36에 불과합니다. 매달 3,000건의 송장을 처리하는 기업의 경우 연간 $490,000의 격차가 발생합니다 — 오류 비용, 지연 납부, 조기 결제 할인 기회 손실은 포함하지 않은 수치입니다.

형식 문제: 모든 벤더 송장이 템플릿을 깨뜨리는 이유

모든 송장이 하나의 표준 레이아웃을 따른다면 템플릿 기반 OCR이 10년 전에 이 문제를 해결했을 것입니다. 하지만 현실은 그렇지 않습니다. 그리고 앞으로도 그럴 일은 없습니다.

독일의 한 벤더는 하단에 세금 내역을 배치합니다. 텍사스의 한 공급업체는 품목 오른쪽 열에 세금을 표시합니다. 싱가포르의 한 계약업체는 세금을 아예 표시하지 않습니다 — 단가에 포함되어 있습니다. 동네 기계 공방은 여백에 손으로 적은 메모가 있는 스캔 PDF를 보냅니다. 또 다른 업체는 책상 위 종이 송장을 휴대폰으로 찍은 사진을 이메일로 보냅니다.

이러한 모든 형식 차이는 템플릿 기반 자동화를 무너뜨립니다. 템플릿 OCR은 알려진 레이아웃에서 필드 위치를 기억하는 방식으로 작동합니다. "송장 번호는 좌표 X,Y에 있습니다. 합계는 좌표 A,B에 있습니다." 벤더가 송장 템플릿을 변경하거나 새 벤더가 추가되는 순간, 그 좌표는 더 이상 유효하지 않게 됩니다.

이것은 예외적인 경우가 아닙니다. 이것이 기본입니다. 중견기업은 평균적으로 200~500개의 서로 다른 공급업체로부터 송장을 받습니다, 각각 고유한 레이아웃을 사용합니다. ERP 시스템, 회계 패키지, 수직 SaaS 도구는 개발자가 선택한 형식으로 송장을 생성합니다 — AP 팀이 통제할 수 있는 형식이 아닙니다.

그리고 상황은 더 악화됩니다. 벤더가 송장 형식을 변경합니다. 공급업체가 청구 시스템을 업그레이드합니다. 레스토랑 체인이 템플릿을 재설계합니다. 프리랜서가 송장 앱을 다른 앱으로 전환합니다. 각 변경은 지난달까지 작동하던 템플릿을 조용히 깨뜨립니다. AP 팀은 데이터가 잘못 나왔을 때 — 또는 몇 주 동안 같은 필드를 수동으로 수정하고 있었다는 것을 알아차렸을 때 — 문제를 발견합니다.

템플릿 함정: "더 많은 자동화"가 더 많은 유지보수를 의미할 때

대부분의 자동화 공급업체가 알려주지 않는 구조적 역설이 있습니다.

템플릿 기반 송장 처리는 벤더 수에 비례하여 확장됩니다. 새 공급업체가 추가될 때마다 새 템플릿을 만들고 테스트하고 유지해야 합니다. 벤더가 20개라면 템플릿도 20개입니다. 관리 가능합니다. 벤더가 200개라면 — 중견 제조업체나 유통업체에게는 일반적인 규모입니다 — 템플릿도 200개입니다. 벤더가 형식을 변경할 때마다 각 템플릿을 업데이트해야 하는데, 벤더는 정기적으로 알리지 않고 형식을 바꿉니다.

Infrrd의 송장 파싱 자동화 분석은 단호하게 말합니다: "템플릿 기반 시스템에 새 벤더를 추가할 때마다 단 한 장의 송장도 정확히 처리되기 전에 구성 작업이 필요합니다. 공급업체 수가 늘어나거나 온보딩이 빠르게 진행되면 템플릿 백로그가 병목 현상이 됩니다. 팀은 송장을 처리하는 것보다 템플릿을 관리하는 데 더 많은 시간을 보내게 됩니다 — 이는 자동화가 달성해야 하는 목표와 정반대입니다."

규모가 커지면 계산이 뒤집힙니다. 템플릿 200개를 유지하는 데 정규직 1명이 필요하고 송장 3,000장을 수동으로 입력하는 데 2명이 필요하다면, 자동화한 것이 아닙니다 — 데이터 입력 노동을 템플릿 유지보수 노동으로 바꿨을 뿐입니다. 비용이 이동했을 뿐 사라지지 않았습니다.

이것이 66%의 팀이 "자동화"를 도입했음에도 여전히 데이터를 수동으로 입력하는 이유입니다. 상위 20개 벤더의 송장 80%를 자동화하는 도구를 구입했지만 — 도구가 파싱할 수 없는 나머지 180개 벤더의 형식은 여전히 수동으로 처리합니다. 도구는 있습니다. 실행 중입니다. 하지만 대부분의 작업은 여전히 사람의 손에 달려 있습니다.

예외 스파이럴: 송장의 20%가 시간의 80%를 차지합니다

부분적으로 자동화된 AP 부서에서도 거의 측정되지 않는 작업 범주가 있습니다: 예외 처리입니다.

2025 State of ePayables 보고서에 따르면 약 22%의 송장에 예외 처리가 필요합니다 — PO 번호 누락, 잘못된 금액, 형식 이상, 중복 제출 등이 그 예입니다. 수동 프로세스에서 이러한 예외는 흐름의 일부일 뿐입니다. 자동화된 프로세스에서는 장애물이 됩니다.

자동화는 예외를 플래그합니다. 처리를 중지합니다. 알림을 생성합니다. 그리고... 사람이 개입해야 합니다. 원본 PDF를 엽니다. 플래그된 데이터와 비교합니다. 벤더에게 이메일을 보냅니다. 응답을 기다립니다. 수정된 데이터를 다시 입력합니다. 승인을 위해 다시 라우팅합니다. 각 예외를 해결하는 데 15~30분이 걸릴 수 있습니다.

이제 계산해 보겠습니다: 월 3,000건의 송장 × 22% 예외율 = 660건의 예외. 각 20분씩이면 220시간 — 풀타임 직원의 월간 업무량을 초과하는 시간 — 이 예외 처리에만 소요됩니다. 그리고 이는 자동화가 이미 송장을 "처리"한 이후의 이야기입니다.

이것이 반자동화의 함정입니다. 기업은 자동화에 투자하고, 쉬운 80%를 줄이며, 나머지 20%가 원래 100%보다 더 어렵다는 것을 발견합니다. 예외가 워크플로 리듬을 깨뜨리기 때문입니다. 팀이 하는 일이 줄어드는 것이 아니라, 더 파편화되고 컨텍스트 전환이 잦은 작업을 더 많이 하게 됩니다. Vic.ai는 이를 "여전히 수작업으로 처리되는 AP 자동화의 마지막 마일"이라고 부릅니다.

템플릿 기반 OCR이 한계에 부딪히는 이유 — 그리고 이를 넘어서는 방법

앞의 세 섹션은 하나의 근본 문제를 설명합니다: 형식 의존성. 템플릿 OCR, 규칙 기반 추출, 전통적인 머신러닝 모델은 모두 동일한 한계를 공유합니다 — 데이터가 어디에 있는지 알아야 하지, 무엇인지 알 필요는 없습니다.

템플릿 시스템은 좌표를 봅니다. "송장 번호가 페이지의 어디에 있나요?"라고 묻습니다. 답은 벤더마다 다릅니다. 비전 언어 모델(VLM)은 의미론을 봅니다. "이 페이지에서 송장 번호로 기능하는 것은 무엇인가요?"라고 묻습니다. 답은 위치와 관계없이 동일합니다.

이것은 미미한 개선이 아닙니다. 범주의 차이입니다. VLM 기반 시스템에 "송장 번호", "벤더명", "납기일", "합계"를 추출하라고 지시하면, 예상 위치에서 해당 단어를 스캔하지 않습니다 — 사람이 읽는 방식으로 문서를 읽어 "Invoice #" 또는 "Reference" 또는 "Document No."라는 라벨 옆의 "INV-2025-08472"가 페이지의 어느 위치에 있든 송장 번호임을 이해합니다.

여기서 세 가지 시사점이 직접 도출됩니다:

1. 구축하거나 유지할 템플릿이 없습니다. 새 벤더의 송장은 10년 동안 거래해 온 벤더의 송장과 동일한 방식으로 처리됩니다. 시스템은 각 문서를 새롭게 읽고 구조를 독립적으로 이해합니다.

2. 형식 변경이 파이프라인을 깨뜨리지 않습니다. 공급업체가 송장 레이아웃을 재설계해도 VLM은 위치가 아닌 의미론적 역할로 필드를 찾습니다. 아무것도 업데이트할 필요가 없습니다.

3. 벤더 간 데이터가 하나의 통합 테이블에 저장됩니다. 원하는 열 이름을 정의하면 — "벤더명", "송장 일자", "라인 설명", "수량", "단가", "합계" — 모든 송장이 원래 레이아웃과 관계없이 해당 열로 데이터를 출력합니다. 하나의 스프레드시트, 모든 벤더, 템플릿 유지보수 불필요.

이것은 이론이 아닙니다. "데이터가 어디에 있는가"(템플릿 OCR)에서 "이 데이터가 무엇을 의미하는가"(VLM)로의 아키텍처 전환은 형식 문제를 규모 있게 해결 가능하게 만드는 요소입니다.

AI 추출로 전환하면 실제로 무엇이 달라지나요

숫자로 구체적으로 살펴보겠습니다. 월 3,000장의 송장을 300개 벤더로부터 처리하는 중견 AP 팀을 기준으로:

VLM 측 워크플로는 간단합니다: 송장을 업로드하고(드래그 앤 드롭, 폴더에서 일괄 업로드, 또는 벤더가 직접 제출할 수 있는 수집 링크 공유), 추출할 열 이름을 지정한 다음, 모든 데이터가 병합된 단일 Excel 파일을 다운로드하세요. Google Sheets를 사용하는 경우, 애드온을 통해 스프레드시트를 벗어나지 않고도 작업할 수 있습니다 — 추출된 데이터가 활성 시트에 직접 추가됩니다.

추출 이상의 기능이 필요한 팀을 위해, 계산 열을 사용하면 추출 중 실행되는 계산을 정의할 수 있습니다. 수량 × 단가로 라인 항목 합계가 필요하신가요? 청구된 합계가 라인 항목 합계와 일치하지 않는 송장을 표시하고 싶으신가요? 계산을 한 번 정의하면 AI가 모든 송장에 자동으로 적용합니다. 일괄 처리 워크플로에 대한 자세한 내용은 여러 PDF에서 하나의 Excel 시트로 송장 데이터를 일괄 추출하는 가이드를 참조하세요.