한 지점에서 열 지점으로
식품 청구서 처리 확장하기

다지점 청구서 규모의 복리적 증가 수학

단일 풀서비스 레스토랑은 8~15개의 서로 다른 식품 및 음료 공급업체를 관리합니다. 해당 공급업체들의 주간 청구서 규모는 일반적으로 10~25건 사이이며, 모두 다른 공급업체에서 다른 형식으로, 주중 다른 시간에 도착합니다. 한 지점의 경우, 유능한 매니저나 오너는 이 규모를 주당 3~4시간 안에 수동으로 처리할 수 있습니다: 배송과 수량 대조, 계약과 가격 확인, 총계정원장이나 회계 시스템에 라인 항목 입력, 서류 정리.

문제를 보이지 않게 만드는 것이 바로 이 수학입니다 — 문제가 드러나기 전까지는요. 두 지점은 업무량을 선형적으로 두 배로 만들지 않습니다. 두 지점은 두 세트의 공급업체 관계, 두 개의 재고 수령 지점, 두 개의 지점별 P&L 요구사항, 그리고 한 지점에서는 존재하지 않았던 통합 작업을 의미합니다. 세 지점부터는 문서 수(주당 30~75건의 청구서)가 레스토랑 오너나 소규모 재무 팀이 해야 할 다른 모든 일과 경쟁하기 시작합니다. 다섯 지점이 되면, 그룹은 주당 50~125건의 청구서를 처리하며, 공급업체 목록도 12개에서 25개 이상으로 늘어납니다. 10개 지점에서는 일반적인 그룹이 주당 100~250건, 즉 월간 약 400~1,000건의 청구서를 처리하게 되며, 이는 IOFM이 중간 규모 AP로 분류하는 기준을 넘어섭니다. 그리고 그 청구서들은 함께 처리되도록 설계된 적이 없는 형식으로 도착합니다: Sysco와 US Foods 명세서, 손으로 쓴 농산물 전표, 이메일로 받은 주류 유통업체 PDF, 지역 빵집과 육류 공급업체의 특수 품목 청구서 등이 섞여 있습니다.

이러한 진행은 예측 가능합니다. 대부분의 성장하는 레스토랑 그룹이 겪는 과정입니다. 차이를 만드는 것은 위기가 닥치기 전에 복리적 증가의 구조를 인지하느냐입니다.

세 지점 단계, 균열은 아직 보이지 않는다 — 지금은

세 지점 규모는 레스토랑 그룹이 기존 백오피스 구조를 이미 벗어났음을 깨닫지 못한 채 운영되는 단계인 경우가 많습니다. 사업은 성공적으로 느껴집니다. 매출은 오르고, 오너는 현장에서 보내는 시간을 줄이고 성장에 더 집중합니다. 하지만 그 뒤에서는 이미 조용한 균열이 발생했습니다. 청구서 처리 주기가 이제 주당 30~75건의 문서를 소화하고 있으며, 이를 처리하는 사람 — 종종 오너, 신뢰하는 지점장, 또는 파트타임 회계 담당자 — 은 속도와 정확성 사이에서 절충을 시작하고 있습니다.

징후는 미묘합니다. 한 지점의 Sysco 청구서에서 가격 차이가 발견되지 않는 이유는 담당자가 세 지점의 청구서를 처리하느라 비교할 전주 가격을 손에 쥐지 못했기 때문입니다. 두 레스토랑의 배송을 합산한 US Foods 통합 청구서가 잘못된 지점으로 분류되고, 월말 정산 때까지 아무도 이를 발견하지 못해 회계 담당자가 지점별 손익을 정리하는 데 두 시간을 더 쓰게 됩니다. 지역 공급업체의 농산물 청구서는 승인 체계 — 지점장이 배송과 대조, 오너가 지급 승인, 회계 담당자가 QuickBooks에 입력 — 에 내장된 인계 메커니즘이 없어 이메일 받은 편지함에서 나흘간 방치됩니다. 이러한 실패는 각각 개별적으로는 사소합니다. 그러나 collectively they begin to 식자재 원가 추적의 정확성을 떨어뜨리기 시작합니다. 이 지표는 레스토랑 그룹이 실제로 수익을 내고 있는지를 결정합니다.

