AP팀에 수천 달러의 손실을 안기는
중복 송장 탐지의 5가지 허점
IOFM의 벤치마킹 연구에 따르면 내부 통제가 약한 조직은 총 지급 현금 흐름의 약 1.5%를 중복 지급으로 손실을 봅니다. 연간 AP 지출이 500만 달러인 기업의 경우, 이는 75,000달러에 달하며 한 번이 아니라 매년 발생합니다. 그런데 AP 담당자에게 중복을 어떻게 잡는지 물어보면, 대답은 거의 항상 "송장 번호 열에 VLOOKUP 함수를 실행합니다"로 시작합니다. 이 두 문장 사이의 간극이 바로 이 글의 주제입니다.
핵심 요점
- 매년 AP팀에 수천 달러의 손실을 안기는 중복은 복사본처럼 보이지 않습니다. 다른 채널, 다른 달에 다른 송장 번호로 도착합니다.
- 송장 번호 열에 대한 VLOOKUP 함수는 실제 중복 5건 중 4건을 놓칩니다. 한 번에 한 필드만 한 달치 데이터와 비교하기 때문입니다.
- ImageToTable.ai로 모든 송장에서 4개 필드를 추출하고 3개 이상 일치하는 행을 플래그 처리하세요. 수동 검토가 500건에서 15건의 후보로 줄어듭니다.
중복 송장이 대기열에 들어오는 4가지 경로 — 그중 3가지는 눈치채지 못할 것입니다
모든 기사가 시작하는 평범한 "데이터 입력 오류" 범주는 건너뛰겠습니다. 오타가 문제를 일으킨다는 것은 이미 아실 것입니다. 실제로 비용이 드는 중복은 표면적으로 충분히 다르게 보여서 기존의 모든 검사를 통과하지만, 그 아래에는 동일한 의무를 나타내는 것들입니다.
1. "이미 지불했습니다" 재전송
공급업체가 송장을 보냅니다. AP 팀이 처리하고 지불을 예약하며 모든 것이 정상입니다. 3주 후, 공급업체가 동일한 송장을 다시 보냅니다 — 이번에는 "2차 통지" 또는 "독촉장"으로 표시되어 있습니다. 이를 여는 AP 담당자는 원본을 처리한 사람이 아닙니다. 그들은 이를 인식하지 못합니다. 송장 번호는 동일하지만 독촉장의 날짜는 3주 더 최신이므로 날짜 필터 검색으로는 찾을 수 없습니다. 송장이 다시 입력되고 지불이 두 번 나갑니다.
이는 드문 일이 아닙니다. 월 200건 이상의 송장을 처리하는 기업에서 가장 흔한 중복 발생 원인이며, 공급업체의 AR 시스템과 귀사의 AP 시스템 간에 연계가 없기 때문에 발생합니다. 공급업체는 귀사가 지불을 예약했는지 알지 못합니다. 그들의 자동 독촉 주기는 30일이 지나면 무조건 작동합니다.
2. 이중 채널 충돌
동일한 송장, 두 가지 전달 채널. 공급업체가 PDF를 [email protected]으로 이메일로 보내면서 동시에 동일한 송장을 EDI를 통해 ERP의 전자 수신 시스템으로 전송합니다. 이메일 첨부 파일은 수동 처리 대기열에 들어가고, EDI 전송은 시스템에 레코드를 자동 생성합니다. 두 명의 다른 담당자, 두 개의 다른 처리 경로, 하나의 근본적인 의무 — 그리고 두 대기열이 서로 다른 시스템에 있기 때문에 그 사이에 교차 검증이 없습니다.
이 문제는 기업이 현대화할수록 나아지는 것이 아니라 악화됩니다. 공급업체 송장 제출을 위해 여는 채널(이메일, 포털, EDI, 종이 우편)이 많을수록 동일한 송장이 두 번 들어올 수 있는 진입점이 더 많아집니다. PDF와 구조화된 송장 형식이 공존하는 하이브리드 환경은 특히 취약합니다. 구조화된 채널(EDI/XML)은 사람의 검토 없이 바로 통과되는 반면, PDF 사본은 담당자의 받은 편지함에 남아 수동 입력을 기다리기 때문입니다.
3. 원본과 수정본의 이중 입력
공급업체가 인보이스 #4521에 오류가 있음을 발견하고 수정 버전(인보이스 #4521-C, 동일 금액, 수정된 라인 항목)을 발행합니다. AP 담당자는 두 건을 모두 받습니다. 원본은 2주 전에 도착했고 이미 입력되었습니다. 수정 버전은 지금 도착합니다. 담당자는 "-C" 접미사를 보고 수정본임을 이해한 뒤 그것도 입력합니다. 하지만 아무도 원본 입력을 취소하지 않습니다. 인보이스 두 건, 지급 두 건, 의무는 하나입니다.
올바른 처리: 수정 인보이스가 도착하면 새 항목을 입력하기 전에 원본을 역분개해야 합니다. 실제 상황: 대부분의 중견기업 AP 워크플로우에는 원본과 수정 버전 간의 자동 연결이 없습니다. "-C" 접미사는 ERP 시스템이 해석하지 않는 인간의 관례일 뿐입니다. 담당자가 원본을 수동으로 취소하는 것을 잊거나, 다른 담당자가 원본을 처리했다면 중복 지급이 그대로 진행됩니다.
4. 월간 반복 중복
반복 서비스에 대한 인보이스가 2월 요금으로 3월에 도착합니다. 동일한 인보이스(동일한 PO(발주서) 참조, 동일 금액)가 4월에 다시 도착합니다. 공급업체가 청구 시스템을 이전하면서 미결 인보이스를 모두 새 번호로 재발행했기 때문입니다. 3월 입력은 3월 원장에 남아 있습니다. 4월 입력은 새로운 거래입니다. 인보이스 번호 열에 VLOOKUP 함수를 적용하면 번호가 다르므로 일치 항목이 없습니다. 금액에 VLOOKUP 함수를 적용하면 정확히 일치하지만, 해당 공급업체의 다른 모든 월간 반복 인보이스도 마찬가지입니다.
월간 중복은 수동으로 잡아내기 가장 어렵습니다. AP 업무의 자연스러운 리듬을 활용하기 때문입니다. 각 월의 배치가 독립적으로 처리됩니다. 특별히 해당 확인을 트리거하는 요소가 없다면 아무도 이번 달 인보이스를 지난달 지급 원장과 비교하지 않습니다. 그리고 그 트리거(중복 지급이 은행에서 결제되는 것)는 두 번째 입력 후 30~60일 후에 도착하는 경우가 많습니다.
위 모든 시나리오의 공통 패턴: 중복은 동일하게 보이지 않습니다. 인보이스 번호, 날짜, 채널, 월이 모두 다릅니다. 중복 확인은 복제본을 찾고 있습니다. 실제 위협은 유사 복제본이며, 그대로 통과합니다.
스프레드시트 중복 확인이 계속 실패하는 이유 — 5가지 구체적 실패 유형
수동 중복 확인 시스템을 구축했다면 — 대부분의 AP 팀이 그렇듯 — 아마 이런 형태일 것입니다: 모든 송장이 입력된 공유 Excel 파일이나 Google Sheet, 그리고 주기적으로 VLOOKUP 함수나 조건부 서식 규칙을 실행해 송장 번호가 두 번 이상 나타나는 행을 강조 표시하는 방식입니다. 올바른 접근 방식입니다. 하지만 대부분의 중복을 놓치고 있습니다. 정확히 어디서 문제가 발생하는지 설명하겠습니다.
실패 유형 1: 송장 번호 형식 불일치
공급업체 A는 "INV-004521"을 사용합니다. 공급업체 B는 "4521"을 사용합니다. 공급업체 C는 "INV4521-2026-03"을 사용합니다. "INV-004521"을 매칭하는 VLOOKUP 함수는 "4521"을 찾지 못합니다 — 두 값이 동일한 문서를 나타내더라도 말입니다. 더 심각한 것은, 같은 공급업체도 자체 형식을 다르게 사용할 수 있다는 점입니다: PDF 헤더에는 "INV-4521", 이메일 제목에는 "4521", EDI 피드에는 "INV4521"처럼 말입니다. AP 담당자가 가장 먼저 보이는 값에서 송장 번호를 복사한다면, 같은 송장이 세 가지 다른 식별자로 스프레드시트에 입력되고 중복 확인은 세 개의 서로 다른 레코드로 인식합니다.
실패 유형 2: 공급업체 이름 변형
"Acme Industrial Supply Inc." 대 "Acme Industrial Supply" 대 "Acme Ind Supply." 단일 공급업체의 송장 내에서도 헤더의 법인명이 지급 지시서의 송금처 이름과 다를 수 있습니다. 공급업체 이름에 대한 VLOOKUP 함수는 일치 항목을 반환하지 않지만, 실제 공급업체는 동일합니다. APQC 벤치마크는 공급업체 마스터 파일 관리 부실을 중복 지급의 주요 원인으로 지적합니다: 동일한 공급업체가 여러 레코드로 존재할 때, 특정 공급업체 ID로 범위가 제한된 중복 확인은 다른 항목을 절대 감지하지 못합니다.
실패 유형 3: 일치해야 할 금액 — 하지만 정확히 일치하지 않는 경우
송장 #4521의 합계는 $1,247.50입니다. 수정된 버전 — 수정된 라인 항목이 포함된 송장 #4521-C — 의 합계는 $1,247.53입니다. 3센트 차이입니다. 금액 열에 대한 VLOOKUP 함수는 일치 항목을 반환하지 않습니다. 두 송장은 0.002% 이내의 오차로 동일한 채무를 나타내지만, 수식은 두 송장을 완전히 무관한 것으로 처리합니다. 이는 세금 조정, 반올림 차이, 총액을 몇 센트씩 변경하는 부분 크레딧 적용으로 인해 끊임없이 발생합니다.
실패 4: PO 참조 불일치
PO 번호를 대조해 중복을 확인합니다. 그리고 그것은 작동하다가, 어느 순간 실패합니다. 공급업체가 동일한 PO에 대해 두 장의 인보이스를 보내는 경우가 있습니다. PO가 두 번의 별도 배송을 포함했기 때문입니다. 둘 다 정당합니다. 중복은 해당 PO에 대한 세 번째 인보이스입니다. 첫 번째 인보이스의 재발행본이며, 동일한 PO 참조를 공유합니다. PO 기반 확인은 세 건 모두를 잠재적 중복으로 표시하고, 실제 중복 하나만 분리하는 대신 모든 라인에 대해 수동 검토를 강제합니다. PO 매칭은 너무 많이 감지하는 동시에 너무 적게 감지합니다.
실패 5: 시간적 사각지대
중복 확인은 이번 달 데이터에 대해서만 실행됩니다. 지난달 지급 원장, 지난 분기 마감 배치, 작년 보관 파일은 확인하지 않습니다. 월 경계를 넘는 중복(3월 원본, 4월 반복)은 보이지 않습니다. 대부분의 팀은 분기별 은행 조정 때까지 이를 발견하지 못하며, 그 시점에는 자금이 이미 60일 이상 지출된 상태입니다. 60일 후 중복 지급을 회수하는 것은 기하급수적으로 어렵습니다. 공급업체가 이미 자체 원장에 적용했을 수 있고, ACH 반제 기간이 종료되었으며, 대화는 "환불 요청"에서 "크레딧 메모 협상"으로 바뀝니다.
이 다섯 가지 실패는 공통된 근본 원인을 공유합니다: 스프레드시트 중복 확인은 한 번에 하나의 열을 한 번에 하나의 데이터 배치와 비교합니다. 실제 중복은 다중 기간 데이터에 대한 다중 필드 비교(인보이스 번호, 공급업체, 금액, PO)가 필요합니다. 단일 VLOOKUP 함수 열로는 이를 수행할 수 없으며, 어떤 수식 중첩으로도 아키텍처를 수정할 수 없습니다.
기존 시스템과 함께 작동하는 4개 필드 감지 레이어
좋은 소식: 이 문제를 해결하기 위해 AP 자동화 플랫폼을 구매할 필요가 없습니다. 필요한 것은 현재 보유하지 않은 하나의 기능 — 모든 인보이스에서 네 개의 필드를 안정적으로 추출하는 능력 — 과 비용이 들지 않는 하나의 프로세스 변경입니다.
네 개의 필드는 다음과 같습니다: 인보이스 번호, 공급업체 이름, 총 금액, PO(발주서) 번호. 단일 필드의 정확한 일치가 아닌, 네 개의 필드를 함께 비교하여 네 개 중 세 개가 일치하면 검토 플래그가 트리거됩니다.
감지 로직은 다음과 같습니다:
- 추출 — PDF, 스캔본, 종이 인보이스 사진, 이메일 첨부 파일 등 모든 수신 인보이스에서 네 개의 필드를 추출합니다.
- 추가 — 각 인보이스의 네 개 필드를 마스터 스프레드시트(Google Sheets 또는 Excel, 팀에서 이미 사용 중인 도구)에 새 행으로 추가합니다.
- 플래그 — 네 개 필드 중 세 개 이상이 기존 행과 일치하는 행에 플래그를 지정합니다. 조건부 서식을 사용하여 일치하는 행을 노란색으로 강조하고 수동 검토 대상으로 표시합니다.
- 플래그된 행만 검토 — 나머지, 즉 플래그가 트리거되지 않는 95% 이상의 인보이스는 중복 확인 없이 승인으로 바로 진행됩니다.
단일 필드 일치가 실패할 때 3/4 일치가 작동하는 이유는 다음과 같습니다:
- 인보이스 번호 형식이 다양한 경우 → 공급업체 이름과 금액이 일치하면 → 플래그 지정.
- 공급업체 이름이 일관되지 않은 경우 → 인보이스 번호와 금액이 일치하면 → 플래그 지정.
- 금액이 3센트 차이 나는 경우(수정된 인보이스) → 인보이스 번호(부분), 공급업체 이름, PO(발주서) 번호가 일치하면 → 플래그 지정.
- 다른 인보이스 번호로 월을 걸쳐 반복되는 경우 → 공급업체 이름, 금액, PO(발주서) 번호가 일치하면 → 플래그 지정 — 스프레드시트에 지난달 및 이전 분기의 행이 포함되어 있는 경우에 한합니다.
세 개 일치 기준은 의도적입니다. 두 개 일치(동일 공급업체, 동일 금액)는 모든 월간 반복 인보이스를 오탐으로 플래그 지정합니다. 네 개 일치는 정확한 복제본만 포착하는데, 이는 가장 쉽게 포착되면서도 가장 드문 경우입니다. 3/4 일치는 골디락스 존입니다: 유사 복제본을 포착할 만큼 민감하면서도 검토자를 노이즈로 압도하지 않을 만큼 정확합니다.
물론 병목 지점은 1단계입니다. 매주 수십~수백 개의 인보이스 PDF에서 네 개의 필드를 안정적으로 추출하는 것입니다. 수동으로 입력하는 것이 바로 데이터 입력 오류의 근본 원인입니다.
이것이 AI 추출이 판도를 바꾸는 지점입니다. 각 PDF를 열고 네 개의 필드를 입력하는 대신, 인보이스 배치를 업로드하고 원하는 네 개의 열 이름(인보이스 번호, 공급업체 이름, 총 금액, PO(발주서) 번호)을 지정하면 됩니다. AI가 각 문서를 읽고 페이지 내 위치와 관계없이 해당 값을 찾아 인보이스당 한 행씩 구조화된 테이블로 출력합니다. 이 테이블을 마스터 스프레드시트에 복사하면 조건부 서식이 나머지를 처리합니다.
워크플로를 대체하는 것이 아닙니다. 이미 수행 중인 단계 앞에 추출 단계 하나를 삽입하는 것입니다. ERP, 승인 라우팅, 지불 일정 — 모두 변경되지 않습니다. 변경되는 것은 인보이스당 10분을 입력에, 5분을 VLOOKUP 함수 실행에 사용하던 AP 담당자가 이제 인보이스당 10초를 추출에, 30초를 플래그된 행 검토에 사용한다는 것입니다. 나머지는 자동화됩니다.
직접 사용해 보세요 — 샘플 인보이스를 업로드하고 네 개의 필드가 몇 초 안에 추출되는지 확인하세요:
파일은 안전하게 처리되며 저장되지 않습니다.
이 접근 방식이 효과적인 이유는 AP 담당자보다 똑똑해지려고 하지 않기 때문입니다. 문서를 읽고 필드를 입력하는 반복적인 부분을 자동화하고, "이것이 실제로 중복인지, 아니면 정당한 두 번째 송장인지"와 같은 판단이 필요한 부분은 공급업체 관계를 이해하는 담당자에게 그대로 맡깁니다. 송장 승인 자동화 프레임워크에서 논의했듯이, 가장 효과적인 자동화 전략은 워크플로를 대체하지 않습니다. 워크플로에 입력되는 데이터 준비 단계를 대체합니다.
알고리즘이 사용자에게 판단을 위임해야 하는 경우
3/4 매칭은 의심스러운 행을 표시합니다. 알고리즘이 할 수 없는 것 — 그리고 시도해서도 안 되는 것 — 은 최종 판단을 내리는 것입니다. 자동 감지가 패턴을 올바르게 식별하지만 해석에는 인간의 판단이 필요한 경계 사례는 다음과 같습니다.
3센트의 차이
인보이스 #4521: $1,247.50. 인보이스 #4521-C: $1,247.53. 세 개의 필드가 일치하지만 금액이 $0.03 차이가 납니다. 플래그가 지정되었습니다.
이것은 거의 확실히 중복이지만, "거의"라는 표현만으로는 지급을 취소하기에 충분하지 않습니다. 3센트의 차이는 세금 반올림 조정으로 인해 수정된 버전이 정당한 대체 인보이스일 수 있습니다. 원본이 EUR로 견적되었고 수정된 버전이 약간 다른 환율로 재환산된 경우 통화 변환 변동일 수도 있습니다. 알고리즘의 역할은 해당 쌍을 표면화하는 것입니다. 담당자의 역할은 공급업체가 원본을 대체하려는 의도가 있었는지 확인하고, 그렇다면 수정 사항을 처리하기 전에 원본 항목을 무효화하는 것입니다. 의도를 확인할 수 없다면, 공급업체에 60초간의 전화나 이메일로 해결할 수 있습니다.
하나의 PO에 대한 여러 정당한 인보이스
건설 자재 공급업체가 PO #7842에 대해 세 차례에 걸쳐 자재를 배송합니다. 각 배송은 별도의 인보이스(#INV-112, #INV-113, #INV-114)를 생성합니다. 동일한 공급업체, 동일한 PO, 다른 인보이스 번호, 다른 금액. 4개 중 3개 일치 규칙은 모든 쌍에서 공급업체와 PO가 일치하므로 모두 플래그를 지정합니다. 그러나 세 개 모두 정당합니다.
이것은 가장 흔한 오탐(false positive) 시나리오이며, 4개 필드 접근 방식이 자동 차단 대신 조건부 서식과 수동 검토를 사용하는 이유입니다. 알고리즘은 패턴을 강조합니다. 담당자는 이를 정당한 분할 배송으로 인식하고 2초 만에 플래그를 해제합니다. 여러 인보이스가 있는 PO를 자동 차단하도록 규칙을 구성했다면, 세 건의 정당한 지급을 보류하고 세 명의 공급업체에 전화를 걸어 이유를 설명해야 했을 것입니다.
인보이스 번호 형식을 변경한 공급업체
공급업체가 ERP를 마이그레이션합니다. 기존 인보이스 형식은 "ACME-YYMM-####"였습니다. 새 형식은 순차적인 8자리 숫자 "00004521"입니다. 새 시스템의 첫 번째 인보이스가 월간 반복 청구로 도착합니다. 동일한 공급업체, 동일한 금액, 동일한 PO — 그러나 인보이스 번호 형식을 알아볼 수 없습니다. 4개 중 3개 일치 규칙은 다른 세 필드가 일치하므로 이를 포착합니다. 이러한 교차 확인이 없으면 스프레드시트는 새 인보이스 번호를 보고 통과시킵니다.
이 시나리오는 유럽 전역에 시행되는 전자 인보이스 의무화와 함께 특히 위험합니다. 공급업체가 Peppol 네트워크를 통해 PDF에서 구조화된 XML 형식으로 전환함에 따라 인보이스 번호 체계가 자주 변경됩니다 — 때로는 규정에 따라(예: 프랑스의 공백 없는 고유 순차 번호 요구 사항) 변경됩니다. 인보이스 번호 일치에만 의존하는 AP 팀은 지난달 PDF 버전과 동일한 반복 의무를 나타내는 경우에도 이러한 형식 전환 인보이스를 새 레코드로 취급합니다.
통화 및 환율 미묘한 차이
해외 공급업체가 EUR로 인보이스를 발행합니다. 귀사 시스템은 처리일의 환율로 USD 환산 금액을 기록합니다. 동일한 인보이스가 다시 도착하는 경우가 있습니다. 예를 들어 다른 채널을 통해 들어와 다른 날짜에 처리되면서 환율이 약간 달라질 수 있습니다. USD 금액은 몇 달러 차이가 납니다. 공급업체 이름은 일치합니다. PO(발주서)도 일치합니다. 인보이스 번호도 일치합니다. 금액은 근접하지만 정확히 같지는 않습니다.
알고리즘은 이를 플래그로 표시해야 하며, 실제로 표시합니다. 세 필드가 정확히 일치하기 때문입니다. 담당자의 검토를 통해 서로 다른 환율로 두 번 처리된 동일한 EUR 인보이스임을 확인합니다. 두 번째 항목을 취소합니다. 다중 필드 검사가 없었다면 USD 금액 차이로 인해 단일 필드 비교에서는 서로 다른 인보이스로 판단했을 것입니다.
원칙: 자동 감지는 분류 도구이지 결정 엔진이 아닙니다. 그 역할은 500개의 인보이스를 15개의 검토 후보로 줄이는 것입니다. 각 후보에 대한 최종 판단에는 공급업체 이력, 계약 조건, 납품 일정 등 인보이스 필드가 아닌 담당자의 판단과 이메일에 있는 맥락이 필요합니다.
이것이 인보이스 필드를 스프레드시트로 추출하는 것이 블랙박스 AP 플랫폼에 감지 로직을 내장하는 것보다 더 실용적인 이유이기도 합니다. 데이터를 직접 보고, 어떤 세 필드가 일치했는지 확인할 수 있으며, 플래그가 지정된 행 바로 위에 원본 행이 표시되므로 해당 공급업체에 대해 알고 있는 모든 정보를 바탕으로 몇 초 만에 판단을 내릴 수 있습니다.
자주 묻는 질문
중복 감지와 3자 매칭의 차이점은 무엇인가요?
3자 매칭은 인보이스가 구매 주문서 및 입고 확인서와 일치하는지 검증하여 주문하고 수령한 항목에 대해 지불하는지 확인합니다. 중복 감지는 이 인보이스에 대해 이미 지불했는지 여부를 묻습니다. 이들은 서로 다른 위험을 방지합니다. 공급업체는 3자 매칭을 통과하는 완벽하게 일치하는 인보이스를 보낼 수 있으며, 3주 후에 다시 보내도 PO(발주서)와 입고 확인서가 변경되지 않았기 때문에 다시 통과할 수 있습니다. 3자 매칭은 무엇을 확인합니다. 중복 감지는 몇 번을 확인합니다.
제 ERP가 이 작업을 자동으로 처리할 수 있나요?
대부분의 중간 규모 ERP(QuickBooks, Xero, NetSuite)는 동일한 공급업체 레코드 내에서 정확한 송장 번호 일치 여부를 확인하는 기본적인 중복 감지 기능을 갖추고 있습니다. QuickBooks는 동일한 공급업체와 송장 번호 조합이 이미 존재하는 경우 송장에 플래그를 지정합니다. 이는 정확한 중복(동일한 번호로 두 번 입력된 동일한 송장)만 포착하며, 앞서 논의한 다른 모든 경우(형식 변형, 채널 간 제출, 원본+수정본 쌍, 번호가 다른 월간 반복)는 놓칩니다. 중복 문제가 정확한 번호 일치에 국한된 경우라면 ERP가 이미 해결해 드립니다. 이 글을 읽고 계시다면 아마 그렇지 않을 것입니다.
팀이 이 작업을 수행할 가치가 생기려면 몇 장의 송장을 처리해야 하나요?
계산은 간단합니다. 월 200장의 송장을 처리하고, 추정 중복률이 0.5%(자동화된 통제 장치가 없는 팀에게는 보수적인 수치)라면 월 1건의 중복이 발생합니다. 회사의 평균 송장 가치가 $800 이상이라면, 월 1건의 중복만으로도 추출 시간을 몇 배로 보상받을 수 있습니다. 수동으로 VLOOKUP 함수를 실행하는 데 드는 직원 시간을 고려하기 전의 이야기입니다. 월 50장 미만이라면 모든 송장을 수동으로 검토하는 것이 자동화된 워크플로우를 구축하는 것보다 여전히 빠를 것입니다. 50~200장 사이에서는 추출 및 플래그 지정 방식이 볼륨이 증가함에 따라 점점 더 가치가 높아집니다.
공급업체가 동일한 송장을 두 가지 통화로 보내면 어떻게 하나요?
3/4 일치 방식은 통화 변환을 자동으로 처리하지 않지만, 해결 방법은 간단합니다. 추출 필드에 다섯 번째 필드인 통화(Currency)를 추가하세요. 송장 번호, 공급업체 이름, PO(발주서)가 일치하지만 통화 필드가 다르면 시스템은 이를 검토가 필요한 잠재적 중복으로 처리합니다. 대부분의 국제 공급업체는 단일 통화로 송장을 발행하므로 이 엣지 케이스는 드물지만, 발생했을 때 통화 필드가 이를 포착할지 놓칠지를 결정합니다.
반복 구독 청구서에도 적용되나요?
이것이 가장 까다로운 범주입니다. 매달 같은 공급업체, 같은 금액, 같은 PO(발주서)가 있는 SaaS 구독은 매 주기마다 3/4 일치를 유발하여 노이즈를 만들 수 있습니다. 해결책: 스프레드시트에 반복 플래그 필드를 추가하세요. 반복으로 표시한 공급업체의 경우, 청구서 날짜가 예상 청구 주기 내에 있으면(예: 같은 달, 같은 금액, 같은 공급업체 = 예상된 반복 청구이지 중복이 아님) 중복 플래그를 억제합니다. 이렇게 하면 반복 청구서를 검토 대기열에서 제외하면서도 같은 공급업체의 비반복 중복 감지는 유지할 수 있습니다.
전자송장이 중복 감지를 어떻게 바꾸나요?
전자송장 의무화 — 프랑스의 2026년 요구사항, 독일의 단계적 도입, 그리고 더 넓은 Peppol 네트워크 프레임워크 — 는 각 송장에 정부 등록 고유 식별자를 부여하여 일부 중복 위험을 줄입니다. 그러나 문제를 완전히 제거하지는 않습니다. 공급업체는 여전히 원본을 대체하는 수정 전자송장을 보낼 수 있습니다. PDF 사본은 특히 아직 의무 대상이 아닌 소규모 공급업체에서 구조화된 XML 버전과 함께 도착할 수 있습니다. 그리고 한 국가는 의무화가 있고 다른 국가는 없는 국가 간 송장은 앞서 설명한 것과 정확히 같은 2채널 충돌 시나리오를 만듭니다. 규정 준수 프레임워크는 세무 당국의 중복 버전을 포착합니다. AP 팀은 여전히 자체 중복을 포착해야 합니다.