항공 일정 데이터를 대사하는 방법
수작업 없이

항공권 일정표에 실제로 포함된 정보

전자 항공권 일정표 영수증에는 경비 처리 프로세스에 필요한 모든 항목이 포함되어 있습니다. 문제는 여행자를 위한 형식으로 작성되어 있어 스프레드시트에는 적합하지 않다는 점입니다. 데이터를 추출하기 전에 항공사가 보내는 세 가지 문서 중 어떤 것이 영수증에 해당하는지 아는 것이 도움이 됩니다: 예약 확인서, 전자 항공권 영수증, 그리고 여행 영수증입니다. 경비 정산을 위해 가장 중요한 문서는 전자 항공권 영수증입니다. 실제로 결제된 금액을 입증하는 문서이기 때문입니다. 탑승권은 이 세 문서 모두의 여행 당일 동반 문서로, 승객명, 항공편명, 게이트, 탑승 시간, 좌석 정보를 담고 있으며, 이러한 항목을 시트에 넣어야 할 때는 자체적인 탑승권 스크린샷 추출 가이드가 있습니다.

해당 영수증의 항목은 페이지 레이아웃이 표준화되어 있지 않더라도 항공 업계의 예약 인프라에 의해 표준화되어 있습니다. 각 예약에는 예약 번호가 포함되어 있습니다. "K7FQ2M"과 같은 6자리 참조 번호로, 항공사 시스템 전반에서 일정표, 항공권, 결제를 연결합니다. 그 주변에는 T&E 프로세스에서 실제로 사용하는 데이터 포인트가 있습니다:

이 데이터가 갇혀 있는 이유가 있습니다. 업계 표준 페이지 레이아웃이 없기 때문입니다. IATA는 PNR의 데이터를 정의하지만, 각 항공사, 글로벌 유통 시스템(GDS), 예약 도구는 각자의 문서를 생성합니다. 유나이티드 전자 항공권 영수증은 델타의 것과 다르고, 델타의 것은 Concur Travel 예약으로 생성된 여정표와도 다릅니다. 그래서 "항공편명은 왼쪽 상단에 있다"는 방식의 워크플로는 두 번째 항공사에서 바로 실패합니다.

수동 방식이 실패하는 이유 — 그리고 그 비용

수동 방식은 단지 시간만 소모하는 것이 아니라, 비용 상환(reimbursement)이 의존하는 감사 추적(audit trail)을 끊어버립니다. 팀이 SAP Concur, Navan, 또는 Expensify를 사용한다면 예약 데이터가 자동으로 유입되는 경우가 많지만, 항공요금 항목에는 운임 내역, 항공권 번호, 세금 항목이 들어갈 자리가 비어 있는 채로 남습니다. 특히 출장이 기업 채널 밖에서 예약되었거나 개인 카드로 결제된 경우가 그렇습니다. 누군가 이를 다시 입력합니다. 바로 여기서 조정(reconciliation) 문제가 시작됩니다.

이런 실패 양상은 T&E 주기를 마감해 본 사람이라면 누구나 익숙할 것입니다. 항공편명의 숫자가 뒤바뀌거나, 여러 구간 일정에서 잘못된 구간의 날짜가 입력되면 비용이 더 이상 예약과 일치하지 않게 됩니다. 일치하지 않으면 감사자나 카드 피드 알고리즘이 이를 표시하고, 직원은 재제출을 요청받습니다. r/Accounting에 반복적으로 올라오는 불만이 바로 이 순환을 설명합니다: 한 직원이 같은 항공편을 여섯 번이나 비용 청구하라는 요청을 받았는데, 그 이유는 지급 담당 팀이 시스템 사이에서 영수증을 계속 잃어버렸기 때문입니다. 이 불만의 핵심은 타이핑 속도가 아니라, 문서가 거래에 계속 연결되어 있는 데이터로 전환되지 않는다는 점입니다.

