직원 항공 일정 120건을 일괄 처리하여
하나의 여행 지출 대시보드로

실제로 이 작업을 해본 사람들은 모두 같은 벽을 이야기합니다. r/consulting의 비용 보고서 일괄 처리에 관한 게시물에서 한 컨설턴트는 이렇게 명확하게 말했습니다. 비용 보고서는 "압도적이거나 시간이 많이 걸리지는 않지만, 한 달 치를 한 번에 처리한다면 아마 꽤 스트레스받을 것입니다." 이 스트레스는 타이핑 속도 문제가 아닙니다. 일괄 작업은 단일 문서 작업에서는 발생하지 않는 결정을 도입하기 때문입니다. 파일 이름을 어떻게 지정할지, 120개의 개별 결과를 어떻게 하나의 테이블로 만들지, 그리고 더미 한가운데 숨어 있는 예외 사항을 어떻게 처리할지가 바로 그것입니다.

일괄 처리의 수학: 120개 여정의 실제 비용

일괄 처리의 첫 번째 효과는 시간 문제를 비용 문제로 바꾸는 것입니다. GBTA가 10년 동안 이 문제를 측정해 왔기 때문입니다. 비용 보고서 문제점에 관한 재단 연구에서 GBTA는 단일 비용 보고서 처리에 $58의 비용과 20분의 시간이 소요되며, 수동으로 작성된 보고서의 19%에 오류가 포함되어 각각 $52와 18분의 추가 수정 비용이 발생한다는 사실을 발견했습니다.

월 120건의 여정 기준으로 이 벤치마크는 약 $6,960의 처리 비용이 발생하며, 그중 약 23건의 보고서에 오류가 포함되어 추가로 $1,196의 수정 비용이 발생합니다. 타이핑 자체는 비용의 절반도 되지 않습니다.

항공료는 또한 일비(per-diem) 단축이 없는 유일한 여행 비용입니다. GSA 일비(per-diem) 요금을 사용하면 영수증을 수집하지 않고도 숙박과 식비를 일일 정액으로 상환할 수 있습니다. 그러나 항공편에 대한 일비(per-diem)는 없습니다. 여정 영수증은 매번 실제로 발급된 것이어야 하며, 항목별로 명시되어 있고, 읽기 쉬워야 합니다. 이 단순한 사실 때문에 항공 여정은 전체 T&E 마감에서 가장 중요도가 높은 문서가 됩니다. 120건이면 일비로 간단히 처리할 수 없는 120개의 영수증이 된다는 뜻입니다.

따라서 일괄 처리는 단순히 "같은 작업을 더 많이 반복하는 것"이 아닙니다. 한 번에 하나씩 처리할 때는 존재하지 않는 세 가지 과제가 있는 워크플로우입니다: 명명 규칙, 결과 병합, 그리고 예외 처리입니다. 각각은 단순한 볼륨의 부산물이 아니라 설계 결정입니다.

출력 열 세트를 한 번만 정의하면 120개 모두에 적용됩니다

무엇보다 먼저 최종 테이블에 어떤 내용이 들어가야 할지 결정합니다. 이것이 맞춤 열 추출의 핵심입니다. 도구에 페이지에서 찾을 위치를 알려주는 방식 대신, 원하는 열 이름을 입력하면 AI 비전 모델이 필드의 의미를 이해하여 문서의 어느 위치에 있든 각 값을 찾아냅니다. 한 번 정의한 열 이름은 출력 스프레드시트의 정확한 헤더가 되며, 동일한 세트로 배치 내 모든 항공사, 모든 GDS, 모든 예약 도구의 문서를 읽을 수 있습니다.

여행 지출 대시보드용으로 만든 열 세트는 단일 비용 정산에 필요한 것 이상을 포함합니다. 대시보드는 차원이 좋을수록 가치가 있기 때문입니다. 직원 일정 배치에 실용적인 세트는 다음과 같습니다:

