독일 상업송장(Handelsrechnung) 수출 데이터 오류 5가지
통관 지연 및 관세조사 유발 요인

이러한 오류가 실제로 발생하는 위치 — 세관 신고서가 아닌 송장 내부

독일 수출 선적은 ATLAS 수출 신고(Ausfuhranmeldung)로 시작되지 않습니다. 상업송장(Handelsrechnung)으로 시작됩니다. 이 서류는 국내 송장(Rechnung)에는 없는 두 가지 필드 세트, 즉 수출 부서가 템플릿에 입력하는 세관 관련 필드와 재무 부서가 UVA에 필요한 회계 필드를 함께 담고 있습니다. 아래 다섯 가지 오류는 모두 "송장에 입력된 내용"과 "이를 필요로 하는 시스템이 읽은 내용" 사이의 간극에서 발생합니다.

세관 데이터 오류를 방지하기 위한 일반적인 조언은 절차적입니다. EZT-online에서 HS 코드를 재확인하고, 관세총국(Generalzolldirektion)에서 EORI 등록을 확인하며, 수출 계약서와 인코텀즈(Incoterms)를 대조하고, 모든 송장에 사자확인원칙(Vier-Augen-Prinzip)을 적용하는 것입니다. 이 조언은 정확합니다. 그러나 모든 상업송장이 통관사에게 도달하기 전에 두 사람이 검토하는 환경을 전제로 합니다. 월 30건의 선적을 처리하고 수출 부서에 두 명이 있는 중견 독일 수출 기업의 경우, 검토는 합계 금액을 훑어보고 고객 주소가 올바른지 확인하는 수준에 그칩니다. 세관 관련 필드(11자리 관세율표번호, 품목별 원산지, EORI, 중량)는 제품 마스터 데이터나 이전 송장에서 복사되며 정확하다고 간주됩니다. 바로 이 가정이 오류를 키우는 지점입니다.

각 오류를 살펴보기에 앞서, 상업송장이 특히 오류에 취약한 구조적 맥락을 이해하는 것이 중요합니다. §14 UStG에 따른 국내 송장은 공급자 및 수취인 정보, 세금번호(Steuernummer) 또는 부가가치세 식별번호(USt-IdNr), 송장 번호 및 발행일, 재화 또는 용역의 수량과 설명, 순 금액, 부가가치세율 및 금액, 총 합계 등 약 10개의 필드를 포함하며, 이 모든 필드는 동일한 회계 시스템으로 전달됩니다. 반면 상업송장은 이러한 모든 필드에 더해 연합관세법전(UCC, 규정 (EU) 제952/2013호) 및 독일 대외무역령(Außenwirtschaftsverordnung, AWV)이 규율하는 세관 특화 필드를 추가로 포함합니다. 따라서 이 서류는 부가가치세법과 관세법이라는 두 가지 규제 체계의 적용을 동시에 받으며, 각 체계의 필드는 서로 통신하지 않는 다른 하위 시스템으로 전달됩니다. 이것이 바로 이중 송장 파이프라인 분석에서 심층적으로 검토하는 이중 파이프라인 문제입니다. 아래의 오류들은 바로 그 간극 내에서 발생하는 현상입니다.

오류 1: 품목별 HS 코드 분류 오류 — 물품 이동 전 ATLAS 반려

독일 상업송장(Handelsrechnung)에 기재되는 11자리 관세율표번호(Zolltarifnummer)는 송장당 하나의 번호가 아니다. 품목별로 하나씩 부여되며, 단일 수출 화물에는 3개, 5개, 또는 10개의 서로 다른 관세율표 항목에 해당하는 제품이 포함될 수 있다. 산업용 펌프와 예비 부품, 장착 브래킷, 제어반이 함께 선적되는 경우 HS 제84류(기계류), 제73류(철강 제품), 제85류(전기 기기)에 걸쳐 분류될 수 있으며, 각 품목마다 고유한 11자리 코드가 필요하고, 각 코드는 수출 통제 분류와 수입국의 관세율을 결정한다.