규정 준수의 중요성은 이 문제를 단순한 효율성 불편을 넘어서게 만듭니다. IRS 규정에 따르면, 회사가 실비 정산 제도(accountable plan)를 운영할 때만 직원에게 지급되는 상환이 세금 면제 대상이 됩니다. 이 제도는 모든 비용이 금액, 시기, 장소, 업무 목적에 따라 입증될 것을 요구합니다. IRS는 이를 간행물 463(Publication 463)에 명시하고 있습니다: 각 비용에 대한 영수증과 비용 발생 시점 또는 그 근처에 작성된 기록이 필요합니다. 잘못 입력된 운임이나 누락된 항공권 번호는 수백 건의 출장에 걸쳐 그러한 입증을 조용히 훼손합니다. 그리고 T&E 정확성에 대한 압박은 커지고 있습니다: 2025년 Deloitte 기업 출장 조사(Corporate Travel Study)에서 여행 관리자의 54%가 비용을 출장의 상위 3대 제약 조건 중 하나로 꼽았습니다. 지출에 대한 검토가 강화될수록 영수증이 정확해야 할 필요성도 커집니다.

이 모든 것은 출장자에게도 새로운 소식이 아닙니다. r/SAP의 Concur 관련 게시물은 직원 측 경험을 분명히 보여줍니다: 시스템이 "너무 느려져서 어떤 종류의 비용 보고서든 작성하는 것이 고통스럽다"는 것입니다. 해결책은 더 빠른 UI가 아니라, 재입력 단계를 제거하여 일정 데이터가 이미 구조화된 상태로 도착하게 하는 것입니다.

열 세트 정의: 출력 테이블에 포함할 항목

출력 테이블은 사용자가 지정한 열에 따라 정의됩니다. 항공 일정의 경우 올바른 열 세트는 예약, 운임, 규정 준수를 각 구간별 단일 행으로 처리합니다. 이것이 맞춤 열 추출의 핵심입니다. 도구에 페이지에서 찾을 위치를 알려주는 대신, "예약 번호(PNR)", "항공편명", "총 결제 금액"과 같은 열 이름을 입력하면 AI 비전 모델이 필드의 의미를 이해하여 문서 어디에 있든 각 값을 찾아냅니다.

항공 일정 일괄 처리의 경우 전체 출장비 정산(T&E) 마감을 처리하는 열 세트는 다음과 같습니다. 그대로 복사하여 사용할 수 있습니다.

이 중 두 열은 단순히 페이지를 읽는 것 이상의 역할을 합니다. 계산 열은 추출 중 계산을 수행합니다. 다구간 항공권의 경우 구간별 운임이라는 열이 단일 운임을 각 구간에 자동으로 분배하므로 각 구간의 행을 개별적으로 정산할 수 있습니다. 그리고 추론 열은 문서에 명시되지 않은 내용을 분류합니다. "출장 목적"을 "고객 방문 / 회의 / 내부 미팅 / 교육 / 개인" 옵션으로 정의하면 AI가 일정 — 경로, 예약 맥락, 주변 보고서 — 를 읽고 각 출장에 목적을 할당합니다. 추출과 분류가 동일한 패스에서 이루어지며, 이것이 숫자 표와 정산 가능한 기록의 차이입니다.

한 번 정의한 열 이름은 최종 스프레드시트의 헤더가 됩니다. 각 열이 페이지의 위치가 아닌 의미로 매칭되므로 동일한 열 세트가 배치의 모든 항공사, GDS, 예약 도구에서 작동합니다.

일정을 한곳에 모으기

추출 전, 수집 단계에서 배치가 완전한지 결정됩니다. 대부분의 워크플로가 계획하지 못하는 단계이기도 합니다. 일정은 세 가지 형태로 도착합니다. 이메일에서 전달된 PDF, 항공사 앱이나 예약 도구의 스크린샷, 기업 출장 포털에서 다운로드한 확인서입니다. 일부 여행자는 직접 업로드하고, 일부는 카드 명세서가 도착할 때까지 잊어버립니다. 수집 설계가 두 경우를 모두 처리합니다.

두 가지 메커니즘이 이 격차를 해소합니다. 이메일 받은편지함은 팀 전용 전달 주소를 제공합니다. 여행자가 일정 PDF를 전달하면 첨부 파일이 업로드 페이지나 로그인 없이 자동으로 처리 대기열에 들어옵니다. "자동 처리" 설정과 결합하면 바인딩된 추출 템플릿이 메일이 도착하는 즉시 각 일정을 읽기 시작합니다. 한 달치 항공 이메일이 월말에 몰아서 처리되는 대신 도착하는 대로 변환됩니다. 링크를 선호하는 여행자를 위해 수집 링크는 짧은 인증 코드가 포함된 공유 가능한 URL을 생성합니다. 누구나 계정 없이 열어서 스크린샷, PDF 등 원하는 형식으로 일정을 넣을 수 있습니다. 두 채널 모두 동일한 대기열로 연결되므로 배치가 월중에 지속적으로 구성됩니다.

