XML 인보이스를 받아도
수동 AP 데이터 추출이 끝나지 않는 이유

블랙박스: XML 인보이스가 수신함에 도착한 후 어떤 일이 벌어질까

전자 인보이스는 단순한 디지털 문서가 아닙니다. 이는 유럽 표준 EN 16931(2017년 유럽 표준화 위원회(CEN/TC 434) 발행)에 따라 기계가 읽을 수 있는 필드에 인보이스 정보를 담은 구조화된 XML 또는 UBL 파일, 즉 데이터 페이로드입니다. 이 표준은 160개 이상의 의미론적 데이터 필드(인보이스 번호, 발행일, 판매자 및 구매자 세금 식별자, 라인 항목 수량, 단가, VAT 카테고리, 결제 조건, 배송 주소 등)를 정의합니다. 이론적으로 이 구조화된 페이로드는 공급업체 시스템에서 구매업체의 ERP로 직접 흘러들어가야 하며, 사람의 눈, 키보드, 복사-붙여넣기 과정이 필요 없어야 합니다.

하지만 이 이론은 첫 단계인 '귀사의 ERP'에서 무너집니다.

SAP, Oracle NetSuite, Microsoft Dynamics 365, Workday 등 대부분의 ERP 시스템은 원시 EN 16931 XML을 기본적으로 수용하지 않습니다. 이들은 자체 내부 형식, 자체 필드 이름에 매핑된 인보이스 데이터를 자체 API 또는 가져오기 템플릿을 통해 기대합니다. Peppol BIS 3.0 인보이스가 <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>와 같은 태그 구조의 UBL 2.1 XML로 도착하면, 귀사의 ERP는 Invoice Type이라는 필드에 Commercial Invoice 값을 기대합니다. 누군가(또는 무언가)가 이를 변환해야 합니다. 이 변환 계층이 전자 인보이스 내러티브에서 해결된 문제로 취급되는 부분입니다. 그러나 많은 AP(미지급금) 팀에게 이는 해결된 문제가 아닙니다. 수작업이 사라지는 것이 아니라, 그 장소가 이동했을 뿐입니다.

2019-2025년을 다루는 Billentis/EESPA 시장 보고서에 따르면, EDI 또는 이와 동등한 네트워크를 통해 구조화된 전자 인보이스를 발송하는 기업은 20% 미만입니다. 약 2/3의 기업은 이메일로 PDF 인보이스를 발행합니다. XML 인보이스를 수신하는 기업 중에서도, 데이터가 중간 단계(미들웨어 플랫폼, Peppol 액세스 포인트, 통합 계층 또는 여전히 수동 입력을 하는 66%의 AP 팀의 경우 XML의 시각적 표현을 읽고 화면에 입력하는 사람의 눈) 없이 ERP에 도달하는 경우는 드뭅니다. 전자 인보이스는 구조화되어 있습니다. 하지만 마지막 단계는 그렇지 않습니다.

전자세금계산서 1장, 필드 164개, 실제 필요한 건 6개

EN 16931은 전자세금계산서가 반드시 포함하거나 포함할 수 있는 항목을 규정하며, 그 목록은 방대합니다: 판매자 및 구매자 법인, 세무 대리인, 수취인, 배송 정보, 지시 사항, 할인 및 추가 요금 세부 정보, 라인 항목별 세액 breakdown, 계산서 기간, 주문 참조, 계약 참조, 프로젝트 참조 등. 완전히 채워진 EN 16931 계산서는 여러 계층적 중첩 수준에 걸쳐 100개가 훨씬 넘는 개별 데이터 포인트를 포함합니다.

귀하의 AP팀에 필요한 것은 그중 6개입니다.

ERP가 전기(Posting)를 위해 실제로 요구하는 필드 — 공급업체명, 계산서 번호, 계산서 발행일, 순 금액, 부가세액, 만기일 — 은 XML에 포함된 내용의 극히 일부에 불과합니다. 나머지 150개 이상의 필드는 잡음(noise)입니다. 이는 세무 당국 검증, Peppol 네트워크 라우팅 로직, 공급업체의 기록 보관 규정 준수를 위해 존재합니다. 귀사를 위해 존재하는 것이 아닙니다. 그러나 전체 XML을 가져오는 모든 통합은 이 모든 필드를 끌어들이며, 누군가는 모든 공급업체, 모든 국가, 모든 XML 스키마 변형에 대해 매핑, 검증 및 유지보수해야 합니다.

