ZATCA Invoice XML과 PDF가
불일치할 때 어떤 값이 우선하는가

ZATCA 인보이스는 하나의 컨테이너에 담긴 두 개의 레코드입니다

서명된 XML이 인보이스이고, PDF/A-3는 이를 포함할 수 있는 렌더링입니다. ZATCA, 즉 Zakat, Tax and Customs Authority는 모든 Phase 2 인보이스를 ZATCA UBL 2.1 XML로 생성 및 저장하거나, 해당 XML을 내장한 PDF/A-3 파일로 생성 및 저장하도록 요구합니다. XML은 서명되는 객체이며, 표준 인보이스의 경우 구매자에게 도달하기 전에 ZATCA의 승인을 받거나, 단순 인보이스의 경우 24시간 이내에 보고됩니다. PDF는 사람이 읽을 수 있는 사본입니다.

ZATCA 전자 인보이스 상세 가이드라인은 흔한 질문에 직접 답합니다. 납세자가 PDF를 보내려면 XML을 내장한 PDF/A-3가 필수입니다. Phase 2에서는 일반 PDF, Word 파일 또는 스캔본은 준수하는 전자 인보이스가 아닙니다. 사람이 읽을 수 있는 사본도 아랍어로 작성해야 하며, 추가 언어는 함께 허용됩니다. 그래서 동일한 공급업체 이름이 아랍어와 영어로 두 번 나타날 수 있고, 두 버전이 매칭 규칙에서 서로 호환되지 않는 것입니다.

UBL 2.1은 이 형식의 기반이 되는 OASIS XML 표준입니다. 그 요소는 두 계열로 나뉩니다. cbc는 ID, IssueDate, TaxAmount와 같은 값에 사용되고, cac는 AccountingSupplierParty, InvoiceLine과 같은 컨테이너에 사용됩니다. 익숙한 접두사는 별칭입니다. 공급업체는 동일한 네임스페이스에 다른 접두사 이름을 사용할 수 있으므로, 파서는 cbc: 문자열을 매칭하기보다 네임스페이스를 해석해야 합니다. ZATCA XML 구현 표준은 UBL과 EN 16931 위에 사우디 규칙을 추가합니다.

PDF/A-3는 내장 파일을 허용하는 보관용 PDF 변형입니다. 하이브리드 인보이스는 평범해 보이는 페이지와 첨부 파일로 구성됩니다. 첨부 파일이 파싱 대상이고, 페이지는 사람이 읽는 대상입니다. QR은 세 번째의 더 작은 레코드로, 최대 500자까지의 tag-length-value 레코드로 이루어진 Base64 문자열입니다. tag 1~5는 판매자 이름, 판매자 VAT 번호, 타임스탬프, VAT 포함 합계, VAT 총액을 담고, tag 6~9는 해시, 서명, 공개 키, 그리고 단순 인보이스의 경우 해당 키에 대한 ZATCA의 서명을 담습니다. ZATCA의 전자 인보이스 프로그램은 Fatoora(فاتورة)라고 합니다.

AP 받은편지함에 실제로 도착하는 것

확장자는 거의 알려주지 않으며, 첨부 파일 모음이 파싱 가능 여부를 알려줍니다. 공급업체의 ERP가 올바른 하이브리드를 생성해도 구매자는 평탄화된 PDF를 받을 수 있습니다. 조달 포털은 첨부 파일을 다시 렌더링하고, 이메일 게이트웨이는 이를 제거하며, AP 담당자는 파일링 전에 PDF로 인쇄합니다. 받은편지함의 인보이스는 완벽해 보이지만 구조적으로 비어 있을 수 있습니다. ZATCA의 2025 연례 보고서에 따르면 해당 연도의 전자 인보이스 볼륨은 80억 건을 넘으므로, 혼합된 받은편지함은 예외적인 경우가 아닙니다. 아래 네 가지 상태는 각각 다른 처리가 필요합니다.

반대의 경우도 발생합니다. ZATCA 개발자 포럼에는 공급업체가 PDF/A-3에 이미지로 값을 제공할 수 있는지 묻는 스레드가 있습니다. 파일은 적합성을 선언하지만, 폰트가 없고 픽셀만 있기 때문에 문자를 선택하거나 복사할 수 없습니다. 이 경우 내장된 XML이 유일한 기계 판독 가능 계층이며, OCR은 기본이 아니라 대체 수단이 됩니다. 포럼 스레드는 "PDF/A-3"가 컨테이너를 설명하는 것이지 페이지의 가독성을 설명하는 것이 아니라는 유용한 알림입니다.

