독일 송장 입력 비용이 더 많이 드는 이유
대부분의 재무팀이 생각하는 것보다

DATEV 역설: 소프트웨어는 어디에나, 손은 여전히 키보드 위에

NRW의 한 중견 제조 기업은 DATEV로 회계를 처리합니다. 세무사는 기업 라이선스를 보유하고 있고, 재무팀은 접근 권한을 갖고 있습니다. 매달 구독료를 지불합니다. 그리고 매달 그 사무실의 누군가는 PDF와 스캔 문서에 담긴 공급업체 인보이스 데이터를 스프레드시트에 필드별로 입력하는 데 이틀 반을 보냅니다. 세무사가 가져올 수 있도록 말이죠.

이것은 예외적인 사례가 아닙니다. 월 100~500건의 공급업체 인보이스를 처리하는 수천 개의 독일 중소기업(Mittelstand)에게 이것이 기본적인 현실입니다. 소프트웨어도 있고, 교육도 받았습니다. 그런데도 지난 10년간의 회계 기술 발전이 없었던 것처럼 수작업 데이터 입력을 계속하고 있습니다.

그 이유는 행동적 문제가 아니라 구조적 문제입니다. DATEV는 PDF를 읽지 못합니다. 세미콜론 구분자와 ANSI 인코딩의 CSV 파일이나 엄격한 스키마를 따르는 XML 문서 같은 구조화된 입력만 처리합니다. 각 필드에는 귀사의 세무사가 기대하는 이름이 있습니다: ISO 8601이 아닌 DD.MM.YYYY 형식의 Belegdatum. 이 항목이 19% VAT인지, 7% VAT인지, 아니면 §13b 역과세인지 DATEV에 알려주는 숫자 세금 코드인 Steuerschlüssel. 차트 구조에 따라 4~8자리 숫자로 올바른 SKR03 또는 SKR04 계정 코드에 매핑된 Gegenkonto. 소프트웨어가 장애물이 아닙니다. 공급업체가 보내는 것과 귀사의 회계 시스템이 수용하는 것 사이의 격차가 장애물입니다.

그리고 그 격차는 매달 한 화면의 숫자를 읽고 다른 화면에 입력하는 사람에 의해 채워집니다.

진짜 병목은 회계 소프트웨어가 아닙니다

독일 기업에서 한 달 동안 들어오는 공급업체 청구서의 일반적인 흐름을 살펴보겠습니다. 화요일 아침, 수신함에 PDF 세 통이 도착합니다. 하나는 Metro에서 온 것으로, 품목 코드, 수량, 단가, 순액, 그리고 19%와 7%로 분리된 부가세 소계가 별도 줄에 표시된 컬럼형 레이아웃입니다. 하나는 지역 Handwerker(수공업자)에게서 온 것으로, 손으로 쓴 청구서 번호와 단일 순액, 그리고 하단에 "zzgl. 19% MwSt."라고 휘갈겨 쓴 스캔된 A4 용지입니다. 하나는 네덜란드 공급업체에서 온 것으로, 영어로 작성되었고 Steuernummer(세금 번호)도 없고 별도의 부가세 줄도 없으며, 바닥글의 작은 글씨에 "역청구(reverse charge)"에 대한 언급이 숨겨져 있습니다.

청구서 세 통, 완전히 다른 추출 과제 세 가지. Metro 청구서는 어떤 라인 항목이 어떤 부가세율에 해당하는지 식별해야 합니다. Metro의 레이아웃이 페이지에서 명시적으로 구분해 주지만, 이 구분은 DATEV의 예약 라인당 단일 Steuerschlüssel(세금 키)로 변환되는 과정에서 유지되어야 합니다. Handwerker 청구서는 필기를 해독하고 "zzgl. 19%"가 실제로 순액에 부가세를 더한 것을 의미하는지, 별도 요금에 대한 설명이 아닌지 확인해야 합니다. 네덜란드 청구서는 EU 역내 역청구 시나리오를 인식하고 올바른 세금 코드로 §13b UStG에 따라 코딩해야 하며, 동시에 이 청구서에 USt-IdNr(부가세 식별 번호)이 없다는 점도 기록해야 합니다. 이 필드는 역내 거래 공제에 필수입니다.

