멕시코 CFDI 전자세금계산서 처리
대부분 팀이 예상보다 어려운 이유

긴 청구서 그 이상: 표면적 문제

CFF 제29-A조를 준수하는 CFDI(인터넷 기반 디지털 세금 영수증)는 단순히 긴 청구서가 아닙니다. 이는 Anexo 20 기술 표준에 따라 구조가 정의된 정부 mandated XML 문서입니다. 현재 CFDI 4.0 버전에서 이 표준은 100개 이상의 XML 요소와 여러 조건부 검증 체인을 정의합니다. 하지만 문제를 필드 수로만 보는 것은 실제 처리 지연 원인을 놓치게 합니다. 어려움은 필드가 많다는 것이 아니라, 필드들이 서로 다른 문서, 다른 시스템, 다른 시점에 걸쳐 추적 의무를 생성하는 방식으로 연결되어 있다는 점입니다.

증상은 쉽게 발견됩니다. 공급업체의 PAC(공인 인증 제공업체)가 수취인의 RFC(멕시코 납세자 등록 번호)가 SAT 납세자 명부와 정확히 일치하지 않는다는 이유로 청구서를 거부합니다. 악센트 하나가 빠진 사소한 불일치일 수도 있습니다. 지난주에 은행을 통해 결제된 금액이 장부의 미결제 청구서 어디에도 나타나지 않는 경우, 해당 결제가 원본 문서의 항목이 아닌 원본 청구서의 UUID(범용 고유 식별자)를 참조하는 별도의 Pago 유형 CFDI로 발행되었기 때문입니다. 3주 전에 팀에서 처리한 청구서가 공급업체에 의해 취소된 것으로 밝혀졌지만, 회사에서 72시간 이내에 취소 요청을 수락하거나 거부하지 않아 자동 승인된 경우, AP 항목은 이제 무효화된 문서를 참조하게 됩니다.

이는 예외적인 경우가 아닙니다. 한 달에 소수 이상의 규모로 멕시코 공급업체 청구서를 처리할 때의 정상적인 운영 조건입니다. 그리고 이러한 문제는 공급업체의 관행 부족이나 부적절한 AP 도구에서 비롯된 것이 아니라, CFDI 시스템 자체의 아키텍처에서 비롯됩니다. 이 시스템의 설계 목표는 규제 가시성과 세금 집행이었지, 거래 수신 측의 운영 효율성이 아니었습니다.

레이어 1: 모든 CFDI를 소규모 세금 신고로 만드는 규제 아키텍처

대부분의 국가에서 인보이스는 상업 문서입니다. 무엇을, 누구에게, 얼마에 팔았는지 기록합니다. 세금 신고는 나중에 이루어집니다. 판매자가 부가가치세 신고서를 제출하거나 구매자가 비용을 장부에 기입할 때입니다. 멕시코에서는 인보이스가 곧 세금 신고입니다. 이 차이는 학문적이지 않습니다. 생성 시점에 어떤 정보가 반드시 포함되어야 하고, 문서가 법적 효력을 가지기 전에 누가 이를 검증해야 하는지를 바꿉니다.

멕시코는 세금 시스템 연구자들이 실시간 승인 모델이라고 부르는 방식을 운영합니다. CFF 제29조 제4항에 따라 모든 CFDI는 수취인에게 발행되기 전에 먼저 SAT(세무행정청, 멕시코 연방 세무 당국)에 전송되어야 합니다. 전송은 SAT 인증 중개 기관인 PAC를 통해 이루어지며, PAC는 Anexo 20 규칙에 따라 XML 구조를 검증하고, 발행자와 수취인의 RFC가 모두 SAT의 활성 납세자 등록부에 존재하는지 확인하며, 발행자의 CSD(디지털 서명 인증서)가 유효하고 취소되지 않았는지 확인하고, 세금 계산이 내부적으로 일관성이 있는지 확인한 후에야 디지털 세금 도장을 적용하고 할당된 UUID와 함께 검증된 CFDI를 반환합니다.