파일 이름이 아니라 첨부 파일을 확인하십시오. PDF 리더에서 첨부 파일 패널을 열거나 /AF 항목을 검사하고, 파일을 통제된 작업 폴더로 추출하며, XML로 파싱되는지 확인한 후 원본 바이트는 그대로 두십시오. 첨부 파일이 누락되었거나 손상되었거나 접근할 수 없는 경우, 페이지를 사용하기 전에 해당 상태를 기록하십시오. 위의 네 가지 상태는 동등하지 않으며, 관찰된 페이지를 파싱된 페이로드로 취급하는 것이 AP 예외가 처음으로 손실되는 지점입니다.

결제를 결정하는 필드

AP에는 약 12개의 헤더 필드와 라인당 5개의 필드가 필요하며, XML은 그 모든 필드의 이름을 명시합니다. 아티팩트 분류가 끝나면 값이 파서에서 오든 페이지에서 오든 필드 목록은 동일합니다. 이 표는 전체 데이터 사전이 아니라 실무용 맵입니다. 결제, 세금 전기 또는 중복 확인을 바꾸는 필드만 남기고 판매자의 통관에만 중요한 필드는 제외했습니다. 경로는 Invoice 루트를 기준으로 합니다.

두 가지 규칙이 이 맵을 쓸 수 있게 만듭니다. 수량과 단가도 추출하더라도 LineExtensionAmount와 PayableAmount는 별도 열로 추출하십시오. 문서에 이미 명시된 값을 다시 계산하는 것이 AP가 존재하지 않는 차이를 만드는 방식입니다. 정규화된 값 옆에 원본 문자열도 함께 보관하십시오. 앞에 0이 붙은 인보이스 번호, 아랍어 법인명, Arabia Standard Time 타임스탬프는 너무 일찍 강제 변환하면 정보를 잃습니다. 아랍어 이름은 문자는 맞더라도 시각적 순서가 다르게 표시될 수 있으므로, 값을 다시 입력하지 말고 원본 문자열을 보관하고 표시 방향을 설정하십시오. 헤더와 라인 분리가 생소하다면 인보이스 데이터 추출 완전 가이드에서 일반 모델을 다룹니다.

두 계층이 실제로 불일치하는 지점

대부분의 불일치는 손상이 아닙니다. 서로 다른 필드를 올바르게 렌더링한 두 가지 결과입니다. 아래 다섯 가지 사례가 데이터 오류처럼 보이지만 실제로는 매핑 오류인 AP 예외의 대부분을 차지합니다.

행 할인은 단가가 아니라 행 순액을 변경합니다

ZATCA의 시행 표준은 행 순액을 ((품목 순가격 ÷ 기본 수량) × 청구 수량)에서 행 할인을 빼고 행 추가금을 더한 값으로 정의합니다. SAR 100에 10개 단위와 SAR 50의 행 할인이 있는 행의 행 순액은 SAR 950이며, 인쇄된 단가는 SAR 100으로 유지됩니다. PDF에 단가와 행 합계는 표시되지만 할인이 표시되지 않으면 페이지가 산술적으로 잘못된 것처럼 보입니다. 그러나 그렇지 않습니다. 할인은 XML 내 cac:InvoiceLine/cac:AllowanceCharge에 있습니다.

AP가 수량과 단가를 추출하여 행 합계를 계산하면 SAR 950이라고 표시된 문서에 대해 SAR 1,000을 얻게 됩니다. 그러면 인보이스는 통과했어야 할 검사에서 실패하거나, 담당자가 균형을 맞추기 위해 잘못된 필드를 조정하게 됩니다. 명시된 행 순액을 추출하고, 할인을 별도 열에 유지하여 나중에 산술을 재현할 수 있도록 하십시오.

계산 열은 확인용으로 유용합니다. 그러나 문서가 명시한 행 순액을 대체하지는 않습니다.

선급금은 총액을 두 개의 숫자로 분할합니다