이 중 두 열은 단순히 페이지를 읽는 것 이상의 역할을 합니다. 계산 열은 추출 중 계산을 수행합니다. 왕복 또는 다구간 티켓의 경우 구간별 운임이라는 열이 하나의 운임을 구간별로 자동 분할하여, 구간별 비용이 이중 계산되지 않고 올바르게 집계됩니다. 추론 열은 문서에 명시되지 않은 내용을 분류합니다. "출장 목적"을 "고객 방문 / 회의 / 내부 회의 / 교육 / 개인"과 같은 옵션으로 정의하면, AI가 노선, 날짜, 예약 맥락을 바탕으로 각 일정에 목적을 할당합니다. "코스트 센터"도 마찬가지입니다. 추출과 분류가 한 번에 이루어집니다 — 이것이 숫자 표와 대시보드 준비 완료 데이터셋의 차이입니다.

배치가 그 비용을 충분히 보상받는 순간입니다. 단일 일정표에 적용되는 동일한 열 세트 — 전체 워크플로는 항공 일정표 데이터를 Excel로 추출하는 단계별 가이드에 나와 있습니다 — 를 한 번의 업로드로 전체 스택에 적용합니다. 항공사별 템플릿도, 형식별 규칙도, United 영수증이 Delta와 다르게 보인다고 필드를 다시 정의할 필요도 없습니다.

명명 규칙: 모든 행을 사람과 출장에 추적 가능하게 유지하기

단일 문서 튜토리얼에서는 아무도 언급하지 않는 배치 문제가 있습니다. 120개의 행이 하나의 스프레드시트에 들어가면, 어떤 행이 어떤 직원, 어떤 출장, 어떤 카드 결제에 속하는지 알아야 합니다. 수동 워크플로는 파일 명명으로 이를 해결합니다 — Smith_J_2026-08-12_UA123.pdf — 그리고 그 규율은 가장 중요한 순간, 월말 압박 속에서 정확히 무너집니다.

배치의 명명 규칙에는 두 가지 층이 있습니다. 첫째, 파일 수준: 직원과 재무팀이 문서를 대기열에 넣기 전에 부르는 이름을 표준화합니다 — 간단한 [성]_[이름 이니셜]_[날짜]_[항공사].pdf 패턴이면 충분합니다. 둘째, 데이터 수준: 출력 테이블은 자체 추적성을 갖습니다. 배치 추출은 병합 결과에 원본 파일 이름을 열로 유지하기 때문입니다 — itinerary.pdf 파일로 가득 찬 폴더도 감사 준비 상태를 유지합니다.

하지만 진정한 추적성의 핵심은 레코드 로케이터입니다. 이는 전체 T&E 데이터셋의 자연스러운 기본 키입니다. 동일한 레코드 로케이터가 예약 도구, e-티켓 영수증, 법인 카드 피드에 나타납니다. 추출된 모든 행이 이를 포함하면, 배치를 카드 거래와 대조하는 작업은 더 이상 추측 게임이 아닙니다.

이를 무너뜨리지 않게 하는 한 가지 규칙: 배치 중간에 열 세트를 절대 변경하지 마십시오. 60개 행이 추출된 후 열을 추가하면 두 개의 스키마를 가진 테이블이 생성됩니다 — 병합된 스프레드시트의 전형적인 "열이 왜 정렬되지 않았지" 실패입니다. 세트를 한 번 결정하고, 한 달 전체를 추출한 다음, 필요하면 다음 달 배치를 위해 반복하십시오.

직원을 쫓지 않고 120개 일정을 한 번에 수집하는 방법

