독일 청구서 80장, 하나의 스프레드시트
수동 입력 없이 일괄 Rechnung 처리하는 방법

청구서 80장이 도착할 때 — 일괄 처리가 "단건 × 80"과 다른 이유

청구서를 한 장씩 처리하는 방식은 한계가 있습니다. 대부분의 독일 기업에서 전환점은 월 30~50장의 Eingangsrechnungen(매입 청구서) 사이에서 발생합니다. 즉, "금요일 오후에 처리할 수 있다"와 "주말을 잡아먹는다"의 차이가 벌어지는 지점입니다. 청구서 80장의 경우, 문제는 청구서당 데이터 입력 속도가 아닙니다. 단건 워크플로우에는 일괄 처리에서도 그대로 이어지고 증폭되는 네 가지 구조적 문제가 있습니다:

형식 차이. 청구서를 하나씩 처리하고 Lexware나 sevDesk에 수동으로 데이터를 입력할 때, 두뇌는 레이아웃 차이를 보정합니다. Metro 청구서의 "Rechnungs-Nr."와 Transgourmet 청구서의 "Rechnungsnummer"가 동일한 필드임을 인식합니다. 그러나 자동화된 일괄 추출은 템플릿 위치가 아닌 의미적 의미로 찾도록 학습시키지 않는 한 이러한 직관이 없습니다. 8개의 공급업체, 8개의 레이아웃, 그리고 이 모든 것을 하나의 스프레드시트에 혼합한 일괄 출력 결과가 나옵니다.

부가가치세(VAT) 분산. 독일 Eingangsrechnungen은 단일 VAT 세율을 사용하지 않습니다. 외식업 공급업체의 청구서 80장 배치에는 최대 4가지 VAT 처리가 나타납니다: 표준 19%(장비, 청소), 인하 7%(식품, 도서), §13b 역과세(하청업체 건설 작업), §19 Kleinunternehmer(소규모 사업자, VAT 면제). 각 청구서에서 숫자를 캡처하는 단일 "세금" 열은 무용지물입니다. 해당 숫자는 각 행에서 다른 의미를 가지며, Vorsteuerabzug(매입세액 공제) 계산은 유형별로 분리해야 하기 때문입니다. 각 청구서의 §14 UStG 필수 항목은 추출해야 할 항목을 결정합니다. 그러나 일괄 처리는 80개 행 전체에서 해당 추출의 의미적 일관성을 유지하는 계층을 추가합니다.

오류 전파. 송장 80개를 수동으로 입력할 때 각각은 독립적인 작업입니다. 44번 송장의 오타가 45번 송장으로 이어지지 않습니다. 반면 일괄 추출에서는 AI가 로고 위치 변경으로 인해 한 송장의 공급업체명을 잘못 식별하면 전체 출력을 검토하기 전까지 알 수 없습니다. 또한 열 매핑이 잘못된 경우(예: 날짜 형식이 다른 공급업체에서 Leistungsdatum 열이 Rechnungsdatum을 대신 캡처한 경우) 문제가 있는 행 하나만 확인하는 것이 아니라 모든 행을 확인해야 합니다.

추적성 결여. 80개 행으로 병합된 스프레드시트는 어떤 행이 어떤 파일에서 왔는지 알려줘야 합니다. 원본 송장으로 돌아가 USt-IdNr를 확인하거나 할인 항목을 검증해야 한다면 신뢰할 수 있는 파일명-행 매핑이 필요합니다. 소스 문서 열 없이 CSV를 출력하는 일괄 도구는 감사를 다운로드 폴더 뒤지는 작업으로 만듭니다.

송장 3개를 처리할 때는 이러한 문제가 전혀 발생하지 않습니다. 80개에서는 네 가지 문제가 동시에 활성화됩니다. 이를 해결하는 것이 "단일 추출을 80번 반복"하는 것과 일괄 처리 워크플로우를 구분짓는 요소입니다.

공급업체 형식 문제 — 하나의 스프레드시트, 여덟 가지 다른 레이아웃

