VERI*FACTU와 자체 개발 인보이스 소프트웨어: 2027년 1월 1일까지 스페인이 요구하는 것

세로 데 산 이시드로에서 바라본 마드리드의 지붕과 성당 돔

2027년 1월 1일 전까지, 스페인에서 법인세(Impuesto sobre Sociedades)를 신고하고 소프트웨어로 인보이스를 발행하는 모든 회사는 Real Decreto 1007/2023에 맞게 조정된 소프트웨어를 사용해야 합니다. 모든 인보이스에는 직전 레코드와 사슬로 연결된 해시 레코드와, 고객이 세무 당국에 대조해 볼 수 있는 QR 코드가 붙습니다. 적용 대상인 나머지, 주로 자영업자는 2027년 7월 1일까지 시간이 있습니다.

인보이스가 상용 패키지에서 나온다면 이 일은 대부분 벤더의 몫입니다. 누군가 귀사를 위해 만들어 준 소프트웨어나 귀사 팀이 직접 만든 소프트웨어에서 나온다면 귀사의 몫입니다. 코드를 고치는 것도, 규정을 준수한다는 선언서에 서명하는 것도 귀사입니다.

일정과 두 번의 연기

이번이 세 번째로 정해진 일정이니 어느 정도 의심하는 것도 당연합니다.

Real Decreto 1007/2023 제정 당시에는 사업자에게 2025년 7월 1일까지 기한이 주어졌습니다.
2025년 4월 1일 자 Real Decreto 254/2025는 이를 법인세 신고자는 2026년 1월 1일, 나머지는 2026년 7월 1일로 미뤘습니다. 이유는 구체적이었습니다. 기술 고시인 Orden HAC/1177/2024가 2024년 10월 28일에야 공포되었기 때문입니다.
2025년 12월 2일 자 Real Decreto-ley 15/2025는 두 날짜를 모두 1년씩 미뤘습니다. 본문은 BOE에 있으며, 하원은 같은 달에 이를 승인했습니다.

2026년 3월 26일에 갱신된 AEAT의 기한 연장 안내는 모호한 데가 없습니다. "las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027." 법인세 신고 법인은 2027년 1월 1일 전에, 나머지 납세의무자는 2027년 7월 1일 전에 인보이스 발행 시스템(SIF)을 조정해야 한다는 내용입니다.

또 미뤄질 수 있을까요? 2026년 10월 현재 그렇다고 말하는 공식 발표는 없습니다. 첫 번째 연기에는 기술적 원인이 있었지만 그 원인은 이제 사라졌습니다. AEAT의 제출 서비스는 2025년 4월 23일부터 운영 중이고, 2025년 7월 29일부터 소프트웨어 벤더는 조정된 시스템만 판매할 수 있습니다. 세 번째 연기를 전제로 계획하는 것은 계획이 아니라 도박입니다.

어느 날짜가 귀사에 해당할까요? SL이나 SA는 Impuesto sobre Sociedades를 신고하므로, 자체 ERP를 운영하는 회사라면 거의 확실히 2027년 1월 1일이 기한입니다. 3개월도 남지 않았습니다. 7월 날짜는 자영업자와 그 밖의 적용 대상 납세자를 위한 것입니다.

적용 대상과 제외 대상

AEAT의 적용 범위 FAQ는 이를 네 가지 부정 조건으로 정리합니다. 인보이스를 전적으로 수기로만 발행하지 않고, SII 대상이 아니며(의무든 선택이든), 세무상 주소지가 바스크 지방이나 나바라가 아니고, 면제 결정을 받지 않았다면 적용 대상입니다.

실무에서 제외되는 경우는 다음과 같습니다.

SII 신고자. Suministro Inmediato de Información은 매출 600만 유로 초과 기업, VAT 그룹, 월별 VAT 환급 등록부(REDEME)에 올라 있는 사업자에게 의무이며, 그 밖의 사업자도 선택해 가입할 수 있습니다. AEAT는 이렇게 분명히 말합니다. "El ámbito subjetivo de ambos proyectos es excluyente." 두 제도의 적용 대상은 서로 배타적이라는 뜻입니다. SII로 옮기면 VERI*FACTU 레코드 전송도, QR 코드 인쇄도 멈춥니다.
바스크 지방과 나바라. 세무상 주소지가 이곳인 사업자는 RD 1007/2023이 아니라 지방(foral) 세무 당국과 그 자체 규정을 따릅니다.
순수 수기 발행. 종이 인보이스 장부는 적용 범위 밖입니다. 인보이스를 입력하고 인쇄하고 보관하는 데만 쓰는 스프레드시트도 그렇습니다. 다만 VAT 장부까지 만들어 내는 스프레드시트는 해당하지 않습니다.

