호텔 정산서 30장이 책상 위에 쌓였을 때
일괄 대사 작업의 간극

GBTA 비즈니스 여행 지수(BTI)는 2026년 글로벌 출장비 지출이 1조 6900억 달러에 달할 것으로 전망합니다. 컨설팅, 법률, 회계 등 전문 서비스 기업들은 팬데믹 이전 출장 기준을 이미 넘어섰으며, 일부 업종은 2019년 대비 출장비 지출이 20% 이상 증가했습니다. 동일한 GBTA 보고서에 따르면, 출장자를 지원하는 재무팀은 매월 증가하는 규모 문제에 직면합니다. 평균 출장비는 1,128달러로 상승했고, 유럽의 평균 출장 숙박 기간은 3.1박으로, 각 숙박 시 여러 페이지에 걸친 다중 항목 청구서가 발생합니다.

청구서를 한 줄씩 처리하는 것은 지루하지만 가능합니다. 잘 구성된 추출 워크플로를 사용하면 3페이지 분량의 청구서를 1분 안에 GL 코드가 적용된 스프레드시트 행으로 변환할 수 있습니다. 하지만 30장의 청구서 더미를 마주하면 병목 현상이 발생합니다. 더 이상 데이터 입력이 아닌 데이터 통합 작업을 하게 됩니다. 각 호텔 체인마다 요금 명칭이 다르고, 세금 항목 위치가 다르며, 청구서를 생성하는 자산 관리 시스템도 제각각인 여러 출력물을 병합해야 합니다. 이 통합 단계에서 시간이 사라지며, 배치 처리가 전체 정산 주기의 효율성을 바꾸는 지점입니다.

형식 파편화 문제

Oracle Opera PMS로 생성된 메리어트 청구서는 OnQ 시스템의 힐튼 청구서와 다르며, 이는 Opera Cloud 또는 레거시 PMS를 사용하는 IHG 청구서와도 다릅니다. 데이터는 동일합니다(객실 요금, 세금, 식사, 주차, 부대 비용). 하지만 배열, 항목 설명, 섹션 제목까지 충분히 달라서 한 체인에 맞춘 템플릿이 다음 체인에서는 작동하지 않습니다.

이는 이론적인 극단적인 경우가 아닙니다. 중견 컨설팅 회사의 일반적인 월말 배치 작업에서 재무 관리자는 다음과 같은 자료를 받을 수 있습니다:

템플릿 기반 OCR 시스템은 메리어트 숙박 영수증에서 "Destination Fee"는 올바르게 읽지만, 힐튼 숙박 영수증의 "Resort Charge"에 대한 규칙은 없어 동일한 GL 배정 항목이 빈 셀로 반환됩니다. 이러한 불일치가 30개의 숙박 영수증에 걸쳐 15개의 고유한 요금 유형에서 발생하면, 스프레드시트는 빈칸, 잘못된 배치, 수동 수정 투성이가 됩니다. 추출은 작동했지만, 통합은 실패한 것입니다.

대안은 사용자 정의 열 추출입니다. 도구에 페이지에서 어디를 볼지 알려주는 대신, 무엇을 찾을지 알려줍니다. "객실 요금", "숙박세", "리조트 요금", "주차", "레스토랑 요금"과 같은 열 이름을 정의하면, AI 비전 모델이 각 숙박 영수증을 읽고 각 요금 설명의 실제 의미를 이해하여 페이지 상의 위치나 체인 명칭과 관계없이 올바른 열에 값을 추출합니다. 한 번 정의한 열 이름은 30개의 숙박 영수증, 8개 체인, 4가지 출처 형식 모두에서 작동합니다. 예전에 몇 시간 걸리던 통합 단계가 추출 단계 자체에 흡수됩니다.

병합 문제: 30개의 추출 결과를 하나의 스프레드시트로

