독일 E-Rechnung 의무화: 2027년 1월 1일까지 자체 시스템에서 구조화 인보이스 발행하기

해 질 녘 마인강에 비친 프랑크푸르트 스카이라인

2027년 1월 1일부터 2026년 매출이 80만 유로를 넘은 독일 사업자는 다른 독일 사업자에게 종이나 PDF 인보이스를 보낼 수 없습니다. 인보이스는 구조화된 전자 인보이스, 즉 유럽 표준 EN 16931에 맞춰 만든 데이터 파일이어야 합니다. 2028년 1월 1일부터는 매출 기준이 사라져, 몇 가지 좁은 예외를 빼면 모든 사업자에게 이 규칙이 적용됩니다.

소규모 회사에게 이 변화는 소프트웨어 업데이트로 찾아옵니다. 자체 과금 시스템, 업종 전용 패키지, 15년 동안 커스터마이징한 ERP에서 인보이스가 나오는 회사에게는 소프트웨어 프로젝트이고, 남은 시간은 13주 정도입니다. 이 글은 두 번째 부류를 위한 것입니다.

법이 정한 내용

정의는 § 14 UStG에 있습니다. 인보이스란 "die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht", 즉 구조화된 전자 형식으로 발행·전송·수신되어 전자적 처리가 가능한 인보이스입니다. 형식은 지침 2014/55/EU에 따른 유럽 표준(실무에서는 EN 16931)을 따르거나, 필요한 데이터를 그 표준과 호환되는 형태로 정확하고 완전하게 추출할 수 있다는 조건 아래 당사자 간에 합의한 것이어야 합니다. PDF는 아무리 깔끔해 보여도 해당하지 않습니다.

의무는 양 당사자가 모두 독일에 설립된 사업자 간 공급에 적용됩니다. 경과 규정은 § 27 Abs. 38 UStG에 있습니다.

2025년과 2026년에 이루어진 공급은 인보이스를 2026년 12월 31일까지 보내기만 하면 여전히 종이로, 또는 고객이 동의하면 다른 전자 형식으로 청구할 수 있습니다.
2027년에 이루어진 공급도 2027년 12월 31일까지 같은 유예를 받지만, 발행자의 직전 역년 총매출이 80만 유로 이하인 경우에 한합니다.
표준을 충족하지 않는 EDI는 회사 규모와 관계없이 고객이 동의하면 2027년에 이루어진 공급까지 계속 쓸 수 있습니다.

세 가지 세부 사항이 보기보다 중요합니다.

매출 기준은 전년도 매출로 판단합니다. 2027년의 의무 여부는 2026년 수치에 달려 있고, 이 수치는 결산이 끝나기 전에는 아무도 정확히 모릅니다. 80만 유로 근처라면 기준을 넘는다고 보고 준비하십시오.

유예는 발송일 기준으로 끝납니다. 문언대로 읽으면 첫 번째 경과 규정은 2026년에 수행한 작업이라도 2026년 12월 31일이 지나면 종이와 PDF를 더 이상 허용하지 않습니다. 기준을 넘는 회사가 후불로 청구한다면, 1월 첫 주에 보내는 12월분 인보이스부터 이미 구조화 인보이스여야 합니다. 세무사와 확인하시되, 시행 시점을 1월 중순으로 잡지는 마십시오.

일부 인보이스는 적용 범위 밖에 있습니다. 소비자 대상 인보이스, 국경 간 인보이스, 총액 250유로 이하의 소액 인보이스, 인보이스로 간주되는 승차권, Kleinunternehmer(소규모 사업자)의 인보이스, UStG § 4 Nr. 8부터 Nr. 29까지에 따라 면세되는 공급입니다.

저희가 아는 한 이 날짜들을 미루려는 법안은 없습니다. 날짜가 그대로 유지된다고 보고 계획하십시오.

수신은 2025년부터 적용 중이고, 새로운 것은 발행입니다

2025년 1월 1일부터 모든 독일 사업자는 전자 인보이스를 수신할 수 있어야 했습니다. 연방재무부의 전자 인보이스 FAQ는 그 요건을 아주 짧게 말합니다. "Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach." 이메일 수신함 하나면 충분하다는 뜻입니다.

§ 14 자체에 있는 한 줄도 눈여겨보십시오. 전자 인보이스 의무가 적용되는 경우 수신자의 동의는 필요하지 않습니다. 독일 사업자 고객은 귀사의 구조화 인보이스를 거부할 수 없습니다.