귀하의 AP 팀에게 이것이 의미하는 바는, 귀하가 받는 모든 CFDI는 이미 정부 검증 지점을 통과했다는 것입니다. 그 데이터는 공급업체의 주장이 아니라 SAT가 확인한 주장입니다. 이는 데이터가 일반 인보이스보다 더 권위적임을 의미합니다. 또한 데이터에 오류(잘못된 RFC, 잘못된 과세 제도 코드)가 있는 경우 공급업체가 빠르게 업데이트된 PDF로 수정할 수 없음을 의미합니다. 잘못된 CFDI는 공식적인 취소 절차를 통해 취소되어야 하며, 새로운 CFDI를 처음부터 다시 발행해야 합니다.

필요한 데이터 자체는 단순히 "이름, 날짜, 금액"이 아닙니다. CFF 제29조-A는 모든 Ingreso(소득 인보이스) 유형의 CFDI에 다음이 포함되어야 한다고 규정합니다: 발행자의 RFC, 법인명, 과세 제도 코드; 수취인의 RFC, 법인명, 과세 주소지 우편번호 및 세금 목적상 인보이스 사용 용도를 선언하는 Uso CFDI 코드; 발행 장소 및 날짜; 고유 일련 번호; 발행자의 디지털 서명; 수량, 측정 단위, SAT 제품/서비스 분류 코드, 단가 및 총액이 포함된 상세 라인 항목; 유형별 완전한 세금 내역(IVA — 부가가치세 — 이전 및 원천징수); 지불 방식 및 지불 방법(PUE는 일시불, PPD는 연불/할부 지불로 코딩됨); 그리고 UUID 및 인증 타임스탬프.

이러한 각 필드는 귀하의 기록뿐만 아니라 SAT의 상호 참조 엔진에도 중요합니다. 수취인의 RFC와 이름은 SAT의 납세자 등록부와 상호 확인됩니다. 과세 제도 코드(예: 법인의 경우 601, 사업 활동을 하는 개인의 경우 612, 급여 소득자의 경우 605)는 거래 양측에 적용되는 세금 처리를 결정합니다. 발행자가 신고한 제도와 보고된 소득 유형이 일치하지 않으면 자동 감사 플래그가 트리거될 수 있습니다. 이것이 멕시코 공급업체가 인보이스를 발행하기 전에 귀하의 정확한 RFC와 과세 제도 코드를 얻는 데 그렇게 엄격한 이유입니다. 그들은 관료적이어서가 아니라 SAT 기록과 일치하지 않는 데이터가 포함된 인보이스를 거부하는 시스템을 준수하고 있는 것입니다.

2026년 세제 개혁으로 이 계층에 새로운 차원이 추가되었습니다. CFF 제29-A조에 신설된 제IX항은 2026년 1월 1일부터 CFDIs가 실제이고 진실된 거래를 반영하도록 요구합니다. CFDI가 실제 법적 행위나 거래를 나타내지 않으면 허위로 간주되며, 발행자, 수취인 및 중개인에 대한 형사 책임을 포함한 결과가 따릅니다. 이는 회사가 수취하는 모든 CFDI의 중요성을 높입니다. 실제로 제공되지 않은 서비스에 대해 송장을 발행하는 공급업체는 단순히 보고 오류를 범하는 것이 아닙니다. SAT가 허위로 추정할 수 있는 문서를 생성하는 것이며, 회사의 이름과 RFC가 허위 CFDI 수취인으로 게시되어 세무 신고를 수정할 수 있는 30일의 기간이 주어질 수 있습니다.

요약하자면, 계층 1의 복잡성: 처리 중인 문서는 귀사를 위해 만들어진 것이 아닙니다. SAT의 실시간 모니터링 인프라를 위해 구축되었습니다. 귀사의 AP 워크플로우는 SAT가 요구하는 모든 필드와 모든 검증을 상속받습니다. 해당 필드가 회계와 관련이 있는지 여부와 관계없이 말입니다.

계층 2: 문서 아키텍처 — 하나의 거래가 두 개(또는 그 이상)의 XML을 생성하는 이유

규제 계층이 필수 필드를 추가한다면, 문서 아키텍처 계층은 거래 자체를 여러 파일로 분할합니다. 이것이 CFDI 처리가 미국 또는 유럽 송장 형식에 익숙한 AP 팀이 기대하는 것과 가장 크게 달라지는 지점입니다.

