공급업체 목록에 200개의 이름이 있지만
실제 공급업체는 약 120개

통합 마감일과 아무도 쓸 수 없는 목록의 만남

재무팀의 공급업체 목록은 누가 돈을 받았는지 알려줍니다. 하지만 실제로 누구에게서 구매하고 있는지는 거의 알려주지 못합니다. 공급업체 지출 통합은 바로 그 두 번째 질문에 달려 있는데, 공급업체별 지출을 합산하려고 하면 같은 회사의 두 행이 이름조차 일치하지 않는다는 사실을 발견하기 전까지는 이 두 질문이 같은 것처럼 보입니다.

데이터 자체는 충분히 완전합니다. 문제는 키(key)가 신뢰할 수 없다는 것이며, 모든 통합 질문은 그 키의 하위에 있습니다.

총 지출 기준으로 공급업체 순위를 매기려면 안정적인 이름이 필요합니다. 세 팀이 동일한 프로젝트 관리 소프트웨어 비용을 지불하고 있는지 파악하려면 안정적인 이름이 필요합니다. 협상된 요율이 실제로 적용되고 있는지 확인하려면 안정적인 이름이 필요합니다. 키가 구매할 때마다 다른 사람이 다른 날짜에 입력한 이름이라면, 이러한 질문 중 어느 것도 답할 수 없으며, 당신이 만들려던 협상력은 결코 현실화되지 않습니다.

이 문제를 잘못 처리했을 때의 비용은 추상적이지 않습니다. APQC의 Open Standards Benchmarking에 따르면 중간 수준 조직의 중복 또는 오류 지급액이 연간 지출액의 1.5%에 달하며, 최상위 조직도 여전히 0.8%에 머물고 있습니다 (APQC). APQC는 마스터 공급업체 파일의 낮은 품질 데이터를 핵심 원인 중 하나로 지목합니다 (이것은 당신이 처음부터 구축하려는 목록과 동일한 유형입니다). 지출액이 1,000만 달러인 회사는 더 나은 공급업체 가시성이 있었다면 막을 수 있었던 수십만 달러 규모의 누수를 보고 있는 셈입니다.

기록이 실제로 존재하는 위치

구매 시스템이 없는 회사에서 공급업체 기록은 한 곳에 있지 않습니다. 공급업체를 각각 다르게 명명하는 네 가지 출처에 분산되어 있습니다.

따라서 통합 작업은 "공급업체 마스터 정리"가 아닙니다. 공급업체 마스터 자체가 없습니다. 작업은 먼저 원시 기록에서 마스터를 구축한 다음, 모두가 당연히 시작했을 것이라고 생각하는 이름 매칭 작업을 시작하는 것입니다.

한 공급업체가 네 가지 이름으로 표시되는 네 가지 이유

공급업체 이름 변동에는 기계적 원인이 있으며, 이를 알면 어떤 변형을 안전하게 병합할 수 있고 어떤 변형에 사람의 판단이 필요한지 알 수 있습니다.

이름을 관리하는 주체가 없었습니다. 분산 구매 환경에서는 비용을 신고하는 직원이 입력할 내용을 선택합니다. 한 직원은 "Acme Supply"라고 쓰고, 다음 직원은 "ACME SUPPLY LLC"라고 쓰며, 세 번째 직원은 "Acme"라고 씁니다. Excel에서 조건부 서식이나 COUNTIF로 수행하는 정확히 일치하는 중복 제거는 두 문자열이 동일한 경우가 없기 때문에 거의 아무것도 찾아내지 못합니다.

카드 설명자가 잘리고 인코딩됩니다. 카드 네트워크는 가맹점 설명자(일반적으로 22자로 제한)를 제한하고, 프로세서는 자체 태그를 접두사로 추가합니다. Amazon에서 구매한 내역은 명세서에 AMZN MKTP US로 표시되고, Square를 통한 결제는 SQ *MERCHANT로 표시될 수 있습니다. 브랜드 이름은 사라지고 코드로 대체됩니다. 동일한 구매에 대한 영수증에는 "Amazon.com"이라고 표시됩니다. 어떤 문자열 유사성 알고리즘도 이 둘을 연결하지 못합니다. 공유하는 문자가 거의 없기 때문입니다.