발행은 전혀 다른 문제입니다. 수신할 때는 도구가 다른 사람의 파일을 읽습니다. 발행할 때는 귀사의 시스템이 작성자입니다. 원천 데이터가 틀렸다면 그 뒤의 누구도 고칠 수 없고, 고객 측 검증에 실패한 인보이스는 대금을 받지 못한 채 머물러 있습니다.

업데이트로 해결되는 회사

솔직히 말씀드리겠습니다. DATEV, lexoffice, sevDesk 같은 패키지로 인보이스를 발행하는 소규모 회사라면 형식은 벤더가 제공합니다. 마스터 데이터(VAT ID, 고객 주소, 은행 정보)를 점검하고, 기능을 켜고, 테스트 인보이스를 보내 보십시오. 프로젝트도, 소프트웨어 회사도 필요하지 않습니다.

표준에 가깝게 유지된 주류 ERP도 사정은 비슷합니다. 벤더나 파트너가 출력 기능을 제공하고, 할 일은 설정과 테스트입니다.

이 글의 나머지는 직접 소유한 코드, 또는 더 이상 아무도 유지보수하지 않는 코드에서 인보이스가 나오는 회사를 위한 것입니다.

구독 플랫폼, 마켓플레이스, 유틸리티의 과금 엔진처럼 프로그램으로 대량의 인보이스를 발행하는 시스템
도매, 건설, 물류, 현장 서비스용 업종 소프트웨어 가운데 벤더가 작거나, 느리거나, 이미 사라진 경우
인보이스 출력이 오래전에 커스텀 인쇄 프로그램, 보고서 템플릿, 월말 메일 머지로 다시 작성된 ERP

형식: EN 16931, XRechnung, ZUGFeRD

EN 16931은 유럽 표준입니다. 인보이스의 의미 모델(필드, 그 의미, 필수 여부, 필드 사이의 비즈니스 규칙)을 정의하고, 이를 UBL 2.1과 UN/CEFACT CII라는 두 가지 XML 구문에 연결합니다.

XRechnung은 KoSIT가 관리하는 EN 16931 위의 독일 사양입니다. 두 구문 중 하나로 쓰는 순수 XML이며, 공공기관에는 필수이고 사업자 간에도 똑같이 유효합니다. KoSIT의 XRechnung 페이지에 따르면 버전 3.0은 2024년 2월 1일부터 시행 중이며 최소한 2027년 7월 31일까지 유효합니다. 4.0의 예비 버전은 2026년 9월에 공개되었고, 최종 버전은 2027년 봄으로 예상됩니다. 처음에는 3.0으로 시행하고 첫해 안에 업그레이드하게 됩니다.

ZUGFeRD는 하이브리드 형식으로, CII XML이 내장된 PDF/A-3 파일입니다. 사람은 PDF를 읽고 기계는 XML을 읽습니다. 프랑스에서는 같은 형식을 Factur-X라고 부르며 둘은 기술적으로 동일합니다. FeRD는 2026년 8월 4일에 버전 2.5.2를 공개했습니다. ZUGFeRD에는 프로필(MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED)이 있고, 연방재무부 FAQ는 버전 2.0.1 이상의 ZUGFeRD를 "mit Ausnahme der Profile MINIMUM und BASIC-WL", 즉 MINIMUM과 BASIC-WL 프로필을 제외하고 인정합니다.

하이브리드 인보이스에서 효력을 갖는 것은 XML입니다. FAQ는 구조화된 부분을 "führender Teil", 즉 주도적인 부분이라고 부릅니다. PDF와 XML이 서로 다르면 틀린 쪽은 PDF입니다.

독일의 B2B 발행자 대부분에게 합리적인 기본값은 EN 16931 프로필의 ZUGFeRD입니다. 아직 인보이스를 눈으로 읽는 고객도 그대로 일할 수 있기 때문입니다. 여기에 공공기관과 요청하는 고객을 위한 XRechnung을 더합니다. 두 형식 모두 두 개의 코드 경로가 아니라 하나의 내부 인보이스 객체에서 나와야 합니다.

시스템에서 바뀌어야 할 것

인보이스는 레이아웃이 아니라 데이터가 됩니다

