XML 전자세금계산서를 받아도
수동 AP 데이터 추출이 끝나지 않는 이유

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

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

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

대부분의 ERP 시스템(SAP, Oracle NetSuite, Microsoft Dynamics 365, Workday)은 원시 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% 미만입니다. 약 3분의 2는 이메일로 PDF 인보이스를 발행합니다. XML 인보이스를 수신하는 기업 중에서도 데이터가 중간 단계(미들웨어 플랫폼, Peppol 액세스 포인트, 통합 계층 또는 여전히 수동 입력을 하는 66%의 AP 팀의 경우 XML의 시각적 표현을 읽고 화면에 입력하는 사람의 눈) 없이 ERP에 도달하는 경우는 드뭅니다. 전자 인보이스는 구조화되어 있습니다. 하지만 마지막 단계는 그렇지 않습니다.

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

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

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

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

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

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

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

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

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

이는 전자송장(e-invoicing) 자체에 대한 반대가 아닙니다. 구조화된 데이터를 받는 것이 곧 당신의 구조로 데이터를 받는 것이라는 가정에 대한 반대입니다. EN 16931 표준은 세무 당국 간의 상호운용성을 위해 설계되었지, 공급업체의 ERP와 귀사의 ERP 간의 상호운용성을 위해 설계된 것이 아닙니다. 국가별 CIUS 계층이 존재하는 이유는 각국의 세법이 서로 다른 필드, 코드, 검증을 요구하기 때문입니다. 세무 수준의 상호운용성은 AP 워크플로 수준의 상호운용성을 보장하지 않으며, 이 두 가지 사이의 간극이 바로 AP 팀이 매일 직면하는 현실입니다.

사라지지 않는 PDF

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

그러나 모든 의무화에는 예외가 있으며, 이러한 예외는 앞으로 어떤 마감일도 없애지 못할 PDF 잔재를 만들어냅니다. 그 패턴은 모든 관할권에서 일관됩니다:

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

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

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는 모두 Invoice # 열에 동일한 추출 결과를 생성합니다. 스키마 매핑이 필요 없습니다. 국가별 구성이 필요 없습니다. 단일 파이프라인입니다.

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

자주 묻는 질문

전자송장이 도입되면 데이터 추출이 완전히 필요 없어지지 않나요?

사람이 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가 실제로 필요로 하는 열에 맞춰 테스트해 보세요. "수신"과 "전기" 사이의 격차가 전자 인보이스 의무가 항상 암시했던 수준으로 줄어드는지 확인해 보세요.