추출이 시작되기 전에 문서가 한곳에 모여 있어야 합니다. 한 달간의 출장이면 일정은 세 가지 형태로 도착합니다. 이메일로 전달된 PDF, 항공사 앱이나 예약 도구에서 캡처한 스크린샷(항공사 앱 캡처 워크플로는 항공사 확인 화면에서 데이터 추출에 대한 별도 가이드가 있습니다), 그리고 기업 출장 포털에서 다운로드한 확인서입니다. 탑승권 자체가 네 번째 캡처 대상입니다. 여행자가 게이트에서 찍는 탑승권 스크린샷에는 일정에는 없는 게이트, 탑승 시간, 좌석 정보가 담겨 있습니다. 어떤 여행자는 즉시 업로드하고, 어떤 여행자는 카드 명세서가 도착할 때까지 기다립니다. 수집 단계가 배치 완료 여부를 결정하며, 대부분의 수동 워크플로가 계획하지 못하는 단계이기도 합니다.

두 가지 메커니즘이 이 격차를 해소합니다. 이메일 수신함은 팀 전용 전달 주소를 제공합니다. 여행자가 일정 PDF를 전달하면 첨부 파일이 자동으로 처리 대기열에 들어옵니다. 업로드 페이지도 로그인도 필요 없습니다. 바인딩된 추출 템플릿으로 '자동 처리'를 켜면 각 일정이 도착하는 즉시 읽히기 시작하므로, 월간 배치가 출장이 발생하는 대로 스스로 조립되고 처리되어 월말에 몰아서 처리할 필요가 없습니다. 링크를 선호하는 여행자를 위해 수집 링크는 짧은 인증 코드가 포함된 공유 가능한 URL을 생성합니다. 누구나 열어서 일정을 넣을 수 있습니다. 스크린샷, PDF, 무엇이든 상관없습니다. 계정이 필요 없습니다. 두 채널 모두 동일한 대기열로 연결되므로, 배치는 마감 주에 이메일 스레드를 재구성하는 대신 월중에 지속적으로 구축됩니다.

소스 품질은 예측 가능한 순서를 따릅니다. 항공사 이메일의 PDF가 가장 깨끗한 입력이고, 평평하고 조명이 좋은 일정 페이지 스크린샷도 거의 동일하게 잘 작동합니다. 공항 조명에서 급하게 찍은 휴대폰 화면 사진은 사용할 수 있지만 검증 과정을 거칠 가치가 있습니다. 현실적인 기대치를 설정하세요. 선명한 PDF와 스크린샷은 도구의 약 99% 인쇄 텍스트 정확도로 추출되며, 거친 캡처는 작업을 '타이핑'에서 '스팟 체크'로 전환합니다.

전체 배치를 한 번에 처리 — 스프레드시트 하나, 병합 불필요

이것이 배치 처리로 결산의 경제성을 바꾸는 지점입니다. 이메일 PDF, 앱 스크린샷, 포털 다운로드 등 120개의 여정을 한 번에 업로드하면, 출력은 각 행이 항공편 구간 하나이고 각 열이 정의한 필드 하나인 단일 Excel 파일입니다. 별도 결과 파일 병합, 120개 다운로드 간 열 정렬, 워크북 간 복사-붙여넣기가 필요 없습니다. ImageToTable.ai는 페이지당 5~10초를 처리하는 반면 평균 수동 입력은 약 3분이 걸립니다. 제품이 제시하는 효율 차이는 약 18배로, 120개 문서 배치가 6시간의 타이핑 대신 약 15분의 처리로 줄어듭니다.

병합 문제 — "완료"를 "실제로 사용 가능한 상태"로 바꾸는 그 문제 — 는 병합이 처음부터 배치에 내장되어 있기 때문에 사라집니다. 테이블 하나, 일관된 스키마 하나, 모든 행이 파일명 열을 통해 원본 문서로 추적 가능합니다. 대안과 비교해 보세요. 각 여정을 개별 처리하고, 120개 결과를 다운로드하고, 열 정렬을 수동으로 맞추는 방식 — 이는 결산을 자동화한 것이 아니라, 타이핑을 스프레드시트 수술로 바꾼 것에 불과합니다.