ZATCA의 선급금 예시는 이 패턴을 보여줍니다. VAT 포함 SAR 230, 이미 선급된 SAR 104, 지불해야 할 SAR 126. TaxInclusiveAmount는 230, PrepaidAmount는 104, PayableAmount는 126입니다. 세 가지 모두 정확하며 각각 다른 질문에 답합니다. 지불 금액을 PayableAmount에, 인보이스 가치를 TaxInclusiveAmount에, 선급금을 자체 열에 매핑하십시오. ERP에 단일 총액 필드가 있으면 인보이스 가치를 거기에 넣고 지불 일정에 지불 금액을 담으십시오. 하나를 다른 것으로 덮어쓰면 선급금이 숨겨지고 두 번 지불하게 됩니다.

외화 인보이스는 두 개의 세금 총액을 포함합니다

문서 통화가 SAR이 아닌 경우 ZATCA는 TaxCurrencyCode가 SAR이어야 하며 SAR로 표시된 두 번째 세금 총액을 요구합니다. PDF는 종종 문서 통화만 인쇄합니다. 인쇄된 총액을 월말 환율로 환산하는 AP 팀은 XML에 있는 것과 다른 SAR VAT 수치를 얻게 되며, 그 차이는 VAT 환급 계정에 반영됩니다. 두 세금 총액을 모두 읽고, SAR 금액을 전기하며, 문서 통화 금액은 공급업체 원장을 위해 유지하십시오.

PDF에는 XML에 반드시 포함되지 않아도 되는 필드가 있을 수 있습니다

ZATCA의 표준은 최소 요건입니다. Fatoora 개발자 포럼에서 한 공급업체가 PDF/A-3에 인쇄된 추가 정보가 XML에도 나타나야 하는지 질문했습니다. 답변은 데이터 사전 외부의 필드는 XML에 필수가 아니지만, UBL을 준수한다면 추가할 수 있다는 것이었습니다. 구매 주문 번호, 납품서 참조, 내부 비용 센터, 승인 스탬프가 바로 여기에 해당하는 경우가 많습니다. 이들은 페이지에는 있지만 페이로드에는 없습니다.

순수 XML 파이프라인에서는 이것이 공백입니다. 3방 대사에는 PO가 필요하고, 지급 일정에는 만기일이 필요합니다. XML에는 cac:OrderReference와 cac:PaymentTerms가 있지만, 공급업체가 모든 인보이스에 이를 채울 의무는 없습니다. 실용적인 설계는 필드 수준의 소스 열입니다. 세금과 신원 정보는 XML에서, 운영 맥락은 페이지에서 가져오고, 어느 쪽에도 없을 때는 명시적인 "없음" 상태를 두는 것입니다.

크레딧 노트는 새 문서이지 마이너스 인보이스가 아닙니다

크레딧 노트는 인보이스 유형 코드 381을 사용하고, 정정 대상 인보이스에 대한 청구 참조를 포함하며, 사유를 명시하고, 일반적으로 문서 유형이 방향을 나타내므로 금액을 양수로 유지합니다. 이를 마이너스 구매 인보이스로 입력하면 부호가 두 번 뒤집힐 수 있습니다. 한 번은 유형에 의해, 한 번은 입력에 의해. 그 결과 잔액을 증가시키는 크레딧이 됩니다.

크레딧 노트를 참조된 인보이스와 상계하고, 참조가 해석되는지 확인하십시오. ZATCA 가이드라인은 하나의 크레딧 노트가 여러 원본 인보이스를 텍스트 범위로 참조하는 것을 허용하므로, 참조가 항상 단일 키는 아닙니다. 범위인 경우 크레딧을 분할하거나, 공급업체가 인보이스별 내역을 제공할 때까지 보류하십시오.

아래 표는 일반적인 사례를 라우팅 시트로 정리한 것입니다.

QR 코드는 일관성 검증 수단이지, 승인 증명서가 아닙니다

QR 코드를 페이지와 대조해 일치한다는 것은 두 값이 동일한 값에서 생성되었음을 증명할 뿐, 인보이스가 승인되었음을 증명하지는 않습니다. 코드에 포함된 비즈니스 값은 tag 1~5뿐입니다. 인보이스 번호도, 품목도, PO도, 구매자 VAT 번호도 없습니다. QR 코드는 요약이며, 그것도 아주 짧은 요약입니다.