법적 이름, DBA, 송금처는 서로 다른 세 개의 문자열입니다. 공급업체의 법적 법인은 "Northwind Logistics Holdings LLC"일 수 있고, 상호는 "Northwind"일 수 있으며, 송금처 주소는 팩토링 회사나 결제 프로세서에 속할 수 있습니다. IOFM은 W-9의 DBA 필드가 법적 이름과 다른 송장 이름을 구매자가 일치시킬 수 있도록 하기 위해 정확히 존재한다고 지적합니다(IOFM). 대규모 공급업체는 또한 사업부에서 송장을 발행하므로 동일한 모회사가 동일한 납세자 ID를 가진 세 개의 별도 공급업체로 나타날 수 있습니다.

환급은 수취인이 아닌 지불인을 기록합니다. 직원이 지불하고 환급을 받으면 비용 시스템의 거래는 직원과 연결됩니다. 공급업체는 영수증 이미지에만 나타나거나 영수증이 없는 경우 전혀 나타나지 않을 수 있습니다.

네 가지 메커니즘, 네 가지 이름. 대소문자 차이, 구두점, Inc 대 Incorporated와 같은 접미사를 추가하면 200대 120 비율은 이상값처럼 보이지 않고 기본 결과처럼 보이기 시작합니다.

퍼지 매칭이 해결할 수 있는 것과 없는 것

퍼지 매칭은 일반적인 다음 단계이며, 문제의 일부를 해결합니다. 두 문자열이 동일할 것을 요구하는 대신 얼마나 유사한지를 점수로 매깁니다. 일반적인 측정 방식은 편집 거리(Levenshtein, 점수는 문자 변경 횟수)와 토큰 기반 유사성(Power Query의 퍼지 병합은 Jaccard 유사도 알고리즘을 사용합니다, Microsoft 문서 참조)입니다. 유사도 임계값을 설정하면, 그 이상인 항목은 가능한 일치 항목으로 표시됩니다.

퍼지 매칭은 후보를 생성합니다. 결정을 내리지는 않으며, 선택한 임계값에 따라 놓침 또는 잘못된 병합 중 어떤 오류를 선호할지가 결정됩니다.

임계값이 바로 한계가 드러나는 지점입니다. "ABC Supply Inc."와 "ABC Supply LLC"를 잡기 위해 충분히 낮추면, 토큰을 공유하는 무관한 이름들도 병합하기 시작합니다. Excel University 독자가 그 실패를 정확히 기록했습니다: 0.9 임계값에서 도구는 "Titan"을 "Twitch"와, "SAVE"를 "Pave"와 일치시켰고, Inc./LLC 변형을 잡기 위해 약 0.5로 낮추자 검토할 수 없을 정도로 많은 오탐지가 발생했습니다(Excel University). 이름만으로는 그 트레이드오프를 조정해 빠져나갈 수 없으며, 이것이 프로덕션 중복 제거가 주소, 세금 ID, 은행 정보 또는 거래 패턴과 같은 지원 속성과 이름을 함께 고려하는 이유입니다.

여기서 임계값보다 더 중요한 두 가지 한계가 있습니다. 첫째, 퍼지 매칭은 설명자 코드에 완전히 실패합니다. "AMZN MKTP US"와 "Amazon.com"은 유사한 문자열이 아니기 때문입니다. 둘째, 하나의 상위 회사의 세 부서가 하나의 공급업체인지 세 개인지 결정할 수 없습니다. 이는 하나의 관계로 협상하는지 세 개로 협상하는지에 달려 있으며, 이는 비즈니스 결정이지 문자열 비교가 아닙니다.

이 지점이 중복 지불을 잡는 작업과 다른 점이기도 합니다. 동일한 송장이 두 번 지급되었는지 감지하는 것은 이력과의 비교이며, 이러한 실패 모드는 중복 송장 탐지에서 다룹니다. 지저분하고 분산된 기록에서 깨끗한 공급업체 목록 하나를 만드는 것은 전체 모집단에 대한 그룹화 문제이며, 일관되지 않은 이름에 키를 두는 중복 확인이 놓치게 될 바로 그 쌍을 찾기 위해 설계되었기 때문에, 중복 지급 확인을 신뢰하기 전에 반드시 해결되어야 합니다.

