최고의 ZUGFeRD 추출 도구가
송장의 절반을 놓치는 이유
2026년 최고의 ZUGFeRD 추출 도구를 검색하면 거의 모든 목록이 동일한 테스트로 시작합니다. 내장된 XML을 파싱할 수 있는가? 완전한 XML 페이로드를 담은 파일에게는 올바른 질문입니다. 하지만 구매업무팀에게는 잘못된 첫 질문입니다. 답은 공급업체가 실제로 보내는 파일에 달려 있기 때문입니다. 독일은 2025년 1월부터 기업이 구조화된 전자 송장을 수신할 수 있도록 의무화했지만, 발행 의무는 2028년까지 단계적으로 적용됩니다. 전환 기간 동안 수신함에 도착하는 송장의 상당 부분은 여전히 일반 PDF입니다. 진짜 ZUGFeRD 파일이라도 XML 첨부 데이터가 너무 빈약해 회계 처리할 수 없는 경우가 있습니다. XML만 읽는 도구는 송장의 절반이 묻지 않는 질문에 대한 훌륭한 답변일 뿐입니다.

핵심 요약
- 2026년 모든 ZUGFeRD 도구 순위는 사실상 하나의 능력, 즉 PDF에 내장된 XML을 얼마나 잘 파싱하는지에 대한 순위입니다.
- 독일 AP 수신함에 도착하는 송장의 절반은 일반 PDF 또는 스캔 파일이며, 진짜 ZUGFeRD 파일이라도 라인 항목이 없는 MINIMUM 또는 BASIC WL 프로필일 수 있습니다.
- 올바른 후보 목록은 목록 상단의 파서가 아니라 공급업체 구성에서 시작해야 합니다.
ZUGFeRD 파일 안에는 실제로 무엇이 들어 있을까
ZUGFeRD(Zentraler User Guide des Forums elektronische Rechnung Deutschland)는 독일의 하이브리드 전자송장 형식입니다. ISO 19005-3에 따른 PDF/A-3 문서인 단일 파일에는 동일한 송장의 사본 두 개, 즉 사람이 읽고 인쇄하는 가시적 페이지와 임베디드 파일을 허용하는 아카이브 규칙에 따라 PDF 내부에 첨부된 XML 문서가 들어 있습니다. 해당 XML은 UN/CEFACT CII(Cross Industry Invoice) 구문을 따르며 독일에서 법적으로 결정적인 계층입니다. Factur-X는 동일한 표준의 프랑스식 명칭이며, ZUGFeRD 2.1부터 두 표준은 기술적으로 동일하여 독일과 프랑스에서 하나의 사양이 두 이름으로 게시됩니다.
XML은 여러 프로필 중 하나로 작성되며, 프로필에 따라 구조화된 계층에 송장의 얼마나 많은 부분이 실제로 포함되는지가 결정됩니다. 이 부분은 대부분의 도구 비교에서 언급하지만, AP 테이블을 구축하는 사람에게 무엇을 의미하는지는 설명하지 않는 부분입니다.
| 프로필 | XML의 라인 항목 | EN 16931 준수 | §14 UStG에 따른 유효한 전자송장 |
|---|---|---|---|
| MINIMUM | 아니요 | 아니요 | 아니요 |
| BASIC WL(라인 없음) | 아니요 | 아니요 | 아니요 |
| BASIC | 예 | 예 | 예 |
| EN 16931(COMFORT) | 예 | 예 | 예 |
| EXTENDED | 예 | 예 | 예 |
| XRECHNUNG(참조 프로필) | 예 | 예, CIUS로 | 예 |

