식품 유통업체 주문 항목 일괄 처리
— 주간 식품 원가 시트 하나로

주간 인보이스 더미는 하나의 문서가 아니다 — 다섯 가지 호환되지 않는 형식의 결합체다

레스토랑의 주간 구매는 단일 채널을 통해 흐르지 않는다. NRA-TCU 조사에 따르면 레스토랑은 평균 8.1개의 농산물 공급업체만을 두고 있으며, 모든 비주류 카테고리를 합치면 평균 50개 이상의 공급업체 관계를 유지하고, 주류 공급업체를 통해 평균 441개의 SKU를, 전체 컨셉에 걸쳐 907개의 SKU를 구매한다. 일반적인 독립 레스토랑의 주간 리듬은 대략 다음과 같다:

즉, 48시간 창 안에 약 90~130개의 라인 항목이 다섯 가지 다른 형식으로 도착하며, 다섯 명의 공급업체가 각각 다른 명명 규칙과 다른 단위 체계를 사용한다. 일괄 처리 워크플로우의 임무는 단 하나다: 이 더미를 모든 열이 일관되고, 모든 제품이 식별 가능하며, 모든 가격이 비교 가능하고, 모든 라인이 식품 원가 보고용으로 분류된 하나의 스프레드시트로 만드는 것이다. 개별 인보이스 추출의 표준 접근 방식 — 단계별 추출 튜토리얼에서 자세히 다룬다 — 의 과제는 단일 문서 내의 형식 다양성이다. 일괄 워크플로우는 그 위에 한 층을 더한다: 병합해야 하는 문서 간의 형식 다양성이다.

열을 한 번만 정의하세요 — 공급업체마다 반복하지 마세요

일괄 워크플로는 이후 모든 것을 결정하는 단일 설계 결정으로 시작합니다: 어떤 공급업체의 인보이스에서 왔는지와 관계없이 출력의 모든 행이 가질 열은 무엇인가요? 답변은 모든 인보이스에 있는 항목(품목 설명, 수량, 가격)과 일부 인보이스에만 있는 항목(실중량, 대체 메모, 로트 번호)을 모두 포함해야 합니다.

다섯 가지 형식에서 이를 가능하게 하는 기술은 열 이름 추출입니다: "이 공급업체의 레이아웃에서 단가는 7열에 있다"는 템플릿을 만드는 대신, 원하는 필드 이름을 정의합니다 — "단가", "품목 설명", "캐치 중량(Y/N)" — 그리고 AI는 정보가 어디에 있는지가 아니라 무엇을 의미하는지 이해하여 각 페이지에서 각 값을 찾습니다. 동일한 열 정의는 Sysco의 5페이지 PDF, US Foods의 3페이지 PDF, 그리고 농산물 공급업체의 손으로 쓴 메모에서도 작동합니다. AI가 레이아웃 위치가 아닌 의미적 의미를 읽기 때문입니다. 템플릿 기반 도구는 공급업체당 하나씩 총 5개의 별도 구성을 요구하며, 손으로 쓴 메모는 전혀 템플릿화할 수 없습니다.

다음은 완전한 주간 일괄 처리를 위한 열 집합입니다:

이 집합의 두 열 — 카테고리 및 배송 날짜 — 은 특히 일괄 수준의 고려 사항입니다. 카테고리는 공급업체 간 통합을 가능하게 합니다: 서로 다른 제품 이름을 동일한 버킷으로 정규화합니다. 배송 날짜는 주간 경계를 일관되게 만듭니다: 각 공급업체의 자체 날짜 규칙을 재정의하여 일괄 처리가 깨끗한 달력 주를 포착하도록 합니다. 둘 다 아래에서 자세히 설명합니다.

이 열로 일괄 실행한 결과는 단일 테이블을 생성합니다:

모든 행은 동일한 열을 갖습니다. 공급업체 이름 열은 각 행이 어떤 인보이스에서 왔는지 알려줍니다. 카테고리 열은 공급업체 간 품목을 그룹화합니다. 실중량 열은 연어 행을 검증 대상으로 표시합니다. 조정 비고 열은 로마 토마토 부족분을 기록합니다. 이것이 일괄 출력입니다 — 하나의 테이블, 모든 공급업체, 식자재 원가 집계에 바로 사용할 수 있습니다.