접수 검사 용도로 사용한다면 tag 1~5는 여전히 유용합니다. 비교 전에 정규화하십시오. VAT 번호는 숫자로, 타임스탬프는 시점으로 맞춰야 합니다. Arabia Standard Time과 UTC가 동일한 시점을 나타낼 수 있기 때문입니다. 금액은 소수점 둘째 자리까지 맞추십시오. 불일치가 발생하면 보통 QR 코드가 다른 인보이스에 속해 있거나, 코드 생성 후 페이지가 재작성되었음을 의미합니다. 두 경우 모두 확인을 멈출 가치가 있습니다.

tag 6~9는 육안이나 휴대폰 스캐너로 확인할 수 없습니다. 이를 검증하려면 서명된 XML, 서명이 계산된 정확한 바이트 단위 형식, 인증서 체인, 그리고 폐기 여부 확인이 필요합니다. 아홉 개 필드를 표시하는 스캔은 아홉 개 필드를 표시했을 뿐입니다. 서명을 검증한 것이 아닙니다.

AP 팀은 이 문제에 대해 서로 다른 이야기를 듣습니다. Fatoora 개발자 포럼에서 한 AP 실무자는 이렇게 썼습니다. "ZATCA 지원팀은 공급업체 인보이스의 QR 코드를 스캔하는 것이 의무라고 합니다. 저는 Accounts Payable 관점에서 질문드립니다." 커뮤니티 리드의 답변은 스캔이 선택적 확인이며, 성공적으로 보고되거나 승인된 인보이스는 이미 전자세금계산서 요건을 충족한다는 것이었습니다. 같은 스레드에는 ZATCA 앱이 사우디아라비아 외 지역에서는 코드를 스캔할 수 없다는 기록도 있으며, 이는 다른 국가에 있는 공유 서비스 센터에 실질적인 문제입니다.

실용적인 입장은 다음과 같습니다. QR 코드는 샘플링 관리 및 첨부 파일 무결성 확인 용도로 사용하십시오. 인보이스별 필수 관문으로 삼지 말고, 스캔 결과를 승인 증거로 취급하지 마십시오. 증거는 승인 또는 보고된 XML이며, 그 응답과 함께 보관해야 합니다.

복사된 QR 코드는 조작된 페이지에 붙어 있을 수 있습니다. 값을 비교하십시오. 사각형을 증거로 삼지 마십시오.

예외 상황에서도 견디는 6단계 워크플로

사우디 전자세금계산서 AP 워크플로는 인보이스 라인당 하나의 행, 모든 필드에 대한 출처 레이블, 그리고 아무도 조용히 덮어쓸 수 없는 예외 상태를 생성해야 합니다. 각 단계는 의도적으로 지루합니다. 지루함이야말로 6년 후에도 결과를 방어할 수 있게 해줍니다.

세 명의 담당자, 세 가지 질문이 있습니다. AP 담당자는 상업적 일치와 공급업체 문의를 담당합니다. ERP 또는 통합 담당자는 첨부 파일, 네임스페이스, 파서를 담당합니다. 사우디 세무 책임자는 VAT 카테고리, 통관 증빙, 보존 결정을 담당합니다. 단일 "유효" 플래그는 이러한 답변을 하나로 합쳐 어느 팀이 조치해야 하는지 숨깁니다. 상태를 개별적으로 저장하십시오: 파싱됨, 스키마 실패, 값 불일치, 암호화 증빙 미검증, AP 보류, 지급 승인.

시각적 추출이 여기서 할 수 있는 것과 없는 것

시각적 추출 도구는 첨부 파일이 아닌 페이지를 읽으므로 이 워크플로의 PDF 측에 속합니다. 이것이 ImageToTable.ai가 담당하는 부분이며, "ZATCA invoice extraction"보다 좁은 역할입니다. 그래도 세 곳에서 유용합니다.

첫째는 PDF에만 존재하는 필드입니다. ERP가 XML을 파싱할 때 PO 번호, 납품서 또는 내부 승인이 나타나는 유일한 곳이 여전히 페이지일 수 있습니다. Custom Column Extraction을 사용하면 "PO Number", "Payment Due Date", "Delivery Note"와 같이 원하는 열 이름을 입력할 수 있으며, 모델은 고정 좌표가 아닌 의미로 값을 찾습니다. 입력한 열 이름은 출력 테이블의 헤더가 됩니다.

둘째는 XML 없음 예외입니다. 공급업체가 일반 PDF 또는 이미지만 있는 PDF/A-3를 보내면 파싱할 것이 없습니다. 페이지가 소스가 됩니다. 배치 처리는 혼합된 공급업체 레이아웃 폴더를 한 번에 처리하고 행을 하나의 스프레드시트로 병합합니다. 이것이 실행 가능한 예외 큐와 일회성 변환 더미의 차이입니다.