소스 품질은 간단한 순서를 따릅니다. 이메일의 PDF가 가장 깨끗한 입력이고, 평평하고 조명이 밝은 일정 페이지 스크린샷도 거의 동일하게 작동합니다. 공항 조명에서 각도로 찍은 서두른 휴대폰 사진은 처리 가능하지만 검증 단계를 거칠 가치가 있습니다. 현실적인 기대치를 설정하세요. 선명한 PDF와 스크린샷은 높은 신뢰도의 추출을 생성하고, 품질이 낮은 캡처는 작업을 "입력"에서 "점검"으로 전환합니다.

배치 처리: 한 번에, 하나의 스프레드시트로

배치 처리는 한 달치 일정을 한 번에 단일 스프레드시트로 변환합니다. 문서당 5~10초, 열은 한 번만 정의하면 됩니다. 모든 일정을 한 번에 업로드하면 출력은 각 행이 항공편 구간이고 각 열이 정의된 필드인 단일 Excel 파일입니다. 병합, 열 재정렬, 파일 간 복사-붙여넣기가 필요 없습니다. ImageToTable.ai는 평균 수동 입력 약 3분 대비 페이지당 5~10초를 처리합니다. 이는 100개 일정에서 점심시간과 하루 업무의 차이를 만드는 의미 있는 비교입니다.

이 시점에서 데이터를 확인할 수 있게 됩니다. 검토 모드를 사용하면 재무 검토자가 추출된 셀 위에 마우스를 올려 원본 문서에서 값이 어디서 왔는지 정확히 볼 수 있습니다. 운임 기준, 세금 항목, 항공권 번호가 일정 이미지에서 강조 표시됩니다. 추출된 값을 클릭하면 소스 영역이 켜지고, 문서의 영역을 클릭하면 해당 셀로 이동합니다. 이 계층은 항공운임에 특히 중요합니다. 잘못된 세금 합계가 카드 정산에 그대로 전파되기 때문입니다. 처리 후 자동 주석을 켜면 모든 새 추출에 검증 맵이 이미 구축된 상태로 도착합니다.

스프레드시트에서 실비 정산까지: 마무리 단계

추출은 스프레드시트에서 끝나고, 정산은 그 지점에서 시작됩니다. 추출된 행은 경비 시스템 옆에 놓이는 것이 아니라, 경비 시스템에 바로 연결되도록 설계되었습니다. 배치에서 얻는 워크북은 T&E 플랫폼의 OCR이 깨끗한 영수증에 대해서만 생성했을 구조화된 버전입니다. 운임, 세금, 항공권 번호, 경로, 날짜, 출장 목적이 모두 열로 정리되어 있습니다. 바로 이 구조 덕분에 마무리 단계가 빨라집니다.

Concur 또는 Navan을 사용하는 조직이라면 추출된 테이블이 항공료 라인 항목에 직접 매핑됩니다. 예약 번호(PNR)와 항공권 번호는 카드 피드 매칭이 기준으로 삼을 수 있는 정보를 제공하고, 총 결제 금액은 법인 카드 거래와 연결되며, 운임 분할 내역은 청구 금액이 광고된 운임과 일치하지 않는 이유를 설명해 줍니다. Expensify나 Zoho Expense를 사용하는 소규모 팀이라면 동일한 워크북이 가져오기 소스로 사용됩니다. 행이 들어오고, 카테고리가 지정되고, 실비가 승인됩니다. 핵심은 추출이 경비 플랫폼을 대체한다는 것이 아니라, 경비 보고서 데이터가 사전 구조화된 형태로 도착한다는 점입니다. 누군가가 PDF를 직접 옮겨 적어야 하는 상황이 아니라요.

규정 준수 측면에서도 같은 방식으로 마무리됩니다. 이제 각 추출 행에는 실비 정산 제도(accountable plan)가 요구하는 네 가지 증빙 요소가 포함됩니다. 금액, 시간, 장소, 목적입니다. 많은 기업이 식비와 숙박비에 사용하는 GSA 일비(GSA per-diem) 체계 — 2026 회계연도 기준 미국 본토(CONUS) 숙박비 일비 $110, 식비 및 잡비 일비 $68 — 는 해당 항목을 정액 기준으로 보장합니다. 항공료에는 일비 단축 경로가 없으므로, 항공 일정 영수증은 항상 실제 문서로 증빙해야 하는 유일한 여행 영수증입니다.

