독일 송장 입력 비용,
대부분 재무팀이 깨닫는 것보다 더 많이 든다

DATEV 역설: 소프트웨어는 있는데, 여전히 키보드에 매달린 손

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

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

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

그리고 그 간극은 매달, 한 사람이 화면을 읽고 다른 화면에 숫자를 입력함으로써 채워집니다.

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

독일 기업의 전형적인 월간 인보이스 유입 과정을 살펴보겠습니다. 화요일 아침, 받은 편지함에 세 개의 PDF가 도착합니다. 하나는 Metro에서 온 것으로, 품목 코드, 수량, 단가, 순 금액, 그리고 19%와 7%의 부가세 소계가 별도 라인에 표시된 컬럼 형식입니다. 하나는 지역 수공업자(Handwerker)의 것으로, 수기로 작성된 인보이스 번호, 단일 순 금액, 그리고 하단에 "zzgl. 19% MwSt."라고 적힌 스캔된 A4 용지입니다. 마지막 하나는 네덜란드 공급업체의 것으로, 영어로 작성되었고 세금 번호(Steuernummer)나 별도의 부가세 항목이 없으며, 작은 글씨로 하단에 "역과세(reverse charge)" 참조가 숨겨져 있습니다.

세 개의 인보이스. 세 가지 완전히 다른 데이터 추출 과제. Metro 인보이스는 어떤 라인 항목이 어떤 부가세율에 해당하는지 식별해야 합니다. Metro의 레이아웃은 이를 페이지에 명확히 표시하지만, 이 정보는 DATEV의 전표 라인당 단일 세금 코드(Steuerschlüssel)로 변환되는 과정에서 유지되어야 합니다. 수공업자 인보이스는 필체를 해독하고 "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가 조정 시 불일치를 발생시킵니다. 역청구 인보이스의 잘못된 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년 전환기의 실제 운영 현실은 이와 정반대로 혼란스럽습니다. 단 1주일 만에 재무팀은 대형 공급업체의 XRechnung XML 파일(기계 판독 가능하지만 전용 뷰어가 필요하며 시각적 요소가 없음), 다른 업체의 ZUGFeRD 하이브리드 PDF(일반 PDF처럼 보이지만 대부분 이메일에서 구조화된 XML이 제거됨), 아직 전환 의무가 없는 소규모 업체의 기존 PDF, 그리고 여전히 우편을 보내는 개인 사업자의 촬영된 종이 송장을 접할 수 있습니다. 네 가지 형식, 네 가지 입력 채널, 하나의 목적지: 세무사가 요구하는 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의 인보이스, 지역 수공업자의 스캔본, 네덜란드 역청구 PDF 모두 동일한 파이프라인을 통과합니다. 출력은 각 행이 인보이스이고 각 열이 세무사가 DATEV 가져오기에 기대하는 필드 구조와 일치하는 스프레드시트입니다. 사람의 역할은 기록에서 검증으로 전환되며, 인보이스당 몇 분이 아닌 몇 초가 소요됩니다.

지정한 필드가 출력 파일의 열이 되어, 세무사가 DATEV CSV 가져오기에 필요한 구조를 정확히 만듭니다. 세무사가 요구하는 필드를 이미 알고 있다면 한 번 정의하고 매달 동일한 열 목록을 재사용하면 됩니다. 재포맷, 수동 입력, 47번째 줄의 날짜 형식이 DATEV에서 허용될지 고민할 필요가 없습니다.

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

수기 입력 중단 시 변화

수동 인보이스 입력의 가장 과소평가된 비용은 시간이나 오류가 아닙니다. 바로 인지 전환 비용(cognitive switching cost)입니다. 한 달에 이틀 반을 공급업체 데이터를 스프레드시트에 입력하는 데 보내는 재무 전문가는 현금 흐름을 분석하거나, 지급 조건을 협상하거나, 지출 패턴을 파악하지 못합니다. 판단력과 경험이 필요한 업무는 긴급하고 마감이 정해져 있지만 그 어떤 것도 필요로 하지 않는 작업이 가용 시간을 소모하면서 뒷전으로 밀려납니다.

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

월 200건의 송장을 처리하는 기업은 건당 15분씩 총 50시간을 데이터 입력에 사용합니다. 건당 30초(추출 5~10초, 검증 20초)로 동일한 분량을 2시간 미만에 처리할 수 있습니다. 월 48시간의 업무가 단순 입력에서 분석으로 전환됩니다. 이것이 지난달 실적을 보고하는 재무 기능과 다음 달 방향을 결정하는 재무 기능의 차이입니다.

독일 인건비가 시간당 €45임을 감안하면 계산은 간단합니다. 월 수동 입력 비용 €2,250이 검증 비용 약 €90으로 줄어듭니다. 연간 기준으로 €25,920의 인건비를 절감하는 셈이며, 이는 시간 비용만 고려한 수치입니다. 스콘토 손실 방지, 세무사(Steuerberater) 수정 주기 단축, 일관된 필드 추출로 인한 감사 리스크 제거 효과는 포함되지 않았습니다.

자주 묻는 질문

XRechnung 및 ZUGFeRD 전자송장에서도 작동하나요?

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

Steuernummer(세금번호) 및 USt-IdNr(부가가치세 식별번호)와 같은 독일 송장 필드를 처리할 수 있나요?

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

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

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

소규모 공급업체의 수기 인보이스는 어떻게 처리하나요?

특히 소규모 장인(Handwerker)이나 개인 사업자의 수기 문서는 독일 회계에서 자주 마주치는 병목 지점입니다. AI는 필기체를 포함한 손글씨를 읽고 인쇄된 PDF에서 추출하는 것과 동일한 필드를 추출할 수 있습니다. 인쇄된 문서보다 정확도는 낮지만, 빠른 수동 확인 단계로 오독을 잡아낼 수 있으며, 이는 인보이스 전체를 처음부터 직접 입력하는 것보다 훨씬 빠릅니다.

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

네. 독일 기업들은 독일어 인보이스와 함께 영어, 네덜란드어, 프랑스어 등 국제 공급업체로부터 다양한 언어로 된 인보이스를 자주 받습니다. AI는 모든 언어를 동시에 처리합니다. 역청구 부가가치세가 적용된 네덜란드어 인보이스, TVA가 포함된 프랑스어 인보이스, 19% MwSt.가 적용된 독일어 인보이스 모두 동일한 처리 대기열에 넣어 하나의 통합 출력물을 생성할 수 있습니다.

이 기능이 세무사의 기존 DATEV 설정과 어떻게 호환되나요?

출력물은 세무사가 요구하는 필드에 맞춰 구조화할 수 있는 표준 스프레드시트(Excel 또는 CSV)입니다. Rechnungsnummer(인보이스 번호), Belegdatum(증빙일), Nettobetrag(순액), USt-Betrag(부가세액), Steuerschlüssel(세금 코드), Gegenkonto(대체 계정) 등 열을 정의하면 도구가 각 행을 추출된 값으로 채웁니다. 결과 파일은 세무사가 예상하는 그대로 CSV 업로드 또는 Unternehmen Online을 통해 DATEV로 바로 가져올 수 있습니다. 세무사 측에 설치할 통합 기능이나 구성할 API가 없습니다.

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