독일 청구서(Rechnung) 데이터를
엑셀로 추출하는 방법

독일 인보이스가 일반 추출 도구를 무력화시키는 이유

독일의 Rechnung은 미국 인보이스를 번역한 것이 아닙니다. 이는 Umsatzsteuergesetz(UStG) — 독일 부가가치세법 — 제14조에 따라 규율되는 법적 문서로, 10개의 필수 항목이 있으며 이 항목들의 존재 여부에 따라 기업이 매입세액 공제(Vorsteuerabzug)를 청구할 수 있는지가 결정됩니다. 항목이 누락되거나 잘못 입력되면 재정청(Finanzamt)이 매입세액 공제를 거부할 수 있습니다. 공급자는 어차피 대금을 받습니다. 위험은 귀사가 부담합니다.

이것이 바로 범용 인보이스 OCR 도구(영어 인보이스에는 잘 작동하는 도구라도)가 독일 인보이스에서 실패하는 이유이기도 합니다. 이 도구들은 독일 법률상 법적으로 구별되는 두 날짜인 Rechnungsdatum(인보이스 발행일)과 Leistungsdatum(서비스 제공일)을 구분하도록 설계되지 않았습니다. 또한 USt-IdNr이 DE123456789 형식을 따르는지 검증하지 않습니다. 19%와 7%의 VAT 세율 차이를 하나의 "세금" 열로 통합하는데, 이는 ELSTER를 통해 Umsatzsteuervoranmeldung(독일 부가가치세 사전 신고)을 제출하는 데 사용할 수 없습니다.

한 달에 3장의 국내 인보이스를 처리하고 모든 것을 Lexware에 수동으로 입력한다면 이러한 문제는 중요하지 않습니다. 하지만 25개의 독일 공급업체로부터 한 달에 80장의 Rechnung을 처리하고, 각각 다른 레이아웃(일부는 PDF, 일부는 사진으로 촬영된 종이 사본, 일부는 VAT 추출이 필요 없고 다른 전기 로직이 필요한 §13b 역과세 적용)을 다뤄야 한다면 이는 상당히 중요한 문제가 됩니다.

§14 UStG가 모든 독일 인보이스에 실제로 요구하는 사항

§14 Abs. 4 UStG는 모든 정식 독일 세금계산서에 반드시 포함되어야 하는 10가지 필수 항목(Pflichtangaben)을 규정합니다. 회계 목적으로 데이터를 엑셀로 추출할 때, 각 항목은 스프레드시트의 열에 매핑되며, 하나라도 누락되면 DATEV 가져오기나 부가세 환급 청구에 데이터를 사용할 수 없게 됩니다.

두 가지 실무적 예외로 필드 수가 줄어듭니다. 총액 250유로 미만의 세금계산서는 §33 UStDV에 따라 소액계산서(Kleinbetragsrechnungen)로 간주되며, 공급자명과 주소, 발행일, 재화/용역 설명, 총액, 적용 부가세율 또는 §19 면제 문구만 필요합니다. 또한 §19 UStG에 따른 소규모 사업자(Kleinunternehmer) — 전년도 매출이 22,000유로를 초과하지 않은 사업자 — 의 세금계산서에는 부가세를 표시해서는 안 되며, 대신 §19에 따라 부가세가 부과되지 않는다는 문구를 포함해야 합니다. 추출 규칙은 세금계산서가 어느 범주에 속하는지에 따라 달라집니다.

독일 부가세 미로: 하나의 "세율" 열로는 부족한 이유

독일 세금계산서의 추출 로직은 적용되는 부가세 체계에 따라 크게 달라집니다. 단일 "부가세율" 및 "부가세액" 열 쌍은 가장 단순한 경우에만 작동합니다. 독일 세금계산서는 다음 네 가지 시나리오 중 하나에 해당할 수 있으며, 각각 다른 열 정의가 필요합니다:

여러 부가세(VAT) 카테고리에 걸쳐 독일 공급업체로부터 인보이스를 수신하는 기업(예: 식품(7%)과 장비(19%)를 Metro 및 Transgourmet에서 구매하는 외식업체 그룹)의 경우, 추출 도구는 모든 인보이스를 동일한 템플릿에 강제로 맞추지 않고 인보이스 유형별로 다른 열 구조를 출력할 수 있을 정도로 유연해야 합니다.

AI 기반 추출이 독일 인보이스 형식을 처리하는 방법

이것이 템플릿 기반 OCR과 AI 기반 추출의 차이가 구체화되는 지점입니다. 템플릿 기반 도구는 모든 공급업체 레이아웃에 대해 필드 좌표를 정의해야 합니다. Metro 인보이스 레이아웃은 Transgourmet 레이아웃과 다르며, 이는 다시 지역 Handwerker의 Rechnung과 다릅니다. 유지보수 부담은 새로운 공급업체가 추가될 때마다 증가합니다.