배치이므로 검토도 확장되어야 합니다. 검토 모드를 사용하면 재무 검토자가 추출된 셀 위에 마우스를 올리면 원본 문서에서 값이 나온 위치 — 운임 기준, 세금 항목, 티켓 번호 — 가 여정 이미지에서 강조 표시됩니다. 120행 테이블에서 워크플로는 다음과 같습니다. 이상치를 스캔하고, 의심스러운 셀을 클릭하고, 출처 영역을 확인하고, 완료. 처리 후 자동 주석을 켜면 모든 추출 결과에 검증 맵이 이미 구축되어 제공되므로, 샘플 점검은 5분 작업이지 전체 재감사가 아닙니다.

스프레드시트에서 출장 지출 대시보드까지

배치 처리의 진짜 가치는 스프레드시트 자체가 아니라, 이제 그 스프레드시트가 답할 수 있는 질문에 있습니다. 출장 지출 대시보드에는 차원(dimension)과 측정값(measure)이 필요한데, 추출된 테이블이 그 둘을 모두 제공합니다. 승객명, 코스트 센터, 출장 목적은 차원으로, 기본 운임, 세금, 총 지불액은 측정값으로, 탑승일과 도시 쌍은 시간 및 경로 축으로 사용됩니다. 이러한 구조는 피벗 테이블이나 Tableau, Power BI 같은 BI 도구가 기대하는 바로 그 형식입니다.

이 데이터에서 세 가지 대시보드 보기가 거의 공짜로 얻어집니다. 부서 및 목적별 지출 — 추론된 출장 목적 및 코스트 센터 열 덕분에 CFO는 직원들이 보고서를 올바르게 태그하도록 요청하지 않아도 고객 방문, 컨퍼런스, 내부 교육에 각각 얼마나 많은 항공료가 사용되었는지 확인할 수 있습니다. 도시 쌍 경제성 — 공항 열 덕분에 "SFO–JFK에 많은 비용을 쓴다"는 말이 실제 숫자로 바뀌며, 이는 항공사와의 협상이나 예약 정책 재검토의 기초 자료가 됩니다. 운임 대 세금 분류 — 기본 운임, 세금, 총액이 별도의 열로 분리되어 있기 때문에 대시보드는 카드 청구 금액이 광고된 운임과 일치하지 않는 이유를 설명하고, 모든 감사자가 묻는 질문을 포착합니다: 이 청구 내역이 조정되었는가?

마지막 요점은 대시보드를 비용 플랫폼에 다시 연결합니다. Concur 또는 Navan을 사용하는 기업에서는 추출된 테이블이 항공권 라인 항목에 직접 매핑됩니다. 레코드 로케이터와 티켓 번호는 카드 피드 매칭이 의지할 수 있는 기준을 제공하고, 총 지불액은 법인 카드 거래와 연결됩니다. Expensify나 Zoho Expense를 사용하는 소규모 팀의 경우 동일한 워크북이 가져오기 소스 역할을 합니다. 두 경우 모두 패턴은 동일합니다: 경비 보고서 데이터가 사전 구조화된 형태로 도착하여 누군가가 PDF를 직접 입력해야 할 필요가 없으며, 일정표에 적용한 것과 동일한 배치 처리를 같은 월간 문서 더미에 있는 호텔 청구서에도 적용할 수 있습니다.

예외 처리: 실제 120건 배치에서 발생하는 문제

120건의 여정이 모두 깔끔한 경우는 없지만, 예외 목록은 한정적입니다. 그리고 워크플로의 신뢰성은 각 예외가 어떻게 처리되는지에 달려 있습니다. 즉, 보이지 않는 격차로 드러나거나, 잘못된 합계에 조용히 흡수되지 않아야 합니다.