공급업체 5곳을 한 장으로 합칠 때 제품명이 깨지는 이유

인보이스를 한 장씩 처리할 때는 존재하지 않는 문제가 있습니다. 세 곳의 서로 다른 공급업체가 같은 식자재 — 파 — 를 서로 다른 이름으로 판매합니다:

같은 식자재인데 문자열이 세 가지입니다. 인보이스를 개별적으로 처리할 때는 이름 차이가 보이지 않습니다 — 한 번에 한 공급업체만 보기 때문입니다. 다섯 곳을 한 배치 출력으로 합치면, 세 가지 설명이 '품목' 열의 서로 다른 행에 들어갑니다. 주간 식품비 시트에 파가 세 개의 별도 품목으로 나타나게 됩니다. 식자재별 지출을 집계하는 것이 불가능해집니다 — 데이터에 "scallion"이 없으니까요. "onion green iceless," "green onion bunch," "scallion"만이 별개로 연결되지 않은 행으로 존재합니다.

이것이 배치 스키마에서 Category(카테고리) 열이 선택 사항이 아닌 이유입니다 — 바로 정규화 계층이기 때문입니다. 미국 요식업 협회(National Restaurant Association)가 발행한 USAR(미국 요식업 통일 회계 체계)가 표준 코딩 프레임워크를 제공합니다: Produce(농산물)는 계정 5140, Protein(단백질, 가금류)은 5130, Dairy(유제품)는 5160, Bakery(제과)는 5150, Grocery and Dry Goods(식료품 및 건식품)는 5170입니다. 모든 품목에 카테고리가 붙어 있으면, Sysco의 onion green iceless와 지역 공급업체의 scallion이 모두 Produce 아래로 분류되고 — 카테고리 수준의 식품비 보고서가 이름 차이와 무관하게 정확해집니다.

이것이 또한 템플릿 방식 대신 열 이름 추출 기반 배치 처리가 더 나은 이유입니다 — 컬럼 이름 추출은 열을 한 번 정의하면 AI가 의미를 읽어내는 방식입니다. 템플릿은 "설명 필드가 Sysco 레이아웃의 2열에 있다"고 매핑합니다. 그 자리에 있는 문자열을 충실히 복사할 뿐입니다. 열 이름 추출은 어떤 레이아웃에서든 "이 줄의 품목 설명은 무엇인가?"를 묻습니다. 결과적으로 이름은 여전히 다를 수 있지만 — AI가 설명을 읽고 어떤 품목인지 이해하여 채우는 Category 열이 그것들을 연결해 줍니다.

단위 측정 문제: 동일한 재료의 두 단가를 비교할 수 없는 이유

Sysco는 닭가슴살을 40파운드 상자 단위로 판매합니다. US Foods는 같은 닭가슴살을 50파운드 상자 단위로 판매합니다. 지역 공급업체는 파운드당 직접 판매합니다. 일괄 출력에서 Sysco 행에는 "단가: $2.82", US Foods 행에는 "단가: $2.70", 지역 공급업체 행에는 "단가: $3.10"이라고 표시됩니다. 어떤 공급업체가 더 저렴할까요? 알 수 없습니다 — $2.82와 $2.70이 파운드당 가격인지, 상자당 가격인지 알 수 없기 때문입니다. 포장 크기 필드를 캡처하지 않고 "단가"라는 숫자를 복사하는 추출 도구는 비교 가능해 보이지만 실제로는 비교할 수 없는 세 개의 숫자를 생성했습니다.

이 문제는 레스토랑 재고 관리에서 널리 발생합니다. Over Easy Office가 문서화했듯이, "레스토랑 회계에서 가장 어려운 부분 중 하나는 '1상자'를 '24병' 또는 '10파운드'로 변환하는 것입니다." Recipe Cost Calculator는 단호하게 말합니다: "잘못된 단위 변환은 조용히 비용을 오염시킵니다. 각 팀원은 머릿속에서 다르게 변환합니다." 일괄 처리 맥락에서는 문제가 더 커집니다: 공급업체 5곳, 다양한 포장 크기, 일관되지 않은 단위 표기. 일괄 출력은 공급업체 가격 비교에 사용할 수 없습니다. 모든 라인 항목에 가격을 정규화하는 데 필요한 데이터가 포함되어 있지 않으면 말이죠.