퍼지 매칭과 다른 모든 정리 기법은 한 가지를 전제로 합니다: 모든 기록이 이미 사용 가능한 공급업체 열이 있는 단일 테이블에 있다는 것입니다. 개인 카드 구매가 1년간 지속된 후에는 그렇지 않습니다. 이것이 먼저 고쳐야 할 단계입니다.

1단계: 모든 기록을 동일한 열 형식의 한 시트로 가져오기

이름을 정규화하기 전에 모든 영수증, 청구서, 명세서 항목이 동일한 열 제목 아래 한 곳에 존재해야 합니다. 이는 데이터 추출 작업이며, 다양한 형식의 수십 개 판매처에서 온 사진, 스캔, PDF를 다루기 때문에 문서의 레이아웃에 의존하지 않는 방식으로 처리하는 것이 좋습니다.

ImageToTable.ai는 맞춤 열 추출을 사용합니다. 원하는 열 이름을 입력하면 AI가 필드가 어디에 있는지가 아니라 무엇을 의미하는지 이해하여 페이지 어디에서든 일치하는 값을 찾습니다. 이 작업에 필요한 열 집합은 작고 안정적입니다:

• 공급업체 이름 (문서 또는 설명자에 인쇄된 그대로)
• 거래 날짜(YYYY-MM-DD)
• 금액
• 카드 (구매에 사용된 카드)
• 카테고리 (옵션: 소프트웨어/사무/여행/식비/기타)

이 중 두 열은 겉보기보다 더 많은 역할을 합니다. 도구가 규칙 형식이라고 부르는 날짜 형식 지침은 모든 공급업체의 날짜를 동일한 문자열로 통일하여 정렬과 기간 필터링이 처음부터 제대로 작동하게 합니다. 카테고리 열은 추론 열의 예로, AI가 영수증 내용을 읽고 제공된 옵션에서 선택하여 문서에 인쇄되지 않은 값을 채웁니다. 이렇게 하여 분류가 별도의 단계가 되는 대신 추출과 함께 수행됩니다.

도구는 일괄 우선 처리 방식이므로 전체 폴더를 업로드하면 파일별로가 아닌 병합된 하나의 시트를 얻을 수 있습니다. 여러 페이지에 걸친 카드 명세서는 다중 페이지 병합으로 처리되며, 이 템플릿 설정은 동일한 명세서에 속한 페이지를 단일 레코드로 그룹화하여 계정 수준 정보가 품목 항목에 걸쳐 전달되도록 합니다. 연말 결산 분량을 처리해야 하는 경우에도 동일한 배치 및 병합 흐름이 신용카드 명세서 일괄 처리에서 자세히 다루어집니다.

시작점은 문서 유형에 따라 다릅니다. 대부분이 영수증 사진과 이메일 청구서라면 영수증을 Excel로 변환 워크플로가 가장 빠른 진입점입니다. 월별 명세서 더미라면 신용카드 명세서 추출 페이지에서 시작하세요. 어느 쪽이든 출력은 동일한 형태의 테이블이며,それが 핵심입니다.

출력 결과에서 한 가지 분명한 점은, 그것이 깔끔한 공급업체 목록이 아니라는 것입니다. 추출 과정은 원본에 나타난 공급업체 이름과 함께 모든 레코드를 하나의 테이블로 제공합니다. 이것이 판단 단계의 원자재입니다. 신뢰하기 전에 이러한 이름을 검증하는 것은 쉽습니다. 추출된 셀 위에 마우스를 올리거나 클릭하면 원본 이미지에서 해당 셀이 나온 정확한 위치가 강조 표시되고, 이미지의 영역을 클릭하면 일치하는 셀로 다시 이동하기 때문입니다. 이것이 Bbox 검증이 포함된 검토 모드이며, 이를 통해 이상한 문자열이 실제로 문서에 명시된 내용인지, 아니면 오독인지 확인할 수 있습니다.

2단계: 데이터를 눈앞에 두고 정식 매핑을 직접 구축하기

공급업체 이름 정규화는 판단 작업이며, 솔직한 답은 결정 순서가 명확하도록 추출된 테이블을 정렬한 상태에서 여러분이 직접 수행해야 한다는 것입니다. 총 금액 내림차순으로 정렬하고 상단부터 작업하세요.