이 현실은 대부분의 전자세금계산서 ROI 모델이 놓치는 역설적인 경제 문제를 지적합니다. 수십 또는 수백 개의 공급업체에 걸쳐 전체 XML 스키마 매핑을 설정하고 유지하는 비용은 XML, PDF 또는 이미지 등 어떤 문서 형식에서든 필요한 6개 필드만 추출하는 비용을 초과할 수 있습니다. 전자세금계산서 인프라는 세무 당국의 정보 격차를 해소하기 위해 구축되었습니다. 귀사 AP팀의 데이터 추출 격차를 해소하기 위해 구축된 것이 아닙니다. 이는 서로 다른 두 가지 문제이며, 첫 번째 문제를 해결한다고 두 번째 문제가 자동으로 해결되지는 않습니다.

Vertex의 2025년 전자세금계산서 연구 보고서는 의무 시장의 기업들을 대상으로 조사한 결과, 기술 통합이 응답자의 55%에게 가장 큰 고충으로 꼽혔으며, 여러 국가에서 운영되는 기업의 경우 63%로 상승한다고 밝혔습니다. 전체 응답자의 절반은 데이터 거버넌스를 중요한 우려 사항으로 지목했습니다. 이는 전자세금계산서 도입에 실패한 기업들이 아닙니다. 도입했지만 그 이후의 문제를 처리하고 있는 기업들입니다.

네 국가, 네 가지 XML 방언, 하나의 AP 수신함

EN 16931은 표준이지 형식이 아닙니다. 이는 송장 필드의 의미를 정의하며 UBL 2.1과 UN/CEFACT Cross Industry Invoice(CII) 두 가지 구문을 허용합니다. 각 국가는 자체 CIUS(핵심 송장 사용 명세서)를 발행하여 국가 세무 규정에 맞게 표준을 조정하고 필드 요구 사항을 추가하거나 강화합니다. 그 결과 구조적으로 다른 네 가지 XML 스키마가 동일한 수신함에 도착할 수 있으며, 모두 "EN 16931 준수"라고 주장하지만 서로의 가져오기 매핑과는 호환되지 않는 상황이 발생합니다.

귀사가 독일, 프랑스, 이탈리아, 폴란드에서 사업을 운영한다면(수천 개의 중견 유럽 기업을 설명하는 범위), AP 수신함에는 모두 전자 송장이라고 주장하는 구조적으로 다른 네 가지 XML 스키마가 도착합니다. 네 개의 별도 가져오기 매핑, 네 세트의 검증 규칙, 그리고 국가 세무 당국이 스키마를 업데이트할 때마다 중단되는 네 개의 유지 관리 파이프라인이 필요합니다. 업데이트 주기는 이론적이지 않습니다. 폴란드의 KSeF가 FA(2)에서 FA(3)로 마이그레이션되면서 모든 통합 시스템이 필드 정의를 다시 매핑해야 했습니다. 프랑스는 2025년 파일럿 단계와 2026년 본격 시행 사이에 PPF 요구 사항을 업데이트했습니다. 독일의 XRechnung 사양은 2026년 초 기준 버전 3.0.1입니다.

이는 전자 송장 발행에 반대하는 주장이 아닙니다. 구조화된 데이터를 수신한다는 것이 귀하의 구조로 데이터를 수신한다는 가정에 반대하는 주장입니다. EN 16931 표준은 귀하의 공급업체 ERP와 귀하의 ERP 간의 상호 운용성이 아닌, 세무 당국 간의 상호 운용성을 위해 설계되었습니다.

사라지지 않는 PDF