Metro 송장과 Transgourmet 송장은 §14 UStG에 따라 동일한 법적 구조를 공유하지만 전혀 다르게 보입니다. Metro는 Rechnungsnummer를 오른쪽 상단 블록에 배치하고 Transgourmet은 테이블 헤더에 배치합니다. 동네 빵집은 공급업체 주소 블록에 명시적인 레이블이 전혀 없는 수기 송장을 보낼 수 있습니다. 왼쪽 상단에 있고 거리 이름으로 시작하기 때문에 인식할 수 있습니다. 이것이 독일 송장에 대한 템플릿 기반 일괄 추출에 반대하는 핵심 논거입니다. 새로운 공급업체마다 새로운 추출 템플릿을 구축하고 유지해야 합니다.

이해를 돕자면: 중간 규모의 독일 레스토랑 그룹은 Metro(식품 도매), Transgourmet(음료), 지역 Gemüsehändler(청과물), 여러 Getränkelieferanten(음료 유통업체), 청소 업체, Wartungsfirma(장비 유지보수), 마케팅 대행사 — 그리고 간헐적인 1회 공급업체로부터 청구서를 받습니다. 이는 Metro 자체 내 변형(표준 청구서, 납품서, Stornorechnung)을 고려하기 전에도 8개의 서로 다른 청구서 형식입니다. 이들은 동일한 브랜드 레이아웃을 사용하지만 필드 배열이 다릅니다. 템플릿 기반 도구는 각 변형마다 별도의 구성을 필요로 합니다. 의미론적 추출을 사용하면 열 이름을 한 번만 정의하면 됩니다.

이것이 대규모에서 열 이름 접근 방식과 템플릿 접근 방식의 차이입니다. 사용자 정의 열 추출 — ImageToTable.ai가 사용하는 메커니즘 — 은 좌표가 아닌 필드 의미를 이해하여 작동합니다. 원하는 열 이름을 입력하기만 하면 됩니다: "Rechnungsnummer", "Lieferant", "Rechnungsdatum", "Leistungsdatum", "Nettobetrag", "USt-Satz", "USt-Betrag", "Bruttobetrag", "USt-IdNr" — 그러면 AI가 레이블의 의미를 이해하여 배치 내 모든 청구서에서 각 값을 찾아냅니다. 레이블 텍스트가 다르더라도 상관없습니다("Rechnungs-Nr." vs "Rechnungsnummer" vs "RNr."). 하나의 열 정의로 한 번의 배치 업로드에서 8개 공급업체 레이아웃을 모두 처리합니다.

실제 의미: 모든 공급업체로부터 받은当月의 Eingangsrechnungen 폴더 전체 — 80개의 PDF, JPG, 스캔 문서 — 를 업로드하면 형식에 관계없이 각 행이 동일한 열을 가진 Rechnung을 나타내는 하나의 병합된 스프레드시트를 얻습니다. 공급업체별 템플릿, 형식 사전 분류, "이 공급업체 청구서는 레이아웃이 다르므로 별도로 업로드해야 함"이 필요 없습니다.

80개 청구서에 걸친 부가세율 분할 — 하나의 "세금" 열이 깨지는 이유

이제 배치 추출이 성공적으로 이루어졌다고 가정해 보겠습니다. 80개의 인보이스가 모두 일관된 열로 스프레드시트에 들어 있습니다. 다음 문제는 USt-Satz 열에 19%, 7%, 0%(또는 공란), "§13b"라는 네 가지 값이 포함되어 있으며, 각각 다른 회계 처리가 필요하다는 점입니다. 단순히 USt-Betrag 열을 SUM하면, §15 UStG에 따라 Vorsteuerabzug(매입세액 공제)가 가능한 19% 일반 부가가치세, 공제 대상이지만 Umsatzsteuervoranmeldung(부가가치세 신고서)의 66번 줄에 별도로 보고해야 하는 7% 감면 세율, 그리고 세금 납부 의무가 수취인에게 이전되어 공제가 불가능하고 별도 보고 의무가 있는 §13b 금액이 모두 합산됩니다.

Umsatzsteuervoranmeldung은 독일의 월별 또는 분기별 부가가치세 사전 신고로, ELSTER를 통해 제출되며, 특정 세금 코드(Kennzahlen)에 따라 부가가치세 금액을 보고해야 합니다.

