독일 세관 신고서 데이터를 Excel로 추출하는 방법
모든 항목을 다시 입력하지 않고

Zollanmeldung 데이터의 출처 — 그리고 데이터가 막히는 지점

EU 외부에서 독일로 수입되는 모든 화물은 세관 신고서(Zollanmeldung, 단일 행정 서류(SAD)라고도 함)를 제출해야 합니다. 이 신고서는 물품을 통관 절차에 배정하고, 11자리 관세율표 번호(Zolltarifnummer)로 분류하며, 가치, 원산지, 순중량을 신고합니다. 신고는 ATLAS(ITZBund가 운영하는 독일 국가 세관 IT 플랫폼)를 통해 전자적으로 제출되며, 법적 근거는 연합 관세법(UZK) 제158~163조입니다. ATLAS는 18자리 마스터 참조 번호(MRN)를 반환하고, 관세율표와 대조하여 신고를 검증한 후, 승인되면 물품을 자유 유통으로 반출합니다.

신고 자체는 구조화된 데이터입니다. ATLAS는 이를 구조화된 데이터로 수집합니다. 문제는 그 이후에 발생합니다. 관세사가 기록용으로 Zollanmeldung의 PDF 사본을 보내드립니다 — 동일한 데이터가 평면 문서로 렌더링된 것입니다. 여러 관세사나 통관 지점을 통해 수입하는 경우, 각각 고유한 형식으로 신고서를 보냅니다: 한 관세사의 PDF 레이아웃, 다른 관세사의 스캔된 종이 양식, 또 다른 관세사의 ATLAS 인터넷 세관 신고(IZA) 출력물입니다. 모든 신고서의 필드는 동일합니다 — 관세율표 번호(Zolltarifnummer), 원산지(Ursprungsland), 물품 가치(Warenwert), 발송국/도착국(Versand-/Bestimmungsland), 통관 절차 코드(Zollverfahrenscode, 4자리), EORI 번호(DE+15자리 형식), 순중량(Eigenmasse) — 하지만 각 페이지의 위치가 다르며, 그 중 어느 것도 스프레드시트에 깔끔하게 복사하여 붙여넣을 수 없습니다.

ATLAS와 스프레드시트 사이의 간극은 그 사이에 있는 PDF입니다 — 시스템이 표시는 할 수 있지만 읽을 수 없는 문서입니다. Zollanmeldung PDF에서 Excel로 다시 입력하는 모든 필드는 ATLAS가 이미 구조화된 형태로 보유하고 있는 필드입니다. 수동 입력은 정보를 추가하는 것이 아니라, 신고서 하나씩 형식을 변환하는 것입니다.

수동 입력이 왜 조정 차이를 만드는가

3개 제품군에 걸쳐 월 30건의 수입 선적을 관리하는 독일 수입 관리자는 관세사로부터 약 30개의 Zollanmeldung PDF를 받습니다. 각 신고서에는 최소한 11자리 Zolltarifnummer(6자리 국제 HS 코드의 독일 특정 확장판으로, EU 통합 명명법(KN) 8자리, TARIC 10자리, 국가 수준 11자리로 확장됨), 유로화 과세 가격, 원산지, EORI 번호가 포함됩니다. ATLAS 포지션 레벨 화면(Positionsdaten)의 완전한 수입 신고서에는 순중량(Eigenmasse, kg), 포장 수(Anzahl der Packstücke), 품목 가격(Artikelpreis), 통관 절차 코드(Zollverfahrenscode, 4자리 필드로 물품이 어떤 절차로 반입되고 어떤 절차에서 왔는지 표시)가 추가됩니다.

월별 보고를 위해 30건의 신고서에서 이러한 필드를 수동으로 추출하여 단일 스프레드시트에 입력하는 데는 신고서당 약 4~5분이 소요됩니다. 각 PDF에서 필드를 찾고, 값을 입력하고, 11자리 Zolltarifnummer(10자리 TARIC이나 8자리 KN이 아닌, 독일 세관이 실제로 수입 관세 계산에 사용하는 전체 11자리 Codenummer)를 올바르게 입력했는지 확인하는 과정입니다. 30건의 신고서 기준으로, 분석 한 줄을 시작하기 전에 2.5시간의 데이터 입력이 필요합니다.

조정 차이는 단순히 시간 문제만이 아닙니다. 이는 세 가지 구조적 문제로, 물량이 늘어날수록 더 심각해집니다:

첫째, HS 코드 전위 오류. Zolltarifnummer는 "6204.62.31.00.0"과 같이 총 11자리의 5개 숫자 그룹으로 구성됩니다. PDF에서 Excel로 다시 입력할 때 일반적인 타이핑 조건에서 약 500회 키 입력당 1회의 전위 오류가 발생합니다. 11자리 관세율표 번호는 11회 키 입력입니다. 평균 3개의 관세율 라인이 있는 30건의 신고서를 기준으로 약 990회의 키 입력이 발생하며, 이는 스프레드시트에서 약 2개의 관세율 코드가 잘못된다는 의미입니다. 이 오류는 세관 감사나 관세 재계산이 이루어질 때까지 눈에 띄지 않습니다.

둘째, 조정 지연. Zollanmeldung 데이터를 추출하는 목적은 공급업체의 상업 송장(Handelsrechnung)과 조정하기 위함입니다. 송장에는 상품 가격이 FOB 선전 기준 €12,000이라고 명시되어 있습니다. Zollanmeldung은 €12,800의 과세 가격을 신고합니다. 이는 CIF 함부르크 가격으로, 운임이 조정된 값입니다. 수입 관리자가 상품 도착 일주일 후에 세관 데이터를 입력한다면, 송장과 신고서 간의 차이는 일주일 늦게 발견됩니다. ATLAS 제출과 스프레드시트 가용성 사이의 체계적인 데이터 격차는 차이를 누적시킵니다. 즉, 30건의 선적, 30건의 잠재적 조정 사항이 선적 통관 시점이 아닌 월말에 일괄로 발견됩니다.

셋째, 신고서 간 비교 불가. Zollanmeldung 데이터가 30개의 개별 PDF에 흩어져 있을 때, "이번 달 수입품 중 관세율표 6204호를 사용한 것은?"이라는 질문에 답하려면 30개의 문서를 열어 각각을 살펴봐야 합니다. "Q3에 함부르크로 수입된 섬유 제품의 kg당 평균 신고 과세 가격은 얼마인가?"라는 질문에 답하려면 먼저 모든 데이터를 추출해야 합니다. 하지만 아무도 그렇게 하지 않습니다. 추출 자체가 병목이기 때문입니다. 데이터는 존재합니다. 단지 질문을 지원할 수 있는 형식이 아닐 뿐입니다. 이는 GST 보고를 위한 AU BAS 데이터 준비의 추출 병목 현상과 구조적으로 동일합니다. 문서에는 답이 포함되어 있지만 파일 전체에 흩어져 있어 비교하려면 먼저 추출이 필요합니다.

Zollanmeldung 필드를 단일 Excel 스프레드시트로 추출하는 방법

맞춤 열 추출은 작업 흐름을 역전시킵니다. 각 Zollanmeldung PDF를 열고 필드를 Excel에 직접 입력하는 대신, 팀에서 사용하는 정확한 독일 세관 필드명을 사용하여 열을 한 번 정의한 후 30개의 신고서를 모두 업로드 영역에 드롭합니다. 엔진이 각 PDF를 읽고, 페이지상의 위치가 아닌 의미를 이해하여 각 필드를 찾아내며, 정의한 열을 헤더로 하여 신고서당 한 행씩 하나의 스프레드시트를 생성합니다. 출력물은 병합이 필요한 30개의 개별 추출 결과가 아니라, 병합이 필요 없는 하나의 파일로 Excel(XLSX)로 내보낼 수 있으며 후속 조정 단계에 맞게 구조화됩니다.

추출된 세관 신고서(Zollanmeldung) 데이터로 할 수 있는 작업

스프레드시트는 최종 목적지가 아닙니다. 다음 세 가지 워크플로우를 가능하게 하는 중간 계층입니다. 월별 수입 보고서가 의존하는 워크플로우이며, 모두 동일한 추출 데이터 세트에서 시작됩니다.

공급업체 송장 대사. 추출된 세관 신고서(Zollanmeldung) 데이터의 가장 즉각적인 용도는 공급업체의 상업 송장(Handelsrechnung)과의 상호 참조입니다. 송장에는 본선 인도 가격(FOB)이 명시되고, 세관 신고서(Zollanmeldung)에는 EU 국경까지의 운임과 보험료를 포함한 운임·보험료 포함 가격(CIF) 과세 가격(Zollwert)이 명시됩니다. 두 값의 차이는 신고된 과세 가격이 기본 거래와 일치하는지 여부를 결정합니다. 세관 신고서(Zollanmeldung) 데이터가 송장 데이터 옆의 스프레드시트에 있으면 이 확인은 나란히 열 비교만 하면 됩니다. 스프레드시트가 없으면 30개의 PDF와 30개의 공급업체 송장을 한 쌍씩 수동으로 상호 참조해야 하며, 일반적으로 포워더(Spediteur)의 송장과 수입 부가세 명세서가 함께 도착하는 월말에 이루어집니다.