오래된 시스템 상당수는 인쇄 시점에 인보이스를 만듭니다. 텍스트를 템플릿에 이어 붙이고, 합계는 보고서 안에서 계산하고, VAT 문구는 하드코딩된 문단입니다. 이 가운데 어느 것도 EN 16931을 통과하지 못합니다. 모든 필드를 담은 인보이스 객체를 저장하고, XML과 PDF를 모두 그 객체에서 렌더링해야 합니다.

대개 빠져 있거나 잘못된 필드는 다음과 같습니다.

당사자 정보. ISO 국가 코드를 포함한 구조화된 주소와 VAT ID 또는 세금 번호입니다. 자유 텍스트 주소 블록은 나눠야 합니다.
공급일 또는 서비스 기간. 머리글 속 문장이 아니라 데이터로 보관합니다.
단위. 모든 수량에 UN/ECE 권고 20의 코드가 필요합니다(개는 H87, 킬로그램은 KGM, 일은 DAY). "Stk."나 "pauschal" 같은 표기는 매핑해야 합니다.
VAT. 모든 라인에 VAT 범주와 세율이 붙습니다. 인보이스에는 범주와 세율의 조합마다 VAT 내역이 하나씩 들어가고, 합계는 소수점 둘째 자리까지 정확히 맞아야 합니다. 라인별로 VAT를 반올림하는 시스템은 여기서 실패합니다.
면세와 역과세(reverse charge) 문구. PDF 하단의 문장은 VAT 범주 코드와 면세 사유로 바뀝니다.
지급. 지급 수단, IBAN, 조건을 구조화된 형태로 넣습니다.
참조 번호. 고객의 매입채무 담당자가 대사하는 주문 번호나 구매자 참조 번호입니다. 한 번도 저장한 적이 없다면 지금부터 수집하십시오.

텍스트만 있는 라인("합의한 대로 납품" 같은 문구)은 흔한 걸림돌입니다. 구조화 인보이스에서 라인은 청구 대상 라인이므로, 그런 텍스트는 비고에 들어가야 합니다.

정정, 크레딧 노트, 역발행

FAQ는 명확합니다. 전자 인보이스 의무가 적용되는 경우 정정 인보이스도 정정용 인보이스 유형을 사용한 전자 인보이스여야 합니다. EN 16931에서 정정 인보이스는 원래 인보이스를 번호와 발행일로 참조하므로, 시스템은 그 연결을 데이터로 유지해야 합니다.

용어에 주의하십시오. 독일 VAT법에서 "Gutschrift"는 사전 합의에 따라 고객이 발행하는 역발행 인보이스입니다(§ 14 Abs. 2 UStG). 영어권에서 크레딧 노트라고 부르는 것(가격 인하나 취소)은 정정입니다. 많은 시스템이 두 가지에 같은 문서 유형을 씁니다. 매핑하기 전에 둘을 분리하고, 공급업체에 대해 역발행을 한다면 그 문서는 귀사 시스템이 발행하는 인보이스로 다루십시오.

최종 인보이스는 구조화된 부분이 첨부 파일을 참조한다면 이전의 부분 지급 내역을 첨부 파일에 나열할 수 있습니다. FAQ는 이 방식이 2027년 이후에도 유지된다고 확인합니다.

내보내기 전 검증

KoSIT는 XML을 스키마와 Schematron 규칙에 대조하는 오픈소스 검증기를 공개하고 있으며, XRechnung용 공개 설정도 제공합니다. 명령줄, HTTP 데몬, 라이브러리 중 어느 방식으로도 실행할 수 있습니다. 이 검증기를 발송 경로에 넣으십시오. 모든 인보이스는 나가기 전에 검증되고, 실패하면 어떤 필드가 어떤 규칙을 어겼는지와 함께 담당자가 정해진 대기열로 들어가야 합니다.

ZUGFeRD는 내장된 XML을 해당 프로필의 규칙으로 검증하고, PDF/A-3 컨테이너는 따로 점검하며, PDF에 표시된 합계가 XML과 같은지 확인합니다.

전송

FAQ에 따르면 법은 "sieht keinen bestimmten Weg vor", 즉 특정 전송 경로를 정하지 않습니다. 파일을 첨부한 이메일도 괜찮습니다. API, 다운로드 포털, 그룹 내부의 공유 저장소, 그리고 연방재무부가 직접 든 예인 USB 메모리도 됩니다. 독일 국내 B2B에 Peppol은 필수가 아닙니다.