배치 추출에서 이를 처리하는 실용적인 방법은 추론 열(Inferred Column)을 정의하는 것입니다. 이는 페이지에 명시적으로 표시된 값을 추출하는 대신 AI가 콘텐츠를 기반으로 송장을 분류하는 열입니다. 예를 들어, VAT 유형 (옵션: 일반 19%/할인 7%/§13b 역과세/Kleinunternehmer §19)라는 열은 AI가 각 송장을 읽고 적용되는 VAT 체제를 판단한 후 올바른 카테고리 레이블을 출력하도록 지시합니다. 이렇게 하면 필터링 가능한 열이 생성되며, 여기서 VAT 유형별로 그룹화하고 각 그룹의 USt-Betrag를 합산하여 Vorsteuerabzug 신고에 사용할 수 있습니다. 추출과 분류는 두 번의 개별 작업이 아닌 한 번의 패스로 이루어집니다.

이는 Buchhaltung의 비용 측면에서도 중요합니다. §13b 송장의 Nettobetrag는 입력 VAT가 0이더라도 여전히 운영 비용(Aufwand)입니다. "세금이 없으니 관련 없음"이라는 이유로 비용 요약에서 제외하면 비용을 과소 보고하게 됩니다. 배치 추출은 VAT 관련 부분뿐만 아니라 전체 재무 상황을 포착해야 합니다.

배치 추출에서 Steuerberater까지 — 한 번의 내보내기로 DATEV 준비 완료

80개의 송장을 스프레드시트로 추출하면 데이터 입력 문제는 해결됩니다. 그러나 이 스프레드시트를 Steuerberater가 각 행을 다시 입력하지 않고 DATEV로 가져올 수 있는 형태로 만드는 인계 문제는 자동으로 해결되지 않습니다. 독일 세무사들은 DATEV의 Kanzlei-Rechnungswesen 및 Unternehmen Online 플랫폼을 사용하며, 이 플랫폼은 두 가지 주요 배치 메커니즘을 통해 데이터를 가져옵니다:

CSV 가져오기 (DATEV 형식) — Kanzlei-Rechnungswesen용 고정 열 CSV로, 필드 순서는 Belegdatum, Buchungstext, Gegenkonto, Betrag, Soll/Haben 표시이며, 선택적으로 Buchungsschlüssel(전기 키)과 Kontierung(SKR03 또는 SKR04 기준 계정 번호)을 포함합니다. 파일은 구분자로 세미콜론, 인코딩은 ISO-8859-1, 날짜 형식은 DD.MM.YYYY를 사용해야 합니다. 쉼표와 MM/DD/YYYY를 기본값으로 사용하는 영어 도구에서 내보낸 CSV는 오류 없이 실패합니다.

XML 가져오기 (dxso-Jobs) — DATEV Unternehmen Online용으로, DATEV의 독점 XML 스키마를 사용한 배치 작업 제출입니다. dxso(DATA XML Send Online) 메커니즘은 DATEV의 XSD 스키마에 대해 검증된 XML 문서로 구성된 송장 데이터를 허용합니다. Unternehmen Online에는 XML이 필수이며, CSV는 데스크톱 Rechnungswesen 애플리케이션용입니다. 세무사(Steuerberater)는 워크플로에 따라 둘 중 하나 또는 둘 다 사용할 수 있습니다.

핵심 통찰: 추출 열은 대상 시스템이 예상하는 가져오기 열과 일치해야 합니다. 세무사가 DD.MM.YYYY 형식의 Belegdatum을 필요로 한다면, 추출 열을 "Invoice Date"가 아닌 "Belegdatum"으로 정의하세요. 비용을 계정 4930(SKR03: Sonstige Kosten)에 전기한다면, "SKR03 Konto"라는 열을 포함하고 적절한 코드를 입력하세요. 이렇게 하면 일반 추출 출력을 회계 소프트웨어 스키마에 맞게 변환하는 중간 단계가 사라집니다. 추출 자체가 가져오기 파일입니다.

