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

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

IFOL의 2025년 지급 계정 자동화 동향 보고서는 약 200명의 AP 및 재무 전문가를 대상으로 조사했으며, 이 중 78%가 지급 계정 부서에서 직접 근무하고 있습니다. 그 결과는 일반적인 통념과 맞지 않습니다.

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

한편, Vic.ai의 2025 AI 모멘텀 보고서에 따르면 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%의 송장에 예외 처리가 필요합니다 — 구매 주문 번호 누락, 금액 오류, 형식 이상, 중복 제출 등이 그 원인입니다. 수동 프로세스에서는 이러한 예외가 흐름의 일부일 뿐입니다. 하지만 자동화된 프로세스에서는 장애물이 됩니다.

자동화 시스템이 예외를 감지합니다. 처리를 중단합니다. 알림을 생성합니다. 그리고... 사람이 개입해야 합니다. 원본 PDF를 열고, 플래그가 지정된 데이터와 비교합니다. 공급업체에 이메일을 보냅니다. 응답을 기다립니다. 수정된 데이터를 다시 입력합니다. 승인을 위해 다시 라우팅합니다. 각 예외를 해결하는 데 15~30분이 소요될 수 있습니다.

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

이것이 반자동화의 함정입니다. 기업은 자동화에 투자해 쉬운 80%를 줄이고, 나머지 20%가 원래 100%보다 더 어렵다는 사실을 깨닫습니다. 예외가 업무 흐름의 리듬을 깨기 때문입니다. 팀이 하는 일이 줄어드는 것이 아니라, 더 파편화되고 컨텍스트 전환이 잦은 업무가 늘어납니다. Vic.ai는 이를 "여전히 사람 손으로 처리되는 AP 자동화의 마지막 단계"라고 부릅니다.

템플릿 기반 OCR이 한계에 부딪히는 이유와 그 돌파구

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

템플릿 시스템은 좌표를 봅니다. "인보이스 번호가 페이지 어디에 있지?"라고 묻습니다. 답은 공급업체마다 다릅니다. 비전 언어 모델(VLM)은 의미를 봅니다. "이 페이지에서 인보이스 번호 역할을 하는 것은 무엇이지?"라고 묻습니다. 답은 그것이 어디에 있든 동일합니다.

이는 미미한 개선이 아닙니다. 완전히 다른 범주입니다. VLM 기반 시스템에 "인보이스 번호", "공급업체명", "마감일", "총액"을 추출하라고 지시하면, 예상 위치에서 해당 단어를 찾는 것이 아니라 사람처럼 문서를 읽습니다. "INV-2025-08472"가 "Invoice #", "Reference", 또는 "Document No."라는 레이블 옆에 있으면, 페이지 내 위치와 관계없이 그것이 인보이스 번호임을 이해합니다.

이로부터 세 가지 시사점이 직접 도출됩니다:

1. 만들거나 유지할 템플릿이 없습니다. 새 거래처의 송장도 10년째 거래해 온 거래처의 송장과 동일한 방식으로 처리됩니다. 시스템이 각 문서를 새롭게 읽어들이며, 그 구조를 독립적으로 이해합니다.

2. 서식이 변경되어도 파이프라인이 중단되지 않습니다. 공급업체가 송장 레이아웃을 재설계해도 VLM은 위치가 아닌 의미적 역할로 필드를 찾습니다. 업데이트할 필요가 전혀 없습니다.

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

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

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

이를 숫자로 구체화해 보겠습니다. 월 3,000건의 송장을 300개 거래처에서 처리하는 중견기업 AP팀의 경우:

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

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