전자 인보이스 연동: Peppol, XRechnung, ZUGFeRD, Factur-X를 염두에 두지 않고 만들어진 시스템을 위한 개발

전자 인보이스 제품을 사는 일은 쉽습니다. 막히는 쪽은 거의 언제나 제품이 아닙니다. 인보이스를 실제로 찍어내는 12년 된 수주 관리 시스템, 문서로 남아 있지 않은 가격 로직, 그리고 2019년에 퇴사한 사람이 작성한 저장 프로시저에서 인보이스 번호가 나온다는 사실입니다.

우리는 실제로 운영 중인 것과 의무가 요구하는 것 사이의 커넥터를 만듭니다. 구조화 인보이스 생성, 검증, 네트워크 전송, 수신 처리, 보관을 기존 시스템을 교체하지 않고 그 안에 연결합니다.

의무 규정과 실제 적용 시점

유럽은 PDF 인보이스에서 구조화된 기계판독 인보이스로 국가별 일정에 따라 전환하고 있습니다. 그 위에는 이를 통일하려는 EU의 VAT in the Digital Age(ViDA) 패키지가 있습니다. 지금 프로젝트를 움직이는 날짜는 다음과 같습니다.

독일: 구조화 전자 인보이스 수신은 2025년 1월 1일부터 의무입니다. 발행은 직전 연도 매출 EUR 800,000 초과 기업의 경우 2027년 1월 1일부터, 그 외 기업은 2028년 1월 1일부터 의무가 됩니다. 실무에서 쓰이는 포맷은 XRechnung(순수 XML)과 ZUGFeRD 2.x(XML이 내장된 하이브리드 PDF)이며, 둘 다 EN 16931을 따릅니다.
프랑스: 수신, 그리고 대기업·중견기업의 발행이 2026년 9월 1일부터입니다. 중소기업 발행은 2027년 9월 1일부터입니다. 전송은 등록된 플랫폼을 거치며, 공통 하이브리드 포맷은 Factur-X입니다.
벨기에: 2026년 1월 1일부터 Peppol을 통한 B2B 전자 인보이스가 의무이며, 2028년에는 5-코너 모델 기반 e-reporting이 예정되어 있습니다.
폴란드: 국가 클리어런스 플랫폼 KSeF가 자체 XML 스키마와 자체 일정으로 운영됩니다.
이탈리아: SdI와 FatturaPA가 2019년부터 가동 중이며, 여전히 EU에서 가장 엄격한 클리어런스 모델입니다.
스페인: Verifactu와 Crea y Crece 인보이스 의무가 지역별 TicketBAI 체계와 함께 단계적으로 시행되고 있습니다.

이들 국가 여러 곳에 판매한다면 프로젝트가 여러 개인 것이 아닙니다. 아키텍처는 하나이고 국가별 어댑터가 여러 개인 것입니다. 그렇게 다루느냐 아니냐가 연동 하나로 끝나느냐 다섯 개가 되느냐를 가릅니다.

프로젝트가 실제로 무너지는 지점

인보이스 데이터가 표준이 요구하는 모양으로 존재하지 않습니다. EN 16931은 많은 시스템이 애초에 수집한 적 없는 필드를 요구합니다. 제대로 된 구매자 참조번호, 라인별이 아닌 세율별 부가세 내역, 구조화된 지급 조건, 통제 어휘에서 가져온 단위 코드 같은 것들입니다. 엔지니어링 작업의 실체는 앞으로 발행할 모든 인보이스에 대해 그 필드를 기존 데이터로부터 결정론적으로 재구성하는 일입니다.

검증 실패는 뒤늦게 도착합니다. 거절된 인보이스는 미수금입니다. 검증은 전송 전에, 현행 스키마와 현행 국가별 비즈니스 규칙에 대해 수행되어야 하고, 실패는 파일에 기록되는 것이 아니라 조치할 수 있는 담당자에게 노출되어야 합니다.

수신이 발행보다 어렵습니다. 모두가 발행을 준비하면서 잊는 것이 있습니다. 수신 의무 시점부터는 모든 공급업체로부터 적합한 형식이라면 무엇이든 구조화 인보이스를 받아들여야 하고, 사람이 한 건씩 열어보지 않고도 매입채무 프로세스로 넘겨야 합니다.

번호 체계와 멱등성. 재시도, 네트워크 타임아웃, 플랫폼 장애는 정상적인 일입니다. 같은 인보이스가 두 개의 번호로 두 번 전송되면 그것은 소프트웨어 문제가 아니라 세무 문제입니다. 이것은 처음부터 맞게 잡아야 합니다.