ImageToTable.ai는 다른 접근 방식을 취합니다: 사용자 정의 열 추출. 도구에 페이지에서 필드가 어디에 있는지 가르치는 대신, 열 이름을 입력하여 추출하려는 내용을 정의합니다. 예: "Rechnungsnummer", "Leistungsdatum", "Nettobetrag 19%", "USt-Betrag 19%", "Nettobetrag 7%", "USt-Betrag 7%", "USt-IdNr" — 그러면 AI는 필드가 어디에 있는지가 아니라 무엇을 의미하는지 이해하여 페이지 어디에서든 각 값을 찾습니다. 이는 공급업체 형식에 관계없이 작동하며 공급업체별 구성이 필요 없습니다. 하나의 열 정의로 Metro, Transgourmet, Selgros, 그리고 옆 동네 독립 Tischlerei까지 모두 처리할 수 있습니다.

위 데모에서 독일 Rechnung을 업로드해 보세요. §14 UStG 필드에 맞는 열을 정의하세요 — Rechnungsnummer, Rechnungsdatum, Leistungsdatum, Lieferant, Nettobetrag, USt-Satz, USt-Betrag, Bruttobetrag, USt-IdNr로 시작 — AI가 추출하는 결과를 확인하세요. 동일한 열 정의는 다른 공급업체의 인보이스 레이아웃으로 전환해도 작동합니다. AI는 위치가 아닌 의미를 읽기 때문입니다.

일괄 처리 기능을 사용하면 한 달치 Metro 및 Transgourmet 청구서를 한 번에 업로드할 수 있습니다. 이 도구는 각 청구서를 병합된 스프레드시트의 한 행으로 추출합니다. 모든 Rechnung이 행으로 정리된 하나의 Excel 파일이 생성되며, 공급업체, 날짜 범위 또는 VAT 세율별로 필터링한 후 Steuerberater에게 전달할 수 있습니다.

추출에서 회계까지: DATEV, Lexware 또는 sevDesk 워크플로우가 기대하는 사항

데이터 추출은 작업의 절반에 불과합니다. 독일에서는 나머지 절반이 추출된 데이터를 Steuerberater가 재작업 없이 사용할 수 있는 형식으로 회계 소프트웨어에 입력하는 것입니다. 각 플랫폼마다 요구 사항이 다르기 때문에 목적지가 중요합니다:

DATEV — 독일 세무사의 약 60~70%가 사용 — Kanzlei-Rechnungswesen(CSV in DATEV-Format) 또는 Unternehmen Online(XML)을 통해 데이터를 수신합니다. CSV 형식에는 Belegdatum, Buchungstext, Gegenkonto, Betrag와 같은 특정 열이 필요하며, 가장 중요한 것은 올바른 Buchungsschlüssel(전기 키)와 Kontierung(SKR03 또는 SKR04 기준 계정 할당)입니다. Steuerberater가 미리 코딩된 계정을 요구하는 경우 추출 출력에 DATEV 계정 번호 열을 추가해야 합니다. Steuerberater가 직접 Kontierung을 처리하는 경우 생략할 수 있지만, 먼저 확인하세요.

Lexware Office(이전 lexoffice) — 월 €7.90에 독일 중소기업이 가장 널리 사용하는 클라우드 회계 플랫폼 — 자체 CSV 구조 또는 직접 은행 피드를 통해 가져옵니다. 거래를 자동으로 분류하지만, VAT 검증을 위해 공급업체의 USt-IdNr이 수신 청구서 데이터에 포함되어야 합니다. 해당 필드가 추출에서 누락되면 Lexware는 해당 청구서를 수동 검토 대상으로 표시합니다.

sevDesk — 월 12.90유로의 현대적 도전자 — 자체 템플릿을 사용하여 CSV로 연락처와 Belege(문서)를 가져옵니다. CSV 업로드는 간단하지만 Belegart(문서 유형) 분류(입고 송장, 출고 송장, 또는 대변 메모)가 필요합니다. 추출 시 이를 구분하지 않으면 가져오기 후 수동으로 행을 재분류해야 합니다.

공통점: 독일 회계 소프트웨어는 독일 송장 데이터 구조를 기대합니다. "공급업체", "날짜", "합계"만 출력하는 일반 추출은 이러한 플랫폼에서 가져오기를 허용하기 전에 상당한 수동 재구성이 필요합니다. 대상 소프트웨어의 스키마에 직접 맞춰 추출 열을 정의하면(예: "VAT Number" 대신 USt-IdNr, "Date" 대신 Belegdatum) 재구성 단계가 사라집니다.

동일한 추출 방식은 여러 언어와 형식으로 도착하는 국제 송장에도 적용됩니다. 열 이름 의미가 송장 원본 언어와 관계없이 일관되기 때문입니다.

GoBD 및 전자 송장: 추출 데이터 감사 준비 유지