세 지점 단계에서 가장 위험한 점은 여전히 감당할 만하다고 느껴진다는 것입니다. 의욕적인 오너는 화요일 밤 늦게까지 일하며 따라잡을 수 있습니다. 시스템은 무너지지 않았습니다 — 단지 팽팽해졌을 뿐입니다. 한 다중 지점 운영자가 Reddit에서 이 경험을 이렇게 설명했습니다: "모든 것이 섞여 있을 때 지점 간 식자재 원가율이나 인건비 비율을 비교할 수 없고, 거래를 분류하는 데 몇 시간을 쓰게 되며, 그때쯤이면 데이터는 이미 낡은 것입니다." 이 문장은 프로세스가 사업을 돕는 것을 멈추고 사업을 소비하기 시작하는 정확한 순간을 포착합니다. 그리고 팽팽하게 버티는 것이 실행 가능한 전략이라는 착각이 5개, 10개 지점에서 필요할 프로세스 구조적 투자를 막는 것입니다.

5개 지점이 대부분의 운영자가 한계에 부딪히는 지점입니다

5개 지점이라는 기준점은 레스토랑 그룹 백오피스 확장에서 가장 흔한 변곡점이며, 결코 미묘하지 않습니다. 5개 지점에서 레스토랑 그룹은 주당 약 50~125장의 청구서를 처리하며, 공급업체 범위도 20~30개의 개별 공급업체로 확장됩니다. 청구서 형식에는 업계에서 생산되는 모든 변형이 포함됩니다: 품목별 세부 정보가 있는 인쇄된 광범위 공급업체 청구서, 음료 유통업체의 이메일 PDF, 지역 농산물 업체의 손으로 쓴 대변 메모, 스캔한 포장 명세서, 그리고 가끔은 운전기사의 배송 시트 사진이 문자로 전송되는 경우도 있습니다.

이러한 물량에서 수동 AP 처리의 한계가 돌파됩니다. 재무관리연구소(IOFM)의 업계 벤치마크에 따르면 숙련된 AP 담당자 1명은 표준 형식의 청구서를 기준으로 하루에 25~40장, 즉 월 약 500~800장을 수동으로 처리할 수 있습니다. 레스토랑 청구서는 표준 형식을 따르지 않습니다. 다중 지점 그룹의 청구서는 처리자가 각 문서를 정신적으로 다시 매핑해야 하는 형식으로 도착합니다: 매번 다른 위치에서 청구서 번호를 찾고, 다양한 제품 이름을 동일한 총계정원장 계정에 맞추고, 품목을 식품비, 종이 제품, 청소 용품 범주로 분할하고, 각 품목이 올바른 지점으로 코딩되었는지 확인해야 합니다. 이러한 인지 전환 비용으로 인해 수동으로 작업하는 레스토랑 AP 처리자는 하루에 약 15~20장, 즉 월 약 300~400장을 처리합니다. 월 최대 500장의 청구서를 생산하는 5개 지점에서 한 명의 정규직 직원이 수동 처리 용량의 상한선에서 작업하고 있으며, 휴가, 병가 또는 계절적 물량 급증은 시스템을 한계점을 넘어서게 만듭니다.

이 단계에서 레스토랑 그룹은 예상치 못한 선택에 직면합니다: 이미 비효율적인 프로세스를 따라잡기 위해 두 번째 AP 담당자를 고용하거나, 프로세스를 재설계하는 것입니다. 대부분의 그룹은 먼저 고용하고 나중에 재설계합니다 — 더 높은 비용으로. Ardent Partners 벤치마크에 따르면 청구서당 평균 수동 처리 비용은 약 $12.90이며, 전담 레스토랑 AP 담당자의 연봉은 복리후생 전 $45,000~$60,000입니다. 5개 지점 문제를 인력 추가로 해결하는 그룹은 연간 약 $90,000~$120,000의 AP 인건비를 부담하게 되며, 여기에 수동 프로세스가 만들어내는 감지되지 않은 가격 오류, 이중 지불, 보고 지연의 누적 비용이 더해집니다.

구조적 현실은 5개 지점이 수동 청구서 처리 및 스프레드시트 기반 추적의 확장 한계에 도달하는 지점이라는 것입니다. 팀이 충분히 열심히 일하지 않아서가 아니라, 물량이 인간의 처리량(스프레드시트를 사용하더라도)이 속도와 정확성을 동시에 유지할 수 없는 영역으로 넘어갔기 때문입니다. 둘 중 하나는 저하될 수밖에 없습니다.

10개 지점: 모든 문제가 동시에 겹칠 때