셋째는 시각적 비교입니다. Bbox 하이라이트가 있는 Review Mode를 사용하면 셀 위에 마우스를 올려 해당 셀을 생성한 원본 페이지의 영역을 볼 수 있고, 영역을 클릭하면 해당 셀로 돌아갈 수 있습니다. ZATCA 인보이스의 경우, 담당자가 페이지를 인쇄하고 자를 사용하지 않고도 인쇄된 지급 금액과 XML 값을 비교하는 방법입니다. AI의 원래 값은 유지되며 편집이 잘못된 경우 복원할 수 있습니다. 이미지만 있는 스캔과 밀집된 이중 언어 레이아웃의 경우 더 높은 Model Tier가 더 강력한 비전 모델을 사용합니다. Standard는 대부분의 인쇄된 테이블을 처리하며, 어려운 경우는 작은 아랍어 텍스트와 합계 위에 스탬프가 있는 스캔 출력물입니다.

한계도 마찬가지로 중요합니다. 내장된 XML을 열지 않고, 암호화 스탬프를 검증하지 않으며, QR 해시를 확인하지 않고, 공급업체를 ZATCA에 온보딩하거나 어떤 것도 제출하지 않습니다. PDF/A-3의 시각적 추출은 서명된 페이로드의 파싱이 아니라 렌더링된 페이지의 관찰입니다. 출력에 그렇게 표시하십시오. 페이지에서 라인 허용량을 생략하면 관찰에서도 생략되며, 4단계의 산술 검사가 그 차이를 잡아냅니다.

동일한 구분이 다른 시장에도 적용됩니다. 일본의 적격 인보이스 제도에는 의무화된 XML 페이로드가 없으므로 시각적 레이어가 종종 유일한 소스이며, 이것이 동일한 원칙이 Japanese qualified invoices에 적용되는 이유입니다. 독일의 의무화는 구조화된 파일을 인보이스로 만들며, 이는 German supplier invoices의 접수 순서를 변경합니다. 두 가지를 모두 처리하는 팀에는 하나의 필드 맵과 두 가지 접수 규칙이 필요합니다.

보관은 추출의 일부입니다

스프레드시트는 인보이스가 아니며, PDF만으로는 감사자가 검증할 수 있는 기록이 되지 않습니다. 사우디 VAT 시행규정 제66조에 따르면 인보이스, 장부, 기록 및 회계 문서는 해당 과세 기간 종료일로부터 최소 6년간 보관해야 합니다. 자본 자산 기록은 제52조 조정 기간에 5년을 더한 기간 동안 보관하며, 이는 동산의 경우 11년, 부동산의 경우 15년입니다. 기록은 아랍어로 작성되어야 하며, 전자적 또는 물리적 형태로 사우디 내에 보관하고 사우디 내 단말기에서 접근할 수 있어야 합니다.

수신한 XML 또는 원본 그대로의 PDF/A-3 컨테이너를 보관하십시오. 첨부파일의 추출본만 보관해서는 안 됩니다. 표준 인보이스의 경우 승인 또는 보고 응답을 보관하십시오. 이는 인보이스가 승인되었다는 증거이기 때문입니다. 인보이스 카운터와 이전 해시 체인을 그대로 유지하십시오. 누락 자체가 증거가 됩니다. 수정이 금지되어 있으므로 수정 세금계산서는 해당 인보이스와 함께 보관하십시오.

추출 기록에는 고유한 필드가 있습니다. 원본 파일 해시, 원본 유형, 파서 또는 모델 버전, 규칙 세트 버전, 필드 수준 출처, 정규화된 값, 원시 값 및 예외 상태입니다. 나중에 파서나 모델을 다시 실행하려면 동일한 바이트가 필요합니다. 원본을 정규화된 값으로 덮어쓰면 해당 행을 방어하는 데 필요한 증거를 파괴한 것입니다.

다른 승인 모델도 같은 점을 강조합니다. 폴란드의 KSeF 시스템은 식별자를 부여하며, 이 식별자가 없으면 인보이스는 법적으로 존재하지 않습니다. 멕시코의 CFDI 인보이스는 구조화된 파일과 인쇄 가능한 표현을 함께 제공합니다. 각 경우에 보관 대상은 PDF가 아니라 구조화된 아티팩트와 당국의 응답입니다.