분할은 Método de Pago라는 필드에서 시작됩니다. 값이 PUE(Pago en Una Sola Exhibición — 일시불 지급)인 경우, Ingreso CFDI 자체가 완전한 거래를 기록합니다: 재화 또는 서비스, 금액, 세금 및 발행 시점에 전액이 결제되었음을 나타냅니다. 하나의 문서, 하나의 거래입니다. 이것이 CFDI가 일반 송장에 가장 가까운 형태입니다.

값이 PPD(Pago en Parcialidades o Diferido — 분할 또는 연기 지급)인 경우, Ingreso CFDI는 의무만을 기록합니다. 실제 지급(발생 시점, 금액, 방법)은 Pago(지급) 유형의 별도 CFDI에 기록되며, 여기에는 Complemento de Recepción de Pagos(지급 수령 보완서, 때로는 Complemento de Pago라고도 함)가 포함됩니다. 이 보완서는 원본 Ingreso CFDI의 UUID를 참조하며 다음을 기록합니다: 지급일, 지급 금액, 지급 방법(송금, 수표, 현금, 전자지갑), 해당되는 경우 통화 및 환율, 그리고 이 지급 후 잔액.

하나의 비즈니스 거래는 이제 함께 추적해야 하는 두 개의 XML을 생성합니다. 지급이 3회 분할로 이루어지면 4개의 XML이 생성됩니다: 하나의 Ingreso와 세 개의 Pago CFDI로, 각각 고유한 UUID를 가지며 보완서 구조를 통해 원본을 참조합니다. 이를 조정하려면 각 Pago 보완서의 UUID를 원본 Ingreso의 UUID와 일치시키고, 부분 지급액을 합산하여 잔액이 0이 되는지 확인해야 합니다. 받은 편지함에서 하나의 Pago CFDI를 놓치면, 은행에서는 출금이 표시되더라도 Ingreso가 원장에서 무기한 미지급 상태로 남게 됩니다.

이러한 이중 문서 구조는 거래량이 늘어날수록 하위 문제를 증폭시킵니다. 월말 마감 시, PPD 조건을 사용하는 50건의 멕시코 공급업체 송장을 처리하는 AP팀은 잠재적으로 100개 이상의 XML을 조정해야 합니다. 각각 Ingreso와 그 Pago 보완서 간의 UUID 교차 참조가 필요합니다. 수동 조정은 각 Pago XML을 열고, 참조된 UUID 노드를 찾고, 처리된 Ingreso 데이터베이스에서 일치 항목을 검색하고, 금액이 일치하는지 확인한 후, 둘 다 조정 완료로 표시하는 과정을 의미합니다. 조정당 3분씩, 50쌍의 PPD는 매달 AP 직원 시간 2시간 30분을 소모합니다. 한 국가의 공급업체에 대해서만 말이죠.

또 다른 문서 분할 차원은 XML과 PDF 표현 간의 관계입니다. 멕시코 법에 따라, 디지털 서명되고 PAC 스탬프가 찍힌 XML 파일이 법적으로 권위 있는 문서입니다. PDF는 SAT가 규정한 시각적 표현(SAT 인증 포털로 연결되는 2D 바코드 포함 필수)이지만, 독립적인 법적 효력은 없습니다. PDF의 데이터가 해당 XML의 데이터와 다른 경우(공급업체 ERP 시스템이 필드를 자르거나 재구성하는 템플릿에서 PDF를 렌더링할 때 발생 가능), SAT는 XML을 올바른 것으로 간주합니다. XML을 확인하지 않고 PDF에서 데이터를 입력하는 AP팀은 규정 준수 측면에서 장식용 출력물을 처리하는 것입니다.

XML과 PDF에서 Excel로 CFDI 데이터를 추출하는 워크플로우에 대한 자세한 내용은 CFDI 추출 방법 가이드를 참조하세요. 대규모 CFDI 송장 처리(특히 Pago 보완서 간 UUID 교차 참조)에 대해서는 배치 CFDI 처리 가이드를 참조하세요.