전자 인보이스 의무화 일정이 가속화되고 있습니다. 벨기에는 2026년 1월에 거의 전면적인 적용 범위로 시행에 들어갔습니다. 폴란드는 2월에 대규모 납세자를 대상으로 뒤를 이었습니다. 프랑스는 2026년 9월에 대기업 및 중견기업을 대상으로 시행합니다. 독일의 B2B 의무화는 2028년까지 단계적으로 도입됩니다. 각 마감일과 법적 근거에 대한 자세한 내용은 유럽 전자 인보이스 의무화 타임라인을 참조하세요.

그러나 모든 의무화에는 예외가 있고, 그 예외는 어떤 예정된 마감일로도 제거되지 않는 PDF 잔재를 만들어냅니다. 그 패턴은 모든 관할권에서 일관됩니다:

• 국경 간 공급업체는 면제됩니다. 미국이나 중국 공급업체로부터 인보이스를 받는 독일 기업은 어떤 EU 전자 인보이스 의무화의 적용을 받지 않습니다. 그런 공급업체들은 계속해서 PDF, 이메일 첨부 파일, 종이 인보이스를 무기한으로 보낼 것입니다.
• B2C 거래는 제외됩니다. 소비자 인보이스, 영수증, 소매 거래는 구조화된 전자 인보이스 범위에서 완전히 벗어나 있으며, 그럼에도 이러한 문서는 비용 정산을 위해 지급계정(매입채무) 워크플로에 자주 유입됩니다.
• 소기업은 일정이 늦춰지거나 영구 면제를 받습니다. 프랑스는 소기업의 발행 의무를 2027년 9월로 연기합니다. 독일의 매출 기준 단계적 도입은 일정 매출 이하의 기업에는 의무가 전혀 없음을 의미합니다. 이러한 기업들은 종종 이미 처리 시간이 가장 많이 걸리는 롱테일 공급업체입니다.
• 기존 공급업체 관계는 하룻밤 사이에 전환되지 않습니다. 2015년에 EDI로 통합된 공급업체는 Peppol BIS 3.0으로 전환할 유인이 없을 수 있습니다. 그들의 PDF 워크플로는 잘 작동합니다. 귀사의 의무화는 그들의 시스템을 바꾸지 않습니다 — 바뀌는 것은 보고 의무이지, 그들의 형식 의무가 아닙니다.

Ardent Partners의 데이터는 그 규모를 확인해 줍니다: 인보이스의 51.4%만 전자적으로 도착하며, 이 수치는 20년간의 전자 인보이스 발전을 반영합니다. 나머지 48.6% — PDF 첨부 파일, 스캔한 종이, 이메일 본문, 팩스 — 는 어떤 의무화 타임라인도 0으로 만들 수 없는 구조적인 인보이스 물량의 절반을 차지합니다. SdI 시스템이 2019년부터 의무화되어 연간 20억 건 이상의 전자 인보이스를 처리하는 이탈리아에서도 국경 간 PDF 인보이스는 매일 계속 도착합니다. 의무화는 정부 보고를 보장합니다. 깨끗한 지급계정(매입채무) 받은 편지함을 보장하지는 않습니다.

Gennai의 2026년 인보이스 자동화 현황 보고서에 따르면 완전 자동화를 달성한 재무 팀은 8%에 불과합니다. 8%입니다. 20년간의 전자 인보이스 개발, 수십억 달러의 시장 투자, 13개의 유럽 의무화 시행 이후에도 말입니다. 이 격차는 일시적인 불편이 아닙니다. 이는 글로벌 지급계정(매입채무) 기능의 영구적인 운영 조건입니다.

두 세계를 위한 단일 파이프라인

AP팀이 XML 송장용 워크플로우와 PDF 송장용 워크플로우를 따로 운영한다면, 송장 처리를 자동화한 것이 아닙니다. 유지 관리해야 할 워크플로우 수를 두 배로 늘린 것뿐이며, 각각 고유한 중단 지점, 통합 표면, 교육 요구사항을 갖게 됩니다. 대안은 전자송장 규정 준수를 포기하는 것이 아닙니다. 구조화된 XML과 비구조화된 PDF를 동일한 기준으로 처리하고, 어떤 형식이 들어오든 동일한 출력 스키마를 생성하는 단일 추출 파이프라인을 운영하는 것입니다.