독일에서 송장 데이터 추출은 효율성 문제일 뿐만 아니라 기록 보관에 대한 법적 의무를 수반합니다. GoBD(Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern)는 디지털 회계를 위한 세무 당국의 프레임워크입니다. 핵심 원칙인 Nachvollziehbarkeit(추적 가능성), Unveränderbarkeit(불변성), Verfügbarkeit(가용성)은 추출된 모든 데이터 포인트가 원본 송장으로 추적 가능해야 하며, 모든 원본 송장은 §147 AO에 따라 원래 형식으로 10년간 보존되어야 함을 의미합니다.

2025년 7월 GoBD 개정안은 전자 세금계산서(e-invoice) 보관에 관한 중요한 사항을 명확히 했습니다. 구조화된 전자 세금계산서(XRechnung 및 ZUGFeRD PDF에 포함된 XML 레이어)의 경우, 기계 판독 가능한 XML이 공식 기록입니다. 사람이 읽을 수 있는 PDF는 XML에 포함되지 않은 추가 세금 관련 정보(예: 시각적 레이어에 수기로 작성된 전기 참고 사항 또는 지불 조건)가 있는 경우에만 보관하면 됩니다. 대부분의 기업에게 이는 추출된 Excel 파일이 작업 데이터 세트이지만, 감사관이 요청하는 원본 파일은 XML 파일임을 의미합니다.

독일의 B2B 전자 세금계산서 의무화(E-Rechnungspflicht)는 다음과 같이 단계적으로 시행됩니다:

• 2025년 1월 1일 — 모든 독일 B2B 기업은 EN 16931 규격(XRechnung 또는 ZUGFeRD 2.1)을 준수하는 전자 세금계산서를 수신할 수 있어야 합니다.
• 2027년 1월 1일 — 전년도 매출이 80만 유로를 초과하는 기업은 전자 세금계산서를 발행해야 합니다.
• 2028년 1월 1일 — 모든 독일 B2B 기업은 전자 세금계산서를 발행해야 합니다. 국내 B2B 거래의 경우, 250유로 미만의 소액 청구서(Kleinbetragsrechnungen) 및 §19에 따른 소규모 사업자(Kleinunternehmer)를 제외하고 종이 및 PDF 세금계산서는 더 이상 허용되지 않습니다.

데이터 추출에 대한 실질적인 영향: 귀하의 수신 청구서 구성이 이미 변화하고 있습니다. 받은 편지함에 도착하는 ZUGFeRD PDF에는 내장된 XML 데이터 레이어가 포함되어 있어, 역량 있는 추출 도구가 해당 필드에 대해 OCR을 완전히 건너뛰고 직접 읽어 100% 정확한 구조화된 데이터를 제공할 수 있습니다. 2027년까지의 전환 기간 동안 여전히 일반 PDF 청구서(Rechnungen)를 보내는 공급업체의 경우, AI 추출이 그 격차를 메워 시각적 PDF를 읽고 동일한 구조화된 열을 출력합니다.

규정 준수에서 중요한 것은 추출 워크플로가 추출된 데이터와 원본 문서 간의 연결을 유지하는 것입니다. 40개의 Rechnung을 하나의 Excel 파일로 일괄 추출하고 Excel 파일만 보관하면 GoBD를 위반하게 됩니다. XML, PDF 또는 스캔한 종이 문서 등 원본 문서는 10년 동안 접근 가능하고 검색 가능한 상태로 유지되어야 합니다.

자주 묻는 질문

독일 청구서 데이터를 필요한 곳으로 보내기

독일 인보이스 추출은 일반적으로 별도로 처리되는 세 가지 문제, 즉 데이터 정확성, 세금 규정 준수, 소프트웨어 호환성이 교차하는 지점에 있습니다. 한 가지를 잘 처리하는 도구는 다른 것을 무시하는 경향이 있습니다. 템플릿 기반 OCR은 단일 공급업체 형식에 대해 정확할 수 있지만, 새로운 공급업체마다 재구축이 필요합니다. Lexware에 수동 입력하면 데이터가 올바른 구조로 유지되지만, 월 30장 이상의 인보이스에는 확장되지 않습니다. ZUGFeRD XML의 AI 파싱은 전자 인보이스에서 100% 정확도를 제공하지만, 여전히 인쇄하여 우편으로 청구서를 보내는 지역 전기 기술자의 종이 Rechnung에는 아무런 도움이 되지 않습니다.

템플릿 위치가 아닌 열 이름으로 필요한 것을 정의하는 의미론적 추출을 기반으로 구축된 워크플로는 세 가지 문제를 동시에 처리합니다. §14 UStG에서 요구하는 필드를 추출하고, Umsatzsteuervoranmeldung에 필요한 VAT 구조를 보존하며, 회계 소프트웨어의 가져오기 스키마와 일치하는 열을 출력합니다. 또한 인보이스가 ZUGFeRD PDF, 공급업체의 카메라폰 사진, 또는 2023년의 스캔된 종이 문서로 도착하더라도 동일한 방식으로 작동합니다.