10개 지점 규모에서 청구서 처리는 더 이상 단일 병목 문제가 아닙니다. 서로를 증폭시키는 다중 병목의 문제입니다. 10개 지점 규모의 레스토랑 그룹은 주당 100~250장, 월간 약 400~1,000장의 청구서를 처리하며, 이는 중상위 AP(지급 계정) 처리량 구간에 해당합니다. 지점이 추가될 때마다 단순히 청구서 수만 늘어나는 것이 아니라, 공급업체 네트워크가 지역적으로 확장되면서 더 다양한 유형의 청구서가 유입됩니다. 특정 도시권에서만 영업하는 신규 해산물 유통업체, 본점의 제과업체와 완전히 다른 형식의 청구서를 사용하는 지역 베이커리, 기존 공급업체 스택과 전혀 다른 PDF를 출력하는 ERP를 사용하는 음료 유통업체가 그 예입니다.

이 규모에서는 세 가지 복합적 실패가 동시에 발생합니다:

형식 다양성이 처리 속도를 저해합니다. 단일 지점 레스토랑은 8~10가지의 서로 다른 청구서 형식을 처리할 수 있습니다. 10개 지점 그룹은 30~50가지 형식을 처리합니다. 각 형식마다 AP 담당자가 서로 다른 인지적 매핑 작업을 수행해야 하며, 이러한 매핑은 모든 지점에 일관되게 적용되어야 합니다. 그렇지 않으면 지점별 손익계산서의 신뢰성이 떨어집니다. 각 공급업체의 데이터가 정규화되지 않은 별도의 형식으로 존재하는 상황에서 공급업체 간 재료 가격 비교 작업은 기하급수적으로 어려워집니다.

승인 지연은 조직적 거리에 비례해 커집니다. 1~2개 지점에서는 오너가 현장에서 즉시 청구서를 승인할 수 있습니다. 10개 지점에서는 청구서를 각기 다른 승인 주기를 가진 여러 지점장에게 라우팅해야 합니다. 음료 청구서 한 장이 지점장의 이메일함에서 3일간 대기하는 일이 발생합니다. 지점장이 더블 시프트를 소화하고 있기 때문입니다. AP 팀이 독촉하고, 지점장은 결국 승인합니다. 그 사이 지급 주기는 최적 시점보다 일주일 늦어졌고, 그룹은 유통업체의 조기 지급 할인을 놓칩니다.

단일 정보 원천이 없으면 통합 보고가 무너집니다. 10개 지점 그룹은 단일 레스토랑이 결코 묻지 않는 질문에 답해야 합니다. 어느 지점의 식재료비 비율이 가장 높고 그 이유는 무엇인가? 모든 지점이 Sysco 닭가슴살에 대해 동일한 계약 가격을 지불하고 있는가, 아니면 특정 지점이 더 높은 가격 구간으로 이탈했는가? 어떤 공급업체의 가격 인상이 그룹 전체의 식재료비 상승을 주도하는가? 이러한 질문에 답하려면 10개 지점 전체의 청구서 데이터가 단일하고 일관된 구조로 정규화되어야 합니다. 수동 처리는 이를 거의 달성하지 못합니다. 데이터는 지점별 스프레드시트, 이메일 스레드, 그리고 일관되지 않은 GL 코딩을 사용하는 회계 시스템 입력 항목에 분산되어 남게 됩니다.

이 단계에서 수동 프로세스를 사용하는 레스토랑 그룹은 재무 운영을 실제보다 한 달 뒤처진 상태로 운영하기 시작합니다. 월 결산은 30일에 이루어집니다. 청구서 입력이 완전히 완료되는 시점은 다음 달 12일입니다. 재무 보고서는 18일에 준비됩니다. 오너가 특정 지점의 식재료비가 예산을 3포인트 초과했다는 사실을 확인할 때쯤, 운영은 이미 다음 달 비용 구조의 절반을 시정 조치 없이 소진한 상태입니다.

회계 문제가 조직도보다 빠르게 커지는 이유

성장하는 레스토랑 그룹에는 재무 프로세스의 성숙도가 매출 성장을 따라잡을 것이라는 지속적인 가정이 있습니다. 5개 지점에서는 컨트롤러를 고용하고, 10개 지점에서는 내부 회계 팀을 구축할 것이라는 논리입니다. 이 가정은 논리적으로 보입니다. 하지만 수학은 이를 뒷받침하지 않습니다.