숙박 영수증을 개별적으로 처리(하나 업로드, 추출, 결과 다운로드)하면 30개의 스프레드시트가 생성됩니다. 기술적으로는 "완료"되었지만, 월말 문제는 해결되지 않았습니다. 데이터 입력 작업을 데이터 병합 작업으로 바꾼 것뿐입니다. 재무 검토자는 여전히 30개의 파일을 열고, 행을 마스터 워크북에 복사하고, 일관성 없는 출력 간의 열 정렬을 확인하고, 신용카드 명세서와 총액을 대조해야 합니다.

일괄 처리는 병합 단계를 없앱니다. 30개의 숙박 영수증(메리어트 PDF, 힐튼 이메일 첨부파일, IHG 휴대폰 사진, 독립 호텔 JPEG)을 한 번에 업로드하고, 추출 열을 한 번만 정의하면, 출력은 각 행이 호텔 숙박이고 각 열이 정의된 필드인 하나의 스프레드시트입니다. 병합도, 열 재정렬도, "17행을 올바른 시트에 복사했나?" 확인도 필요 없습니다.

구체적인 예: 전문 서비스 회사의 재무 관리자가 한 달 간의 고객 출장 후 17명의 컨설턴트로부터 34개의 숙박 영수증을 수집합니다. 7개는 이메일로 받은 메리어트 PDF입니다. 9개는 힐튼 숙박 영수증으로, 일부는 PDF, 일부는 앱 스크린샷입니다. 6개는 컨설턴트가 주차장을 떠나기 전에 촬영한 IHG 인쇄물입니다. 4개는 프런트 데스크에서 감열지로 한 부만 인쇄해 준 독립 호텔에서 나온 것입니다. 2개는 여행자가 숙박 영수증 요청을 잊어버려 플랫폼 영수증만 있는 Booking.com 예약 건입니다.

추출 열은 한 번만 정의되며, 동일한 필드 이름 세트가 34개 문서 모두에서 작동합니다. 출력은 단일 스프레드시트에 저장됩니다. 검토 단계는 "모든 항목을 입력"하는 것에서 "이상치 스캔"으로 바뀌며, 이 규모의 배치에서는 10시간 대신 10분이면 충분합니다.

일괄 GL 배분: 400개 라인 항목, 한 번에 처리

데이터 추출은 일괄 처리 문제의 절반을 해결합니다. 나머지 절반은 각 요금을 올바른 일반 원장 계정에 수동으로 검토하고 분류하지 않고 할당하는 것입니다. 4페이지 분량의 메리어트 폴리오에는 5개의 USALI 부서 범주에 걸쳐 47개의 라인 항목이 포함될 수 있습니다. 이러한 폴리오 30개는 대략 400개의 개별 요금을 생성하며, 이를 4~5개의 GL 코드에 매핑해야 합니다. 수동으로 수행되는 이 매핑은 피로가 쌓이고 오류가 누적되는 지점입니다.

이것이 바로 추론 열이 규모에 따라 지렛대 역할을 하는 부분입니다. 추론 열은 AI에 유효한 옵션 세트를 제공하고 폴리오의 요금 설명에 따라 올바른 옵션을 선택하도록 요청하여 작동합니다. "GL 코드"라는 열을 "6400 (숙박), 6500 (식사 및 접대), 6600 (교통), 6800 (사무/통신), 비상환" 옵션으로 정의하면 AI가 각 라인을 읽습니다. "객실 요금" → 6400, "팜 레스토랑" → 6500, "발렛 파킹" → 6600, "인룸 영화" → 비상환. 분류 규칙은 한 번 작성되어 전체 배치에 적용됩니다.

실질적인 차이는 극명합니다. 400개의 라인 항목을 항목당 30초씩 올바른 GL 코드에 수동으로 할당하는 데는 3시간 이상이 소요되며, 이는 수정 전 시간입니다. 배치 전체에 추론 열을 적용하면 할당은 금액을 읽는 동일한 추출 패스 내에서 이루어집니다. 출력은 미리 분류되어 도착합니다. 검토자의 작업은 분류("주차 요금은 어떤 GL인가?")에서 예외 처리("이 스파 요금이 자동으로 숙박으로 분류되었습니다. 비상환으로 재정의")로 전환됩니다.