레이어 3: 취소 함정 — 오류 수정에 72시간과 서명 두 개가 필요한 이유

대부분의 인보이스 처리 환경에서 오류를 수정하려면 공급업체가 크레딧 노트나 수정된 PDF를 보내고 구매자가 조정을 기록합니다. 그러나 CFDI 시스템에서는 발행되어 스탬프가 찍힌 인보이스를 편집할 수 없습니다. 취소만 가능하며, 취소 자체도 양 당사자, 정부 시스템, 그리고 시간 제한이 관여하는 규제된 프로세스입니다.

현행 규정에 따르면, CFDI를 취소하려면 발행자가 SAT 세금 사서함(Buzón Tributario)을 통해 취소 요청을 제출해야 하며, 네 가지 표준 사유 코드 중 하나를 지정해야 합니다: 01 — 관련 오류가 있는 증서(취소된 CFDI가 관련 문서로 대체됨을 의미); 02 — 관련 없는 오류가 있는 증서; 03 — 거래가 수행되지 않음; 04 — 글로벌 인보이스의 관련 명목 거래. 코드 01은 비즈니스 수정에 가장 일반적이며, 발행자는 취소된 CFDI를 대체하는 대체 CFDI의 UUID를 지정해야 합니다.

취소 요청이 제출되면 수신자는 72시간(영업일 기준 3일) 이내에 승인 또는 거부해야 합니다. 수신자가 아무 조치도 취하지 않으면 시간 초과로 자동 승인됩니다. 수신자가 거부하면 CFDI는 법적으로 유효한 상태로 유지되며, 발행자는 수신자와 재협상하거나 SAT의 분쟁 해결 채널을 통해 문제를 해결해야 합니다.

수신자 승인이 필요하지 않은 제한된 예외 사항이 있습니다: 급여 CFDI(Nómina), MXN 1,000 미만의 인보이스, 일반 대중과의 거래(일반 RFC XAXX010101000 사용), 그리고 최초 발행 후 72시간 이내에 수행된 취소입니다. 그 외의 모든 경우 — MXN 1,000 이상의 모든 상업용 Ingreso CFDI — 수신자의 72시간 승인 기간이 적용됩니다.

수신 측 AP 팀에게 이는 두 가지 운영상의 위험을 초래합니다. 첫 번째는 무효 문서 위험입니다: 3주 전에 처리하고 기록한 CFDI가 공급업체에 의해 취소되었을 수 있으며, 조직 내 누구도 SAT 세금 사서함에 로그인하여 요청을 승인 또는 거부하지 않았기 때문에 자동으로 승인되었습니다. 이제 장부에는 무효화된 세금 문서로 뒷받침되는 항목이 포함되어 있습니다 — 이는 SAT가 유효하지 않은 CFDI로 뒷받침되는 비용으로 간주하여 공제를 불허하고 잠재적으로 소급 세금과 벌금을 부과할 수 있는 상황입니다.

두 번째는 대체 추적 격차입니다: 공급업체가 사유 코드 01로 CFDI를 취소하면 새로운 UUID로 대체 CFDI를 발행합니다. AP 팀은 이제 원래 항목을 찾아 무효화하고 대체 항목을 다시 입력해야 하며, 새 UUID를 이전 UUID와 일치시켜야 합니다. 대체 CFDI가 다른 이메일 스레드, 약간 다른 제목 줄, 다른 팀원에 의해 처리되어 도착하면 원본과 대체본 간의 연결이 끊어지고 두 버전이 시스템에 동시에 존재할 수 있습니다.

레이어 4: 다중 RFC 및 국경 간 문제

위의 세 가지 레이어는 멕시코 CFDI 인보이스를 수취하는 모든 조직에 적용됩니다. 다국적 기업의 경우 RFC 시스템이 국경 간 운영과 상호작용하는 방식과 관련된 네 번째 복잡성이 있습니다.

