1단계와 2단계는 서로 다른 문제입니다
1단계(생성)는 QR 코드와 정해진 필드를 갖춘 구조화된 전자 세금계산서를 요구했습니다. 규정에 맞는 문서를 만들 수 있는 청구 시스템이라면 어느 것이든 요건을 충족했고, 회사 밖으로 나가는 데이터도 없었습니다. 2단계(연동)는 전혀 다른 범주의 작업입니다. 이제 시스템은 세금계산서를 발행할 때마다 ZATCA 플랫폼과 통신하고, 세무 당국이 그에 응답합니다.
많은 팀이 허를 찔리는 지점이 바로 이 한 가지 변화입니다. 1단계 구현은 문서 형식의 문제입니다. 2단계 구현은 가용성이 핵심인 시스템 연동으로, 암호화 키와 만료되는 인증서, 그리고 계산원과 인쇄된 세금계산서 사이에 놓이는 외부 의존성을 수반합니다.
승인(클리어런스)과 보고(리포팅)는 서로 다른 흐름입니다
표준 세금계산서, 즉 기업 간(B2B) 문서는 승인 절차를 거칩니다. 구매자에게 전달하기 전에 세금계산서를 ZATCA에 제출해야 하며, ZATCA가 승인하고 서명된 사본을 반환한 뒤에야 법적으로 유효한 세금계산서가 됩니다. 승인에 실패했다면 아직 세금계산서가 존재하지 않는 것입니다.
간이 세금계산서, 즉 일반적인 기업 대 소비자(B2C) 판매시점 영수증은 보고 절차를 거칩니다. 영수증을 즉시 발행해 건네고, 공표된 기한 안에 사후적으로 ZATCA에 보고합니다. 고객이 네트워크 응답을 기다리는 일은 없습니다.
실무상 결론은 POS와 B2B 세금계산서 발행이 서로 다른 장애 대응 방식을 갖춰야 한다는 것입니다. 매장 계산대는 연결이 끊겨도 판매를 계속하고 나중에 대사해야 합니다. B2B 세금계산서는 승인되기 전까지 발행된 것으로 취급해서는 안 됩니다.
암호화 요소를 순서대로 살펴보면
연동은 대부분 자격 증명을 차례로 갖추어 가는 과정입니다. 각 단계는 앞 단계에 의존하며, 어느 단계에서든 도입 작업이 멈춰 설 수 있습니다.
- 장치별 또는 청구 단위별로 생성하는 키 쌍과 인증서 서명 요청(CSR). 여기에는 부가가치세 등록 정보가 ZATCA가 요구하는 필드에 정확히 담겨 있어야 합니다.
- ZATCA 포털에서 받은 일회용 비밀번호(OTP)와 함께 CSR을 제출해 발급받는 컴플라이언스 인증서. OTP의 유효 시간이 짧기 때문에 가장 자주 실패하는 단계입니다.
- 컴플라이언스 검사. 발행하려는 유형별 세금계산서, 크레딧 노트(감액 계산서), 데빗 노트(증액 계산서) 샘플이 모두 통과해야 다음 단계로 진행할 수 있습니다.
- 실제 운영 문서에 서명하는 운영(프로덕션) 인증서. 만료일이 있으므로, 만료가 닥치기 훨씬 전부터 누군가 책임지고 관리해야 합니다.
세금계산서 자체에 담겨야 하는 것
제출하는 문서는 PDF가 아니라 UBL 2.1 XML입니다. 그 안에는 세금계산서를 검증할 수 있게 해 주는 요소가 들어 있습니다. 직전 세금계산서의 암호화 해시는 문서를 사슬처럼 이어 주어 삭제되거나 끼워 넣어진 세금계산서를 찾아낼 수 있게 합니다. 여기에 전자서명, 그리고 판매자명, 부가가치세 등록번호, 타임스탬프, 합계 금액, 부가가치세액, 서명 데이터를 정해진 바이너리 인코딩으로 담은 QR 코드가 더해집니다.
사람이 읽을 수 있는 출력물도 여전히 중요합니다. 구매자는 보관할 수 있는 문서를 원하기 때문입니다. 그래서 대부분의 구현은 서명된 XML을 내장한 PDF/A-3를 생성해, 사람이 읽을 수 있으면서 기계로도 검증할 수 있는 하나의 파일을 만듭니다.
설계 단계에서 대비해야 할 장애 유형
이를 실제 운영해 본 시스템이라면 모두 같은 짧은 목록을 겪었습니다. 각 항목은 나중에 고칠 버그가 아니라 설계 단계에서 내려야 할 결정입니다.
- ZATCA에 접속할 수 없거나 응답이 느린 경우. 간이 세금계산서는 대기열에 넣었다가 나중에 보고하면 되지만, 표준 세금계산서는 그대로 발행해 버릴 수 없습니다. 이때 계산원 화면에 무엇이 표시될지 미리 정해 두십시오.
- 인증서가 만료되는 경우. 갱신은 장애 대응이 아니라 일정에 따른 운영 업무입니다. 운영 인증서가 만료되면 세금계산서 발행이 완전히 멈춥니다.
- ERP는 허용하지만 ZATCA는 허용하지 않는 필드 때문에 세금계산서가 거부되는 경우. 흔치 않은 수량 단위, 또는 XML 매핑으로 표현할 수 없는 방식으로 구성된 할인·배송비 행이 대표적입니다.
- 백업 복원이나 데이터베이스 수동 수정 후 해시 체인이 끊어져, 이후의 모든 세금계산서가 그 문제를 물려받는 경우.
공급업체에 물어야 할 것
규정 준수를 주장하기는 쉽습니다. 유용한 질문은 구체적입니다. 샌드박스가 아닌 운영 환경에서 어떤 문서 유형을 승인받고 보고해 보았습니까? ZATCA 응답이 시간 초과되면 해당 판매는 어떻게 처리됩니까? 인증서는 누가 갱신하며, 무엇이 그 담당자에게 미리 알려 줍니까? 계약을 종료할 때 서명된 XML과 해시 체인을 내보낼 수 있습니까? 2단계를 실제로 운영해 본 공급업체라면 구체적인 답을 내놓을 것입니다. 이 문제들 하나하나로 어느 시점엔가 하루씩을 허비해 보았을 것이기 때문입니다.
자주 묻는 질문
ZATCA 1단계와 2단계는 무엇이 다릅니까?
1단계(생성)는 QR 코드와 정해진 필드를 갖춘 구조화된 전자 세금계산서를 요구했을 뿐, 회사 밖으로 나가는 데이터는 없었습니다. 2단계(연동)는 전혀 다른 범주의 작업으로, 시스템이 세금계산서를 발행할 때마다 ZATCA 플랫폼과 통신하고 세무 당국이 응답합니다. 1단계가 문서 형식의 문제라면, 2단계는 암호화 키와 만료되는 인증서, 계산원과 인쇄된 세금계산서 사이에 놓인 외부 의존성을 수반하는, 가용성이 핵심인 시스템 연동입니다.
2단계에서 승인(클리어런스)과 보고(리포팅)는 어떻게 다릅니까?
표준 세금계산서, 즉 기업 간 문서는 승인 절차를 거칩니다. 구매자에게 전달하기 전에 ZATCA에 제출해야 하며, ZATCA가 승인하고 서명된 사본을 반환한 뒤에야 법적으로 유효한 세금계산서가 됩니다. 간이 세금계산서, 즉 일반적인 판매시점 영수증은 보고 절차를 거쳐, 영수증을 즉시 발행해 건넨 뒤 공표된 기한 안에 사후적으로 ZATCA에 보고합니다. 고객이 네트워크 응답을 기다리는 일은 없습니다.
ZATCA에 접속할 수 없거나 응답이 느리면 계산대에서는 어떻게 됩니까?
두 흐름은 서로 다른 장애 대응 방식이 필요하며, 이는 나중에 고칠 버그가 아니라 설계 단계의 결정입니다. 간이 세금계산서는 대기열에 넣었다가 나중에 보고해야 하므로, 매장 계산대는 연결이 끊겨도 판매를 계속하고 이후에 대사합니다. 표준 세금계산서는 그대로 발행해 버릴 수 없으므로, 이때 계산원 화면에 무엇이 표시될지 미리 정해 두어야 합니다.
2단계 세금계산서에는 실제로 무엇이 담겨야 합니까?
제출하는 문서는 PDF가 아니라 UBL 2.1 XML입니다. 그 안에는 문서를 사슬처럼 이어 삭제되거나 끼워 넣어진 세금계산서를 찾아낼 수 있게 하는 직전 세금계산서의 암호화 해시, 전자서명, 그리고 판매자명, 부가가치세 등록번호, 타임스탬프, 합계 금액, 부가가치세액, 서명 데이터를 정해진 바이너리 인코딩으로 담은 QR 코드가 들어 있습니다. 구매자는 여전히 보관할 수 있는 문서를 원하므로, 대부분의 구현은 서명된 XML을 내장한 PDF/A-3를 생성합니다.
2단계 연동과 관련해 공급업체에 무엇을 물어야 합니까?
규정 준수를 주장하기는 쉬우므로 질문을 구체적으로 하십시오. 샌드박스가 아닌 운영 환경에서 어떤 문서 유형을 승인받고 보고해 보았습니까? ZATCA 응답이 시간 초과되면 해당 판매는 어떻게 처리됩니까? 운영 인증서는 누가 갱신하며, 만료 전에 무엇이 그 담당자에게 알려 줍니까? 계약을 종료할 때 서명된 XML과 해시 체인을 내보낼 수 있습니까?
이 가이드는 일반적인 정보이며 세무, 회계 또는 법률 자문이 아닙니다. 규정은 국가마다 다르고 시간이 지나면서 바뀝니다. 조치하기 전에 관할 세무 당국이나 자격을 갖춘 전문가에게 현재 상황을 확인하십시오.
단일 작업 공간에서 운영을 시작할 준비가 되었습니까?