외국 회사는 스페인에 고정사업장이 있으면 적용 대상입니다.

상용 패키지(A3, Sage, Holded 등)로 인보이스를 발행한다면 벤더가 제작자이며, 조정된 버전을 자체 선언서와 함께 제공해야 합니다. 업데이트하고, 선언서가 있는지 확인하면 이 글은 여기까지 읽으셔도 됩니다.

이 글은 나머지 경우를 위한 것입니다. 자체 ERP, 15년 전에 만든 Access, Delphi, FileMaker 프로그램, 또는 자사 웹 플랫폼 안의 과금 모듈 같은 경우입니다.

제작자는 귀사입니다

규정 제13조 제1항은 시스템을 제작한 자에게 declaración responsable(책임 선언서)을 통한 인증 의무를 지웁니다. AEAT의 인증 FAQ는 사내 개발의 경우를 직접 다룹니다. "Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo." 운영 중인 모든 시스템은 제작자의 책임 선언서로 발행된 인증을 갖춰야 하며, 회사가 직접 개발한 소프트웨어라면 회사가 인증해야 한다는 내용입니다.

실무적으로는 다음을 뜻합니다.

외부 감사는 없습니다. AEAT는 이를 제작자의 "auto-certificación", 즉 자기 인증이라고 부릅니다. 아무도 귀사의 시스템을 사전에 승인하지 않습니다. 귀사가 서명하고, 귀사가 책임을 집니다.
외주 업체가 확장 기능을 제품으로 만들어 주었다면 그 확장 기능은 외주 업체가 인증합니다. 직접 만들었다면 귀사가 인증합니다.
선언서는 모든 버전에서 시스템 안에 보여야 하며, 제품과 별개로 시스템 밖에서도 열람할 수 있어야 합니다.
내용은 정해져 있습니다. Orden HAC/1177/2024 제15조에 따라 시스템의 이름, 식별자, 버전, 구성 요소, VERI*FACTU 모드로만 작동하는지 여부, 제작자의 이름, NIF, 주소, 서명 일자와 장소 등이 들어갑니다.

곤란한 것은 작성자가 몇 년 전에 퇴사한 프로그램입니다. 그래도 누군가는 조정된 버전을 만들고 서명해야 합니다. 작업을 시작하기 전에 그 사람이 누구인지 문서로 정해 두십시오.

인증된 상용 제품을 커스터마이징하는 경우, 그 변경이 규정 요건의 구현 방식을 건드릴 때에만 별도의 선언서가 필요합니다. 제작자의 통제 밖에서 이루어진 수정이 요건을 바꿀 수 있다면 그 시스템은 규정에 맞지 않습니다.

걸려 있는 금액은 일반조세법 제201조의2가 정합니다. 요건을 충족하지 못하는 시스템을 제작하면 회계연도별, 시스템 유형별로 15만 유로의 정액 벌금이 부과되고, 인증되어야 하는데 인증되지 않았거나 변조된 시스템을 보유하면 회계연도별로 5만 유로가 부과됩니다. 자체 개발 시스템이 이 중 어느 쪽에 해당할지는 세무 자문가에게 물을 질문입니다. 어느 쪽이든 작은 금액이 아닙니다.

소프트웨어가 해야 할 일

발행 시점에 모든 인보이스의 레코드 생성

제9조 제1항은 시스템이 registro de facturación de alta(발행 레코드)를 "de forma simultánea o inmediatamente anterior a la expedición de cada factura", 즉 각 인보이스 발행과 동시에 또는 그 직전에 생성하도록 요구합니다. 무효가 된 인보이스에는 취소 레코드(registro de anulación)가 생성됩니다.

제10조는 레코드에 담을 내용을 열거합니다. 발행자의 NIF와 이름, 필요한 경우 수신자, 시리즈와 번호, 발행일과 거래일, 인보이스 유형, 정정 대상 인보이스가 있으면 그 정보, 설명, 총액, VAT 제도, 과세표준, 세율과 세액, 면세 또는 과세 대상 외 사유, 시스템과 제작자의 식별 정보, 초 단위 타임스탬프입니다.

오래된 시스템에서는 바로 여기에 작업이 숨어 있습니다.

