독일 인보이스
(Rechnung) 데이터를 Excel로 추출하는 방법

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

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

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

월 3건의 국내 인보이스를 처리하고 모든 것을 Lexware에 수동으로 입력한다면 이러한 문제는 중요하지 않습니다. 그러나 25개 독일 공급업체로부터 월 80건의 Rechnung을 처리할 때는 상황이 완전히 달라집니다 — 각각 다른 레이아웃을 가지며, 일부는 PDF, 일부는 촬영된 종이 사본, 일부는 부가가치세 추출이 필요 없고 완전히 다른 회계 로직이 적용되는 §13b 역부과 방식으로 도착합니다.

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

§14 Abs. 4 UStG는 모든 완전한 독일 인보이스가 포함해야 하는 10개의 필수 항목 — Pflichtangaben — 을 규정합니다. 회계 목적으로 데이터를 Excel로 추출하는 경우 각 필드는 스프레드시트의 열에 매핑되며, 하나라도 누락되면 DATEV 가져오기나 매입 부가가치세 청구에 데이터를 사용할 수 없게 될 수 있습니다.

두 가지 실용적인 예외로 인해 필드 수가 줄어듭니다. 총액 €250 미만의 인보이스는 §33 UStDV에 따라 Kleinbetragsrechnungen(소액 청구서)에 해당하며, 공급업체 이름과 주소, 인보이스 날짜, 재화/서비스 설명, 총액, 적용 VAT 세율 또는 §19 면제 문구만 필요합니다. 그리고 §19 UStG에 따른 Kleinunternehmer(소규모 사업자) — 전년도 매출이 €22,000를 초과하지 않은 사업자 — 의 경우 인보이스에 VAT를 표시해서는 안 되며, 대신 §19에 따라 VAT가 부과되지 않는다는 문구를 포함해야 합니다. 인보이스가 어느 범주에 속하는지에 따라 추출 규칙이 달라집니다.

독일 VAT 미로: "세금" 열 하나로는 부족할 때

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

여러 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 파일 하나를 얻고, Steuerberater에게 넘기기 전에 공급업체, 날짜 범위 또는 VAT 세율로 필터링할 준비가 됩니다.

추출에서 회계까지: 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 계정 번호용 추가 열이 필요합니다. Kontierung을 직접 처리한다면 생략할 수 있지만, 먼저 확인하세요.

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

sevDesk — 월 €12.90의 현대적 도전자 — 자체 템플릿의 CSV를 통해 연락처와 Belege(문서)를 가져옵니다. CSV 업로드는 간단하지만 Belegart(문서 유형) 분류를 기대합니다: Eingangsrechnung, Ausgangsrechnung 또는 Gutschrift. 추출이 이를 구분하지 않으면 가져온 후 행을 수동으로 재분류해야 합니다.

공통점: 독일 회계 소프트웨어는 독일 인보이스 데이터 구조를 기대합니다. "Supplier", "Date", "Total"만 출력하는 일반적인 추출은 이러한 플랫폼이 가져오기를 수락하기 전에 상당한 수동 재구성이 필요합니다. 대상 소프트웨어의 스키마에 맞게 추출 열을 직접 정의하면 — 예를 들어 열 이름을 "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 개정안은 전자 세금계산서 보관에 대한 중요한 점을 명확히 했습니다: 구조화된 전자 세금계산서(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일 — 전년도 매출이 €800,000를 초과하는 기업은 전자 세금계산서도 발송해야 합니다.
• 2028년 1월 1일 — 모든 독일 B2B 기업은 전자 세금계산서를 발송해야 합니다. 종이 및 PDF 송장은 국내 B2B 거래에서 더 이상 허용되지 않으며, €250 미만의 Kleinbetragsrechnungen 및 §19에 따른 Kleinunternehmer는 예외입니다.

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

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

자주 묻는 질문

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

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

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