이것이 바로 열 이름 추출 모델이 설계된 접근 방식입니다. 국가별 XML 스키마 매핑을 구축하는 대신, ERP가 실제로 필요로 하는 필드 — 공급업체, 송장 번호, 날짜, 순액, 부가세, 납기일 — 를 한 번만 정의합니다. 이 여섯 개의 열 이름은 벨기에 공급업체의 Peppol BIS 3.0 XML, 프랑스 공급업체의 Factur-X 하이브리드 PDF, 중국 제조업체의 스캔 종이 송장, 또는 의무화 대상에 아직 포함되지 않은 국내 중소기업의 이메일 PDF 등 파이프라인에 유입되는 모든 문서의 추출 대상이 됩니다.

메커니즘이 중요합니다. 각 XML 태그 구조에 대한 정확한 지식을 요구하는 스키마 기반 가져오기와 달리, 맞춤 열 추출은 문서의 내용 — 실제 송장 데이터 — 을 읽고 각 필드의 의미를 이해하여 열 정의와 일치하는 값을 찾습니다. XML 계층 구조에서의 위치가 아니라 의미를 기준으로 말입니다. 송장 번호를 <cbc:ID>INV-2026-0451</cbc:ID>로 기록하는 UBL 송장과 오른쪽 상단에 "Invoice INV-2026-0451"을 인쇄하는 PDF는 송장 번호 열에 동일한 추출 결과를 생성합니다. 스키마 매핑 없이, 국가별 구성 없이, 단일 파이프라인으로 처리됩니다.

이 접근 방식이 다양한 송장 형식, 언어 및 숫자 표기법에서 어떻게 작동하는지 자세히 알아보려면 다양한 형식의 송장에서 데이터를 추출하여 하나의 통합 테이블로 만드는 방법에 대한 가이드를 참조하세요.

자주 묻는 질문

전자송장이 데이터 추출의 필요성을 완전히 없애주지 않나요?

사람이 PDF를 읽고 ERP에 값을 입력하는 유형의 데이터 추출은 없앱니다. 하지만 공급업체의 XML 스키마와 ERP의 필드 구조 사이에 데이터 변환 계층이 필요 없다는 의미는 아닙니다. 모든 공급업체와 모든 운영 국가에 걸쳐 이 변환 계층을 구축하고 유지 관리하는 기업에게 전자송장은 완전 자동 처리(straight-through processing)를 실현해줍니다. Ardent Partners 데이터에 따르면 재무팀 중 8%만이 이 상태에 도달했습니다. 나머지 92%에게는 XML과 PDF를 동일한 메커니즘으로 읽는 추출 계층이 두 개의 개별 수동 워크플로우를 하나의 자동화된 워크플로우로 대체해줍니다.

국가별로 XML 가져오기 매핑을 한 번만 구축하면 끝나는 것 아닌가요?

그렇게 하는 조직도 있습니다. 하지만 대부분 초기 추정치가 유지보수 비용을 과소평가합니다. 국세 당국은 스키마를 업데이트합니다 — 폴란드는 FA(2)에서 FA(3)로 마이그레이션했고, 독일의 XRechnung 사양은 버전 3.0.1이며, 프랑스의 PPF 요구사항은 파일럿과 실시 사이에 진화했습니다. 각 변경 사항은 공급업체 기반 전체에 대한 회귀 테스트가 필요합니다. 4개국에서 200개 공급업체와 거래하는 기업에게 매핑 유지보수 프로그램은 일회성 IT 프로젝트가 아닌 반복적인 운영 비용입니다. 시각적 추출 방식은 XML 태그 구조에 의존하지 않음으로써 이를 우회합니다 — 데이터를 전달한 스키마가 아닌 데이터 자체를 읽습니다.

동일한 송장의 XML 버전과 PDF 버전을 모두 보내는 공급업체는 어떻게 하나요?