누락된 여정. 개인 카드로 예약하거나 기업 채널 외부에서 예약한 여행은 여정이 첨부되지 않은 카드 청구를 발생시킵니다. 배치 처리는 도착하지 않은 문서를 수정할 수 없습니다. 해결책은 수집 설계에 있습니다. 위에서 설명한 이메일 수신함과 수집 링크, 그리고 추출된 행을 카드 피드와 대조하고 후속 조치를 위해 일치하지 않는 청구를 나열하는 대사 확인 절차가 그것입니다. 이것은 r/Accounting이 반복되는 마감 고통으로 지적하는 월말 루프와 정확히 같습니다. 차이점은 추출 표면 덕분에 누락된 항목이 막연한 의심이 아닌 눈에 보이는 목록으로 드러난다는 점입니다.

합계만 있는 영수증. 일부 예약 도구와 항공사는 합계만 표시된 요약을 보냅니다. 추출은 보이는 것을 포착하고 운임 분할 열은 비워 두어 숫자를 임의로 만들지 않고 격차를 드러냅니다. 항공사 포털에서 레코드 로케이터를 사용하여 전체 e-티켓 영수증을 받아 해당 문서 하나를 다시 처리하세요.

다중 구간 및 왕복 운임. 왕복 항공권은 한 영수증에 두 개의 항공편명이 있고, 경유가 있으면 더 많아집니다. 추출은 구간별로 하나의 행을 생성하고, 계산된 구간별 운임 열이 단일 운임을 각 구간에 분할합니다. 따라서 검토자는 승인 전에 구간과 세금의 합계가 총액과 일치하는지 확인할 수 있습니다.

통화 불일치. 프랑크푸르트-시카고 티켓이 유로로 가격이 책정되었는데 카드는 달러로 청구되는 경우가 있습니다. 통화 열은 원래 금액과 ISO 코드를 보존하므로 팀은 입력자가 우연히 사용한 환율이 아닌 정책에 정의된 하나의 환율로 환산합니다.

중복 제출. 동일한 레코드 로케이터가 배치에 두 번 나타나는 경우는 재업로드이거나 실제 중복 청구입니다. 레코드 로케이터가 열이므로 중복 제거는 필터 하나로 해결됩니다. 120개 행을 눈으로 일일이 확인하며 반복 티켓 번호를 찾을 필요가 없습니다.

저품질 캡처. 여정 화면을 비스듬히 찍은 휴대폰 사진은 추출 신뢰도를 떨어뜨립니다. 솔직한 기대치는 다음과 같습니다. 깨끗한 PDF는 약 99% 정확도로 추출되고, 거친 캡처는 검토 모드에서 표본 점검이 필요합니다. 그래도 처음부터 직접 입력하는 것보다 훨씬 빠릅니다.

배치 규모에 맞춰 확장되는 규정 준수

규정 준수 측면에서 배치 정확도는 더 이상 효율성 문제가 아니라 법적 문제가 됩니다. IRS 간행물 463에 따르면, 회사가 실비 정산 제도를 운영하는 경우에만 직원에게 환급이 비과세 처리됩니다. 이 제도는 모든 지출의 금액, 시간, 장소, 업무 목적을 입증해야 하며, 지출 시점 또는 그에 준하는 시점에 기록을 작성해야 합니다. 추출된 각 행에는 네 가지 요소가 포함됩니다: 금액, 시간, 장소, 목적. 120개 행에서 이러한 일관성은 감사 파일과 감사 지적 사항을 가르는 기준이 됩니다.

국제적 측면에서는 엄격한 기한이 추가됩니다. EU 부가가치세 환급 제도에 따라, 청구는 일반적으로 VAT가 발생한 연도의 다음 해 9월 30일까지 전자 포털을 통해 제출됩니다. 일부 회원국은 더 이른 제출을 요구합니다. 2026년 6월에 프랑크푸르트나 파리로 출장을 보낸 직원이 있는 회사는 해당 기한까지 티켓 수준의 VAT 데이터를 검색 가능한 상태로 유지할 법적 의무가 있습니다. 구조화된 배치 테이블은 VAT 환급 파일에 필요한 정확한 형식이며, 1년 후 보관된 PDF에서 재구성하는 대신 여행이 발생한 달에 이미 완성되어 있습니다.

FAQ