VAT 내역은 인쇄 시점에 계산되고 저장되지 않는 경우가 많습니다. 발행 시점에 데이터로 존재해야 합니다.
"발행"이 보고서 인쇄에 불과한 경우가 많습니다. 초안이 인보이스가 되는 명시적인 시점이 있어야 하고, 레코드는 그때 생성됩니다.
번호 재사용은 끝났습니다. 인보이스를 삭제하고 번호를 다시 쓰는 것은 작은 시스템에서 흔한 습관이지만 이제는 통하지 않습니다. AEAT는 두 번째 레코드를 "Registro de facturación duplicado"(중복된 발행 레코드)로 거부합니다. 운영 환경에서 발행한 테스트 인보이스는 실제 인보이스이므로 취소해야 합니다.
누구도 레코드를 수정하지 않습니다. AEAT FAQ는 발행된 레코드의 데이터베이스를 직접 변경하는 것이 허용된 작업이어서는 안 된다고 말합니다. 지금 직원들이 SQL로 인보이스를 고치고 있다면 그 관행은 멈춰야 합니다. 정정은 정정 인보이스로 합니다.

해시 체인

각 레코드는 직전 레코드의 시리즈, 번호, 일자와 그 해시(huella)의 일부를 담습니다. 알고리즘은 SHA-256이며, 정확한 필드와 연결 방식은 레코드 설계, XSD 스키마, WSDL, 검증 및 오류 목록과 함께 AEAT의 기술 문서에 있습니다.

새 레코드를 생성하기 전에 시스템은 마지막 레코드가 올바르게 연결되어 있는지, 그 타임스탬프가 현재 시각보다 1분 넘게 늦지 않은지 확인해야 합니다. 레코드는 인보이스가 발행된 순서대로 생성됩니다.

여기에는 아키텍처상의 결과가 따릅니다. 설치본마다 레코드를 생성하는 단일하고 직렬화된 지점이 하나 필요합니다. 웹 서버 두 대가 조율 없이 같은 체인에 레코드를 덧붙이면 체인이 깨집니다. AEAT는 중앙 백오피스에서 레코드를 받는 POS 단말처럼 혼합된 구성도 인정하지만, 체인 자체는 한곳에 있어야 합니다.

각 시스템은 납세자의 NIF, 두 글자로 된 시스템 ID, 그리고 같은 소프트웨어를 같은 기기에 다시 설치하더라도 절대 반복되어서는 안 되는 설치 번호로 식별됩니다.

인보이스의 QR 코드

모든 인보이스에는 ISO/IEC 18004를 따르는 QR 코드가 30×30mm에서 40×40mm 사이 크기로, 오류 정정 수준 M으로 들어갑니다. QR 코드에는 발행자의 NIF, 시리즈와 번호, 발행일, 총액이 담긴 URL이 인코딩되며, 고객은 이를 AEAT에 대조해 확인할 수 있습니다. VERI*FACTU 모드에서는 인보이스에 "VERI*FACTU" 또는 "Factura verificable en la sede electrónica de la AEAT"(AEAT 전자 사무소에서 검증 가능한 인보이스)라는 문구도 들어갑니다.

레거시 소프트웨어에서는 인보이스 템플릿(Access 보고서, FileMaker 레이아웃, PDF 생성기)을 다시 손보고, 한 번도 QR 라이브러리를 써 본 적 없는 기술 스택에 그것을 추가해야 한다는 뜻입니다.

두 가지 모드: VERIFACTU와 비 VERIFACTU

VERI*FACTU 모드. 시스템이 레코드를 생성하는 즉시 자동으로 AEAT에 보냅니다. 그 대신 레코드에는 해시만 있으면 되고 전자 서명은 필요 없으며, 레코드는 AEAT가 보관하고, 이 모드로만 작동하는 시스템에는 이벤트 로그가 필요 없습니다. 필요한 것은 AEAT가 공개한 서비스에 연결하는 SOAP 클라이언트, 적격 전자 인증서, 연결이 끊겼을 때를 위한 대기열입니다. AEAT의 개발자 FAQ는 장애를 사고로 취급합니다. 레코드는 대기열에서 기다렸다가 재시도되고, 인보이스 발행은 계속됩니다.

비 VERI*FACTU 모드. 레코드는 귀사가 보관하며, 각 레코드에 적격 인증서로 서명(XAdES Enveloped, ETSI EN 319 132)해야 합니다. 시스템은 이 모드에서의 시작과 정지, 이상 점검과 그 결과, 백업 복원과 내보내기를 기록하는 서명된 이벤트 로그도 유지해야 하며, 운영 시간 6시간마다 최소 한 번 요약 이벤트를 남기고, AEAT가 요청하면 레코드를 제출해야 합니다.