이 모델은 또한 간행물 463에 따른 IRS 책임 있는 계획 요구 사항과 일치합니다. 책임 있는 계획은 직원이 각 비용에 대해 시간, 장소, 업무 목적, 금액의 네 가지 요소를 입증하도록 요구합니다. $1,247의 폴리오 총액은 라인 항목 수준에서 이 중 어느 것도 입증하지 못합니다. 이를 객실 요금, 세금, 식사, 잡비로 나누고 각각 자체 금액과 GL 분류를 부여하면 폴리오가 영수증 이미지에서 규정 준수 문서로 전환됩니다. 이 분석이 한 달 치 폴리오 배치 전체에 적용되면 규정 준수 가치는 배가됩니다. 모든 여행자, 모든 호텔의 모든 요금이 동일한 GL 구조에 일관되게 할당됩니다.

호텔 업계 자체 회계 기준이 이것이 중요한 이유를 강화합니다. 2025년 2월에 발행되어 2026년 1월 1일부터 의무적으로 적용되는 숙박업계 통일 회계 계정 체계(USALI) 제12차 개정판은 호텔 수익을 객실, 식음료, 기타 운영 부서, 잡수입의 부서 범주로 구조화합니다. 폴리오는 게스트 회사의 GL이 아닌 호텔의 내부 계정 체계를 반영합니다. USALI 부서 논리에서 기업 비용 논리로의 변환 작업은 추론 열을 사용한 일괄 추출이 자동화하는 것이며, 어떤 템플릿 기반 OCR도 수행할 수 없었던 작업입니다.

우선 영수증을 확보하는 방법: 수집 과제

30장의 영수증을 처리하려면 먼저 30장의 영수증이 있어야 합니다. 실제로 이것이 워크플로우의 더 어려운 부분입니다. 출장 중인 컨설턴트는 체크아웃 시 인쇄된 영수증을 요청하는 것을 잊곤 합니다. 호텔 이메일 시스템은 PDF를 전달하지 못하는 경우가 많으며, 이는 여행 포럼에서 반복적으로 제기되는 불만입니다. 감열지 영수증은 몇 주 내에 희미해집니다. 어두운 호텔 방 책상 위에서 비스듬히 촬영한 영수증 사진은 기술적으로는 영수증이지만 데이터 추출에는 사실상 사용할 수 없는 이미지를 생성합니다.

월말 마감을 관리하는 재무팀의 경우, 이러한 누락은 늦게, 특히 신용카드 명세서가 도착했을 때 시카고 힐튼 호텔의 $1,247 청구 건에 해당하는 영수증이 배치에 없음을 발견할 때 표면화됩니다. 이 차이를 조정하려면 이미 다음 고객 프로젝트에 투입된 직원을 추적하고, 그 직원이 호텔에 전화를 걸어 안내 전화를 거치고, 도착할 수도 있고 안 할 수도 있는 중복 영수증을 기다려야 합니다. 영수증 한 장이 누락될 때마다 데이터 추출이 아닌 조정에 한 시간의 비용이 발생합니다.

수집 링크는 이러한 격차를 초기 단계에서 해소합니다. 직원이 영수증을 제출하는 것을 기억할 때까지 기다리는 대신, 재무팀은 공유 가능한 링크를 생성하여 월초에 모든 출장 직원에게 보냅니다. 링크가 있는 사람은 누구나 로그인, 계정, 소프트웨어 설치 없이 영수증을 업로드할 수 있습니다. 영수증은 처리 대기열에 직접 들어가며, 월말이 도착하기 전에 한 곳에 정리됩니다. 배치는 마감 주간에 급하게 모으는 것이 아니라 한 달 내내 지속적으로 구축됩니다.

실무에서 발생하는 문제: 예외 처리의 현실

서른 장의 숙박 영수증 중 깨끗한 배치는 없습니다. 일부는 누락되고, 일부는 읽을 수 없으며, 일부는 잘못된 유형(총액만 표시된 요약본)으로 출력되어 항목별 추출이 무용지물입니다. 어떤 여행자는 개인 물품을 객실 요금에 청구하여 환급 가능 항목과 불가능 항목이 뒤섞이기도 합니다. 현실적인 배치 워크플로우는 마감 프로세스를 중단시키기 전에 이러한 예외 상황을 처리해야 합니다.