문제는 청구서 규모가 기하급수적으로 증가한다는 것입니다. 각 신규 지점은 공급업체 관계, 형식 변형, 통합 요구 사항을 추가하여 처리 복잡성을 배가시키는 반면, 조직 역량은 점진적으로만 성장합니다. 5개 지점에서 컨트롤러를 고용한다고 해서 청구서 처리 문제가 해결되지는 않습니다. 컨트롤러의 업무는 재무 감독, 보고, 분석입니다. 컨트롤러는 이러한 감독을 수행하기 위해 여전히 깨끗하고 구조화된 청구서 데이터가 필요합니다. 청구서 접수 프로세스가 수동으로 남아 있다면, 컨트롤러를 고용하는 것은 단지 더 높은 급여를 받는 전문가가 동일한 병목 현상을 바라보게 하는 것에 불과합니다.

Technomic과 Crunchtime이 300개 이상의 다중 지점 레스토랑 운영자를 대상으로 실시한 설문 조사에 따르면, 4명 중 3명이 확장이 점점 더 어려워지고 있으며 시스템, 팀, 파트너가 "확장에 맞게 구축"되어야 한다고 답했습니다. 5~10개 지점의 변곡점을 수익성 있게 통과하는 운영자들은 수요가 발생하기 전에 프로세스 인프라(표준화된 접수, 자동화된 데이터 추출, 일관된 GL 코딩 규칙)에 투자하는 사람들입니다. 수요가 발생한 후가 아니라요.

실제로 재정적 혼란을 최소화하면서 성장 곡선을 통과하는 그룹들은 공통된 패턴을 보여줍니다. 그들은 청구서 처리를 사무적인 작업으로 취급하는 것을 중단하고 데이터 파이프라인으로 취급하기 시작했습니다. 청구서는 여전히 청구서입니다. 그러나 그 주변의 프로세스(데이터가 시스템에 입력되는 방식, 표준화되는 방식, 보고로 흐르는 방식)는 그룹이 3개 지점일 때 20개 지점을 위해 설계되었습니다.

변곡점 도달 전에 구축해야 할 것

다중 지점 청구서 확장 문제를 해결하는 가장 비용이 많이 드는 방법은 현재 프로세스가 무너진 후 압박 속에서 수리하는 것입니다. 가장 비용이 적게 드는 방법은 현재 프로세스가 여전히 작동하는 동안 인프라를 구축하는 것입니다 — 처리되지 않은 청구서가 큐에 쌓이는 부담 없이 표준화, 테스트, 개선할 시간이 있을 때 말입니다. 각 단계에서 구축해야 할 인프라는 다음과 같습니다:

1~2개 지점 — 계정과목표를 표준화하세요. 전국 레스토랑 협회의 레스토랑 통일 회계제도(USAR)는 단일 매장에서 다중 매장 그룹으로 확장되도록 설계된 표준화된 COA 프레임워크를 제공합니다. 첫날부터 USAR 분류(식품비(계정 5100), 음료비(5200), 종이 및 일회용품(5400), 청소용품(7300))를 사용하여 GL 코딩을 설정하는 레스토랑은 성장하면서 각 지점이 동일한 비용을 서로 다른 계정으로 코딩하고 있음을 발견했을 때 그룹이 겪는 고통스러운 재매핑 작업을 피할 수 있습니다. 이는 성장하는 그룹이 할 수 있는 가장 저렴하고 효과가 큰 인프라 결정입니다.

2~3개 지점 — 수요가 발생하기 전에 추출 자동화를 도입하세요. 수동 데이터 입력과 AI 기반 청구서 추출의 차이는 정도의 차이가 아니라 종류의 차이입니다. ImageToTable.ai의 청구서 처리 방식은 열 이름 추출을 사용합니다: 각 공급업체의 청구서 형식에 맞는 템플릿을 만드는 대신 필요한 필드("청구서 번호", "공급업체 이름", "품목", "수량", "단가", "지점")를 지정하면 AI가 데이터의 의미를 이해하여 각 문서에서 해당 값을 찾습니다. 하나의 열 이름 템플릿은 Sysco 청구서, US Foods 청구서, 손으로 쓴 농산물 영수증, 음료 유통업체의 PDF를 단일 배치로 처리합니다. 출력은 모든 청구서가 원래 형식과 관계없이 동일한 구조화된 열에 입력되는 통합 Excel 스프레드시트입니다.