DATEV로 보낼 80개의 송장 배치의 경우, 열 세트는 다음과 같을 수 있습니다:

• 증빙일자 — DD.MM.YYYY
• 전표 텍스트 — 공급업체명 + 송장번호 조합
• 대체계정 — 공급업체의 채권자 번호(SKR04 기준 70000번대)
• 금액 — 총액(부가세 포함)
• 차변/대변 — "S"는 차변(비용), "H"는 대변
• SKR03 계정 — 비용 계정(예: 잡비 4930, 상품 3400)
• 부가세율 — 19 또는 7 또는 0
• 매입부가세액 — 환급 가능한 부가세 금액

Lexware Office와 sevDesk는 자체 CSV 템플릿을 사용하지만 원리는 동일합니다. 추출 열을 가져오기 스키마에 맞게 정의하고, CSV로 내보낸 후 직접 가져오면 됩니다. 일괄 처리의 가치 제안 — 80장의 송장을 단 몇 분 만에 처리 — 은 출력물에 추가로 한 시간의 스프레드시트 재작업이 필요 없을 때에만 완전히 실현됩니다.

워크플로우 — 80장의 매입 송장을 한 번에 처리하는 방법

형식 다양성, 부가세 분할, DATEV 호환성이라는 구조적 과제를 파악한 후, 80장의 송장 폴더에서 세무사 준비 스프레드시트까지 이어지는 종단 간 일괄 워크플로우는 다음과 같습니다:

검증 단계에서 특히 중요한 점은: 배치에서 가장 위험도가 높은 항목은 잘못 보이는 항목이 아니라, 공급업체 특유의 서식 차이로 인해 특정 필드가 체계적으로 잘못 읽혔지만 정상으로 보이는 항목입니다. Metro 송장이 다른 79개 송장과 Nettobetrag 정렬 방식이 다르다고 해서 오류가 표시되지는 않습니다. 셀에는 숫자가 있고, 그 숫자는 그럴듯해 보입니다. 이를 잡아내는 검사는 Bruttobetrag 기준 상위 10개 샘플 점검입니다: 원본 Metro 송장을 열어 총 brutto 금액과 추출된 brutto 금액을 비교하세요. 일치하면 추출이 정확할 가능성이 높습니다. 일치하지 않으면 조사해야 할 서식 차이가 있는 것입니다.

GoBD 준수 배치 보관 — 엑셀 파일이 아닌 원본을 보관하세요

배치 처리는 유혹적인 지름길을 만듭니다: 80개의 송장을 하나의 깔끔한 스프레드시트로 추출하고, 스프레드시트를 보관한 후 지저분한 원본을 삭제하는 것입니다. 이는 자동화된 송장 처리에서 가장 흔한 GoBD 준수 실수이며, 여러 측면에서 감사 요구 사항을 충족하지 못합니다.

GoBD(독일 상업 및 세무 기록 보관 원칙)는 2025년 7월 개정되어 독일 전자송장 의무화에 맞춰 조정되었으며, 세무 관련 문서는 파생되거나 변환된 버전이 아닌 원본 수신 형식 그대로 보존해야 한다고 요구합니다. 구체적으로:

• 구조화된 전자세금계산서 (XRechnung XML, ZUGFeRD 하이브리드 PDF): XML이 법적 세무 기록입니다. ZUGFeRD PDF로 수신된 경우, 전체 PDF/A-3 파일(내장 XML 포함)을 하나의 단위로 보관해야 합니다. 2025년 7월 개정안에 따르면, XML에 없는 추가 세무 관련 정보(예: 시각적 레이어의 수기 결제 메모)가 포함되지 않는 한 별도의 사람이 읽을 수 있는 PDF 사본은 필요하지 않습니다.
• 일반 PDF 및 스캔 문서: 원본 파일은 §147 AO에 따라 10년간 변경 없이 보관해야 합니다. 추출된 Excel 행은 작업용 사본일 뿐이며, 보관 대체물이 아닙니다.
• 촬영된 종이 세금계산서: 디지털 사진이 기록이 됩니다. GoBD의 불변성(Unveränderbarkeit) 원칙에 따라, 사진 파일은 타임스탬프, 해시, 또는 수정 잠금 시스템에 저장하여 추후 변경을 방지해야 합니다.