멕시코에 여러 법인(제조 자회사, 유통 자회사, 서비스 법인)을 둔 회사는 각각 별도의 RFC를 보유합니다. 잘못된 RFC로 발송된 CFDI 인보이스는 법적으로 잘못된 납세자에게 발행된 것입니다. 공급업체가 제조 자회사의 RFC로 인보이스를 발행했지만, 상품이 유통 법인에 인도되어 소비된 경우, 제조 법인은 해당 거래가 자사의 세금 등록 하에 발생하지 않았으므로 비용을 법적으로 공제할 수 없으며, 유통 법인은 매출 원가를 뒷받침할 CFDI가 없습니다. 이를 해결하려면 위에서 설명한 72시간 수취인 수락 영향을 모두 포함한 취소 및 재발행 주기가 필요합니다.

멕시코 공급업체로부터 CFDI 인보이스를 수취하지만 자체 RFC가 없는 외국 기업의 경우, 일반 외국인 수취인 RFC인 XEXX010101000을 사용할 수 있습니다. 이 RFC에는 중요한 제한 사항이 있습니다. 수취인이 IVA(부가가치세) 공제를 청구하거나 멕시코 세금 목적으로 비용을 공제할 수 없습니다(멕시코 세금 신고 의무가 없는 외국 기업에게는 일반적으로 무관함). 운영상 더 중요한 점은 XEXX010101000이 수천 개의 무관한 법인이 사용하는 일반 식별자이므로 특정 법인으로의 추적성이 없다는 것입니다. 회사에 세 개의 지역 사무소가 있고 각각 다른 멕시코 공급업체로부터 CFDI 인보이스를 수취하며 모두 XEXX010101000을 사용하는 경우, 처리 중 인보이스를 올바른 법인으로 라우팅할 RFC 수준의 방법이 없습니다. 라우팅 로직은 공급업체 이름, 설명 필드 또는 이메일 수신자에 의존하여 AP 워크플로우에 구축되어야 하며, 이 중 어느 것도 세금 ID의 구조적 신뢰성을 갖추지 못합니다.

수취 측면에는 과세 체계 불일치 문제도 있습니다. 멕시코 공급업체가 CFDI를 발행할 때 수취인의 과세 체계 코드를 기록해야 합니다. 회사가 멕시코 법인에 대한 RFC를 취득한 경우, 해당 법인은 특정 체계(예: 601 - 법인 일반 체계)로 등록됩니다. 공급업체가 온보딩 중에 잘못된 코드를 제공받아 612(사업 활동을 하는 개인)를 실수로 입력하더라도 CFDI는 PAC 검증을 통과할 수 있지만(612는 유효한 체계 코드이므로), 향후 감사에서 SAT가 플래그를 지정할 수 있는 구조적 데이터 오류가 포함됩니다. CFDI는 유효하지만 올바르지 않습니다. 이는 문제가 되기 전에 발견하기 가장 어려운 유형의 오류입니다.

스페인어권 시장 전반의 문서 처리에 대한 광범위한 과제 분석은 스페인 시장 문서 추출 개요를 참조하십시오.

템플릿 기반 방식이 CFDI에서 실패하는 이유

송장 처리의 복잡성에 대한 일반적인 대응은 템플릿 기반 OCR입니다. 각 공급업체 레이아웃에 대한 템플릿을 정의하고, 필드를 위치에 매핑한 후 좌표로 데이터를 추출합니다. 이 접근 방식은 하나의 샘플로 학습된 템플릿이 이후 수백 개의 문서에서도 작동할 만큼 문서 형식이 일관적이라고 가정합니다. CFDI는 두 가지 측면에서 이 가정을 깨뜨립니다.

첫째, PDF 표현은 공급업체마다 다릅니다. 모든 CFDI가 Anexo 20에서 정의한 동일한 필수 필드를 포함하더라도, 각 공급업체의 ERP 또는 송장 시스템은 PDF를 다르게 렌더링합니다. 한 공급업체는 UUID를 오른쪽 상단에 36자 문자열로 배치합니다. 다른 공급업체는 하단의 QR 코드 바코드에만 UUID를 포함합니다. 세 번째 공급업체는 바닥글에 압축된 글꼴로 UUID를 인쇄합니다. 공급업체 A의 레이아웃용으로 구축된 템플릿은 공급업체 B의 송장에서 완전히 실패합니다.