엔지니어링 작업은 고객별로 발생합니다. 인보이스 수신 주소, 선호하는 형식, 무엇을 어디로 보냈는지의 기록이 필요합니다. 발송에 실패해 재시도할 때는 같은 문서를 같은 인보이스 번호로 보냅니다. 하나의 공급에 번호가 두 개면 소프트웨어 문제가 아니라 세무 문제입니다.

보관

최소한 구조화된 부분은 "unversehrt in seiner ursprünglichen Form", 즉 원래 형태 그대로 손상 없이 보관해야 하며, § 14b UStG는 보관 기간을 발행 연도 말부터 8년으로 정합니다. 보낸 바이트를 그대로, 해시와 함께 저장하십시오. 나중에 데이터베이스에서 인보이스를 다시 생성하겠다는 계획은 세우지 마십시오. 그때가 되면 데이터도 코드도 이미 바뀌어 있습니다. 수신한 전자 인보이스도 마찬가지입니다.

2026년 10월부터 12월까지의 계획

원천 데이터가 웬만한 상태라면 13주는 집중적으로 구축하기에 충분한 시간입니다. 과금 시스템을 교체하기에는 부족합니다.

1주차와 2주차: 현황 파악과 결정. 인보이스가 만들어지는 모든 곳을 나열합니다. 수작업 크레딧 노트, 프로젝트 최종 인보이스, 대형 고객 한 곳을 위한 스프레드시트까지 포함합니다. 2026년 매출을 기준과 비교합니다. 기본 형식을 고르고, 생성기를 직접 만들지 아니면 인보이스 데이터를 전자 인보이스 서비스 제공자의 API로 보낼지 결정합니다.

2주차부터 4주차까지: 데이터 격차 분석. 실제 인보이스 3개월 치를 필드 단위로 EN 16931에 매핑합니다. 빠진 것, 코드로 바꿔야 할 것, 계산 방식이 다른 것을 표시합니다. 프로젝트의 실제 규모는 여기서 드러납니다.

4주차부터 9주차까지: 구축. 인보이스 객체, 매핑, XML과 PDF/A-3 렌더링, 발송 경로의 검증기, 실패 대기열, 보관소를 만듭니다. 동시에 누군가는 마스터 데이터를 정리하고 고객에게서 인보이스 수신 주소를 수집합니다.

9주차부터 11주차까지: 재실행과 파일럿. 지난 3개월의 인보이스를 새 생성기로 다시 돌리고 전부 검증합니다. 그다음 협조적인 고객 몇 곳과 파일럿을 하면서 그쪽 시스템이 파일을 읽는지 물어봅니다.

11주차부터 13주차까지: 동결과 운영 매뉴얼. 12월에는 변경을 동결합니다. 실패 대기열의 담당자, 정정 인보이스 발행 방법, 고객이 인보이스를 거부했을 때의 처리를 문서로 남깁니다. 12월 작업분에 대한 1월 인보이스는 이미 적용 대상입니다.

2027년 1월. 시행하고, 첫 월말과 첫 VAT 신고가 끝날 때까지 대기열을 매일 지켜봅니다.

2027년 내내. 3.0의 효력이 끝나기 전에 XRechnung 4.0 업그레이드를 계획하고, 기준 미만인 그룹 계열사는 2028년 1월 1일 전에 전환합니다.

늦게 시작했다면 줄일 것은 자동화이지 출력물의 적법성이 아닙니다. 물량이 많은 인보이스 유형부터 자동화하고, 드문 문서는 몇 주 동안 전자 인보이스 도구로 손수 보내십시오.

도움이 필요하시면

저희는 인보이스를 만드는 시스템과 법이 요구하는 형식 사이의 연결을 구축합니다. 데이터 모델 변경, 매핑, 검증, 전송, 보관을 귀사의 코드베이스 안에서 귀사 팀과 함께 진행합니다. 프로젝트 진행 방식은 전자 인보이스 연동 서비스에 있고, 의무 시행이 ERP 교체 도중에 닥친다면 ERP 현대화를 참고하십시오. 전체 일정은 2026년 EU 디지털 규제 가이드에 있습니다.

저희는 세무사가 아니라 엔지니어입니다. 적용 범위에 관한 질문은 Steuerberater(세무사)의 몫이고, 저희는 그 답에 맞춰 만듭니다. 지금 무엇이 인보이스를 만들고 매달 대략 몇 건이 나가는지 office@c9group.dev로 알려 주십시오.