추출 결과물인 80행 Excel 스프레드시트는 운영 문서이지 보관 문서가 아닙니다. 일상적인 회계(Buchhaltung), 매입세액 공제(Vorsteuerabzug) 계산, DATEV 가져오기에 사용됩니다. 세무 조사(Betriebsprüfung) 시 감사관은 추출 스프레드시트가 아닌 원본 세금계산서 파일을 요청합니다. 추출물은 해당 원본으로의 추적 가능성만 제공하면 되므로, 스프레드시트에는 각 행의 출처 파일을 식별하는 열(파일명 또는 참조 번호)이 포함되어야 합니다. 이 추적 열이 없으면, 80개 세금계산서의 일괄 추출은 출처와 대조할 수 없는 80개 데이터 행을 생성하여, 추출 정확도와 관계없이 GoBD 규정 위반이 됩니다.

실용적인 배치 아카이빙 워크플로: 원본 파일을 날짜별 폴더(예: /Eingangsrechnungen/2026-05/)에 보관하고, 일관된 이름(2026-05-03_Metro_INV-48291.pdf)으로 저장하며, 추출 결과에 파일명을 열로 포함시킵니다. 세무사가 DATEV Unternehmen Online을 사용하는 경우, Belegverwaltung(문서 관리) 기능을 통해 원본 인보이스 파일을 해당 전표에 첨부할 수 있어, 스프레드시트에서 원본 문서, DATEV 감사 추적까지 연결 고리가 유지됩니다.

독일의 단계적 전자 인보이스 의무화(2025년 1월부터 수신 의무, 2027년부터 매출 80만 유로 초과 기업의 발행 의무, 2028년부터 전면 발행 의무)는 '지저분한 원본' 문제를 점차 줄이고 있습니다. 공급업체가 ZUGFeRD와 XRechnung으로 전환함에 따라, 내장된 XML 계층이 OCR 없이도 구조화된 데이터를 제공합니다. 그러나 전환 기간 동안 배치 파이프라인은 ZUGFeRD PDF, 일반 PDF, 2028년까지 전환하지 않는 공급업체의 스캔된 Rechnung 등 다양한 형식을 처리해야 합니다. 추출 워크플로는 이 세 가지를 모두 처리할 수 있어야 하며, 아카이빙 워크플로는 각각을 원본 형식 그대로 보존해야 합니다.

자주 묻는 질문

독일 인보이스 일괄 처리 워크플로우 시작하기

독일 Eingangsrechnungen의 일괄 처리는 특정 지점에 위치합니다. 바로 송장 수가 "수동 입력이 짜증나지만 관리 가능한 수준"에서 "수동 입력이 구조적 시간 낭비인 수준"으로 넘어가는 지점입니다. 대부분의 독일 중소기업에서 이 기준선은 월 40~60건 사이에 있습니다. 그 이하에서는 마찰이 워크플로우에서 발생합니다. DATEV를 열고, 필드를 입력하고, 저장하는 과정입니다. 그 이상에서는 마찰이 시스템적입니다. 형식 다양성, VAT 분할, 그리고 단일 송장 워크플로우로는 해결되지 않는 추적성 격차입니다.

여기에 설명된 일괄 처리 접근 방식(공급업체 형식에 관계없이 작동하는 열 이름 기반 추출, 자동 VAT 분류를 위한 추론 열, DATEV에 맞춰진 내보내기 스키마)은 송장당 속도가 아닌 시스템적 문제를 해결합니다. 18배의 효율성 향상(수동으로 송장당 3분 vs 추출 시 5~10초)이 핵심 수치입니다. 그러나 더 큰 운영적 변화는 이것입니다: 한 달 치 Eingangsrechnungen 전체가 하나의 작업이 됩니다. 빠르게 수행되는 80개의 작업이 아니라, 한 번 수행되는 하나의 작업입니다. 그 차이는 "데이터 입력이 빨라졌다"와 "데이터 입력이 더 이상 월말 마감의 일부가 아니게 되었다"의 차이입니다.