실무에서 문제가 되는 경우

현실적인 실패 지점은 특별하지 않습니다. 구간별 운임, 통화 불일치, 변경 수수료 등이며, 각각 정의된 처리 방식이 있습니다. 깨끗한 이메일 PDF 배치는 거의 검토 없이 처리되며, 예외 사항이 바로 워크플로우의 가치를 발휘하는 부분입니다.

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

여정 통화와 카드 통화의 차이입니다. 프랑크푸르트-시카고 티켓이 유로로 책정되었지만 카드는 달러로 청구됩니다. 추출된 "통화" 열은 원래 금액과 ISO 코드를 그대로 유지하므로, 팀은 입력자가 우연히 사용한 환율 대신 정책에 정의된 환율로 환산합니다. 이는 "카드 명세서와 일치하지 않음" 플래그의 반복적인 원인을 제거합니다.

총액만 표시된 영수증입니다. 일부 예약 도구와 항공사는 운임 내역 없이 총액만 표시하는 요약을 보냅니다. 추출은 표시된 내용만 캡처하고 운임 분할 열은 비워 두어, 숫자를 임의로 만들지 않고 차이를 표면화합니다. 해결 방법은 항공사 포털에서 전체 전자 항공권 영수증을 가져오는 것입니다(일반적으로 예약 번호(PNR)를 입력하여 조회 가능). 분할을 추측하는 것이 아닙니다.

변경, 환불 및 저품질 캡처입니다. 변경 후에는 일정과 여행 영수증이 일치하지 않을 수 있습니다. 추출된 행은 두 가지를 나란히 제공하므로 차이가 숨겨지지 않고 명확히 보입니다. 그리고 휴대폰 화면을 비스듬히 촬영한 저품질 사진의 경우 정확도가 떨어집니다. 솔직한 기대치는 깨끗한 입력은 도구의 인쇄 텍스트 정확도 약 99%로 추출되지만, 거친 캡처는 검토 모드에서 점검이 필요하다는 것입니다. 그래도 처음부터 직접 입력하는 것보다 훨씬 빠릅니다.

FAQ

모든 항공사나 예약 도구의 여정에서도 작동하나요?

네. 추출이 템플릿 위치가 아닌 의미로 필드를 매칭하기 때문에 항공사별 설정이 필요 없습니다. 유나이티드 전자 항공권 영수증, 델타 영수증, Concur Travel이나 Navan의 예약 도구 여정 모두 동일한 열 정의로 처리됩니다. 선명한 PDF와 평면 스크린샷은 가장 높은 정확도로 추출되며, 항공사 간 레이아웃 차이는 추출에 영향을 미치지 않습니다.

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

워크플로는 문서에 표시된 내용을 추출하고 누락된 운임 분할 열은 비워 두며, 추측하지 않고 공백을 표시합니다. 전체 내역을 얻으려면 예약 번호(PNR)를 사용해 항공사 포털에서 전자 항공권 영수증을 받아 해당 문서를 대신 처리하세요. 큰 운임의 경우 기본 운임과 세금의 분할이 카드 청구 내역을 대조 가능하게 만들기 때문에 이 작업을 수행할 가치가 있습니다.

추출된 스프레드시트를 Concur나 Navan에 입력할 수 있나요?

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

다른 통화로 예약된 여행은 어떻게 처리하나요?

추출된 테이블에 원래 금액과 ISO 통화 코드를 유지하세요. "통화" 열은 항공권에 표시된 내용을 보존합니다. 입력하는 사람이 우연히 사용한 환율이 아니라 단일 정책 정의 환율로 환산하세요. 이러한 일관성이 여러 통화 배치를 카드 피드와 대조 가능하게 유지합니다.

개인적으로 예약하고 비용을 청구하는 직원은 어떻게 처리하나요?

탑승권이 여전히 영수증 역할을 합니다 — 추출 기능은 운임, 세금, 항공권 번호를 동일한 방식으로 캡처하며, 승객명 열을 통해 해당 항공권이 청구인의 것임을 확인할 수 있습니다. 이때 출장 직원에게 보낸 수집 링크가 효과를 발휘합니다. 직원이 공항에서 휴대폰으로 탑승권을 업로드하면, 데이터가 몇 주 후에 전달된 PDF에서 재구성되는 대신 바로 대기열에 들어옵니다.