이것이 소프트웨어 공급업체의 마케팅 페이지 어디에도 언급되지 않는 구조적 문제입니다: 공급업체 청구서 형식은 본질적으로 다양하며, 독일 회계 규정 준수는 본질적으로 정밀합니다. 이 두 사실 사이의 긴장감이 재무팀이 계속 수작업 입력을 하게 만드는 이유입니다.

SKR03과 SKR04의 이중 기준이 이 문제를 가중시킵니다. 동일한 사무실 임대료 공급업체 청구서도 회사가 사용하는 계정과목표에 따라 다른 비용 계정 코드로 매핑됩니다. SKR03은 프로세스 중심 계정군으로, SKR04는 재무 보고 정렬 방식으로 라우팅할 수 있습니다. 데이터 입력을 담당하는 사람은 자신이 어떤 시스템에 있는지 알고 매번 올바른 Kontierung(계정 배정) 로직을 적용해야 합니다. 두 공급업체가 동일한 레이아웃을 제시하는 경우는 없습니다. 동일한 공급업체 내에서도 두 청구서의 필드 위치가 동일하다고 보장되지 않습니다. 인지 부하는 누적되며, 그 작업을 하지 않는 사람에게는 보이지 않습니다.

잘못된 키 입력 한 번의 실제 비용

가장 명백한 비용은 시간입니다. 2025년 독일의 전 산업 평균 인건비가 시간당 €45.00(Destatis)이고, 송장 한 장당 필드 찾기, 입력, 세금 코드 확인, 계정 배정 확인에 약 15분이 소요된다고 가정할 때, 월 200장의 송장을 처리하는 기업은 50시간을 소비합니다 — 순수 데이터 입력 인건비로 매월 약 €2,250에 해당합니다. 이것이 눈에 보이는 비용입니다. 눈에 보이지 않는 비용은 더 큽니다.

수동 데이터 입력의 오류율은 문서 복잡성과 작업자 피로도에 따라 3%~5%입니다. 월 200장 기준으로 6~10장의 송장에 오류가 포함됩니다. Rechnungsnummer의 숫자 전위 오류는 Steuerberater가 대사 작업을 시도할 때 불일치를 발생시킵니다. 역청구(reverse charge) 송장의 잘못된 Steuerschlüssel은 가져오기 실패에 그치지 않고, 수개월 후 Betriebsprüfung에서 드러나는 잘못된 부가가치세 신고로 이어집니다. DD.MM.YYYY 대신 MM/DD/YYYY 형식으로 입력된 날짜는 해당 레코드 하나만이 아니라 전체 배치를 DATEV가 거부하게 만듭니다. Steuerberater가 이를 반송하면 월 결산이 며칠씩 지연됩니다.

정량화하기 더 어려운 비용도 있습니다. 2% Skonto 할인이 적용되는 공급업체 송장이 접수 당일에 처리되지 않고 대기열 지연으로 7일째에 입력되면, 실제 현금 손실이 발생합니다. EU 공급업체 송장의 USt-IdNr 누락은 감사 중 Finanzamt가 §15 UStG에 따라 매입세액 공제를 거부할 수 있는 컴플라이언스 리스크를 만듭니다. 6개월 전 그 송장을 입력한 담당자가 더 이상 회사에 없을 수도 있지만, 오류는 아카이브에 남아 있습니다 — GoBD에 따라 원본 구조화 형식으로 10년간 보존해야 합니다.

모든 키 입력은 영향을 남깁니다. 재무팀은 입력 시점에 그 비용을 느끼지 못합니다. 월 결산이 지연될 때, Steuerberater가 수정을 요청할 때, 또는 세무 조사에서 3분기 전 화요일 오후의 입력으로 거슬러 올라가는 불일치가 발견될 때 비용을 실감합니다.

문제를 해결하지 못할 의무 — 적어도 아직은

2025년 1월 1일부터 모든 독일 B2B 기업은 XRechnung 또는 ZUGFeRD 2.0.1+ 형식의 구조화된 전자 송장을 수신할 수 있어야 합니다. 2027년 1월까지 매출 80만 유로를 초과하는 기업은 이를 발행해야 합니다. 2028년 1월까지는 모든 기업이 발행해야 합니다. 서류상으로는 이는 수동 입력 문제를 원천적으로 해결하는 것처럼 보입니다. 송장이 구조화된 XML로 도착한다면 아무도 입력할 필요가 없기 때문입니다.