각 공급업체에 대해 정식 이름이 무엇인지 결정한 다음, 모든 변형을 두 번째 열에 매핑하세요. 실행 가능한 구조는 세 개의 열입니다: 추출된 원시 Vendor Name, 여러분이 채우는 Vendor (canonical) 열, 그리고 통합한 변형에 대한 별칭 메모입니다. 이렇게 하면 감사를 위해 원래 문자열을 보존하면서 피벗할 수 있는 안정적인 대상을 제공합니다.

목록의 상단은 빠르게 정리됩니다. 8개의 디자인 에이전시는 8개의 정식 이름이 됩니다. 3개의 중복되는 프로젝트 관리 도구는 3개가 되고, 이제 중복을 확인하고 하나를 제거하기로 결정할 수 있습니다. AMZN MKTP US, AMAZON.COM, AMZN Prime으로 읽히는 명세서 줄 무리는 모두 Amazon에 속하지만, AWS는 인프라 지출이며 일반적으로 자체 라인에 속하므로 그룹화 결정은 단순히 "유사한 것은 모두 병합"이 아닙니다. 이러한 구분은 퍼지 매칭이 정확히 할 수 없는 부분이며, 알고리즘의 출력을 수용하는 대신 매핑을 검토해야 하는 이유입니다.

추측 대신 확인을 위해 지원 열을 사용하세요. 두 변형이 동일한 카드, 날짜 범위 및 반복 금액을 공유한다면 동일한 공급업체일 가능성이 매우 높습니다. "Supply"와 같은 토큰만 공유한다면 아마 그렇지 않을 것입니다. 기계 판독 가능한 식별자는 존재할 때 가장 신뢰할 수 있는 증거입니다: 세금 ID 또는 정확한 주소는 이름 유사성 점수보다 우선합니다.

빈 열 대신 시작점을 원한다면, 추론 열이 각 행에 대한 정식 그룹화 또는 정규화된 이름을 제안할 수 있습니다. 초안으로 취급하세요. 의존하기 전에 지출 총액과 대조하여 확인하고, 긴 꼬리는 직접 수정해야 할 것으로 예상하세요. 잘못된 병합(재협상하려는 관계를 숨기는 두 실제 공급업체의 통합)의 결과가 후보를 검토하는 비용보다 더 나쁘기 때문에 판단은 여러분에게 남아 있습니다.

이는 한 공급업체의 인보이스 내 형식 표준화보다 더 좁은 작업이며, 이는 공급업체 인보이스 데이터 표준화에서 별도로 다룹니다. 여기서 형식은 추출 시 이미 처리되었습니다. 여러분이 구축하는 것은 그 위의 ID 계층입니다.

이 접근 방식이 여전히 해결하지 못하는 것

위 단계를 거치면 깔끔한 목록이 만들어집니다. 하지만 판단이 필요 없는 것은 아니며, 자동화가 어디서 멈추는지 분명히 할 필요가 있습니다.

이는 자동 공급업체 마스터 중복 제거 엔진이 아닙니다. 추출은 모든 레코드를 원시 공급업체 이름과 함께 하나의 시트로 가져오지만, 어떤 이름이 동일한 업체인지 결정하지는 않습니다. 그 매핑은 여러분이 정의해야 하며, 도구의 역할은 그 매핑을 빠르게 구축하고 쉽게 검증할 수 있도록 만드는 것입니다.

퍼지 매칭은 설명자 코드와 같은 관련 없는 문자열에서는 여전히 실패하므로, 순수 알고리즘 방식으로는 AMZN MKTP US 유형의 행을 병합하지 못한 채 남겨둡니다. 모회사와 그 자회사가 하나의 공급업체인지 여러 개인지는 기술적 결정이 아니라 비즈니스 결정이며, 어떤 도구도 이를 대신 결정해 주지 않습니다. 또한 환급 기록에 영수증 없이 직원 이름만 있는 경우, 기록에서 공급업체를 복구할 방법이 아예 없을 수도 있습니다. 이러한 경우는 데이터가 아닌 카드 명세서나 직원에게 확인하여 해결해야 합니다.