독일 연방재무부는 ZUGFeRD 2.0.1 이상 버전을 승인하지만 MINIMUM과 BASIC WL은 제외하는데, 이 두 프로필은 준수 전자송장으로 인정되기에는 너무 단순하기 때문입니다. 현재 사양은 FeRD가 프랑스의 FNFE-MPE와 함께 유지 관리하며, 프로필이 XML 내부에 선언된 형태로 게시되어 검증기와 회계 시스템 모두가 읽습니다. 정확한 프로필 규칙과 파일 명명 규칙은 공식 ZUGFeRD 정보 사이트에 문서화되어 있습니다.
XML 첨부 파일의 존재 여부가 아니라 프로필이 ZUGFeRD 파일에 AP 테이블에 필요한 라인 항목이 포함되는지 여부를 결정합니다. MINIMUM과 BASIC WL에는 라인 항목이 전혀 포함되지 않습니다.
XRechnung은 대부분의 실용적 목적에서 ZUGFeRD와 나란히 존재하며 그 내부에 있지는 않습니다. 이는 사람이 읽을 수 있는 PDF 계층이 전혀 없는 순수 XML 형식으로, CII 또는 UBL 구문 중 하나를 사용하며 KoSIT이 유지 관리하고 독일 공공 부문 송장에 요구됩니다. ZUGFeRD는 또한 하이브리드 PDF 내부에 XRechnung 준수 XML을 감싸는 XRECHNUNG 참조 프로필을 정의합니다. 이 구분은 나중에 어떤 도구가 파일을 열 수 있는지를 결정하기 때문에 중요합니다.
XML 네이티브 도구와 시각적 도구는 서로 다른 문제를 해결합니다
거의 모든 ZUGFeRD 비교는 두 가지 기술 계열로 좁혀지며, 유용한 접근은 어느 쪽이 더 고급스러워 보이는지가 아니라 각각 무엇을 읽는지 이해하는 것입니다.
XML 네이티브 도구는 내장된 CII XML을 찾아 직접 파싱합니다. 인식 단계가 없으므로 필드 값은 결정적입니다. 도구는 검증기가 읽는 것과 동일한 바이트를 읽습니다. PDF에 첨부된 페이로드든 독립형 XRechnung 파일로 전달되든 XML을 처리합니다. 이 도구의 사각지대는 XML을 사용할 수 없는 인보이스로, 일반 PDF, 스캔본, 사진, 그리고 XML에 라인 항목이 없는 경량 파일이 여기에 해당합니다.
시각적 계층 도구는 사람이 보는 방식대로 렌더링된 페이지를 읽고, OCR과 비전 모델을 사용해 각 값의 의미를 파악합니다. 읽을 수 있는 페이지가 있는 모든 파일(정식 ZUGFeRD PDF, 일반 공급업체 PDF, 스캔본, 휴대폰 사진)을 처리할 수 있습니다. 이 도구의 사각지대는 읽을 페이지가 전혀 없는 원시 XRechnung XML이며, 파싱 수준의 바이트 단위 정확성을 제공할 수 없습니다.
| 받은 입력 | XML 네이티브 도구 | 시각적 계층 도구 |
|---|---|---|
| ZUGFeRD PDF, EN 16931 (COMFORT) 또는 EXTENDED | 내장 XML을 정확히 읽음 | 렌더링된 페이지를 읽음 |
| ZUGFeRD PDF, MINIMUM 또는 BASIC WL | 헤더 데이터만 읽고 라인 항목은 읽지 못함 | 페이지에 표시된 내용을 읽음 |
| 일반 PDF 또는 스캔 인보이스 | 파싱할 내용 없음 | 페이지를 읽음 |
| 원시 XRechnung XML (PDF 없음) | XML을 직접 읽음 | 읽을 페이지 없음 |

두 계열은 서로 순위가 매겨지지 않습니다. 입력에 맞춰 선택되며, 대부분의 실제 수신함은 특정 시점에 두 가지 유형의 적용 범위를 모두 필요로 합니다.
실제 AP 수신함에서 "XML만 파싱하면 된다"가 왜 실패하는가