독일의 11자리 Zolltarifnummer는 계층적으로 구성된다: 첫 6자리는 국제 HS 코드(세계관세기구(WCO)에 따라 국제적으로 통일), 7~8자리는 EU 통합품목분류(CN) 확장 코드, 9~10자리는 TARIC 조치(반덤핑 관세, 관세 유예, 수량 제한)를 추가하며, 11번째 자리는 부가가치세 코드 및 특정 수입 통제를 위한 독일 국가 코드이다. 6자리 HS 코드가 정확하더라도 10번째 또는 11번째 자리에서 오류가 발생할 수 있으며, ATLAS는 수출 신고를 수락하기 전에 전체 11자리 코드를 검증한다.

실무에서 이 오류가 발생하는 방식. 수출 부서에서 5가지 다른 제품이 포함된 선적에 대한 Handelsrechnung을 생성한다. SAP, Microsoft Dynamics 또는 DATEV와 같은 ERP의 제품 마스터 데이터에는 각 제품의 관세 코드가 저장되어 있다. 그러나 제품 마스터가 18개월 전에 마지막으로 업데이트되었고, EU 통합품목분류(CN)가 1월에 개정되었다. 한 제품의 CN 코드가 8자리 수준에서 변경되었다. 다른 제품(예비 부품)은 엔지니어링 부서에서 "기계의 일부"라는 이유로 이전 감사에서 완제품 코드로 분류되었다. 이러한 오류는 Handelsrechnung에서 확인할 수 없다. 송장에는 ERP에 있는 그대로의 Zolltarifnummer가 기재된다. 오류는 ATLAS가 수출 신고를 처리할 때 신고된 품목 코드와 제품 설명 간의 불일치를 감지하거나, 목적지 국가의 세관 당국이 분류에 대해 문의했을 때 수출자가 이를 입증할 수 없는 경우에 표면화된다.

하류에서 발생하는 상황. ATLAS는 신고된 품목 설명 및 TARIC 수준에서 인코딩된 모든 적용 가능한 무역 조치(반덤핑, 이중 용도 통제)에 대해 관세 분류를 검증한다. 분류가 일관되지 않으면 ATLAS는 신고를 반려(Zurückweisung)한다. 반려의 연쇄 효과는 행정적이지 않다. 즉, 운영적이다:

즉각적인 반려 외에도, 잘못된 분류는 감사 위험을 초래한다. 관세총국(Generalzolldirektion)은 통관 후 적합성 감사를 실시하며, 선적 전반에 걸쳐 반복적인 분류 수정 패턴은 내부 통제가 취약함을 의미하며, 이는 향후 더 심층적인 조사를 초래한다. 최악의 경우, 오류는 ATLAS가 아닌 목적지 세관 당국에 의해 몇 달 후에 발견되며, 수입자는 소급 관세와 이자를 부과받고, 수출자는 입증할 수 없는 분류를 설명해야 한다.

송장 단계에서 예방이 어려운 이유. 상업송장(Handelsrechnung)을 생성하는 수출 부서는 ERP의 제품 마스터 데이터를 신뢰합니다. 모든 송장의 모든 라인 항목에 대해 11자리 코드를 EZT-online에서 확인하는 작업은 월 30건의 선적(평균 4개 라인 항목) 기준으로 월 120건의 품목 분류 점검에 해당합니다. 통관사(Zollspediteur)가 ATLAS 신고 과정에서 잘못된 분류를 발견할 수 있지만, 그 시점에는 이미 송장이 발행되어 고객에게 전달된 상태입니다. 이를 수정하려면 정정된 상업송장(Handelsrechnung)을 재발행하고 잠재적으로 상업 조건을 조정해야 합니다. 구조적인 해결책은 더 꼼꼼한 수출 부서가 아니라, 송장이 최종 확정되기 전에 분류 오류를 포착하는 것입니다. 즉, 데이터 캡처 시점에 추출된 관세 코드를 검증된 제품 마스터 데이터와 비교하는 것입니다. 관세 신고 HS 코드 오류 분석은 중개업체 관점에서의 분류 실패를 다루며, 상업송장(Handelsrechnung) 오류는 이를 유발하는 상류 원인입니다.