카드 명세서를 장부와 조정하는 것은 또 다른 작업이며, 개인 카드와 회사 카드를 혼용하면 그 자체로 문제가 발생합니다. 이에 대해서는 신용카드 조정에서 다룹니다. 공급업체 계층을 먼저 올바르게 정리하면 매달 같은 공급업체를 다시 결정하는 일이 없어지므로 조정이 더 쉬워집니다.

공급업체 목록 중복 제거: FAQ

Excel Power Query의 퍼지 매칭을 공급업체 목록에 그냥 사용하면 안 되나요?

사용할 수 있으며 일부 변형은 잡아내겠지만, 이 특정 작업에는 두 가지 맹점이 있습니다. 설명자 코드를 브랜드 이름과 연결할 수 없는데, 이는 유사한 문자열이 아니기 때문입니다. 또한 접미사 변형을 잡아내는 임계값은 관련 없는 이름도 병합하므로 결국 모든 후보를 검토해야 합니다. Power Query는 레코드가 이미 하나의 시트에 있고 후보 목록을 조정할 때 가장 유용하며, 첫 번째이자 유일한 단계로는 적합하지 않습니다.

이 규모의 회사에 전체 공급업체 마스터 시스템이 필요한가요?

100~300명 규모의 회사라면 지출 관리 플랫폼(Ramp, Brex, Expensify, Bill.com)이 구매 시점에 공급업체를 분류하고 중복을 표시하는 카드로 향후 지출을 라우팅하여 지속적인 문제를 해결합니다. Coupa 및 Zip과 같은 도구는 더 큰 조달로 확장됩니다. 그러나 개인 카드로 이미 구매한 기록을 재구성하는 도구는 없습니다. 이 과거 목록은 여전히 문서에서 재구성해야 하며, 이 접근 방식이 처리하는 부분이 바로 이것입니다.

AI가 공급업체 이름을 추출했지만 여전히 일관성이 없습니다. 어떻게 해야 하나요?

예상된 결과입니다. 추출은 소스에 표시된 대로 이름을 재현하며, 소스가 일관성이 없습니다. 다음 단계는 정식 매핑입니다: 지출별로 정렬하고, 변형을 그룹화하고, 실제 공급업체당 하나의 정식 이름을 할당합니다. Vendor (canonical) 열이 있는 추출된 테이블이 결과물이며, 합계를 신뢰할 수 있게 만드는 요소입니다.

직원 이름만 표시되는 환급은 어떻게 처리하나요?

영수증이나 카드 명세서를 공급업체의 진실 원본으로 사용하고, 금액과 날짜로 환급과 연결하세요. 영수증이 없으면 카드 설명자가 대체 수단이며, 코드처럼 보여도 명세서에서 원시 공급업체 문자열을 캡처하는 것이 중요한 이유입니다. 둘 다 없으면 비용은 데이터에서 복구할 수 없으므로 수동으로 추적해야 합니다.

이 목록은 얼마나 자주 재구축해야 하나요?

정식 매핑이 있으면 기존 공급업체의 새 구매가 이미 정의한 이름에 매핑되므로 지속적인 유지 관리가 더 가볍습니다. 새 지출에 대해 추출 및 매핑을 다시 실행하고, 일치하지 않는 이름을 정기적으로 검토하세요. 분기별은 AP 팀이 공급업체 마스터 검토에 일반적으로 사용하는 주기이며, 목록이 변형 더미로 다시 붕괴되는 것을 방지합니다.

공급업체 통합의 병목은 ID 계층이며, 각 레코드가 어떤 공급업체에 속하는지 결정하는 것이 시간이 걸리는 부분입니다. 이 계층이 스프레드시트에 존재하면 지출 순위를 매기고 통합 기회를 찾는 데 몇 분이 걸리며, 존재하지 않으면 목록 위에 구축하는 모든 보고서는 그 아래 이름만큼만 안정적입니다. 비용 문서에서 구조화된 데이터를 추출하는 더 넓은 그림은 비용 보고서 데이터 추출 가이드를 참조하세요. 레코드가 여러 달에 걸쳐 있으면 연말 거래 추출 및 신용 카드 조정 파이프라인이 동일한 추출 테이블이 조정 및 ERP 없는 3자 매칭 후속 작업에 어떻게 공급되는지 보여줍니다.