주간 물량이 20~60건일 때 2~3개 지점에서 이를 배포하면 수동 처리 한계를 넘어서기 전에 추출 인프라가 구축되고 테스트됩니다. 20건의 청구서 더미 처리 시간은 수 시간의 수동 입력에서 수 초의 AI 추출로 단축되며, 출력의 일관성 덕분에 해당 데이터를 기반으로 구축된 식품비 비율 계산은 수동 입력에 항상 필요한 정리 작업 없이도 신뢰할 수 있습니다.

4~5개 지점 — 일괄 처리 및 지점별 출력을 구현하세요. 이 단계에서 청구서 접수 프로세스는 단일 작업이어야 합니다: 모든 지점의 주간 청구서를 업로드하고, AI가 데이터를 추출 및 정규화하고, 지점 태그가 지정된 품목이 포함된 통합 스프레드시트를 내보냅니다. 절약되는 시간(주간 수동 AP 작업 8~12시간에서 검토 10~15분으로 단축)은 상당합니다. 그러나 더 중요한 이점은 데이터 구조가 이제 5개 지점 그룹이 답해야 할 운영 질문을 지원할 만큼 신뢰할 수 있다는 것입니다: 어느 지점의 식품비가 벗어나고 있습니까? 계약 가격이 준수되고 있습니까? 낭비는 어디에 있습니까?

프로세스 마찰을 더 줄이려는 그룹을 위해 ImageToTable.ai의 수집 링크 기능은 각 레스토랑의 GM에게 보낼 수 있는 공유 가능한 업로드 페이지를 생성합니다. GM은 휴대폰에서 링크를 열고 짧은 인증 코드를 입력한 후 해당 주의 청구서를 직접 업로드하며, 파일은 중앙 백오피스 처리 대기열에 도착합니다 — GM 로그인 불필요, 추가 교육 불필요, 분실되거나 잘못 분류되는 이메일 첨부 파일도 없습니다.

6~10개 지점 규모 — 통합 보고 레이어 구축. 이 단계에서는 핵심 추출 파이프라인이 일일 개입 없이 작동해야 합니다. 업무는 데이터 입력에서 데이터 분석으로 전환됩니다: 예외 보고서 검토, 이상 가격 검증, 정규화된 지출 데이터를 활용한 공급업체와의 더 나은 조건 협상. 10개 지점에 도달하면서도 간소한 재무 팀을 유지하는 그룹은 가장 열심히 일하는 AP(지급 계정) 담당자를 둔 그룹이 아닙니다. 그들은 AP 담당자가 수동으로 데이터를 생성하는 대신 자동화된 출력을 검토하는 데 시간을 쓰는 그룹입니다.

자주 묻는 질문

일반적인 레스토랑 지점은 주당 몇 장의 청구서를 처리하나요?

단일 풀서비스 레스토랑은 일반적으로 8~15개 공급업체로부터 주당 10~25장의 청구서를 처리합니다. Over Easy Office의 AP 자동화 서비스 업계 데이터는 레스토랑 청구서 규모를 세 단계로 분류합니다: 지점당 월 최대 125장의 저용량, 지점당 월 126~299장의 중간 용량, 지점당 월 300~599장의 고용량. 전용 AP 인프라를 갖춘 다중 지점 그룹은 볼륨이 여러 지점에 분산되므로 각 단계의 하한에 속하는 경향이 있습니다. 수동 프로세스를 운영하는 그룹은 처리 비효율로 인해 청구서가 처리되지 않고 누적되므로 각 단계의 상한에 머무는 경우가 많습니다.

도매 유통업체인 Sysco와 US Foods는 여러 레스토랑 지점의 청구를 통합하나요?

일반적으로 아닙니다. Sysco와 US Foods는 개별 지점별로 청구하며, 각 레스토랑은 자체 인보이스를 받습니다. 일부 다중 지점 그룹은 여러 배송 지점이 있는 단일 계정에 대해 통합 청구를 협상하지만, 이는 기본값이 아니며 유통업체의 비즈니스 분석가와의 명시적 설정이 필요합니다. 통합 청구를 하더라도 인보이스에는 지점별 품목이 나열되므로, 각 지점의 손익계산서에 맞게 품목을 분류하고 배분해야 합니다. Restaurant365는 Location Groups와 AP Invoice Distribution을 통해 이를 기본적으로 지원하며, QuickBooks Online은 개별 청구 라인의 Class 추적을 통해 처리할 수 있지만, 데이터 입력 시점에 지점 식별자가 캡처되어야 합니다.