2025~2028년 전환 기간의 운영 현실은 깔끔함과는 정반대입니다. 단 일주일 만에 재무 팀은 대형 공급업체의 XRechnung XML 파일(기계 판독은 가능하지만 시각적 구성 요소가 없어 전용 뷰어가 필요함), 다른 업체의 ZUGFeRD 하이브리드 PDF(일반 PDF처럼 보이지만 대부분의 이메일 받은 편지함이 제거하는 구조화된 XML이 내장됨), 아직 전환 의무가 없는 소규모 공급업체의 기존 PDF, 그리고 여전히 물리적 우편을 보내는 개인 사업자의 촬영된 종이 송장을 받을 수 있습니다. 네 가지 형식, 네 가지 입력 채널, 하나의 목적지: 귀사의 Steuerberater가 기대하는 DATEV CSV입니다.

XRechnung과 ZUGFeRD는 수신 측에서 송장을 기계 처리 가능하게 만들도록 설계되었습니다. 그러나 "기계 처리 가능"은 수신 시스템이 XML 요소를 구문 분석하고, 올바른 DATEV 필드에 매핑하고, 계정과목표에 대해 세금 코드를 검증할 수 있을 때만 작동합니다. "재무 팀원이 PDF를 열고 스프레드시트에 입력하는" 워크플로우를 가진 기업의 경우 XML 파일의 도착은 아무것도 바꾸지 않습니다. 오히려 마찰을 추가할 수도 있습니다. XML은 뷰어 없이는 읽을 수 없으며, 누군가는 이를 프로그래밍 방식으로 구문 분석할지, 아니면 뷰어를 열어 필드를 읽고 어쨌든 입력할지 결정해야 하기 때문입니다.

전환 기간은 2027년 말까지 계속됩니다. 현장의 재무 팀에게 이는 3년 더 혼합 형식 처리를 의미하며, 전자 송장 의무는 문제를 해결どころか 이미 PDF, 스캔, 사진, 수기 문서를 포함하는 더미에 또 다른 형식을 추가합니다. 이 의무는 목적지 시스템을 위해 설계되었습니다. 그 사이의 인간적 연결고리는 고려하지 않았습니다.

추출이 더 이상 문제가 되지 않을 때

병목 현상이 회계 소프트웨어가 아니라 공급업체의 형식과 회계 소프트웨어의 형식 사이의 단계에 있다면, 해결책은 더 나은 회계 소프트웨어가 아닙니다. 더 나은 추출입니다. 특히, 다음 공급업체가 어떤 레이아웃을 사용할지 미리 알 필요가 없는 추출이 필요합니다.

기존 OCR 도구는 템플릿 방식으로 이 문제에 접근합니다. 페이지에서 특정 필드가 나타나는 영역을 정의하면 소프트웨어가 해당 영역을 읽습니다. 이는 한 공급업체에 대해서는 작동합니다. 그러나 두 번째 공급업체가 다른 레이아웃을 사용하는 순간 — 실제로는 두 번째 인보이스가 도착하는 순간 — 실패합니다. 독일 재무팀은 수십 개의 공급업체 각각의 계절별 형식 변형에 맞춰 템플릿 라이브러리를 만들고 유지 관리할 여유가 없습니다.

구조적 문제를 실제로 해결하는 다른 접근 방식은 AI가 인간처럼 문서를 읽게 하는 것입니다. 필드가 어디에 있는지가 아니라 무엇을 의미하는지를 이해하는 방식입니다. 이것이 맞춤 열 추출의 메커니즘입니다. 원하는 열 — Rechnungsnummer, Belegdatum, Lieferant, Nettobetrag, USt-Betrag, USt-Satz, USt-IdNr — 을 지정하면 AI는 문서의 의미론을 이해하여 페이지 상단, 하단, 표 안 또는 문단에 포함되어 있는지 여부와 관계없이 각 값을 찾습니다. 템플릿 없이, 영역 정의 없이, 공급업체별 설정 없이 말입니다.