맞춤형 시스템이라면 대개 VERI*FACTU 전용으로 만드는 편이 작업량이 적습니다. 서명 인프라도, 이벤트 로그도, 이상 탐지 도구도 필요 없습니다. 두 모드를 모두 제공하는 시스템은 이 전부를 구현해야 합니다.

2027년 1월 1일 전에 끝낼 수 있는 계획

10월 초부터 계산하면 법인세 신고자에게는 13주 정도가 있습니다. 다음 순서가 효과적입니다.

1주차: 현황 파악. ERP, 웹 쇼핑몰의 과금 모듈, 구독 스크립트, 매장 단말 등 인보이스를 발행하는 모든 시스템을 나열합니다. SII 대상이 아니고 지방(foral) 규정을 따르지 않는다는 것을 확인합니다.
1주차부터 2주차까지: 서명자와 모드 결정. 시스템별로 제작자를 지정합니다. 그러지 않을 이유가 없다면 VERI*FACTU 전용을 선택합니다. 회사의 적격 인증서가 있고 그 관리자가 정해져 있는지 확인하십시오. AEAT의 개발자 FAQ에 따르면 인증서 없이는 시스템이 작동할 수 없습니다.
2주차부터 4주차까지: 데이터 격차 분석. 시스템이 저장하는 데이터를 제10조와 AEAT의 레코드 설계에 대조합니다. 누락된 VAT 내역, 인보이스 유형 코드, 정정 참조가 여기서 드러납니다.
3주차부터 8주차까지: 구축. 발행 시점의 레코드 생성, 체인과 그 점검, 변경 불가능한 저장소, 취소, 모든 템플릿의 QR, 재시도 대기열을 갖춘 제출 클라이언트를 만듭니다. 발행된 레코드를 직접 수정하는 경로는 없앱니다.
6주차부터 10주차까지: 테스트. AEAT의 테스트 환경에서 시작한 뒤 실제 레코드를 보냅니다. AEAT는 기한 전까지의 기간을 테스트 기간으로 보며, 이 기간에는 전송을 멈추고 다른 시스템으로 되돌아가도 됩니다. 취소와 정정 흐름을 작성하기 전에 개발자 FAQ를 읽으십시오. 예외 상황 대부분이 거기 다뤄져 있습니다.
9주차부터 12주차까지: 선언과 교육. declaración responsable을 작성해 애플리케이션 안과 밖에 게시하고 버전을 기록합니다. 재무팀에는 번호를 절대 재사용하지 않으며 오류는 정정 인보이스로 바로잡는다고 알립니다.
12월 중순: 시행. "antes del 1 de enero"(1월 1일 전)라는 기한은 시행일이 아닙니다. 2주 일찍 시행해야 첫 문제가 드러났을 때 아직 시간이 남아 있습니다.

2027년 7월 1일이 기한이라면 같은 계획을 더 여유 있게 적용하면 됩니다. 5월이 아니라 1월에 시작하십시오.

다시 만드는 것 말고도 솔직하게 따져 볼 만한 대안이 두 가지 있습니다. AEAT는 혼합 아키텍처를 인정하므로, ERP는 계속 인보이스 데이터를 준비하고 구매하거나 만든 별도 구성 요소가 레코드, QR, 제출을 맡는 방식도 가능합니다. 단, 선언서가 각 부분이 어떻게 맞물리는지까지 다뤄야 합니다. 그리고 오래된 프로그램이 한 달에 인보이스를 몇 건밖에 발행하지 않는다면, AEAT가 소규모 사업자에게 무료로 제공하는 인보이스 애플리케이션이나 표준 패키지가 조정 작업보다 저렴할 수 있습니다.

도움이 필요하시면

저희는 오래된 기술 스택을 포함해 회사가 이미 운영 중인 인보이스 코드를 수정합니다. 레코드 생성, 해시 체인, 템플릿의 QR, AEAT 제출 클라이언트를 만들고 테스트까지 남겨 둡니다. 구축은 전자 인보이스 연동 서비스에서 다루며, 오래된 프로그램의 작동 방식을 아는 사람이 아무도 남아 있지 않다면 레거시 시스템 유지보수가 출발점입니다.

기한이 2027년 1월 1일이고 자체 시스템을 쓰고 있다면 office@c9group.dev로 연락 주십시오. 저희는 세무 자문가가 아니라 엔지니어입니다. 적용 범위와 책임에 관한 질문은 귀사의 자문가 몫이고, 저희는 그분들이 내린 답에 맞춰 만듭니다.