일괄 스키마는 모든 라인 항목에 대해 단가와 함께 포장 크기를 추출하여 이 문제를 처리합니다. 두 필드가 모두 채워지면 — Sysco: 40파운드 상자, $2.82/파운드, US Foods: 50파운드 상자, $2.70/파운드 — 파운드당 비용을 계산하거나 직접 비교할 수 있습니다. 추출 시점에 정규화를 수행하고 후처리 단계를 피하려는 팀을 위해, 이 도구의 계산 열 기능이 산술을 처리합니다: 파운드당 비용(총 금액 ÷ (수령 수량 × 포장 무게(파운드))) 같은 열을 정의하면 모든 라인 항목이 이미 계산된 정규화된 단위당 비용과 함께 도착합니다.

공급업체 5곳의 예외 처리: 단일 인보이스 워크플로우가 놓치는 것

인보이스를 한 장씩 처리할 때, 예외는 단일 인보이스 문제처럼 보입니다. Sysco의 중량 조정: 닭고기 40파운드 주문, 38.7파운드 수령, 38.7파운드 × $3.87로 청구. US Foods의 대체: 85/15 간 쇠고기가 80/20 대신 동일 가격으로 대체. 농산물 메모의 부족 배송: 로마 토마토 2파운드 차감. 서로 다른 세 가지 예외 유형, 서로 다른 세 공급업체 — 그리고 일괄 출력에서는 세 가지 모두 동일한 스프레드시트에 들어갑니다. 일괄 스키마가 예외를 계획하지 않았다면, 추출은 세 가지 다른 방식으로 잘못된 깔끔한 숫자를 생성합니다.

FDA 규정 21 CFR 101.105는 식품의 순중량 표시를 규제합니다 — 이것이 Sysco의 공급업체 준수 매뉴얼이 모든 선하증권에 대해 소수점 셋째 자리까지 중량을 요구하는 이유입니다. 이는 규제된 관행이지 공급업체의 특성이 아닙니다. "Qty" 옆에서 찾은 첫 번째 중량 필드를 읽는 추출 시스템은 단순히 잘못된 중량을 읽는 것입니다 — 인보이스는 주문 중량과 수령 중량을 모두 표시하도록 설계되었으며, 추출은 어느 것이 가격을 결정하는지 알아야 합니다. 이러한 구조적 실패 모드에 대한 전체 분석은 Sysco 및 US Foods 인보이스가 라인 항목 추출을 깨뜨리는 이유에 대한 기사를 참조하십시오.

일괄 스키마가 이러한 예외에 대비하는 방어책은 Catch Weight (Y/N) 및 Adjustment Note 열입니다. Catch Weight는 청구 수량이 주문 수량과 다른 모든 라인에 플래그를 지정합니다. Adjustment Note는 대체, 부족 배송, 및 수기 수정을 포착합니다. 이 둘을 함께 사용하면 90행 일괄 출력을 스캔하여 추출된 숫자에 검증이 필요한 5~8행을 식별할 수 있습니다 — 어느 행이 잘못되었는지 알 수 없어 90행 전체를 검증하는 대신 말입니다.

유료 레스토랑 플랫폼조차 식품 유통업체 인보이스의 완전 자동화 예외 처리의 어려움을 인정합니다. MarginEdge (월 $330/지점)는 데이터 게시 전에 수기 메모를 읽고 예외 라인을 검증하기 위해 특별히 인간 검토 레이어를 사용합니다. 그 가격대의 도구에 인간 검토가 존재한다는 것은 다중 공급업체 식품 인보이스의 완전 자동화 일괄 처리 — 예외가 문서 경계를 넘는 경우 — 여전히 어려운 문제라는 증거입니다. 여기 설명된 일괄 워크플로우는 깔끔하게 추출되는 90%의 라인을 처리하고 주의가 필요한 10%에 플래그를 지정합니다. 10개 이상 지점 규모에서 인보이스를 처리하는 레스토랑 그룹의 경우, 그 90/10 분할은 상당한 시간 절약으로 이어집니다.