가장 흔한 배치 예외 상황을 빈도순으로 나열하면 다음과 같습니다.

독립 호텔의 영수증 누락. 표준화된 PMS 시스템을 갖춘 체인 호텔은 요청 시 이메일로 영수증을 보낼 수 있습니다. 그러나 구형 시스템이나 수동 프로세스를 사용하는 독립 호텔은 불가능한 경우가 많습니다. 프런트 데스크에서 한 장만 출력하고 여행자가 사진을 찍지 않으면 해당 영수증은 사라집니다. 재무팀은 처리 중이 아니라 대사 과정에서 법인카드 청구 내역과 일치하는 영수증이 없음을 발견합니다. 예방책은 여행 전에 발송되는 '수집 링크'가 유일한 신뢰할 수 있는 해결책입니다.

총액만 표시된 요약 영수증. 일부 호텔, 특히 프런트 데스크에서 고객이 간단한 영수증을 원한다고 가정하는 시장에서는 '객실 요금' 한 줄과 총액만 있는 축약된 영수증을 출력하거나 이메일로 보냅니다. 이 버전은 항목별 추출 및 책임 회계 규정 준수에 무용지물입니다. 여행자는 구체적으로 '잔액이 0인 게스트 영수증'(전체 항목이 기재된 버전)을 요청해야 하지만, 모든 여행자가 이를 요청해야 한다는 것을 아는 것은 아닙니다. 배치 워크플로우는 추출된 항목의 합계가 총액과 일치하지 않는 영수증(요약된 원본 문서를 나타냄)에 플래그를 지정해야 합니다.

업무 및 개인 비용 혼합. 룸서비스, 미니바, 스파, 객실 내 영화 등은 객실 요금 및 업무 식사와 동일한 영수증에 청구됩니다. 단일 영수증 워크플로우에서는 검토자가 개인 비용을 수동으로 찾아냅니다. 서른 장의 배치에서는 섞여서 눈에 띄지 않습니다. '환급 가능?'(옵션: 예/아니요/검토)이라는 추론 열은 감사 중이 아닌 추출 중에 이를 표시하여 숨겨진 규정 준수 위험을 검토자가 몇 초 만에 처리할 수 있는 가시적인 항목으로 전환합니다.

원본 품질 차이. 호텔 PMS에서 이메일로 전송된 PDF는 깨끗하고 선명하며 기계에 최적화되어 있습니다. 형광등 아래에서 각도로 찍은 감열지 영수증의 휴대폰 사진은 그렇지 않습니다. 추출을 구동하는 시각-언어 모델은 픽셀 템플릿을 일치시키는 대신 문서 레이아웃과 맥락을 이해하여 읽음으로써 둘 다 처리하지만, 품질이 낮은 캡처에서는 정확도가 떨어집니다. 실용적인 배치 워크플로우는 품질 기대치를 설정합니다. PDF와 선명한 휴대폰 사진은 신뢰도 높은 추출을 생성합니다. 심하게 구겨지거나 각도가 잘못된 감열지 인쇄물은 확인 과정이 필요할 수 있습니다. 확인 과정이 있더라도 스프레드시트에서 이상값을 스캔하는 것은 47개의 항목을 처음부터 수동으로 입력하는 것보다 훨씬 빠릅니다.

자주 묻는 질문

일부 여행자만 서류가 부분적으로 있는 경우, 일괄 처리로 처리할 수 있나요?

네. 여행자가 전체 고지서 대신 Booking.com 영수증만 제출하면, 체크인 날짜, 체크아웃 날짜, 총액 등 보이는 필드는 추출하고 항목별 열은 비워둡니다. 일괄 출력 결과는 정보를 숨기지 않고 누락된 부분을 표시합니다. 재무 검토자는 해당 여행에 대해 플랫폼 영수증을 승인할지, 호텔에 전체 고지서를 요청할지 결정할 수 있습니다.