오류 2: 인코텀즈 불일치 — 송장에는 EXW, 물품가액(Warenwert)에는 운임 포함

상업송장(Handelsrechnung)에 기재된 국제상업조건(Incoterms 2020) 조항은 선적의 각 구간에서 운송비, 보험료 및 관세 위험을 누가 부담하는지 정의합니다. EXW(공장인도) 조건 송장은 구매자가 판매자의 공장에서 물품을 인수하며, 그 시점부터 모든 비용과 위험을 부담함을 의미합니다. 송장 금액은 공장도 가격이어야 하며, 운임, 보험료 또는 수출 통관 비용이 포함되어서는 안 됩니다. FOB(본선인도) 조건 송장은 판매자가 지정된 항구에서 물품을 선적까지 인도함을 의미합니다. 송장 금액에는 항구까지의 내륙 운송비가 포함되지만, 해상 운임이나 보험료는 포함되지 않습니다. CIF(운임보험료포함인도) 조건 송장에는 물품 대금, 보험료 및 지정된 목적지 항구까지의 운임이 포함됩니다. 송장 금액은 목적지까지의 양륙 비용입니다.

이 오류가 발생하는 방식. 수출 부서가 인코텀즈 EXW Stuttgart 조건으로 상업송장(Handelsrechnung)을 생성합니다. 송장 총액 필드(Rechnungsbetrag)에는 송장 하단의 총합계가 기재됩니다. 그러나 수출 코디네이터가 신속하게 작업하는 과정에서 운임 비용과 보험료를 물품가액(Warenwert) 라인 항목에 포함시켰습니다. 송장에 기재된 인코텀즈는 EXW입니다. 송장에 기재된 숫자는 CIF를 나타냅니다.

이러한 송장은 독일 수출 단계에서 ATLAS를 통과할 수 있습니다. 수출 신고(Ausfuhranmeldung)는 주로 품목 코드, 중량 및 EORI를 검증하기 때문입니다. 수출 목적의 관세 가격은 통계적 가치이며, ATLAS는 수출 측면에서 엄격한 가치 대 인코텀즈 일관성을 강제하지 않습니다. 오류는 목적지 국가의 세관에서 표면화됩니다. 수입업자는 해당 세관 당국에 상업송장(Handelsrechnung)을 제시합니다. 당국은 인코텀즈를 EXW로 확인합니다. WTO 관세 평가 협정에 따른 관세 평가를 위해 거래 가격은 물품에 대해 실제로 지불되었거나 지불해야 할 가격입니다. EXW 조건에서는 수출항까지의 내륙 운임과 보험료를 추가하여 FOB 관세 가격을 산출해야 합니다. 그러나 이 상업송장(Handelsrechnung)에서는 운임이 이미 물품가액(Warenwert)에 포함되어 있습니다. 세관 당국은 이제 선택에 직면합니다: 명시된 대로 EXW 가격을 수락하거나(과소 평가 — 운임이 이미 포함되어 있어 추가되지 않음), 가격이 인코텀즈와 일치하지 않는다고 이의를 제기하고 증빙 서류를 요구합니다.