XML 우선 접근 방식에 공백이 생기는 이유를 설명하는 세 가지 현실이 있으며, 각각은 오늘날 독일 및 EU의 지급 계정 업무에서 실제로 나타납니다.
전환 기간이 아직 끝나지 않았습니다. 2025년 1월 1일부터 독일의 모든 기업은 EN 16931 전자송장을 수신할 수 있어야 하며, 유럽위원회의 독일 전자송장 페이지는 단계적 시행을 명시합니다: 매출이 800,000유로를 초과하는 공급업체는 2027년 1월 1일부터, 나머지 모든 공급업체는 2028년 1월 1일부터 전자송장을 발행해야 합니다. 그때까지, 그리고 전환 규정에 따른 소규모 기업의 경우, 공급업체는 수신자의 동의를 얻어 종이 또는 일반 PDF 송장을 계속 보낼 수 있습니다. 2026년에 "전자송장이 이제 의무화되었으니" PDF 처리를 제거하는 팀은 아직 전환하지 않은 모든 공급업체를 놓치게 됩니다. XRechnung과 ZUGFeRD 구분을 포함한 전체 법적 일정은 독일 전자송장 의무화에 대한 가이드에서 다룹니다.
모든 XML이 파싱할 가치가 있는 것은 아닙니다. 위의 프로필 표는 단순한 참고 자료가 아닙니다. MINIMUM과 BASIC WL은 의무 적용에서 명시적으로 제외되므로, 이를 보내는 공급업체도 요구 사항을 충족하지 못하는 것이며, 그럼에도 해당 파일은 도착하여 마치 완전한 것처럼 AP로 전달되는 경우가 많습니다. 출력 테이블에 품목별 수량, 단가, 세금 코드가 필요하다면 BASIC WL 파일을 성실히 읽는 파서는 헤더 합계만 반환하고 멈춥니다. XML은 존재합니다. 필요한 데이터는 없습니다. EN 16931 이전에 만들어졌고 다른 루트 요소를 사용하는 레거시 ZUGFeRD 1.0 파일은 보관된 송장에 동일한 문제를 추가합니다.
XML과 PDF가 서로 다를 수 있습니다. 이것이 도구 목록이 완전히 건너뛰는 지점이며, 공식 ZUGFeRD 지침이 직접 제기하는 사항입니다. 하이브리드 파일은 두 가지 표현을 담고 있기 때문에, 사기성 또는 오류가 있는 송장은 페이지에 한 수치를 표시하고 XML에 다른 수치를 표시할 수 있습니다. ZUGFeRD FAQ는 PDF만 확인한 후 XML 버전을 지불하는 것에 대해 경고하며, 편차를 자동으로 감지하려면 OCR과 송장 인식이 필요하고 결과가 대부분 완벽하지 않을 가능성이 높다고 지적합니다. 실제로 이는 양방향으로 작용합니다: XML이 존재하더라도 시각적 레이어를 읽을 가치가 있으며, 시각적 방법이나 XML 방법 모두 완벽함을 주장할 수 없습니다.
이 문제의 실제 버전은 덜 기술적으로 들립니다. 비독일 ERP로 독일 전자송장을 처리하는 방법에 대한 r/Accounting 스레드에서 한 실무자는 상황을 솔직하게 설명했습니다: "대부분의 독일 공급업체는 전자송장 과대광고에도 불구하고 여전히 일반 PDF를 보내고, 우리 ERP(SAP 아님)는 기본적으로 XRechnung을 외국어처럼 취급해서 여전히 수동 입력이 많이 발생합니다. 시도한 OCR 도구는 잘 해야 70% 정확도였습니다" (r/Accounting). PDF를 보내는 공급업체, XML을 이해하지 못하는 ERP, 필드를 놓치는 도구가 모두 같은 문장에 나타납니다.
결과를 결정하는 질문은 "XML을 파싱하는가"가 아닙니다. "공급업체가 보내는 모든 종류의 파일에서 출력에 필요한 열을 생성하는가"입니다.
2026년 최고의 ZUGFeRD 추출 도구, 접근 방식별 분류
2026년 ZUGFeRD 추출 도구 중 단일 우승자는 없습니다. 도구마다 서로 다른 입력 형식을 대상으로 설계되었기 때문입니다. 단일 순위 목록보다는 접근 방식별로 분류하는 것이 더 유용합니다. 아래 항목은 주요 후보 목록에 자주 등장하는 도구들과 시각적 레이어 옵션을 다룹니다. 더 넓은 범주에서 기준을 아직 정하지 못했다면, 송장 데이터 추출 소프트웨어 비교 자료를 참고하세요.
| 도구 | 접근 방식 | 적합한 대상 | 유의 사항 |
|---|---|---|---|
| FormX | XML 기반 REST API, 무료 단일 문서 도구 | 완전한 XML이 포함된 파일을 보유하고 API를 통해 JSON을 원하는 개발자 | 호스팅 전용이며 데이터 보관 규정에 부합하는지 확인 필요 |
| InvoiceXML | 추출, 생성, 검증, 변환을 위한 XML 기반 API | 전자 송장 생성 또는 검증도 필요한 팀 | 개발자 중심 도구이며 AP 검토 인터페이스가 아님 |
| Rossum | 엔터프라이즈 문서 AI, 워크플로 규칙 기반 ML 추출 | ZUGFeRD가 여러 형식 중 하나인 혼합 포트폴리오 | ZUGFeRD 입력이 XML 또는 시각적 레이어 중 어느 경로로 처리되는지 확인 |
| Klippa (Doxis) | 검토 UI와 API를 갖춘 EU 문서 처리 플랫폼 | 자동화와 함께 사람의 검토를 원하는 중견 EU 팀 | 공급업체 주도의 온보딩 및 가격 정책 |
| ABBYY | 엔터프라이즈 IDP, XML 방향으로 구성 가능 | 이미 ABBYY를 표준으로 사용하는 조직 | ZUGFeRD 전용 범위에 대한 구성 및 구현 오버헤드 |
| Docsumo | 금융 문서용 문서 AI, OCR 우선 | 은행 명세서, 송장, 구매 주문을 하나의 플랫폼에서 처리하려는 경우 | ZUGFeRD XML이 재인식이 아닌 직접 읽히는지 확인 |
| Mustang | CII XML용 오픈소스 Java 라이브러리 | Java 팀, 라이선스 비용 없음, 자체 호스팅 및 데이터 보관 가능 | 서비스를 직접 구축하고 운영해야 하며, 타입 객체만 제공되고 UI 없음 |
| ImageToTable.ai | XML 파싱 없이 PDF 또는 스캔의 시각적 레이어 추출 | 일반 PDF, 스캔, 프로필이 낮은 ZUGFeRD 파일이 Excel 또는 Sheets로 향하는 혼합 수신함 | 원시 XRechnung XML 파일은 읽을 수 없음. XML이 진실의 원천인 경우 XML 기반 도구 사용 |
위 표를 읽을 때 유의할 점이 몇 가지 있습니다. "적합한 대상"은 도구가 설계된 입력 프로필을 설명하는 것이지 전반적인 품질 순위가 아닙니다. 도구 기능은 변경될 수 있으므로 도입 전에 최신 문서를 확인하세요. 그리고 정답은 도구 하나가 아니라 두 개인 경우가 많습니다. 완전한 구조화 데이터가 포함된 파일용 XML 기반 파서와, 처음부터 사용 가능한 XML이 없었던 일반 PDF, 스캔, 불완전한 파일용 시각적 레이어 도구가 그것입니다. 두 번째 범주는 독일 전환 기간 동안 도구 목록이 암시하는 것보다 더 큽니다.
공급업체가 실제로 보내는 형식에 따른 선택 방법
실제로 유효한 결정 기준은 기능 비교표가 아니라 수량에서 출발합니다. 지난 100건의 입고 공급업체 인보이스를 꺼내 네 가지로 분류하세요. EN 16931 또는 EXTENDED 프로필이 포함된 진짜 ZUGFeRD 또는 Factur-X PDF, 원시 XRechnung XML, 일반 PDF, 스캔 또는 사진입니다. 각 더미의 크기가 선택 문제의 대부분을 해결해 줍니다.
거의 모든 문서에 완전한 XML이 포함된 경우
XML 네이티브 파서 또는 API를 선택하세요. 결정적인 필드를 얻을 수 있고 EN 16931 규칙에 대해 검증할 수 있으며 원시 XML은 독일 기록 보관 규정이 원본으로 보관하도록 요구하는 아카이빙용으로 계속 사용할 수 있습니다. 이 경우 시각적 도구가 추가로 제공하는 것은 거의 없습니다.
상당한 비중이 일반 PDF 또는 스캔인 경우
시각적 레이어 도구 또는 2개 도구 구성이 필요합니다. 이것이 2026년의 일반적인 상황입니다. 공급업체 기반이 초기 e-인보이스 도입 기업과 전환 기간 내에 있는 기업으로 나뉘어 있습니다. 시각적 도구는 동일한 파이프라인을 통해 진짜 ZUGFeRD 페이지와 일반 PDF를 모두 읽습니다.
원시 XRechnung XML을 읽어야 하는 경우
XML 네이티브 도구가 유일한 옵션입니다. 순수 XML 파일에는 시각적 도구가 읽을 페이지가 없습니다. 독일 공공 부문 구매자로부터 인보이스를 받는 팀은 이를 선호 사항이 아닌 필수 요건으로 간주해야 합니다.
데이터가 도착해야 하는 대상을 결정하세요
DATEV, Lexware, SAP는 포함된 XML을 직접 가져오므로 해당 경로가 이미 작동한다면 남은 격차는 PDF입니다. 대상이 스프레드시트 또는 가져오기 템플릿이라면 Excel 또는 CSV를 출력하고 선택적으로 Google Sheets에 쓰는 시각적 도구가 재입력 작업을 가장 많이 줄여 줍니다.
도구를 볼륨과 라인 깊이에 맞추세요
하루에 몇 건 이상의 인보이스를 처리하거나 개별 인보이스가 여러 페이지에 걸쳐 수백 개의 라인 항목으로 구성되면 배치 처리가 중요해집니다. 문서별 API 호출 모델과 배치 업로드 모델은 데모에서는 동일해 보이지만 월말 볼륨에서는 크게 달라집니다.
형식과 무관한 한 가지 더 고려 사항이 있습니다. 국경 간 전자 인보이스는 계속 확대되고 있습니다. EU의 VAT in the Digital Age 패키지에 따라 역내 EU B2B 거래에 대한 구조화된 전자 인보이스와 디지털 보고는 2030년 7월 1일부터 의무화되며, 유럽 위원회는 이미 회원국이 특별 유예 없이 국내 전자 인보이스를 의무화할 수 있도록 허용했습니다. XML 비중은 계속 증가할 것입니다. 유용하게 유지되는 도구는 문서로 계속 도착하는 파일을 포기하지 않으면서 구조화된 경로를 포괄하는 도구입니다.
ZUGFeRD에 대해 PDF 레이어 추출이 할 수 있는 것과 할 수 없는 것
이것은 우리 도구 자체의 경계가 중요해지는 지점이며, 분명히 밝힐 가치가 있습니다. ImageToTable.ai는 인보이스의 시각적 레이어를 읽습니다. 내장된 XML은 구문 분석하지 않습니다. 이 한 가지 사실이 도구가 잘하는 것과 할 수 없는 것을 모두 결정합니다.
메커니즘은 맞춤 열 추출입니다. "공급업체", "인보이스 번호", "인보이스 날짜", "순 금액", "VAT 금액", "품목 설명"과 같은 열 이름을 입력하면 AI가 페이지에서의 위치가 아니라 의미를 이해하여 각 값을 찾습니다. 그릴 템플릿도, 학습할 샘플도 없으며, 입력한 열 이름이 출력 테이블의 헤더가 됩니다. 이것이 일반 공급업체 PDF와 진짜 ZUGFeRD PDF가 동일한 요청으로 처리되는 이유이며, 둘 다 읽을 페이지가 있기 때문입니다.
AP 업무의 경우, ZUGFeRD 현실에 부합하는 세 가지 추가 기능이 있습니다. 배치 처리는 여러 파일을 한 번에 업로드하면 일관된 열을 가진 단일 Excel 테이블로 병합되므로, ZUGFeRD PDF와 스캔본이 섞인 폴더가 공급업체별 파일 하나가 아닌 하나의 데이터셋으로 생성됩니다. 다중 페이지 병합은 동일한 논리 문서에 속하는 결과를 그룹화하므로, 여러 페이지에 걸친 긴 인보이스나 페이지별로 촬영된 문서가 흩어지지 않고 하나의 행 또는 연속된 행 집합으로 접힙니다. bbox 검증이 포함된 검토 모드는 추출된 셀에 마우스를 올리거나 클릭하면 값이 원본 페이지의 정확히 어디에서 왔는지 확인할 수 있게 해주며, 잘못 읽은 숫자 하나가 잘못된 지불이 되는 금융 업무에서 중요합니다. 입력 형식에는 비밀번호로 보호된 파일을 포함한 PDF와 JPG, PNG, WebP, AVIF, 스크린샷이 있으며, 출력은 Excel, CSV, JSON 또는 Word로 가능합니다.
속도 측면에서 이 도구는 인쇄된 인보이스 페이지를 5~10초 안에 처리하며, 평균 약 3분의 수동 입력 시간과 비교되고, 인쇄된 표 데이터에서 최대 99%의 인식 정확도를 달성합니다. 빽빽한 손글씨나 저품질 스캔은 더 높은 처리 티어에서 더 잘 처리되며, 도구는 이를 Standard, Advanced 또는 Premium으로 제공합니다.
한계도 마찬가지로 구체적입니다. 내장된 CII XML을 읽거나, 생성하거나, 검증하지 않으므로 구조화된 원본을 유지하거나 검증해야 하는 팀의 경우 XML 네이티브 파서를 대체할 수 없습니다. 읽을 페이지가 없기 때문에 원시 XRechnung XML 파일을 처리할 수 없습니다. EN 16931 규칙에 대해 파일을 확인하지 않으며, DATEV, Lexware 또는 SAP에 어떤 것도 전기하지 않습니다. 도구가 하는 일은 사용 가능한 구조화 데이터가 없는 문서를 나머지 프로세스가 소비하는 스프레드시트 행으로 변환하는 것입니다. 이 메커니즘은 파일이 ZUGFeRD인지 여부와 관계없이 일반 독일 인보이스(Rechnung) 추출에도 그대로 적용됩니다.
시각적 추출은 받는 모든 인보이스에 존재하는 레이어를 다루고, XML 구문 분석은 때때로만 완전한 레이어를 다룹니다. 둘 중 하나가 다른 하나를 대체하지 않으며, 어떤 파일이 어떤 것인지 아는 것이 도구 목록이 빠뜨리는 기술입니다.
자주 묻는 질문
2026년 최고의 ZUGFeRD 추출 도구는 무엇인가요?
공급업체가 보내는 파일 형식에 따라 다릅니다. 수신 파일에 완전한 EN 16931 또는 EXTENDED XML이 안정적으로 포함되어 있다면 API 기반 추출 서비스와 같은 XML 네이티브 파서를 사용하면 결정적인 필드를 얻을 수 있습니다. 상당 부분이 일반 PDF, 스캔 또는 낮은 수준의 ZUGFeRD 파일로 도착한다면 렌더링된 페이지를 읽는 시각적 레이어 도구가 필요합니다. 많은 팀이 결국 두 가지를 모두 사용하게 됩니다.
ZUGFeRD 추출 도구는 XML 레이어를 읽어야 하나요, 아니면 PDF 레이어를 읽어야 하나요?
두 접근 방식 모두 유효하며 서로 다른 상황에 적합합니다. XML을 읽는 것은 정확하고 표준에 대해 검증할 수 있지만 XML이 존재하고 완전할 때만 작동합니다. PDF나 스캔을 읽는 것은 읽을 수 있는 페이지가 있는 모든 파일에서 작동하며, 독일 전환 기간 동안 많은 수신함에서 여전히 우세한 일반 인보이스도 포함됩니다. 한 가지 접근 방식이 전체 공급업체 기반을 커버한다고 가정하는 것이 실수입니다.
ImageToTable.ai가 ZUGFeRD PDF에서 데이터를 추출할 수 있나요?
네, 표시되는 PDF 페이지에서 추출할 수 있습니다. ZUGFeRD는 하이브리드 파일이므로 항상 사람이 읽을 수 있는 레이어가 있으며, ImageToTable.ai는 사용자가 정의한 열을 사용하여 해당 레이어를 읽습니다. 포함된 XML을 구문 분석하거나 출력하지 않으므로 라인 항목과 헤더 필드를 스프레드시트로 가져오는 데 적합한 도구이며, 구조화된 원본을 검증하거나 보관하는 데는 적합하지 않습니다.
ImageToTable.ai가 XRechnung 인보이스에서 작동하나요?
XRechnung이 읽을 수 있는 페이지가 있는 PDF 또는 스캔으로 도착하는 경우에만 작동합니다. 원시 XRechnung 파일은 시각적 레이어가 없는 순수 XML이며 ImageToTable.ai는 XML을 입력으로 허용하지 않습니다. 순수 XRechnung 파일에는 XML 네이티브 파서가 필요합니다.
여러 ZUGFeRD 인보이스를 한 번에 일괄 처리할 수 있나요?
네. ImageToTable.ai는 일괄 우선 처리 방식으로 구축되었습니다. 여러 파일을 업로드하면 동일한 열을 가진 하나의 Excel 테이블로 병합됩니다. 진짜 ZUGFeRD PDF, 일반 공급업체 PDF, 스캔이 혼합된 폴더에서도 작동합니다. 추출은 각 파일의 형식이 아니라 사용자가 설정한 열 이름에 따라 진행되기 때문입니다.
무료 ZUGFeRD 추출 도구가 있나요?
무료 옵션이 존재하며 첫 시도에 유용합니다. 오픈소스 Mustang 라이브러리는 라이선스 비용 없이 ZUGFeRD 및 Factur-X XML을 실제로 파싱하지만, 그 주변 서비스를 직접 구축하고 실행해야 합니다. 여러 상용 공급업체가 테스트용 무료 단일 문서 온라인 도구나 평가판을 제공하며, 일반적으로 배치 또는 API 액세스는 포함되지 않습니다. 대량 작업에는 유료 플랜이나 자체 호스팅 노력이 필요합니다.
ZUGFeRD와 Factur-X의 차이점은 무엇인가요?
두 이름은 동일한 기술 표준을 가리킵니다. ZUGFeRD는 독일식 명칭이고 Factur-X는 프랑스식 명칭으로, ZUGFeRD 2.1부터 공동으로 유지 관리되며 동일한 PDF/A-3 컨테이너, 동일한 CII XML, 동일한 프로필을 사용합니다. 하나를 처리하는 도구는 다른 하나도 처리해야 합니다. factur-x.xml 첨부 파일과 이전 zugferd-invoice.xml 이름을 가진 파일을 어떻게 처리하는지 구체적으로 문의하세요.
"최고의 ZUGFeRD 추출 도구" 목록은 실제로 한 가지 좁은 질문에 대한 답변 목록입니다. 즉, 어떤 도구가 포함된 XML을 파싱하는지입니다. 이 질문은 물어볼 가치가 있으며, 완전히 구조화된 공급업체 집합에는 XML 기반 답변이 올바른 선택입니다. 그러나 독일의 의무화는 아직 단계적으로 시행 중이며, 일반 PDF도 당분간 합법이며, 하위 ZUGFeRD 프로필에는 AP 테이블에 필요한 라인 항목 없이 XML만 포함됩니다. 어떤 인보이스에 완전한 구조화 데이터가 실제로 포함되어 있는지 아는 팀은 가장 높은 순위의 파서를 선택하는 팀보다 더 나은 도구를 선택합니다.