자주 묻는 질문

ZATCA QR 코드에서 품목을 추출할 수 있나요?

아니요. tag 1~5에는 판매자 이름, 판매자 VAT 번호, 타임스탬프, VAT 포함 총액, VAT 총액이 담겨 있습니다. 청구서 번호도, 구매자 식별자도, 품목 상세도 없습니다. 이 코드는 그 다섯 가지 값을 교차 확인하는 데 사용하고, 품목 테이블을 만드는 데 사용하지 마십시오.

모든 PDF/A-3 청구서는 XML이 내장된 하이브리드인가요?

아니요. PDF/A-3는 내장 파일을 허용하는 컨테이너일 뿐이며, 공급자가 실제로 파일을 넣었는지, 첨부 파일을 읽을 수 있는지, 페이지가 그 파일에서 생성되었는지는 보장하지 않습니다. PDF를 구조화된 소스로 취급하기 전에 첨부 파일 모음을 열고 파일을 파싱하십시오.

청구서에 선급금이 포함된 경우 어느 총액을 기장해야 하나요?

청구서 금액은 TaxInclusiveAmount에서 기장하고, 지급할 금액은 PayableAmount에서 지급하십시오. PrepaidAmount는 별도 열에 담고 선급금 청구서와 연결하십시오. 세 가지를 하나의 "총액" 필드로 합치지 말고, 청구서 금액을 지급 금액으로 덮어쓰지 마십시오.

PDF/A-3가 법적 청구서인가요?

아니요. 서명된 XML이 청구서입니다. PDF/A-3는 이를 담을 수 있는 사람이 읽을 수 있는 사본입니다. 표준 청구서의 경우 승인된 XML 또는 승인된 하이브리드를 보관하고, 다시 저장한 PDF가 아닌 컨테이너를 보관하십시오.

ZATCA 청구서에 OCR을 사용할 수 있나요?

예, 사용할 수 있는 XML이 없을 때 가능합니다. 이미지만 있는 PDF, 스캔본 또는 사진은 시각적으로 읽을 수 있지만, 그 결과는 서명된 페이로드의 파싱이 아니라 페이지를 관찰한 것입니다. 방법을 기록하고, 동일한 정규화 및 산술 검사를 실행하며, 읽을 수 있는 경우 QR의 다섯 가지 값을 교차 확인하십시오.

여러 청구서를 참조하는 대변표는 어떻게 처리하나요?

음수 매입 청구서가 아니라 type 381과 billing reference가 있는 새 문서로 취급하십시오. 참조가 범위인 경우, 원래 청구서에 대해 대변표를 분할하거나 공급자가 청구서별 내역을 제공할 때까지 보류하십시오. 수정 대상 청구서에 순액으로 반영하고, 해당 청구서와 함께 보관하십시오.

ImageToTable.ai가 내장된 UBL XML을 파싱하거나 QR을 검증하나요?

아닙니다. PDF 페이지, 이미지 또는 스캔을 읽고 정의한 열을 추출하며, 인쇄된 페이지에만 있는 필드도 포함합니다. 내장된 XML 첨부 파일을 열거나, 암호화 스탬프를 검증하거나, QR 해시를 확인하거나, 공급업체를 ZATCA에 등록하거나, 신고서를 제출하지는 않습니다. XML 파싱과 서명 검증은 ERP 또는 통합 계층의 역할입니다.

사우디 공급업체 인보이스는 얼마나 보관해야 하나요?

해당 과세 기간 종료일로부터 최소 6년이며, 이는 VAT 시행규정 Article 66에 따른 것입니다. 자본 자산 기록은 조정 기간에 5년을 더해 보관하며, 이는 동산의 경우 11년, 부동산의 경우 15년입니다. XML 또는 원본 그대로의 PDF/A-3 컨테이너, 승인 또는 보고 증빙, 그리고 크레딧 노트를 함께 보관하십시오.

의문을 견뎌내는 행

감사에서 살아남는 인보이스는 모든 행이 자신이 어느 필드에서 왔는지, 그 뒤에 있는 산출물이 무엇인지, 그리고 어떤 검사를 통과했는지를 밝힐 수 있는 인보이스입니다. 그 매핑이 존재하면 PDF와 XML 사이의 불일치는 더 이상 미스터리가 아니라 담당자가 있는 대기열이 됩니다.