수출업자가 부담하는 결과가 항상 직접적인 벌금인 것은 아니다. 이는 가치 검토를 위해 보류된 선적, 분쟁 가치에 대해 관세를 납부하는 수입업자, 그리고 수출업자가 자신의 인코텀즈(Incoterms)를 제대로 알고 있는지 의문을 품는 고객으로 이어진다. DDP(Delivered Duty Paid, 관세지급인도) 조건으로 선적하는 독일 수출업자의 경우 — 판매자가 목적지에서 모든 수입 관세를 부담하는 조건 — 통관 가격 오류는 수출업자가 부담해야 할 잘못된 관세 납부로 직결된다.

송장이 근본 원인인 이유. 송장 데이터를 입력하는 수출 담당자는 판매 계약(인코텀즈 명시), 포워더 견적서(실제 운송 비용 명시), ERP 제품 가격(상품 가치 명시)을 참고한다. 이 세 출처는 판매 주기의 서로 다른 시점에 세 명의 다른 사람이 작성한 것이다 — 계약은 영업팀, 운송 견적은 물류팀, 가격은 제품 관리팀이 작성한다. 상업송장(Handelsrechnung)은 이 세 숫자가 처음으로 함께 나타나는 문서이다. 불일치는 송장이 생성되는 순간 발생했다. 단지 세관 당국이 이를 읽기 전까지는 눈에 띄지 않았을 뿐이다.

오류 3: 포지션별 원산지(Ursprungsland) 오류 — 무효 특혜증명서(Präferenznachweis), EUR.1 거부

독일 상업송장(Handelsrechnung)의 원산지(Ursprungsland)는 해당 상품이 목적지에서 특혜 관세 대우를 받을 자격이 있는지 여부를 결정한다. 연합관세법전(UCC) 제60조에 따라, 비특혜 원산지는 상품이 완전히 획득된 국가 또는, 둘 이상의 국가가 관련된 경우, 마지막 실질 가공을 거친 국가이다. 각 자유무역협정의 특혜 원산지 규정에 따르면 기준은 더 엄격하다 — 특정 세번변경기준, 부가가치 임계값 또는 특정 가공 요건 — 그리고 수출업자는 공급자 신고서(Lieferantenerklärung) 또는 EUR.1 이동 증명서로 이를 입증해야 한다.

이 오류가 발생하는 방식. 독일 수출업자가 제어반을 제조한다. 금속 외함은 중국에서 조달되었다. 내부 배선, PLC, 단자대는 독일에서 조달되어 독일에서 조립되어 기능하는 제어 시스템을 형성한다. EU-일본 경제동반자협정의 특혜 원산지 규정에 따라, 조립이 충분한 가공에 해당한다면 제어반은 독일산으로 인정될 수 있다 — 그러나 동일한 상업송장(Handelsrechnung)에 별도의 예비 부품 라인 항목으로 공급되는 금속 외함은 중국 원산지를 유지한다. 송장을 생성하는 수출 부서는 상업송장(Handelsrechnung)의 모든 라인 항목 — 중국산 금속 외함을 포함하여 — 에 대해 원산지(Ursprungsland)를 "DE"로 입력한다. EUR.1 신청은 이 송장을 증빙 서류로 사용하여 제출된다. 상공회의소(IHK) 또는 세관(Zollamt)의 세관 당국은 신청을 검토하고, 원산지 신고를 제품 설명과 대조하여 불일치를 지적한다. EUR.1이 거부된다.

이 오류는 특히 다국적 원산지(多原産地) 선적을 처리하는 독일 수출업자에게 위험합니다. 독일, 중국, 태국에서 조달된 부품이 포함된 단일 화물은 동일한 상업송장(Handelsrechnung)의 세 가지 다른 라인 항목에 대해 세 가지 다른 원산지 신고가 필요합니다. 이 모든 것을 "DE"로 처리하는 것은 부정행위가 아닙니다. 이는 제품 마스터(완제품 원산지는 저장하지만 별도 판매되는 예비 부품의 부품 수준 원산지는 저장하지 않음)를 기반으로 작업하는 수출 조정자의 실수입니다. 제품 마스터는 재고 관리를 위해 구축되었으며, 관세 원산지 신고를 위한 것이 아니며, 이 둘 사이의 차이가 상업송장(Handelsrechnung)의 오류가 됩니다.