둘째, PDF와 XML은 서로 다른 데이터를 전달할 수 있습니다. 공급업체의 ERP는 XML 필드의 하위 집합에서 PDF를 렌더링하여 라인 항목 합계는 표시하지만 IVA 세부 내역은 표시하지 않거나, 등록된 razón social 대신 공급업체의 상호를 표시할 수 있습니다. 추출 도구가 PDF를 읽으면 단순화된 인쇄 데이터를 캡처합니다. 규정 준수 의무에 XML의 전체 세금 세부 정보가 필요한 경우 PDF로는 충분하지 않습니다. PDF로 조정하는 AP 팀은 SAT가 공식 기록으로 간주하는 데이터보다 적은 데이터로 조정하는 것입니다.

이러한 구조적 가변성을 처리하는 접근 방식은 UUID, RFC, IVA 16%, Régimen Fiscal과 같은 필드의 의미론적 의미인 문서의 내용을 읽는 것입니다. 이러한 필드가 페이지의 어디에 나타나든, 출처가 PDF든 XML이든 관계없이 말입니다. 의미론적 추출은 RFC가 좌표(200, 450)에 있기 때문에 식별하는 것이 아니라, 주변 텍스트에서 "RFC"로 레이블이 지정된 12자 또는 13자 영숫자 식별자 패턴과 일치하기 때문에 식별합니다. 이것이 시각적 위치 매핑과 문서 내용 이해의 차이이며, CFDI 처리를 공급업체별 템플릿 유지 관리 부담이 아닌 확장 가능한 규모로 가능하게 만드는 차이입니다.

멕시코 AP 워크플로우에 미치는 영향

네 가지 계층을 종합하면, 이 모든 요소를 고려한 CFDI 처리 워크플로우는 대부분의 표준 AP 시스템(송장을 단일하고 독립적이며 상태 비저장 문서로 가정)이 기본적으로 제공하지 않는 기능을 필요로 합니다.

다중 형식 수집. 공급업체가 XML과 PDF를 모두 제공하고, 권위 있는 데이터는 XML에 있으므로 워크플로우는 두 형식을 모두 입력으로 받아들여야 합니다. XML에서만 추출하면 시각적 확인 단계(인쇄된 문서가 구조화된 데이터와 일치하는지)가 누락됩니다. PDF에서만 추출하면 법적 기록이 누락됩니다. 두 형식 모두 동일한 추출 파이프라인에 공급되어 CFDI당 통합 출력 행을 생성해야 합니다.

UUID 인식 조정. 모든 CFDI에 내장된 36자 식별자인 UUID는 Ingreso 송장을 Pago 보완 문서에 연결하고, 취소를 추적하며, 각 문서를 SAT의 검증 포털에 연결하는 영구 키입니다. 배치 간 UUID를 캡처, 저장 및 상호 참조하지 않는 CFDI 워크플로우는 수동 조회 없이 PPD 지불 조정을 수행할 수 없습니다. 배치 조정 워크플로우에 대한 자세한 내용은 CFDI 배치 처리 가이드를 참조하세요.

수령 시 규정 및 RFC 검증. CFDI가 회계 시스템에 입력되기 전에 수취인의 RFC와 규정 세금 코드를 회사 등록 데이터와 비교하여 검증해야 합니다. 수령 시 발견된 불일치는 연쇄 문제를 방지합니다. 즉, 비용이 잘못된 법인에 기록되고, 세무팀이 감사 준비 중에 오류를 발견하며, 수정에는 더 이상 응답하지 않을 수 있는 공급업체와의 취소-재발행 주기가 포함됩니다.

취소 상태 인식. 한 번 처리된 CFDI가 영구적으로 정산된 CFDI는 아닙니다. SAT 검증 포털에 대한 정기적인 UUID 상태 확인을 포함하거나 공급업체가 정의된 채널을 통해 취소 요청을 팀에 알리도록 요구하는 워크플로우는 무효화된 문서를 원장에 보관할 위험을 줄입니다.

이를 위해 엔터프라이즈 규모의 PAC 통합이나 전용 멕시코 세금 준수 플랫폼이 필요하지 않습니다. 필요한 것은 CFDI가 무엇인지(다중 문서, 상태 저장, 정부 검증 기록) 이해하고 그에 따라 데이터를 추출하는 처리 단계일 뿐이며, 긴 PDF에 추가 숫자가 있는 것으로 취급하지 않는 것입니다.