관세율표 번호별 월별 수입 요약. 추출된 스프레드시트와 추론된 HS 장(Chapter) 열을 사용하면 월별 수입 요약(관세 장별 총 과세 가격, 원산지별 총 순중량, 통관 절차 코드별 신고 건수)을 피벗 테이블로 생성할 수 있습니다. 내보낸 Excel을 열고, 열을 선택하고, 피벗을 만들면 보고서가 완성됩니다. 이는 각 세관 신고서(Zollanmeldung) PDF를 열고, 관세율표 번호(Zolltarifnummer)와 상품 가격(Warenwert)을 기록한 후 별도의 보고 스프레드시트에 값을 입력하는 수동 프로세스를 대체합니다. 이 작업은 30건의 신고에 대해 또 한 시간을 소모하며, 항상 월간 재무 회의 직전에 마무리되는 작업입니다.

EORI 및 통관 절차 코드 감사 추적. 모든 Zollanmeldung(세관 신고서)에는 수입업자의 EORI 번호(Economic Operators' Registration and Identification number — EU 관세 참여자를 위한 고유 식별자, 형식은 DE 뒤에 15자리)가 포함되어 있으며, 이는 2009년 7월 1일부터 규정 (EG) No. 312/2009에 따라 기존 독일 Zollnummer(세관 번호)를 대체하는 주요 참여자 식별자입니다. 각 신고서의 EORI(수입업자, 신고인, 대리인)가 포함된 스프레드시트는 관세사(Zollvertreter)가 집계된 형태로 제공할 수 없는 감사 추적을 생성합니다. EORI로 필터링하여 어떤 주체가 어떤 선적을 신고했는지 확인하고, Zollverfahrenscode(통관 절차 코드)로 필터링하여 표준 통관(통관 절차 코드가 "40"으로 시작)과 가공 위탁(코드가 "51"로 시작) 중 어떤 방식으로 수입되었는지 확인할 수 있습니다. 이 데이터는 항상 신고서에 존재했습니다. 스프레드시트에 담길 때 비로소 감사 가능해집니다.

독일 공식 양식에서 구조화된 필드를 추출하는 동일한 접근 방식은 무역 컴플라이언스 워크플로우의 다른 문서 유형에도 적용됩니다. 열을 한 번 정의하고 PDF 배치를 처리하는 패턴은 문서가 Zollanmeldung(세관 신고서), ELSTER 세금 신고서, 또는 상업 송장 상호 참조인지에 관계없이 동일합니다. 필드는 달라지지만 추출 메커니즘은 그렇지 않습니다.

단일 신고서를 넘어: 관세 데이터 허브 구축

단일 배치 추출은 월간 보고 문제를 해결합니다. 구조적 개선은 동일한 열 정의(7개의 관세 필드와 추론된 HS 챕터)가 매월 재사용될 때 발생합니다. 1월에 정의된 열 이름은 재구성 없이 2월과 3월의 신고서에도 작동합니다. 매월 배치는 동일한 열을 가진 스프레드시트를 생성합니다. 월별 파일을 연결하면 연간 누적 관세 데이터 허브가 완성됩니다. ATLAS(자동 관세 및 현지 통관 시스템)를 통해 제출된 모든 수입 신고서, 모든 Zolltarifnummer(관세율표 번호), 모든 신고된 과세 가격, 모든 원산지가 하나의 정렬 및 필터 가능한 Excel 파일에 담깁니다.

이는 관세 관리 플랫폼을 대체하는 것이 아닙니다. ATLAS에 신고서를 제출하는 기능은 여전히 관세사(Zollvertreter)의 업무입니다. 대체하는 것은 브로커의 PDF 출력물과 수입업자의 내부 시스템 사이의 수동 데이터 연결, 즉 수입 관리자나 물류 코디네이터가 PDF를 열고 관세율표 번호를 읽어 스프레드시트에 입력하는 단계입니다. 그 단계는 형식 변환이지 무역 전문성이 아닙니다. 이를 워크플로우에서 제거하면 이전에 Excel에 필드를 입력하는 데 2.5시간을 소비했던 사람이 이제 추출 결과를 확인하는 데 10분을 사용하고, 회사 공급망에 대한 지식이 실제로 필요한 조정 분석에 2시간을 사용하게 됩니다.

이는 독일 ELSTER 세금 양식에서 Excel로 데이터를 추출하는 것과 동일한 원리입니다. 세금 신고서는 PDF로 표시된 구조화된 데이터이며, 이를 스프레드시트로 추출하는 것은 형식 변환이지 회계가 아닙니다. 이러한 점에서 세관 신고서는 세금 신고서와 다르지 않습니다. 둘 다 모든 필드가 정의된 의미를 가진 공식 양식이며, 필드와 스프레드시트 사이를 가로막는 유일한 것은 입력하는 단계입니다.

FAQ — 독일 세관 신고서 데이터 추출