날짜 경계: 주간 배치에 특정 공급업체의 구매 내역이 빠질 수 있는 이유

주간 식품 원가 보고를 작성하려면 모든 공급업체의 청구서에 걸쳐 깔끔한 7일 경계를 설정해야 합니다. 문제는 공급업체마다 청구서에 기재하는 날짜 기준이 다르다는 점입니다.

Sysco는 배송일(트럭이 도착한 날)을 기준으로 청구서를 발행합니다. US Foods는 출하일(주문이 창고를 떠난 날)을 기준으로 하는 경우가 있는데, 이는 배송일보다 하루 빠를 수 있습니다. 농산물 공급업체는 농산물을 수확한 날을 기준으로 합니다. 유제품 공급업체는 배송일이 아닌 주문일을 사용할 수 있습니다. 배치 날짜 필터가 "월요일부터 일요일까지의 청구서"로 설정되어 있는데, US Foods가 월요일에 출하하여 화요일에 배송했다면, 그 화요일 배송 청구서에는 월요일 날짜가 기재되어 배치에서 제외됩니다. 그러면 주간 식품 원가 보고서에서 해당 주의 특정 공급업체 구매 내역 전체가 누락됩니다.

NRA-TCU 조사는 이것이 왜 중요한지 잘 보여줍니다: 운영자의 40%는 청구서 외에 유통업체로부터 어떤 데이터도 받지 못합니다. 배송 도착을 독립적으로 확인해 줄 별도의 배송 일정 피드, API, EDI 데이터 스트림이 없습니다. 청구서가 유일한 기록이며, 청구서에 배치 필터와 맞지 않는 날짜 기준이 기재되어 있으면 해당 공급업체의 구매 내역은 오류 메시지 없이 보고서에서 사라집니다. 추출 스키마의 배송 날짜 열은 배치 경계를 명확하고 감사 가능하게 만듭니다.

병합된 출력 활용법: 주간 식품 원가, 레시피 업데이트, 가격 이력

병합된 배치 출력 — 5개 공급업체 중 하나의 라인 항목이 각 행에 담긴 단일 스프레드시트 — 은 해당 주의 완전한 구매 원장입니다. 공급업체별로 분리된 데이터로는 불가능했던 세 가지 작업이 가능해집니다:

카테고리별 주간 식품 원가. 확장 가격 열을 카테고리별로 집계하면 USAR 계정별 주간 지출이 산출됩니다 — 육류(5110/5130) vs. 농산물(5140) vs. 유제품(5160) vs. 제과(5150) vs. 건조식품(5170). POS의 주간 식품 판매 총액을 활용하면 식품 원가율 계산이 즉시 가능합니다. 미국 레스토랑 협회 보고서에 따르면 식품과 인건비가 매출 1달러당 약 33센트씩을 차지하며, 세전 마진은 약 5%에 불과합니다. 카테고리 정규화 없이 배치 처리할 때 발생하는 2%의 오차만 있어도 식품 원가 보고서는 5% 마진을 3%로 보이게 만들거나, 실제 3% 마진을 5%로 위장해 숨길 수 있습니다.

레시피 원가 업데이트. 배치 출력의 각 라인 항목에는 단위당 가격이 포함됩니다. 접시 원가를 추적하는 레스토랑의 경우 이 데이터가 식품 원가율 계산에 직접 활용됩니다. Sysco 행에 닭가슴살이 파운드당 $2.82로 표시되고 US Foods 행에 $2.70로 표시되면, 더 저렴한 가격이 레시피 원가에 반영됩니다. 주간 배치 추출을 통해 아무도 숫자를 입력하지 않아도 레시피 원가가 매주 업데이트됩니다.