표준 독일 공급업체 조건(제조 부문의 일반 구매 조건(Allgemeine Einkaufsbedingungen)에서 찾을 수 있는 표준 조항)에 따라, 허위 원산지 신고 또는 허위 특혜증명서(Präferenznachweis)를 제공한 공급업체는 발생한 모든 손해에 대해 구매자에게 배상할 의무가 있습니다. 상업송장(Handelsrechnung)의 부주의한 원산지 입력으로 인해 거부된 EUR.1은 단순히 거부된 증명서가 아닙니다. 이는 공급업체의 책임입니다.

오류 4: 상업송장(Handelsrechnung)과 ATLAS 신고 간 EORI 번호(EORI-Nummer) 불일치

경제운영자등록식별번호(EORI-Nummer)는 EU 관세 시스템에서 수출업자의 고유 식별자입니다. 형식은 DE + 10~15자리(예: DE123456789012345)입니다. 연합관세법전(UCC) 제9조에 따라, 관세 활동에 참여하는 모든 경제운영자는 등록해야 하며 모든 관세 신고에 EORI 번호를 사용해야 합니다. EORI는 수출 선적에서 선택 사항이 아닙니다. EORI 없이는 ATLAS 수출 신고를 제출할 수 없습니다.

이 오류가 발생하는 방식. 오류는 EORI가 누락된 경우가 거의 없습니다. 상업송장(Handelsrechnung)에 인쇄된 EORI가 ATLAS에 등록된 EORI와 일치하지 않는 경우입니다. 이 불일치에는 몇 가지 일반적인 근본 원인이 있습니다:

다운스트림에서 발생하는 상황. ATLAS는 관세총국(Generalzolldirektion)의 중앙 EORI 데이터베이스에 대해 EORI를 검증합니다. EORI 불일치는 두 가지 결과 중 하나를 초래합니다. 신고서의 EORI가 유효하지만 송장에 명시된 법인과 다른 법인에 속하는 경우, ATLAS는 해당 신고서를 수동 심사(manuelle Prüfung) 대상으로 표시하여 통관 시간에 몇 시간 또는 며칠이 추가될 수 있습니다. EORI가 유효하지 않은 경우(만료되었거나 등록 취소된 법인에 속한 경우), ATLAS는 신고서를 즉시 거부하며 해당 선적물은 통관될 수 없습니다.

더 심각한 결과는 감사 추적 불일치입니다. 세무서(Finanzamt)가 §4 Nr. 1a UStG에 따른 부가가치세 면제를 위한 증빙 서류로 사용하는 상업송장(Handelsrechnung)에는 하나의 EORI가 기재되어 있습니다. ATLAS 수출 신고서에는 다른 EORI가 기재되어 있습니다. 부가가치세 조사(Umsatzsteuer-Sonderprüfung) 중에 세무서(Finanzamt)는 UVA 27번 라인에 보고된 면세 수출 매출에 대한 입증 자료를 요청할 수 있습니다. 조사관은 상업송장(Handelsrechnung)과 ATLAS 신고서를 비교하여 동일한 선적물에 대해 두 개의 다른 EORI 번호를 발견합니다. 조사관은 이제 의문을 가지게 되며, 조사관의 질문은 답변이 양호한 경우에도 시간을 소모하게 합니다.

오류 5: 순중량(Nettogewicht) / 총중량(Bruttogewicht) 불일치 — 중량 확인 시 ATLAS 검증 거부

이 목록에 있는 다섯 가지 오류 중에서 순중량(Nettogewicht)과 총중량(Bruttogewicht) 불일치는 가장 무해해 보이면서도 가장 빠르고 강력한 중단을 초래합니다. ATLAS는 수출 신고서의 중량 필드에 대해 자동화된 검증 확인을 수행하며, 중량 불일치는 세관(Zollamt)의 담당자가 확인하기 전에 신고서를 즉시 거부할 수 있습니다.