배치 추출이 모든 항공사나 예약 도구의 여정 일정에서 작동하나요?

네. 추출은 템플릿 위치가 아닌 의미로 필드를 매칭하므로 항공사별 설정이 필요 없습니다. United e-티켓 영수증, Delta 영수증, Concur Travel 또는 Navan의 예약 도구 여정 일정 모두 동일한 배치의 동일한 열 정의로 처리됩니다. 선명한 PDF와 평면 스크린샷이 가장 높은 정확도로 추출되며, 항공사 간 레이아웃 차이는 문제가 되지 않습니다.

추출된 테이블은 Concur, Navan 또는 Expensify에 어떻게 연동되나요?

이 도구는 이들 플랫폼과 함께 작동합니다. 비용 플랫폼은 승인, 정책, 환급 엔진입니다. 여러 항공사와 여러 형식의 여정 일정 더미를 읽도록 설계되지 않았습니다. 추출된 워크북은 구조화된 입력입니다. 각 행에는 운임 분할, 티켓 번호, 레코드 로케이터, 날짜, 경로, 출장 목적이 포함되며, 이를 수기로 입력하는 대신 항공료 라인 항목으로 가져오거나 붙여넣습니다. 입력 데이터가 깨끗할수록 플랫폼에서 필요한 수동 수정이 줄어듭니다.

일부 여정 일정에 운임 내역이 아닌 총액만 표시되면 어떻게 하나요?

추출은 문서에 표시된 내용을 포착하고 누락된 운임 분할 열은 비워 두며, 추측하지 않고 공백을 표시합니다. 전체 내역을 얻으려면 레코드 로케이터를 사용해 항공사 포털에서 e-티켓 영수증을 받으세요. 대부분의 항공사가 온라인으로 조회를 허용합니다. 해당 문서를 대신 처리하면 됩니다. 큰 운임의 경우 이 작업을 수행할 가치가 있습니다. 기본 운임과 세금 분할이 카드 청구를 조정 가능하게 만들고 대시보드의 운임 대 세금 보기에 반영되기 때문입니다.

개인 카드로 예약한 직원은 어떻게 처리하나요?

여정 일정은 여전히 영수증입니다. 추출은 운임, 세금, 티켓 번호, 승객명을 동일한 방식으로 포착하며, 승객명 열은 티켓이 청구인 소유임을 확인합니다. 월초에 출장 직원에게 수집 링크를 보내면 이 과정이 간편해집니다. 직원은 공항에서 휴대폰으로 여정 일정을 업로드하고, 데이터는 몇 주 후 전달된 PDF에서 재구성되는 대신 대기열에 바로 들어옵니다. 탑승구에서 촬영한 캡처도 동일하게 작동합니다. 탑승권 스크린샷은 여행자가 이미 들고 있는 탑승권에서 승객명, 항공편명, 게이트, 좌석을 추출합니다.

항공권 120장 배치를 처리하는 데 비용이 많이 들까요?

처리는 플랜의 월간 포인트 허용량을 사용합니다 — 다른 추출과 동일한 할당량이며, 이 도구의 명시된 효율은 수동 입력보다 약 18배 빠릅니다. 중요한 비용 비교 기준은 GBTA 벤치마크입니다: 수동 처리 시 보고서당 $58, 오류당 $52가 들던 시절, 120장의 항공권이 포함된 한 달은 인건비와 수정 비용으로 수천 달러가 들었지만, 이제는 처리 할당량의 일부와 짧은 검토 과정만으로 해결됩니다.

처리 후 데이터는 어떻게 되나요?

병합된 스프레드시트를 Excel, CSV 또는 JSON으로 내보낼 수 있습니다 — 다운스트림 요구 사항에 맞게 선택하세요. 웹 도구를 통해 업로드된 파일은 안전하게 처리되며 세션 대기열 이후에는 저장되지 않습니다. 구조화된 출력은 비용 시스템, 대시보드 또는 감사 파일에 보관할 수 있습니다.