공급업체 및 식자재별 가격 이력. 매주 배치 출력을 저장하면 모든 공급업체의 모든 식자재 가격을 주 단위로 검색 가능한 기록으로 남길 수 있습니다. 12주간의 닭가슴살 가격을 필터링하고 단가를 차트로 만들면 시각적 이력이 완성됩니다. 이 차트는 Sysco 담당자의 "가격이 안정적이었다"는 주장이 데이터와 일치하는지 보여줍니다. 공급업체가 가격 인상을 제안할 때, 배치 이력은 객관적인 근거를 제공합니다: "닭가슴살 가격이 6주 동안 $2.70에서 $2.95로 9.2% 인상되었습니다. 같은 기간 뼈 없는 가슴살의 상품 지수는 3.1% 변동했습니다." 대화가 의견에서 데이터로 전환됩니다.

여러 지점에서 인보이스를 처리해야 하는 레스토랑 그룹의 경우 — 여기서 설명한 배치 워크플로가 각 지점에서 독립적으로 실행되는 경우 — 다중 단위 수준에서 레스토랑 유통업체 인보이스를 일괄 처리하는 가이드를 참조하세요. 동일한 열 스키마, 동일한 정규화 규칙, 동일한 카테고리 구조 — 지점별로 복제될 뿐입니다.

자주 묻는 질문

일반적인 레스토랑은 매주 실제로 몇 개의 유통업체에서 구매하나요?

대부분의 독립 레스토랑은 일반적인 주에 4~7개 공급업체에서 구매합니다: 건화물과 단백질을 위한 광범위 유통업체(Sysco, US Foods 또는 PFG), 농산물 전문 업체, 유제품 공급업체, 베이커리 또는 빵 공급업체, 음료 유통업체, 그리고 해산물, 커피 또는 민족 식자재를 위한 전문 공급업체가 가끔 포함됩니다. NRA-TCU 조사에 따르면 레스토랑은 전체 공급업체 네트워크에서 평균 8.1개의 농산물 유통업체와 2.0개의 유제품 유통업체를 보유하고 있습니다 — 하지만 특정 주에 배송하는 업체는 그중 일부에 불과합니다. 여기서 설명한 배치 워크플로는 주당 5개의 정기 공급업체를 처리합니다. 6번째 또는 7번째를 추가해도 열 스키마는 변경되지 않습니다 — 동일한 열 구조로 배치 출력에 행만 추가됩니다.

공급업체별로 별도의 열 템플릿을 정의해야 하나요?

아니요 — 이것이 배치 워크플로의 핵심 효율성입니다. 열 이름 추출을 사용하면 열 집합을 한 번만 정의하면 됩니다: 공급업체 이름, 인보이스 번호, 품목 코드, 설명, 카테고리, 주문 수량, 수령 수량, 단위, 포장 크기, 단가, 확장 가격, 실중량, 조정 메모. 동일한 열 정의가 Sysco의 5페이지 PDF, US Foods의 3페이지 PDF, 그리고 손으로 쓴 농산물 메모에서도 작동합니다. AI가 각 값을 의미를 이해하여 찾기 때문입니다 — 사전 구성된 레이아웃을 일치시키는 것이 아니라. 템플릿 기반 추출은 공급업체별로 별도의 구성이 필요하며, 손으로 쓴 메모는 템플릿화할 수 없습니다. 열 스키마는 템플릿으로 저장하여 매주 한 번의 클릭으로 재사용할 수 있으며, 매번 동일한 구조의 출력을 생성합니다.

공급업체가 청구서 레이아웃을 변경하면 어떻게 되나요?

레이아웃이 변경되면 템플릿 기반 추출이 즉시 중단됩니다. 도구가 7번째 열에서 단가를 찾도록 되어 있는데, 이제 9번째 열로 이동했기 때문에 모든 줄이 잘못된 값으로 반환됩니다. 열 이름 기반 추출은 레이아웃과 무관합니다. AI가 "단가"를 의미적으로 검색하여 새 레이아웃에서 이동한 위치를 찾아냅니다. 재구성이 필요 없습니다. 이는 광범위한 유통업체가 정기적으로 청구서 형식을 업데이트하고, 소규모 공급업체가 해당 분기에 회계 담당자가 설정한 템플릿을 사용할 수 있는 외식업계에서 특히 중요합니다.