이 오류가 발생하는 방식. 수출 부서는 상업송장(Handelsrechnung)에 중량을 입력합니다. 품목별 순중량은 제품 마스터에서 가져옵니다. 예를 들어 펌프는 45kg, 모터는 12kg입니다. 총중량(상품 + 포장재)은 추정됩니다. 팔레트, 상자, 포장재에 대해 표준 15%를 추가하거나, 포워더의 패킹 리스트에서 복사하거나, 유사한 화물의 이전 선적물에서 가져옵니다. 상업송장(Handelsrechnung)에는 다음과 같이 명시될 수 있습니다:

• 순중량: 520 kg (모든 품목 순중량의 합계)
• 총중량: 535 kg (520 kg 상품에 대해 추정된 15 kg 포장재)

ATLAS는 비율을 확인합니다. 520kg 기계류에 대한 15kg의 포장재 대 상품 비율(약 2.9%)은 타당하지 않습니다. 520kg 화물에 대한 산업용 기계 포장재(나무 상자, 팔레트, 버팀대, 방습재)는 40~50kg 미만인 경우가 거의 없습니다. ATLAS는 중량 비율이 예상 범위를 벗어난 것으로 플래그를 지정하고 신고서를 거부합니다.

검증 외에 중량이 중요한 이유. 총중량은 운임을 결정합니다. 운송사는 운임 중량(해상 운송의 경우 총중량과 용적 중량 중 더 높은 값)을 기준으로 요금을 청구합니다. 상업송장(Handelsrechnung)에 기재된 과소계상된 총중량은 포워더가 선하증권 또는 항공화물운송장에 기록한 실제 중량과 일치하지 않을 수 있으며, 이는 세관이 가치 불일치로 플래그를 지정할 수 있는 서류 불일치를 생성합니다. 순중량은 또한 규제 기준을 촉발합니다. 독일 수출 규정에 따라 가치가 €1,000를 초과하거나 중량이 1,000kg을 초과하는 선적물은 ATLAS를 통해 신고되어야 합니다. 1,000kg에 근접한 중량이 과소계상된 경우, 해당 선적물이 신고 기준 미만으로 잘못 분류되어 세관(Zollamt)이 미신고 수출로 간주하는 준수 실패가 발생할 수 있습니다.

무게 오류는 해결책 자체는 단순해 보입니다(화물의 무게를 재면 됩니다). 하지만 실제로는 매우 흔하게 발생하는 오류입니다. 그 이유는 상업송장(Handelsrechnung)을 작성하는 수출 부서가 제품 마스터 데이터상의 순중량(개당)을 기준으로 작업하는 반면, 실제 포장 중량은 창고에서 물품을 포장할 때 결정되며(종종 송장이 이미 발행된 이후), 이 차이를 반영하지 못하기 때문입니다. 구조적인 해결책은 정책 변경이 아닙니다. ATLAS 신고서가 제출되기 전에 실제 포장 목록의 중량 데이터를 데이터 파이프라인에 다시 공급하는 것입니다. 즉, 데이터 추출 단계에서 상업송장(Handelsrechnung)의 중량을 단순히 전사하는 것이 아니라, 포워더의 포장 목록과 비교할 수 있도록 해당 중량을 포착해야 합니다.

단일 추출 단계가 신고서 제출 전에 이 다섯 가지 오류를 제거하는 방법