두 직원이 같은 메리어트 호텔에 묵었는데 한 명은 PDF를, 다른 한 명은 휴대폰 사진을 받았다면 어떻게 되나요?

열 정의는 두 형식 모두에서 작동합니다. AI는 PDF 텍스트를 직접 읽고, 휴대폰 사진은 문서 레이아웃을 시각적으로 이해하여 읽습니다. PDF는 텍스트가 기계적으로 선명하여 추출 품질이 더 높지만, 휴대폰 사진도 이미지가 비교적 평평하고 읽을 수 있으면 사용 가능한 결과를 생성합니다. 출력 스프레드시트에는 동일한 열 구조로 두 행이 동일한 배치에 포함됩니다.

이 기능은 Concur나 Expensify와 어떻게 함께 작동하나요?

보완 관계입니다. 기업 T&E 플랫폼은 예약, 승인 라우팅, 정책 시행, 환불 등 전체 경비 라이프사이클을 처리합니다. 하지만 이 플랫폼들이 안정적으로 처리하지 못하는 것은 모든 체인의 다중 페이지 호텔 고지서를 구조화된 GL 코드 항목 데이터로 대규모 일괄 변환하는 것입니다. 이 추출 기능은 깔끔하고 분류된 스프레드시트를 생성하여 경비 시스템에 구조화된 입력 데이터로 제공합니다. 플랫폼의 OCR이 고지서 총액을 읽고 직원이 수동으로 항목을 분류하는 대신, 직원이 고지서를 한 번 업로드하면 항목이 자동으로 채워집니다. 20명 이상의 여행자를 위해 경비 보고서를 처리하는 소규모 재무 팀이 이러한 연계를 통해 가장 큰 비례적 시간 절감 효과를 봅니다.

일괄 처리에서 수동 수정이 필요한 고지서의 비율은 얼마인가요?

대형 체인 호텔의 깨끗한 PDF 형식 고지서의 경우 추출 정확도가 매우 높고 GL 할당이 일관되어 대부분의 행이 수정 없이 검토를 통과합니다. 수정 비율은 저화질 휴대폰 사진, 감열지 인쇄물, 비표준 형식의 독립 호텔 고지서에서 높아집니다. 현실적인 기대치: 일반적인 배치에서 약 80~85%의 행은 전혀 수정이 필요 없고, 나머지 15~20%는 빠른 검토와 가끔 재정의가 필요합니다. 검토자는 모든 항목이 아닌 예외 사항에 시간을 할애합니다.

추론 열은 리조트 피와 같이 체인마다 명칭이 다른 항목도 처리할 수 있나요?

네, 이것이 바로 추론 열이 템플릿 규칙보다 뛰어난 점입니다. 템플릿 기반 시스템은 "Resort Fee"라는 텍스트 문자열만 찾기 때문에 "Destination Fee", "Resort Charge", "Urban Fee", "Amenity Fee" 등을 놓칩니다. 추론 열은 요금 설명을 읽고 "객실당 부과되는 필수 일일 숙박 시설 요금"이라는 의미를 이해하여 호텔이 무엇이라고 부르든 올바른 열로 분류합니다. 동일한 추론이 전체 배치에 적용됩니다.

30개의 숙박 청구서 배치를 처리하는 데 얼마나 걸리나요?

추출 자체는 숙박 청구서당 5~10초가 소요되며, 30개 배치의 경우 약 2~5분입니다. 검토 단계는 더 오래 걸립니다. 출력 스프레드시트에서 이상값을 스캔하고, GL 할당을 확인하며, 예외를 처리하는 데 일반적으로 깨끗한 배치의 경우 10~15분이 소요되며, 많은 숙박 청구서의 품질이 낮거나 모호한 요금이 포함된 경우 더 오래 걸립니다. 수동 방식과 비교해 보세요. Concur나 스프레드시트에서 30개의 숙박 청구서를 한 줄씩 처리하고 항목별로 분류하는 데는 일반적으로 4~6시간의 집중 작업이 필요하며, 월말 마감 기간에 여러 날에 걸쳐 진행되는 경우가 많습니다.