자주 묻는 질문

멕시코 공급업체가 일반 PDF 인보이스를 발행하지 못하는 이유는 무엇인가요?

멕시코 법률은 PDF를 유효한 세금 문서로 인정하지 않기 때문입니다. 2014년부터 멕시코의 모든 납세자(회사, 독립 전문가, 상업 활동에 종사하는 개인)는 PAC의 검증을 받고 SAT에 실시간 등록된 CFDI XML 인보이스를 발행해야 합니다. PDF만 발행하는 공급업체는 멕시코 세법상 법적으로 유효한 인보이스를 생성하는 것이 아니며, 해당 문서를 멕시코에서 세금 공제 증빙으로 사용할 수 없습니다.

실무에서 PUE와 PPD의 차이점은 무엇인가요?

PUE(단일 결제)는 인보이스 발행 시 전액이 결제됨을 의미하며, 하나의 CFDI가 전체 거래를 포괄합니다. PPD(연기/분할)는 인보이스가 의무를 기록하고, 각 후속 결제 시 원본을 참조하는 Complemento de Pago와 함께 고유 UUID를 가진 별도의 Pago 유형 CFDI가 생성됩니다. PPD는 거래당 최소 2개의 XML을 추적해야 하지만, PUE는 1개만 필요합니다. 결제 방법 코드(PUE 또는 PPD)는 Ingreso CFDI의 Método de Pago 필드에 표시됩니다.

기록 보관을 위해 XML을 보관해야 하나요, 아니면 PDF만으로 충분한가요?

XML이 필요합니다. CFF 제30조에 따라 발행자와 수취인 모두 CFDI XML 파일을 최소 5년간 보관해야 합니다. PDF는 규제된 시각적 표현으로, SAT의 검증 포털로 연결되는 QR 코드를 포함해야 하지만 독립적인 법적 효력은 없습니다. 감사 시 SAT는 PDF가 아닌 XML을 요구합니다.

공급업체의 취소 요청을 무시하면 어떻게 되나요?

72시간(영업일 기준 3일) 이내에 응답하지 않으면 시간 초과로 취소가 자동 승인됩니다. 해당 CFDI는 무효가 되며, 해당 CFDI에 기반한 모든 세금 공제 또는 시스템 내 비용 항목은 더 이상 유효한 세금 문서로 뒷받침되지 않습니다. 회사가 멕시코에서 세금을 신고하는 경우 규정 준수 위험이 발생합니다. 멕시코에서 신고하지 않는 경우, 무효화된 인보이스에 대해 대금을 지불하고도 이를 인지하지 못하는 운영상의 위험이 있습니다.

멕시코 공급업체 인보이스에 일반 RFC XEXX010101000을 사용할 수 있나요?

네, 회사에 멕시코 세금 등록 및 자체 멕시코 RFC가 없는 경우 가능합니다. 단, XEXX010101000은 모든 외국 수취인이 공유하는 일반 식별자로, 개별 법인 수준의 추적성을 제공하지 않습니다. 회사에 CFDI 인보이스를 수취하는 여러 지사, 부서 또는 법인이 있는 경우, 공급업체명, 설명 또는 이메일을 기반으로 각 인보이스를 올바른 처리 대기열로 안내하는 내부 라우팅 메커니즘이 필요합니다.

CFDI의 복잡성이 다른 국가의 전자 인보이스 시스템보다 더 심각한가요?

멕시코의 시스템은 브라질의 NF-e와 함께 세계에서 가장 엄격하게 통제되는 시스템 중 하나입니다. 둘 다 실시간 정부 승인, 구조화된 XML과 디지털 서명을 요구하며, 원본 인보이스와 이후 지불 또는 운송 문서 간의 조정 의무를 생성합니다. 멕시코 시스템의 특별한 복잡성은 이중 문서 PPD/Pago 구조와 수취인 동의를 통한 취소 메커니즘에 있습니다. 이러한 기능은 대부분의 유럽 전자 인보이스 규정에 직접적인 대응물이 없습니다.