주간 일괄 처리는 업로드부터 사용 가능한 스프레드시트까지 실제로 얼마나 걸리나요?

인보이스 5개(5페이지 PDF 1개, 3페이지 PDF 1개, 손으로 쓴 메모의 휴대폰 사진 1개, 1페이지 PDF 2개)를 업로드하는 데는 드래그 앤 드롭으로 몇 초밖에 걸리지 않습니다. AI 추출은 모든 페이지를 동시에 처리합니다. 100개 이상의 라인 항목 배치의 경우 처리 시간은 일반적으로 1분 미만입니다. 검증 단계 — 중량 확인 및 조정 메모 열에서 플래그가 지정된 라인을 스캔하고, 여러 공급업체에 걸쳐 일부 품목 설명을 무작위로 확인하는 작업 — 은 수동 입력에 필요한 시간 대신 배치당 몇 분이 소요됩니다. 동일한 100개 라인 항목을 수동으로 입력하는 레스토랑 관리자는 입력에 줄당 약 15초에 제품 코드 조회와 단위 변환을 더해 약 25~40분이 소요됩니다. 이는 통합이나 분류 작업 전의 시간입니다.

크레딧 메모와 조정 인보이스는 배치 처리를 중단시키나요?

아니요. 크레딧 메모와 조정 인보이스는 표준 인보이스와 동일한 방식으로 처리됩니다. AI가 문서를 읽고 정의한 열을 추출합니다. 스키마에 문서 유형(인보이스 / 크레딧 / 조정) 열을 포함하면 병합된 출력에서 청구 금액과 크레딧을 구분할 수 있습니다. 반품 또는 가격 조정에 대한 크레딧 메모는 동일한 스프레드시트 구조로 흘러 들어가며, 문서 유형 열을 통해 정확한 순비용 계산이 가능합니다. 배치 처리는 인보이스와 함께 이를 그대로 처리합니다.

일괄 출력물을 회계 소프트웨어에 직접 공급할 수 있나요?

일괄 출력물은 표준 Excel(XLSX) 또는 CSV 파일로, QuickBooks, Xero 및 대부분의 레스토랑 회계 플랫폼에서 가져오기(import)를 지원하는 형식입니다. 각 열은 회계 시스템의 데이터 필드에 매핑됩니다. USAR(미국 요식업 통일 회계 체계) 코드별 분류(생산품 → 5140, 단백질 → 5110/5130 등)를 통해 매주 GL 계정 매핑이 일관되게 유지되며, 수동 코딩이 필요 없습니다. Google Sheets를 사용하여 식자재 비용을 추적하는 레스토랑의 경우, 도구의 Google Sheets 애드온을 통해 추출된 데이터를 스프레드시트에 직접 작성할 수 있어 내보내기 및 재가져오기 단계가 필요 없습니다.

주간 식품 유통업체 청구서 일괄 처리

이 글에서 설명하는 일괄 워크플로우(단일 열 스키마, 모든 공급업체, 매주)는 레이아웃 일치가 아닌 의미를 읽는 추출에 의존합니다. ImageToTable.ai는 열 이름 추출을 사용합니다. 원하는 필드 이름을 입력하면 비전 모델이 형식, 레이아웃, 인쇄 여부, 필기 여부와 관계없이 모든 페이지에서 일치하는 값을 찾습니다. 동일한 열 정의가 Sysco, US Foods, 농산물 공급업체, 유제품 공급업체, 제과점 청구서에 공급업체별 구성 없이 적용됩니다.

화요일 청구서 5개를 한 번에 업로드하세요. 도구는 하나의 통합 스프레드시트를 생성하며, 각 행은 공급업체 중 하나의 라인 항목이고 각 열은 지정한 필드이며 Category 열은 식품 원가 보고를 위해 모든 항목을 그룹화합니다. 매주 동일한 열 템플릿을 재사용하면 공급업체 협상을 근거 기반으로 만드는 가격 이력을 구축할 수 있습니다.