Metro의 인보이스, 지역 Handwerker의 스캔 문서, 네덜란드 역청구(reverse-charge) PDF가 모두 동일한 파이프라인을 거칩니다. 출력은 각 행이 인보이스이고 각 열이 귀사의 Steuerberater가 DATEV 가져오기에 기대하는 필드 구조와 일치하는 스프레드시트입니다. 인간의 역할은 기록에서 검증으로 바뀌며, 인보이스당 몇 분이 아닌 몇 초가 소요됩니다.

지정한 필드는 출력 파일의 열이 되며, 귀사의 Steuerberater가 DATEV CSV 가져오기에 필요로 하는 정확한 구조를 갖춥니다. 이미 Steuerberater가 요구하는 필드를 알고 있다면 한 번 정의하고 매월 동일한 열 목록을 재사용할 수 있습니다. 재구성 없이, 수동 기록 없이, 47행의 날짜 형식이 DATEV에서 허용되는 형식인지 고민할 필요도 없습니다.

독일 공급업체 인보이스를 대량으로 처리하는 기업의 경우, 이 접근 방식은 일괄 워크플로와 직접 통합됩니다. 한 달치 Eingangsrechnungen을 한 번에 업로드하고, 추출 열을 한 번 지정하면, Steuerberater가 바로 사용할 수 있는 단일 통합 스프레드시트를 받게 됩니다. 인보이스 데이터를 DATEV로 가져오는 기본 메커니즘(예: §14 UStG에 따라 중요한 필드, SKR03/SKR04 차트 구조가 계정 코딩에 미치는 영향)은 이 워크플로를 처음부터 구축하는 독일 재무팀을 위해 자세히 다루었습니다.

수동 입력 중단 시 달라지는 점

수동 인보이스 입력의 가장 과소평가된 비용은 시간이나 오류가 아닙니다. 바로 인지 전환 비용입니다. 한 달에 이틀 반 동안 공급업체 데이터를 스프레드시트에 입력하는 재무 전문가는 현금 흐름을 분석하지 못하고, 지급 조건을 협상하지 못하며, 지출 패턴을 파악하지 못합니다. 판단력과 경험이 필요한 업무는 긴급하고 기한이 정해져 있지만 그런 것이 필요 없는 업무에 시간을 빼기면서 주변으로 밀려납니다.

전환은 추출이 단순 입력 작업이 아닌 검증 작업이 될 때 일어납니다. AI가 Metro 인보이스를 읽고 순액, VAT 구분, 공급업체 이름, 인보이스 날짜를 5~10초 만에 식별합니다. 재무팀 구성원은 추출된 필드를 검토하여 원본 문서와 일치하는지 확인합니다. 일치하면 해당 행이 승인됩니다. 일치하지 않으면 전체를 다시 입력하는 대신 한 번의 수정으로 끝납니다. 처리량은 시간당 약 4건에서 분당 약 4건으로 바뀝니다.

월 200건의 인보이스를 건당 15분씩 처리하는 기업은 데이터 입력에 50시간을 소비합니다. 건당 30초(추출 5~10초, 검증 20초)로 처리하면 같은 물량이 2시간 미만이 걸립니다. 월 48시간이 단순 입력에서 분석으로 전환됩니다. 이것이 지난달에 있었던 일을 보고하는 재무 기능과 다음 달에 있을 일을 설계하는 재무 기능의 차이입니다.

시간당 €45의 독일 인건비를 기준으로 계산하면 명확합니다. 월 수동 입력에 €2,250이던 비용이 검증에는 약 €90만 소요됩니다. 1년이면 €25,920의 인건비가 절감됩니다. 이 수치는 시간만 고려한 것이며, Skonto 손실 방지, Steuerberater 수정 주기 단축, 일관된 필드 추출로 제거된 감사 위험은 포함하지 않았습니다.

자주 묻는 질문

XRechnung 및 ZUGFeRD 전자송장과도 호환되나요?

XRechnung과 ZUGFeRD는 구조화된 형식으로, 이미 기계 판독 가능한 데이터를 포함하고 있습니다. 2025~2028년 전환 기간 동안의 추출 과제는 혼합 환경입니다. 같은 달에 XRechnung XML, ZUGFeRD 하이브리드 PDF, 기존 PDF, 스캔 문서를 모두 받게 됩니다. 이 도구는 기존 PDF와 스캔 문서를 동등하게 잘 처리합니다. 구조화된 XML 파일의 경우, Steuerberater가 가져오기 매핑을 구성한 후 회계 시스템에 직접 가져올 수 있는 경우가 많습니다. 추출의 가치는 구조화되지 않은 문서를 처리하는 데 있습니다. 오늘 도착하는 대부분의 문서가 여기에 해당합니다.