레스토랑 그룹은 언제 회계사 대신 컨트롤러를 고용해야 하나요?

대부분의 레스토랑 회계 법인은 약 3~5개 지점 규모에서 회계사에서 컨트롤러로 전환할 것을 권장하지만, 중요한 전제가 있습니다. 컨트롤러는 데이터 입력이 아닌 시스템 구축을 위해 배치되어야 한다는 점입니다. 5개 지점에서 컨트롤러를 고용했는데 그가 시간의 60%를 인보이스 수동 입력에 쓴다면, 고용은 잘못된 것입니다. 컨트롤러의 가치는 재무 분석, 차이 조사, 비용 최적화, 보고 구조에 있으며, 이러한 작업은 원시 인보이스 데이터가 추출되고 정규화된 후에만 수행할 수 있습니다. 더 나은 순서는 2~3개 지점에서 추출 자동화를 도입한 다음, 5개 지점에서 서류 더미가 아닌 구조화된 데이터로 하루를 시작하는 컨트롤러를 고용하는 것입니다.

AI 추출이 손으로 쓴 인보이스와 배송 명세서를 처리할 수 있나요?

예 — 필기 가독성의 자연스러운 한계 내에서 가능합니다. ImageToTable.ai는 문서 이미지 전체를 한 번에 처리하는 비전 대형 모델을 사용하므로, 인쇄된 품목, 손으로 쓴 생산자 이름, 포장 명세서에 동그라미 친 수량, 도장 찍힌 승인 표시가 모두 동일한 패스에서 해석됩니다. 운전기사가 "Roma Tomatoes — 2 cs — $34"라고 손으로 적은 농산물 명세서는 완전히 인쇄된 Sysco 인보이스와 같은 배치에서 함께 읽힙니다. AI는 "인쇄된" 문서와 "손으로 쓴" 문서 사이에서 모드를 전환하지 않습니다. 사람처럼 문서 전체를 시각적으로 읽습니다. 알아볼 수 없는 필기는 어떤 독자에게도 그렇듯 여전히 알아볼 수 없지만, 알아볼 수 있는 필기 데이터는 인쇄된 텍스트와 동일한 메커니즘으로 추출됩니다.

2~3개 지점을 운영하는 레스토랑 그룹에서 청구서 처리를 자동화하는 가장 빠른 방법은 무엇인가요?

가장 빠른 방법은 열 이름 추출로 시작하는 것입니다. 필요한 필드(청구서 번호, 날짜, 공급업체, 품목, 수량, 단가, 합계, 지점)를 지정하고, 모든 공급업체의 일주일치 청구서를 한 번에 업로드하면 AI가 데이터를 추출하여 단일 스프레드시트로 정규화합니다. 템플릿 작성이 필요 없고, 공급업체별 설정도, 공급업체 온보딩도 필요 없습니다. 출력된 스프레드시트는 회계 시스템에 직접 가져오거나 식품 원가 추적 워크북을 업데이트하는 데 사용할 수 있습니다. Google Sheets를 사용하는 그룹의 경우 ImageToTable Google Sheets 애드온을 통해 스프레드시트 환경을 벗어나지 않고 활성 시트에 직접 추출할 수 있습니다.

청구서 추출 소프트웨어는 레스토랑 회계 플랫폼과 통합되나요?

추출된 데이터는 Excel(XLSX), CSV 또는 JSON 형식으로 출력되며, 모든 회계 플랫폼에서 바로 가져올 수 있습니다. Restaurant365는 AP 모듈에 CSV와 Excel을 직접 가져옵니다. QuickBooks Online은 CSV 청구서와 품목 영수증을 가져옵니다. MarginEdge에는 자체 청구서 OCR이 내장되어 있지만, MarginEdge를 다른 도구와 함께 사용하는 그룹의 경우 외부 AI로 추출한 구조화된 데이터를 MarginEdge의 표준 가져오기 경로를 통해 업로드할 수 있습니다. 핵심은 추출 계층이 원본 청구서가 어느 공급업체에서 왔는지와 관계없이 동일한 열, 동일한 형식, 동일한 코딩으로 일관된 구조의 출력을 생성한다는 것입니다. 대부분의 레스토랑 AP 플랫폼은 회계 측면이 아니라 데이터 수집 측면에서 실패합니다. 소비할 깨끗한 데이터가 필요합니다.