이 다섯 가지 오류는 부주의와는 무관한 공통된 구조적 근원을 가지고 있습니다. 상업송장(Handelsrechnung)에는 약 24개의 필드가 있습니다(국내 계산서(Rechnung) 구조에서 비롯된 14개 필드와 관세 관련 약 10개 필드). 이 중 5개의 관세 필드(관세율표번호, 인코텀즈(Incoterms), 원산지, EORI 번호, 중량)는 상호 의존적입니다. 즉, 한 필드의 값이 다른 필드의 유효 범위를 제한합니다. EXW 조건의 인코텀즈(Incoterms)는 물품가액(Warenwert)에 운임 비용이 포함될 수 있는지 여부를 결정합니다. 한 품목에 대한 DE(독일) 원산지 신고가 중국에서 조달된 다른 품목에 자동으로 적용되지는 않습니다. 송장에 기재된 EORI 번호는 신고서를 제출하는 법인과 일치해야 합니다. 순중량 대 총중량 비율은 물리적으로 타당해야 합니다. 이러한 상호 의존성은 사람이 PDF를 열고 각 필드를 개별적으로 확인하는 방식으로는 검증할 수 없습니다. 오류는 단일 필드에 있는 것이 아니라 필드 간의 관계에 있기 때문입니다.

맞춤 열 추출은 각 문서에서 추출하려는 데이터를 설명하는 열 이름 집합을 정의하는 것입니다. 이는 데이터를 추출하는 것(이는 당연한 부분입니다)이 아니라, 데이터를 테이블 구조로 정리하여 교차 필드 검증이 정신적 체크리스트가 아닌 스프레드시트 작업이 되도록 함으로써 문제를 해결합니다. 상업송장(Handelsrechnung) 데이터가 관세율표번호, 인코텀즈(Incoterms), 품목별 원산지, EORI 번호, 순중량, 총중량에 대한 열을 가진 구조화된 행으로 포착되면, 위의 다섯 가지 오류 각각이 하나의 화면에서 식별 가능해집니다:

변화는 위치 기반 판독(Handelsrechnung의 각 필드가 고정된 위치에 있어야 하며, 포워더의 레이아웃이 SAP와 다를 경우 작동이 중단되는 템플릿)에서 의미 기반 판독으로의 전환입니다. 의미 기반 판독이란 AI가 송장 내 위치와 관계없이 11자리 숫자 패턴을 이해하여 관세율표번호를 찾고, 3자리 코드로 인코텀즈 필드와 지급 조건 필드를 구분하며, EORI 번호는 DE 접두사가 붙고 원산지 코드는 2자리 ISO 코드임을 인식하는 것을 의미합니다. 추출이 템플릿 불필요 방식이므로, SAP의 Handelsrechnung, 수출 부서에서 서명한 종이 원본의 스캔본, 포워더가 생성한 견적 송장 모두 동일한 출력 테이블의 행을 생성하여 동일한 검증 검사를 거치게 됩니다.

추출 방식이 통관사를 대체하는 것은 아닙니다. 통관사는 여전히 ATLAS 신고를 접수하고, 이중 용도 분류를 확인하며, 세관(Zollamt)과의 관계를 관리합니다. 추출 방식이 대체하는 것은 수출 부서가 상업송장을 생성하고, 통관사가 그 필드를 ATLAS 소프트웨어에 재입력하며, 회계 부서가 그 일부를 ERP에 재입력하는 수동 단계입니다. 각 단계는 고유한 전사 오류를 발생시키며, 필드 간 상호 검증이 이루어지지 않습니다. 구조화된 추출 결과는 하나의 소스에서 세 가지 목적지 모두에 데이터를 제공하며, 교차 검증은 데이터가 개별 파이프라인으로 분기되기 전인 캡처 시점에 수행됩니다. 단일 상업송장의 필드별 추출에 대해서는 독일 상업송장 데이터를 Excel로 추출하는 가이드에서 전체 열 정의 및 설정을 다룹니다. 일괄 처리 측면, 즉 40개의 상업송장을 한 번에 처리하는 경우에는 일괄 수출 정산 가이드에서 통합 수출 원장 구축 방법을 다룹니다.

자주 묻는 질문