Steuernummer, USt-IdNr 같은 독일 송장 필드를 처리할 수 있나요?

네. AI는 템플릿 매칭이 아닌 의미론적으로 문서를 읽기 때문에 Steuernummer, USt-IdNr, Steuerschlüssel, Belegdatum 같은 필드가 페이지의 어디에 있거나 공급업체가 어떻게 표시하든 식별할 수 있습니다. 출력에 원하는 열 이름을 지정하면 AI가 각 문서에서 해당 값을 찾아냅니다. §14 UStG가 요구하는 필드와 추출 방법에 대한 자세한 안내는 독일 송장 추출 전체 가이드를 참조하세요.

DATEV 가져오기용 출력 날짜 형식은 무엇인가요?

AI는 문서에서 날짜 값을 추출하여 열 설정에서 지정한 형식으로 출력합니다. Steuerberater가 DATEV CSV 가져오기에 DD.MM.YYYY를 요구하는 경우 해당 형식으로 날짜를 출력하도록 열을 구성할 수 있습니다. 소수 구분 기호도 마찬가지입니다. 독일 회계 관례는 소수점에 쉼표를 사용하며(1.234,56), 출력도 이 관례에 맞출 수 있습니다.

소규모 공급업체의 수기 송장은 어떻게 처리하나요?

수기 문서는 독일 회계에서 입력 지연의 흔한 원인이며, 특히 소규모 Handwerker와 개인 사업자에게서 자주 발생합니다. AI는 필기체를 포함한 손글씨를 읽고 인쇄된 PDF에서 추출하는 것과 동일한 필드를 추출할 수 있습니다. 인쇄 문서보다 정확도는 낮지만, 빠른 수동 검증 단계에서 오독을 잡아낼 수 있으며, 이는 전체 송장을 처음부터 입력하는 것보다 훨씬 빠릅니다.

같은 배치에서 여러 언어로 된 인보이스를 처리할 수 있나요?

네, 가능합니다. 독일 기업들은 독일어 인보이스와 함께 영어, 네덜란드어, 프랑스어 등 다른 언어로 작성된 해외 공급업체 인보이스를 자주 받습니다. AI는 모든 언어를 동일한 배치에서 처리합니다. 역부과 VAT가 적용된 네덜란드 인보이스, TVA가 적용된 프랑스 인보이스, 19% MwSt.가 적용된 독일 인보이스가 모두 동일한 처리 큐에 들어가 하나의 통합 출력물로 생성될 수 있습니다.

저희 세무사의 기존 DATEV 환경에서는 어떻게 작동하나요?

출력물은 귀사가 세무사의 필드 요구사항에 맞게 구조화하는 표준 스프레드시트(Excel 또는 CSV)입니다. 귀사가 열을 정의하면 — Rechnungsnummer, Belegdatum, Nettobetrag, USt-Betrag, Steuerschlüssel, Gegenkonto — 도구가 각 행에 추출된 값을 채웁니다. 결과 파일은 세무사가 기대하는 방식 그대로 CSV 업로드 또는 Unternehmen Online을 통한 DATEV 가져오기에 바로 사용할 수 있습니다. 세무사 측에 설치할 통합 기능이나 구성할 API가 없습니다.

독일 인보이스 데이터 입력의 문제는 소프트웨어가 없다는 것이 아닙니다. 문제는 소프트웨어가 공급업체가 문서를 보내는 방식과 회계 시스템이 이를 소비하는 방식 사이의 간극을 메우도록 설계된 적이 없다는 것입니다. 그 간극은 사람이 메웁니다 — 자격을 갖추고 잘 훈련된 재무 전문가들이 기계가 처리해야 할 작업을 수행하고 있습니다. 그 간극이 유로와 시간, 감사 노출 측면에서 얼마나 비용이 드는지는 전자 인보이스 의무화가 완전히 시행될 때까지 기다린다고 해서 개선되지 않습니다. 추출이 수동 입력을 대체하는 순간 개선됩니다.