우리가 구축하는 것

진단과 포맷 결정

보통 1~2주의 짧은 단계입니다. 인보이스가 실제로 어떻게 생성되는지, 어떤 의무가 언제 귀사에 미치는지, 현실적인 선택지가 무엇인지 살펴봅니다. 산출물은 문서화된 권고안입니다. 필요한 포맷, Peppol 접속을 사업자를 통할지 자체 액세스 포인트를 운영할지, 소스 시스템에서 무엇을 바꿔야 하는지, 비용이 얼마인지를 담습니다.

표준 제품에 작은 어댑터를 붙이면 끝난다는 결론이 나올 때도 있습니다. 6개월을 청구하는 것보다 첫 주에 그렇게 말씀드리는 편이 낫다고 봅니다.

인보이스 생성과 매핑

소스 데이터에서 요구되는 구문으로 가는 매핑 계층을 만듭니다. EN 16931 기반의 UBL과 CII, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, KSeF XML을 다루며, 필드 도출 규칙을 문서화해 감사인과 재무팀이 모두 따라갈 수 있게 합니다. 소스 시스템이 필수 필드를 아예 제공하지 못하는 경우에는 기본값을 지어내지 않고 그 사실을 일찍 알린 뒤 수집 방법을 설계합니다.

전송 전 검증

스키마 검증, Schematron 비즈니스 규칙, 국가별 점검을 문서가 회사 밖으로 나가기 전에 수행합니다. 실패 건은 담당자가 있는 큐로 보내고, 스택 트레이스가 아니라 어떤 필드가 왜 실패했는지 적힌 메시지를 함께 남깁니다.

네트워크 연결

Peppol 액세스 포인트 연결을 기존 사업자를 통해 하거나 직접 운영합니다. 물량과 필요한 통제 수준에 따라 결정합니다. 클리어런스 모델 국가에서는 국가 플랫폼과 직접 연동합니다. KSeF, SdI, 프랑스의 PDP 생태계가 그렇고, 이들 플랫폼이 저마다 다르게 처리하는 인증서와 인증 방식도 함께 다룹니다.

수신 처리

공급업체 인보이스를 수신, 검증한 뒤 하나의 내부 표현으로 정규화하고, 발주와 입고 데이터가 있는 경우 대사하여 매입채무 워크플로로 전달합니다. 프로젝트의 회수 효과는 보통 여기에서 나옵니다. 아무도 측정한 적 없던 수기 입력을 걷어내기 때문입니다.

보관과 감사 증적

원본 구조화 문서를 독일 GoBD, 이탈리아 conservazione sostitutiva 또는 사업을 영위하는 지역의 동등 규정이 요구하는 형식과 기간으로 보관하고, 조회 경로는 가정하지 않고 실제로 테스트합니다.

연동 대상 시스템

SAP ECC와 S/4HANA, Microsoft Dynamics 365와 Business Central, Odoo, NetSuite, Sage, Infor, Xero, DATEV 인터페이스, 그리고 가장 흔하게는 비즈니스 운영의 중심에 있으면서 의무 대응을 이유로 교체될 일은 없는 자체 개발 또는 대폭 수정된 시스템입니다. .NET, Java, PHP, Python, Node.js로 작업하며, 눈앞에 있는 것이 더 오래된 스택이라면 그것으로도 작업합니다.

마켓플레이스, 구독 플랫폼, 또는 대량으로 인보이스를 프로그램 발행하는 빌링 엔진을 운영한다면 그것이 바로 우리가 상정한 경우입니다. 인보이스를 귀사의 코드가 만들어 내므로 컴플라이언스도 귀사의 코드 안에 있어야 합니다.

우리가 하지 않는 일

인보이스 소프트웨어를 팔지 않으며 회계 패키지도 아닙니다. 적합한 인보이스를 만들어 주는 도구를 찾는 소규모 사업자라면 그냥 사서 쓰시는 편이 낫습니다. DATEV, sevDesk, Lexware를 비롯한 여러 제품이 그 일을 잘하고, 비용도 연동 프로젝트의 몇 분의 일입니다.

우리를 찾을 때는 인보이스가 이미 보유한 시스템에서 생성될 때, 여러 국가의 규칙이 공존해야 할 때, 또는 물량 때문에 아무도 지켜보지 않아도 돌아가야 할 때입니다.