이는 PDF/A-3 컨테이너 내에 XML 데이터 계층을 포함하는 ZUGFeRD/Factur-X 하이브리드 형식에서 흔히 발생합니다. PDF 계층과 XML 계층은 차이가 있을 수 있습니다 — PDF에는 전체 라인 항목 내역이 포함되어 있지만 XML은 라인 항목이 없는 MINIMUM 프로필이거나, XML은 수정된 버전을 반영하지만 PDF는 원본을 보여줄 수 있습니다. 시각적 추출 방식은 실제 렌더링된 콘텐츠를 읽으며, 이는 AP팀이 보고 검증할 버전입니다. 또한 맹목적인 XML 가져오기가 놓칠 수 있는 불일치를 포착합니다.

XML과 PDF 인보이스가 섞여 있을 때 배치 처리는 어떻게 작동하나요?

통합 추출 파이프라인을 사용하면 배치 처리가 XML과 PDF를 동일한 작업의 두 가지 입력 형식으로 취급합니다. 벨기에 공급업체의 Peppol XML 20개, 국내 공급업체의 이메일 PDF 15개, 해외 공급업체의 스캔 종이 인보이스 5개가 포함된 폴더를 업로드하고, 열을 한 번 정의한 후 단일 실행으로 전체 배치를 처리하면 일관된 열로 40개 인보이스가 모두 포함된 단일 스프레드시트를 받을 수 있습니다. 형식별 사전 분류, 별도의 워크플로, 배치의 PDF 부분에 대한 수동 재입력이 필요하지 않습니다.

이 접근 방식이 Peppol에서도 작동하나요?

네. Peppol은 인보이스 형식이 아닌 전송 네트워크입니다. 실제 파일 형식은 Peppol BIS Billing 3.0에 따라 구조화된 UBL 2.1 XML입니다. 시각적 추출 방식은 Peppol, 이메일, 공급업체 포털 또는 기타 채널을 통해 도착했는지 여부에 관계없이 콘텐츠 계층에서 인보이스 데이터를 읽습니다. Peppol 네트워크는 전달 문제(공급업체에서 사용자에게 인보이스 전송)를 해결합니다. 추출 계층은 데이터 문제(인보이스 데이터를 ERP가 예상하는 구조로 ERP에 입력)를 해결합니다.

진정한 지표

전자 인보이스 업계는 의무 적용 범위(몇 개국, 몇 개 기업, 정부 플랫폼을 통과하는 인보이스 수)로 진행 상황을 측정합니다. 이러한 지표는 세금 준수(정당하고 중요한 목표)를 측정합니다. 그러나 AP 팀이 관심을 갖는 것(오늘 인보이스가 사람이 키보드를 건드리지 않고 ERP에 게시된 수)은 측정하지 않습니다.

전자 인보이스 투자 후 이 두 번째 숫자가 예상보다 낮다면, 잘못된 전자 인보이스 플랫폼을 선택했기 때문이 아닙니다. 전자 인보이스 플랫폼은 다른 문제를 해결하도록 설계되었기 때문입니다. 여러분의 문제는 종이와 디지털 간의 격차가 아닙니다. "올바른 형식으로 도착"과 "올바른 필드로 도착" 사이의 격차입니다. 이는 두 가지 별개의 격차입니다. 첫 번째 격차를 해소한다고 해서 두 번째 격차가 해소되지는 않았습니다.

전자 인보이스 플랫폼과 ERP 사이에 위치한 추출 계층은 완전 자동화된 미래로 가는 임시 다리가 아닙니다. 이는 공급업체 인보이스가 여러 규제 체제 하에 여러 관할권에서 여러 형식으로 도착하는 세상(그리고 앞으로도 그럴 것)에서 영구적인 인프라입니다. 문제는 그 추출 계층이 사람인지, 국가별 XML 매핑의 취약한 집합인지, 아니면 인보이스가 어떻게 도착했는지에 관계없이 내용을 읽는 단일 파이프라인인지입니다.

직접 인보이스로 테스트해 보세요. 동일한 배치에서 XML과 PDF를, ERP가 실제로 필요로 하는 열에 대해 테스트하세요. "수신"과 "게시" 사이의 격차가 전자 인보이스 의무가 항상 암시했던 수준으로 줄어드는지 확인해 보세요.