디지털 인보이스란? ── '청구서 PDF를 메일로 보내는 것'과 무엇이 다른가
· Go Komura · 디지털 인보이스, 인보이스 제도, Peppol, JP PINT, 청구서, 전자장부보존법, EDI, 기업 간 거래, 업무 효율화, 시스템 연동, BtoB, DX
「청구서는 이미 PDF로 만들어 메일로 보내고 있습니다. 우리 회사의 청구 업무는 전자화가 끝났습니다」
이렇게 말할 수 있는 회사가 늘었습니다. 그럼에도 받는 쪽의 경리 담당자는 도착한 PDF를 열어 금액과 거래처, 날짜를 확인하고 회계 시스템에 다시 입력하고 있습니다. 발행하는 쪽도 판매관리 시스템에서 만든 청구 데이터를, 굳이 사람이 읽기 위한 문서로 변환하여 보내고 있습니다.
이 ‘데이터 → 문서 → 다시 데이터’라는 우회를 없애고, 청구 정보를 시스템에서 시스템으로 직접 전달하는 구조가 바로 디지털 인보이스입니다.
이 글에서는 디지털 인보이스란 무엇인지, PDF 청구서와 무엇이 다른지, 인보이스 제도와는 어떤 관계인지, 그리고 중소기업은 어떻게 대응하면 좋을지를 정리합니다.
다만 이 글은 구조에 대한 해설이며, 세무상의 판단(보존 방법의 적합 여부나 공제 가능 여부 등)에는 관여하지 않습니다. 개별적인 세무 판단은 세무사나 관할 세무서에 확인하시기 바랍니다.
1. 먼저 결론
디지털 인보이스란 디지털청의 설명에 따르면, 청구 정보를 판매자의 시스템에서 구매자의 시스템으로 사람을 거치지 않고 직접 데이터로 연계하여 자동 처리하는 구조입니다.
핵심은 ‘사람을 거치지 않고’라는 부분입니다. 종이·PDF·디지털 인보이스의 차이를 정리하면 다음과 같습니다.
| 방법 | 보내는 것 | 받는 쪽의 처리 | 재입력 |
|---|---|---|---|
| 종이 청구서를 우편으로 발송 | 종이 문서 | 눈으로 보고 회계 시스템에 입력 | 필요 |
| PDF 청구서를 메일로 송부 | 전자화된 문서 | PDF를 보고 회계 시스템에 입력 | 필요 |
| 디지털 인보이스 | 표준화된 구조화 데이터 | 시스템이 직접 가져옴 | 원칙적으로 불필요 |
PDF 청구서는 종이가 전자 파일이 되었을 뿐, ‘사람이 읽고 다시 입력한다’는 업무의 형태는 바뀌지 않았습니다. 이는 종이의 대체, 즉 전자화입니다.
디지털 인보이스는 청구 정보 자체를 컴퓨터가 처리할 수 있는 데이터로 교환합니다. 업무의 형태 자체를 바꾸는 디지털화입니다. 디지털 인보이스 추진 협의회(EIPA)도 단순한 종이의 전자화가 아니라, 업무 프로세스 전체를 재검토하는 디지털화의 맥락에서 디지털 인보이스를 자리매김하고 있습니다.
이 관계는 앞선 글들에서 정리한 수발주 EDI와 완전히 같은 구도입니다. 「EDI란? 기업 간 수발주를 어떻게 편하게 만드는가」에서는 주문 데이터를 다루었는데, 디지털 인보이스는 그 청구서 버전이라고 생각하면 이해하기 쉬울 것입니다.
2. 인보이스 제도와 디지털 인보이스는 별개의 이야기
먼저 혼동하기 쉬운 두 용어를 구분하겠습니다.
인보이스 제도(적격청구서 등 보존방식)는 소비세에 관한 세제상의 제도입니다. 국세청의 설명대로, 2023년 10월 1일부터 시행되었습니다. 구매자가 매입세액공제를 받기 위해, 판매자가 교부하는 ‘적격청구서(인보이스)’의 보존 등이 요건이 되는 제도로, 적격청구서에는 다음 기재 사항이 요구됩니다.
- 서류를 교부받는 상대방의 성명 또는 명칭
- 판매자의 성명 또는 명칭과 등록번호
- 거래 연월일
- 거래 내용(경감세율 대상 품목이라는 취지)
- 세율별로 구분하여 합계한 대가의 금액과 적용 세율
- 세율별로 구분한 소비세액 등
등록번호는 세무서에 등록 신청을 하면 통지받는 번호로, 국세청의 적격청구서발행사업자 공표사이트에 따르면 ‘T + 13자리 숫자’로 구성됩니다.
여기서 중요한 것은, 적격청구서는 종이로도 PDF로도 교부할 수 있다는 점입니다. 인보이스 제도는 ‘무엇을 기재할 것인가’를 정하는 것이지, ‘어떤 형식·경로로 보낼 것인가’를 정하는 것이 아닙니다.
디지털 인보이스는 그 ‘어떤 형식·경로로 보낼 것인가’에 대한 답 중 하나입니다. 적격청구서에 필요한 정보를 표준화된 구조화 데이터로서 시스템 간에 직접 주고받습니다.
즉 다음과 같은 관계가 됩니다.
| 정하는 것 | |
|---|---|
| 인보이스 제도 | 청구서에 무엇을 기재하고 무엇을 보존할 것인가(세제) |
| 디지털 인보이스 | 청구 정보를 어떤 데이터 형식·경로로 교환할 것인가(구조) |
‘인보이스 제도에 대응한 회계 소프트웨어를 사용하고 있다’는 것과 ‘디지털 인보이스로 청구 데이터를 송수신하고 있다’는 것은 별개의 상태입니다. 전자는 많은 회사가 이미 마쳤지만, 후자는 앞으로 확산될 단계입니다.
3. Peppol이라는 토대 ── 세계 표준 네트워크와 JP PINT
디지털 인보이스가 ‘표준화된’ 데이터라고 말할 수 있는 것은, Peppol(페폴)이라는 국제 표준 사양 위에서 성립되어 있기 때문입니다.
Peppol은 청구서 등의 전자 문서를 네트워크상에서 주고받기 위한 ‘문서 사양’, ‘운용 규칙’, ‘네트워크’의 프레임워크로, 유럽을 중심으로 많은 국가에서 사용되고 있습니다. 일본에서는 디지털청이 Japan Peppol Authority(일본의 Peppol 관리국)로서 관리를 담당하고 있으며, 2021년 9월부터 OpenPeppol의 멤버로 활동하고 있습니다.
3.1. 4코너 모델 ── 메일과 비슷한 구조
Peppol의 데이터 교환은 ‘4코너 모델’이라 불리는 구성으로 이루어집니다. EIPA의 해설에서는 메일의 구조에 비유하여 설명하고 있습니다.
판매자(C1) 구매자(C4)
│ ↑
│ 청구 데이터를 전달 │ 청구 데이터를 수신
↓ │
판매자 측 액세스 포인트(C2) ──→ 구매자 측 액세스 포인트(C3)
Peppol 네트워크
판매자(C1)는 자신이 계약한 액세스 포인트(C2)에 데이터를 전달하고, C2가 Peppol 네트워크를 통해 구매자 측 액세스 포인트(C3)로 송신하며, 이것이 구매자(C4)에게 도달합니다.
메일로 비유하면 액세스 포인트가 메일 서버에 해당합니다. 상대방이 어떤 메일 서비스를 사용하든 메일이 도착하는 것과 마찬가지로, 판매자와 구매자가 서로 다른 회계 소프트웨어·서비스를 사용하더라도, 둘 다 Peppol에 대응하기만 하면 청구 데이터를 주고받을 수 있습니다. 이 점이 거래처마다 개별적인 협의가 필요해지기 쉬운 기존 EDI와의 큰 차이입니다.
3.2. JP PINT ── 일본 표준 문서 사양
Peppol 네트워크상에서 주고받는 청구 데이터의 일본 표준 사양이 바로 JP PINT입니다. 디지털청이 공표하고 있으며, 인보이스 제도의 적격청구서에 대응하는 항목 정의를 갖추고 있습니다.
대상 문서는 청구서만이 아닙니다. 2026년 7월 현재, 다음 3종류의 사양이 공표되어 있습니다.
| 사양 | 용도 |
|---|---|
| Standard Invoice | 적격청구서(일반적인 청구서) |
| Self Billing Invoice | 자기청구(구매자 측이 작성하는 매입명세서에 대응) |
| Invoice for Non-tax Registered Businesses | 적격청구서발행사업자 이외(면세사업자 등)로부터의 청구 |
사양은 지속적으로 갱신되고 있으며, 디지털청의 공표에 따르면 2026년 6월 8일에 위의 3개 사양 모두가 Ver. 1.1.3으로 갱신되었습니다.
‘자사에서 이 사양을 직접 읽어 구현해야 하는가’라고 긴장할 필요는 없습니다. 8장에서 설명하듯, 많은 회사에게 JP PINT는 대응 소프트웨어 안쪽에 존재하는 것으로, 이를 직접 다루는 쪽은 소프트웨어를 개발·제공하는 쪽입니다.
4. 디지털 인보이스에서는 무엇이 ‘데이터’로서 흐르는가
‘구조화 데이터’라고 해도 이미지를 떠올리기 어려우므로, 한 걸음 더 구체적으로 살펴보겠습니다.
디지털 인보이스에서 흐르는 항목의 중심은 2장에서 언급한 적격청구서의 기재 사항 그 자체입니다. 같은 정보라도 PDF와 데이터에서는 ‘그 이후에 무엇을 할 수 있는가’가 완전히 다릅니다.
| 적격청구서의 기재 사항 | PDF 청구서에서의 처리 | 디지털 인보이스에서의 처리 |
|---|---|---|
| 판매자의 성명·등록번호 | 사람이 눈으로 확인 | 항목으로 가져와 등록번호를 자동 대조할 수 있음 |
| 거래 연월일 | 사람이 읽고 입력 | 날짜 데이터로 그대로 가져옴 |
| 거래 내용(경감세율 대상이라는 취지) | 명세를 육안으로 확인 | 명세행 데이터. 세금 구분도 항목으로 보유 |
| 세율별 대가의 금액·적용 세율 | 필요하면 계산기나 Excel로 검산 | 금액 데이터로서 검산을 자동화할 수 있음 |
| 세율별 소비세액 등 | 위와 동일 | 위와 동일 |
| 교부받는 상대방의 성명 | 수신처를 확인 | 구매자의 식별 정보로 보유 |
4.1. 등록번호 대조를 자동화할 수 있다
이 표에서 실무상의 효과를 가장 알기 쉬운 것이 등록번호의 처리입니다.
인보이스 제도에서는 받은 청구서의 발행자가 실제로 적격청구서발행사업자인지 확인하기 위해, 국세청의 적격청구서발행사업자 공표사이트에서 등록번호를 검색하는 작업이 발생합니다. PDF 청구서 운용에서는 이를 사람이 번호를 직접 입력하여 확인하고 있습니다.
국세청은 이 공표 시스템에 Web-API 기능을 마련해 두어, 지정한 등록번호의 공표 정보나 지정 기간의 갱신 정보를 시스템에서 직접 취득할 수 있습니다(이용에는 애플리케이션 ID 발급 신청이 필요합니다. 무료).
등록번호가 ‘PDF에 인쇄된 문자’가 아니라 ‘데이터 항목’으로 도착한다면, 이 대조 작업은 시스템의 몫으로 만들 수 있습니다. 신규 거래처의 등록 확인이나 기존 거래처의 등록 상태를 정기적으로 점검하는 작업을 자동화하는 방식입니다. 회계 소프트웨어에 따라서는 이러한 대조 기능을 처음부터 갖추고 있는 경우도 있으므로, 먼저 자사 소프트웨어의 기능을 확인하고, 자사 개발 시스템에 통합하고 싶은 경우에 Web-API를 검토하는 순서가 현실적입니다.
4.2. ‘읽는다’에서 ‘검증한다’로
등록번호에 국한되지 않고, 데이터로 도착한다는 것의 본질은 확인 작업의 성격이 바뀐다는 데 있습니다.
PDF 운용에서 경리의 업무는 ‘읽고, 옮겨 적고, 눈으로 확인하는’ 것이었습니다. 데이터로 도착하면 옮겨 적는 과정은 사라지고, 확인 작업은 ‘시스템이 검증한 결과 중 걸러진 것만 보는’ 형태로 바뀝니다. 세율별 금액이 맞는지, 지급 기일은 언제인지, 과거 같은 거래처의 청구와 비교해 이상이 없는지 ── 이러한 점검은 사람보다 시스템이 더 빠르고 빠짐없이 처리할 수 있는 종류의 업무입니다.
5. 디지털 인보이스로 무엇이 편해지는가
5.1. 받는 쪽 ── 입력과 대조가 줄어든다
효과가 가장 알기 쉬운 것은 청구서를 받는 쪽의 경리 업무입니다.
PDF 청구서의 경우, 경리 담당자는 다음과 같은 작업을 하고 있습니다.
- 메일에서 청구서를 찾아 연다
- 거래처명·금액·날짜·등록번호를 확인한다
- 회계 시스템에 입력한다
- 입력 내용을 재확인한다
- 지급 예정에 반영한다
디지털 인보이스에서는 청구 데이터가 시스템에 직접 반영되기 때문에, 이 흐름의 중심에 있던 ‘보고, 입력하고, 확인하는’ 과정이 원칙적으로 불필요해집니다. 사람의 업무는 반영된 내용의 승인이나, 금액이 맞지 않거나 낯선 청구라는 예외 상황에 대한 처리로 바뀝니다.
월말에 청구서가 몰리는 회사일수록 이 차이는 커집니다. 옮겨 적는 과정에서의 실수나 이중 입력이 줄어드는 원리는 수발주 EDI와 동일합니다.
5.2. 발행하는 쪽 ── ‘문서를 만들어 보내는’ 공정이 사라진다
발행하는 쪽에서는 판매관리 시스템이나 청구 시스템에서 만든 청구 데이터를 인쇄하여 봉투에 넣어 우송하거나, PDF로 변환하여 메일에 첨부하는 공정이 사라집니다.
보낸 후의 ‘도착했나요’, ‘다시 보내주세요’ 같은 주고받음도 줄일 수 있습니다. 수신처 오류, 첨부 파일 누락, 비밀번호 걸린 ZIP 처리 등 메일 첨부에 따라다니는 문제에서도 벗어날 수 있습니다(메일 첨부 청구서 운용이 안고 있는 문제는 「왜 메일 보안에서 PPAP는 안 되는가. 올바른 방법은?」에서도 다루고 있습니다).
5.3. 그 다음 ── 지급·입금 대사(對査)로의 연결
청구 정보가 구조화 데이터로 흐르게 되면, 그 다음 업무로도 이어집니다. 구매자 측에서는 지급 예정의 작성이나 이체 데이터로의 반영, 판매자 측에서는 입금 대사와의 대조입니다.
이는 수발주 글에서 언급한 ‘EDI는 수주를 입구로 하여 재고·출하·청구까지 연결하는 토대가 된다’는 이야기를, 청구 측에서 바라본 모습입니다. 주문에서 청구·지급까지를 데이터로 일관되게 연결했을 때, 기업 간의 사무 작업은 가장 적어집니다.
6. 전자장부보존법과의 관계
디지털 인보이스 이야기를 하면 반드시 전자장부보존법(전자장부법)이 함께 언급됩니다. 그 관계를 간단히 정리하겠습니다.
국세청의 전자장부 등 보존제도 안내에 따르면, 2024년 1월 1일 이후 청구서나 영수증 등을 전자 데이터로 주고받은 경우(전자거래), 그 데이터는 전자 상태 그대로 보존하는 것이 의무화되어 있습니다. 보존 시에는 크게 다음 두 가지가 요구됩니다.
- 진정성 확보 ── 타임스탬프나 정정·삭제의 기록·방지 등 위변조를 막는 조치
- 가시성 확보 ── 날짜·금액·거래처로 검색할 수 있는 상태로 만들고, 화면이나 서면으로 출력할 수 있도록 해 둘 것
디지털 인보이스의 수수도 전자거래에 해당하므로, 이 보존 의무의 대상입니다. 즉 디지털 인보이스를 도입한다면, 받은 데이터와 보낸 데이터를 어떻게 보존할지도 함께 정해야 합니다.
실무적으로는 Peppol에 대응하는 회계·청구 소프트웨어 대부분이 보존 요건에 대응하는 기능을 갖추고 있으므로, ‘대응 소프트웨어를 사용하고 그 보존 기능의 설정과 운용을 확인한다’는 것이 기본적인 진행 방식입니다. 다만 자사의 보존 방법이 요건을 충족하는지에 대한 최종 판단은 세무의 영역이므로, 세무사나 관할 세무서에 확인하시기 바랍니다.
7. 흔히 있는 오해 정리
디지털 인보이스 이야기를 할 때 반복해서 나오는 오해가 있습니다. 먼저 정리해 두겠습니다.
| 흔히 있는 오해 | 실제 |
|---|---|
| 디지털 인보이스 대응은 의무다 | 이용은 임의입니다. 2026년 7월 현재, 이용을 의무화하는 제도는 없습니다 |
| PDF 청구서는 더 이상 쓸 수 없게 된다 | 사용할 수 있습니다. 적격청구서는 종이로도 PDF로도 교부할 수 있습니다(2장) |
| 인보이스 제도에 대응한 소프트웨어라면 디지털 인보이스도 대응이 끝난 것이다 | 별개입니다. Peppol 대응 여부는 개별적으로 확인이 필요합니다 |
| 전자장부보존법에 대응하고 있다면 청구 업무 재검토는 끝난 것이다 | 보존 의무 대응과, 입력·대조 작업을 줄이는 업무 효율화는 별개의 이야기입니다 |
특히 첫 번째가 중요합니다. 의무가 아닌 이상, ‘대응하지 않으면 곤란해지니까’가 아니라 자사의 청구 업무 부담이 얼마나 줄어드는가로 도입 여부를 판단하게 됩니다. 그렇기 때문에 다음 장의 ‘어떻게 시작할 것인가’는 제도 대응의 이야기가 아니라 업무 개선의 이야기로 읽어 주시기 바랍니다.
한편, 거래처로부터 ‘디지털 인보이스로 보내 달라(받고 싶다)’는 요청을 받을 가능성은 앞으로 높아질 것입니다. 임의이기 때문에 오히려 먼저 대응한 쪽이 거래 조건에 관한 대화를 주도하는 구도가 되는 점은, FAX에서 웹 수주로의 이행과 동일합니다.
8. 중소기업은 어떻게 시작할 것인가
8.1. 현실적인 입구는 ‘대응 소프트웨어를 사용하는 것’
디지털 인보이스라고 하면 뭔가 새로운 시스템을 구축하는 이야기처럼 들리지만, 많은 중소기업에게 현실적인 입구는 이미 사용 중인(또는 앞으로 선택할) 회계·청구 소프트웨어가 Peppol에 대응하는지 확인하는 것입니다.
EIPA는 Peppol 디지털 인보이스에 이미 대응한 서비스 목록을 공표하고 있습니다. 또한 디지털청은 일본 내 인증 Peppol 서비스 프로바이더 목록을 공개하고 있습니다. 자사의 소프트웨어가 대응하고 있다면, 대규모 개발 없이도 송수신을 시작할 수 있는 가능성이 있습니다.
확인하는 순서는 다음과 같습니다.
- 자사의 회계·청구 소프트웨어가 Peppol(디지털 인보이스)에 대응하고 있는가
- 대응하고 있다면 송신·수신 중 어느 쪽에 대응하는가, 이용 요금은 어떠한가
- 주요 거래처가 받을 수 있는 상태인가(상대방도 대응 소프트웨어나 서비스가 필요)
- 받은 데이터의 보존(전자장부법 대응)이 소프트웨어 측에서 어떻게 처리되는가
8.2. 자사 개발 시스템이 있는 경우
판매관리나 청구관리를 자사 개발 시스템으로 운영하는 회사에서는 한 단계 더 검토가 필요합니다.
다만 JP PINT의 사양서를 직접 읽어 자체적으로 Peppol 액세스 포인트에 접속한다는 이야기가 되는 경우는 보통 없습니다. 현실적인 것은 다음과 같은 구성입니다.
- 자사 시스템에서 청구 데이터를 CSV나 API로 Peppol 대응 청구 서비스·회계 소프트웨어에 전달하고, 송신은 그쪽에 맡긴다
- 수신도 대응 소프트웨어 측에서 처리하고, 가져온 데이터를 자사 시스템에 연계한다
즉 자사 시스템의 개수 포인트는 ‘Peppol 대응’ 그 자체가 아니라, 대응 소프트웨어와의 사이에서 데이터를 정확하게 주고받는 연계 부분입니다. 이 부분은 수발주의 웹 이행에서 언급한 ‘CSV 가져오기라는 중간 형태’(「FAX 수주를 웹으로 이전하려면」)와 완전히 동일한 사고방식으로 설계할 수 있습니다.
8.3. 서두를 필요는 없지만, 무시해서도 안 된다
디지털 인보이스는 2026년 현재 ‘사용하지 않으면 업무가 멈추는’ 것은 아닙니다. 거래처가 PDF 청구서를 요구한다면 당분간은 PDF와의 병용이 계속됩니다. 수발주의 FAX·웹 병용과 마찬가지로, 이행은 단계적으로 진행됩니다.
한편, 대형 거래처나 지방자치단체·관공서와의 거래에서 디지털 인보이스 이용이 화제에 오르는 장면은 앞으로 늘어날 것입니다. 디지털청도 정부 조달이나 기업 간 거래에서의 활용 사례 공표를 진행하고 있습니다. ‘거래처가 요청했을 때 자사 소프트웨어로 받을 수 있는가’를 한번 확인해 두는 것만으로도 대비로서 충분한 의미가 있습니다.
8.4. 검토 우선순위를 판단하는 체크리스트
‘우리 회사는 언제 움직여야 하는가’의 기준으로, 다음 항목에 해당할수록 검토의 우선순위는 높아집니다.
- 청구서의 수령·발행이 월 수십 장 이상이다
- 월말·월초에 청구서 입력·대조·발행 작업으로 경리 부서가 야근하고 있다
- 받은 청구서의 등록번호 확인을 수작업으로 하고 있다
- 입력 실수나 이중 지급으로 아찔했던 경험이 있다
- 주요 거래처나 업계 단체에서 디지털 인보이스나 Peppol 이야기가 나오기 시작했다
- 마침 회계·청구 소프트웨어 교체나 자사 개발 시스템의 개수를 계획하고 있다
반대로 청구서가 월 몇 장 정도이고 거래처도 고정적이라면 서두를 이유는 없습니다. 소프트웨어 교체 시기에 ‘다음 소프트웨어는 Peppol에 대응하는가’를 선정 조건에 추가해 두는 정도로 충분합니다.
중요한 것은 도입 그 자체를 목적으로 삼지 않는 것입니다. 4장과 5장에서 언급한 ‘어떤 수작업이 줄어드는가’를 자사의 업무에 대입하여 헤아려 보았을 때, 줄어드는 작업이 구체적으로 보인다면 추진할 가치가 있고, 보이지 않는다면 아직 시기상조라는 이야기일 뿐입니다.
9. 수발주 디지털화의 전체 지도 속에서
이 글은 수발주 관련 데이터 연계를 다루는 시리즈의 세 번째 글입니다. 전체적인 위치 관계를 정리해 두겠습니다.
| 글 | 다루는 범위 |
|---|---|
| EDI란? 기업 간 수발주를 어떻게 편하게 만드는가 | 주문·출하·청구 데이터를 기업 간에 교환하는 구조의 전체상 |
| FAX 수주를 웹으로 이전하려면 | 수주 측의 이행 실무(이중 운용·CSV 가져오기·마스터 정비) |
| 디지털 인보이스(이 글) | 청구 데이터의 표준화된 교환 구조 |
EDI가 ‘기업 간 데이터 교환’이라는 큰 사고방식이고, 그 수주 측의 실천이 FAX 수주의 웹 이행, 청구 측의 표준화된 형태가 디지털 인보이스라는 관계입니다.
어디서부터 손을 대야 할지는 회사마다 다릅니다. 수주 입력 부담이 크다면 수주 측부터, 청구서 발행·수령 매수가 많다면 청구 측부터 시작하는 것이 자연스러운 판단입니다. 공통되는 것은 ‘같은 정보를 사람이 몇 번 입력하고 있는가’를 헤아리는 것부터 시작한다는 점입니다.
정리
- 디지털 인보이스란 청구 정보를 판매자 시스템에서 구매자 시스템으로 사람을 거치지 않고 직접 데이터로 연계하여 자동 처리하는 구조입니다
- PDF 청구서는 문서의 ‘전자화’이며, 받는 쪽의 입력 작업은 그대로 남습니다. 디지털 인보이스는 구조화 데이터로 업무를 연결하는 ‘디지털화’입니다
- 인보이스 제도(세제)와 디지털 인보이스(데이터 교환 구조)는 별개의 이야기입니다. 제도에 대응했더라도 디지털 인보이스의 이용은 앞으로 시작해야 하는 회사가 대부분입니다
- 토대는 Peppol이라는 국제 표준이며, 일본에서는 디지털청이 Peppol Authority로서 관리하고, 일본 표준 사양으로서 JP PINT를 공표하고 있습니다
- 액세스 포인트를 매개로 하는 4코너 모델을 통해, 상대방이 다른 소프트웨어를 사용하더라도 주고받을 수 있는 것이 기존의 개별 EDI와의 차이입니다
- 흐르는 것은 적격청구서의 기재 사항 그 자체입니다. 등록번호 대조(국세청 공표 시스템의 Web-API)나 세율별 금액 검산 등, 사람이 눈으로 하던 확인 작업을 시스템의 검증으로 바꿀 수 있습니다
- 받은 디지털 인보이스는 전자장부보존법의 전자거래에 해당하며, 전자 데이터 그대로의 보존이 필요합니다
- 이용은 임의이며 의무가 아닙니다. ‘대응하지 않으면 곤란해지니까’가 아니라, 자사의 청구 업무에서 어떤 수작업이 줄어드는가로 판단합니다
- 중소기업의 현실적인 입구는 Peppol 대응 회계·청구 소프트웨어의 이용입니다. 자사 개발 시스템이 있는 경우에는 대응 소프트웨어와의 데이터 연계 부분을 설계합니다
청구 업무·수발주 데이터 연계를 검토 중이신 분께
청구서의 발행이나 수령에 따른 사무 부담을 줄이고 싶지만, 자사의 판매관리 시스템이나 청구 업무의 어디서부터 손을 대야 할지 모르는 경우에는 먼저 현재의 청구 데이터 흐름을 정리할 필요가 있습니다.
판매관리 시스템에서 청구 데이터를 어떻게 만들고, 어떻게 거래처에 보내며, 받은 청구서를 어떻게 회계 시스템에 입력하고 있는지 확인하면, 디지털 인보이스나 대응 소프트웨어와의 연계로 자동화할 수 있는 범위가 보이게 됩니다.
합동회사 코무라소프트(合同会社小村ソフト)에서는 자사 개발 업무 시스템과 회계 소프트웨어·Peppol 대응 서비스와의 연계를 포함하여, 청구·수발주 관련 데이터 연계에 대해 현황 정리나 실현 방법 검토를 상담받고 있습니다.
전면 개편을 전제로 하지 않고, 현재의 구조를 유지하면서 데이터의 출입구만을 단계적으로 연결하는 구성도 검토할 수 있습니다.
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
EDI란 무엇인가? 기업 간 수발주를 어떻게 편하게 만드는가 ── 팩스·메일·수작업 입력에서 데이터 연계로
EDI란 주문서나 청구서 등의 거래 데이터를 기업 간 시스템으로 교환하는 구조입니다. 팩스·메일과의 차이, 수작업 입력과 전기(轉記) 오류를 줄이는 구조, 수주·재고·출하·청구를 연계하는 장점을 알기 쉽게 해설합니다.
FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간 설계와 단계적 이행 실무
FAX 수주를 웹 수주나 CSV 가져오기로 이행하는 실무를 설명합니다. 갑작스러운 전면 웹화가 실패하기 쉬운 이유, FAX와 웹의 이중 운영 기간 설계, 상품·거래처 마스터 정비, CSV 가져오기라는 중간 형태, 거래처를 끌어들이는 방법을 단계적...
PowerShell 실용 명령어 모음 ── 일상 업무에서 자주 쓰는 작은 기능 늘리기
PowerShell로 일상 업무에 쓰는 실용 명령어로서, Measure-Object, Group-Object, Select-String, Compare-Object, Tee-Object, Start-Transcript 등의 활용 시점을 정리합니다.
Windows 앱의 작업 트레이 상주와 토스트 알림 ── NotifyIcon의 함정과 AppNotification 선택 기준
업무용 Windows 앱을 작업 트레이(알림 영역)에 상주시키고 토스트 알림으로 사용자에게 알리는 구현을 정리합니다. NotifyIcon의 올바른 사용법과 「닫으면 트레이로」설계, 탐색기 재시작 시 재등록, 토스트 API 3종(Windows Ap...
WordPress에서 Movable Type으로의 이전 ── '반대 방향'이기에 더욱 정리해 두어야 할 실무 절차
WordPress에서 Movable Type(MovableType.net)으로의 이전 절차를 실무 관점에서 해설합니다. 이전이 합리적인 경우, 게시물·고정 페이지·이미지 임포트, 커스텀 게시물 타입 처리, URL 설계와 301 리다이렉트를 통한 ...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
Windows 앱 개발
자사 개발 판매관리·청구 시스템과 회계 소프트웨어나 Peppol 대응 서비스 사이에서 청구 데이터를 주고받는 연계 처리의 설계·구현은 업무 애플리케이션 개발 상담 범위에 해당하기 때문입니다.
Windows 소프트웨어 유지 보수 & 현대화
기존 기간계 시스템이나 청구 업무를 전면 개편하지 않고, 청구 데이터의 출입구만을 디지털 인보이스로 단계적으로 연결하는 개수는 기존 Windows 소프트웨어의 개수·유지보수에 해당하기 때문입니다.
기술 상담 & 설계 리뷰
청구 업무의 어느 부분을 자동화하고, 어떤 소프트웨어·서비스와 어떻게 연계할 것인가라는 구성의 정리는 설계 리뷰를 수반하는 기술 상담이기 때문입니다.
자주 묻는 질문
이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.
- 디지털 인보이스와 전자 인보이스(PDF 청구서)는 무엇이 다른가요?
- PDF 청구서는 사람이 읽기 위한 문서를 전자 파일로 만든 것으로, 받는 쪽은 내용을 보면서 회계 시스템에 다시 입력해야 합니다. 디지털 인보이스는 청구 정보 자체를 표준화된 구조화 데이터로 보내기 때문에, 구매자의 시스템이 직접 가져와 처리할 수 있습니다. 종이를 파일로 바꾸는 '전자화'와, 업무 처리를 데이터로 연결하는 '디지털화'의 차이입니다.
- 인보이스 제도에 대응이 끝났다면 디지털 인보이스에도 대응이 되어 있는 건가요?
- 별개의 이야기입니다. 인보이스 제도(적격청구서 등 보존방식)는 소비세의 매입세액공제에 관한 세제상의 제도로, 적격청구서는 종이로도 PDF로도 교부할 수 있습니다. 디지털 인보이스는 그 청구 정보를 시스템 간에 주고받기 위한 데이터 형식과 유통 구조(Peppol·JP PINT)로, 제도 대응과는 별개로 이용할지 여부를 판단하는 것입니다.
- 중소기업이 디지털 인보이스를 사용하기 시작하려면 무엇이 필요한가요?
- 현실적인 입구는 Peppol에 대응하는 회계·청구 소프트웨어를 사용하는 것입니다. 디지털 인보이스 추진 협의회(EIPA)가 대응이 끝난 서비스 목록을 공표하고 있으며, 자사가 사용 중인 소프트웨어가 대응하고 있다면 설정을 활성화하는 것만으로 송수신을 시작할 수 있는 경우도 있습니다. 자사 개발 판매관리 시스템을 사용하는 경우에는 대응 소프트웨어나 서비스 프로바이더와의 연계 방법을 검토하게 됩니다.
- 받은 디지털 인보이스는 어떻게 보존해야 하나요?
- 디지털 인보이스의 수수는 전자장부보존법상의 전자거래에 해당하므로, 2024년 1월 이후에는 전자 데이터 그대로, 위변조 방지 조치(진정성 확보)와 날짜·금액·거래처로 검색할 수 있는 상태(가시성 확보)를 충족하여 보존해야 합니다. 많은 Peppol 대응 소프트웨어가 보존 요건에 대응하는 기능을 갖추고 있지만, 자사의 운용이 요건을 충족하는지는 세무사나 관할 세무서에 확인하시기 바랍니다.
저자 프로필
기사 저자의 프로필 페이지입니다.
Go Komura
합동회사 코무라소프트 대표
Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.
공개 링크