프로젝트 진행 방식

진단, 1~2주, 고정 금액. 문서화된 권고안과 비용이 산정된 계획으로 마무리합니다.

구축, 첫 국가 기준 보통 6~12주이며 소스 데이터가 얼마나 깨끗한지에 따라 달라집니다. 귀사의 리포지토리에서, 귀사의 브랜치 전략에 따라, 귀사 팀과 함께 작업하고 테스트를 남깁니다.

파일럿, 기존 프로세스와 병행하여 소수의 거래처에 실제 인보이스를 보내며 실패율이 있어야 할 수준에 이를 때까지 운영합니다.

전환과 지원, 실패 큐를 모니터링하고 책임자를 두며, 첫 월마감과 첫 부가세 신고까지 함께합니다. 정말 중요한 질문은 그때 나옵니다.

준수하는 표준

EN 16931과 그 구문 바인딩(UBL 2.1, UN/CEFACT CII), Peppol BIS Billing 3.0과 Peppol 전송 인프라, XRechnung과 KoSIT 검증기, ZUGFeRD 2.x와 Factur-X 프로파일, FatturaPA, KSeF, 그리고 2030년 이후를 규정할 ViDA 제안입니다.

자주 묻는 질문

독일 전자 인보이스 의무는 정확히 언제부터 적용되나요?

수신은 2025년 1월 1일부터 모든 독일 사업자에게 적용되고 있습니다. 발행은 직전 연도 매출이 EUR 800,000를 초과하면 2027년 1월 1일부터, 그 외에는 2028년 1월 1일부터 적용됩니다. 의무는 독일 국내 B2B 거래를 대상으로 하며, 국경 간 거래와 B2C 인보이스의 취급은 다르므로 세무 자문과 확인하실 것을 권합니다.

XRechnung과 ZUGFeRD는 무엇이 다른가요?

XRechnung은 순수 XML이며 독일 공공부문이 정의했고 공공기관 대상 인보이스에는 필수입니다. ZUGFeRD 2.x는 하이브리드입니다. PDF/A-3 문서 안에 동일한 구조화 데이터를 내장해 사람은 PDF를 읽고 기계는 XML을 읽습니다. 둘 다 EN 16931을 따릅니다. 독일의 상거래 B2B 실무는 ZUGFeRD 쪽으로 기울어 있고, 많은 구매자가 양쪽 다 받아들입니다.

자체 Peppol 액세스 포인트가 필요한가요?

대개 필요하지 않습니다. 대부분의 기업은 기존 액세스 포인트 사업자를 통해 접속하며 그편이 더 저렴하고 빠릅니다. 자체 운영이 타당한 경우는 물량이 많을 때, 전송 계층을 직접 통제해야 할 때, 또는 다른 회사에 인보이스 서비스를 제공할 때입니다.

기존 전자 인보이스 벤더와 함께 일할 수 있나요?

가능하며, 오히려 그 구성이 맞는 경우가 많습니다. 벤더가 전송과 네트워크 가입을 맡고, 우리는 귀사 시스템과 벤더 API 사이의 모든 것을 만듭니다. 매핑, 검증, 재시도, 실패 처리, 대사가 여기에 해당합니다.

검증에 실패한 인보이스는 어떻게 되나요?

어떤 필드가 어떤 규칙을 위반했는지 읽을 수 있게 설명된 큐로 갑니다. 이 큐는 의도적으로 설계합니다. 가동 초기 몇 달 동안 가장 많이 쓰이는 부분이고, 이것이 부실하면 컴플라이언스 프로젝트가 영구적인 수작업으로 굳어지기 때문입니다.

같은 인보이스를 두 번 보내는 일은 어떻게 막나요?

인보이스 식별 정보에서 도출한 안정적인 멱등성 키를 모든 재시도에 그대로 실어 보내고, 무엇이 전송되었는지에 대한 최종 권위를 갖는 전송 로그를 둡니다. 재시도는 새 식별자를 만들지 않고 원래 식별자를 재사용합니다.

시작하기

어느 국가로 인보이스를 발행하는지, 월 발행 건수가 대략 얼마인지, 지금 무엇이 인보이스를 생성하는지 알려 주십시오. 어떤 의무가 어떤 순서로 귀사에 미치는지, 그리고 이것이 커넥터인지 프로젝트인지 말씀드리겠습니다.

전자 인보이스 준비도 진단을 예약하시려면 문의해 주십시오.