디지털 인보이스란? ── '청구서 PDF를 메일로 보내는 것'과 무엇이 다른가

「청구서는 이미 PDF로 만들어 메일로 보내고 있습니다. 우리 회사의 청구 업무는 전자화가 끝났습니다」

이렇게 말할 수 있는 회사가 늘었습니다. 그래도 받는 쪽의 경리 담당자는 도착한 PDF를 열고, 금액과 거래처와 날짜를 확인한 뒤, 회계 시스템에 다시 입력하고 있습니다. 발행하는 쪽도 판매관리 시스템에서 만든 청구 데이터를, 굳이 사람이 읽는 문서로 바꿔서 보내고 있습니다.

이 「데이터 → 문서 → 다시 데이터」라는 우회를 없애고, 청구 정보를 시스템에서 시스템으로 직접 넘기는 구조가 디지털 인보이스입니다.

이 글에서는 디지털 인보이스가 무엇인지, PDF 청구서와 무엇이 다른지, 인보이스 제도와는 어떤 관계인지, 그리고 중소기업은 어떻게 마주하면 되는지를 정리합니다.

이 글은 수발주 주변의 데이터 연계를 다루는 시리즈의 세 번째입니다. 첫 번째 「EDI란? 기업 간 수발주를 어떻게 편하게 만드는가」에서 기업 간 데이터 교환의 전체 그림을, 두 번째 「FAX 수주를 Web으로 옮기려면」에서 수주 쪽의 이행 실무를 다루었습니다. 이번은 그 청구 쪽에 해당합니다. 앞의 두 글을 읽지 않아도, 이 글만으로 이야기가 통하도록 썼습니다.

다만 이 글은 구조에 대한 해설이며, 세무상의 판단(보존 방법의 적합 여부나 공제 가능 여부 등)에는 들어가지 않습니다. 개별 세무 판단은 세무사나 관할 세무서에 확인하시기 바랍니다.

1．먼저 결론

디지털 인보이스란, 디지털청의 설명에 따르면, 청구 정보를 판매자의 시스템에서 구매자의 시스템으로, 사람을 거치지 않고 직접 데이터 연계하여 자동 처리하는 구조입니다.

핵심은 「사람을 거치지 않고」라는 부분입니다. 종이·PDF·디지털 인보이스의 차이를 정리하면 다음과 같습니다.

PDF 청구서는 종이가 전자 파일이 되었을 뿐, 「사람이 읽고 다시 입력한다」는 업무의 형태는 바뀌지 않았습니다. 이는 종이를 대체하는 것, 즉 전자화입니다.

디지털 인보이스는 청구 정보 자체를 컴퓨터가 처리할 수 있는 데이터로 교환합니다. 업무의 형태 자체를 바꾸는 디지털화입니다. 디지털 인보이스 추진 협의회(EIPA)도, 단순한 종이의 전자화가 아니라, 업무 프로세스 전체를 다시 보는 디지털화의 맥락에서 디지털 인보이스를 자리매김하고 있습니다.

이 관계는 이전 글까지에서 정리한 수발주의 EDI와 완전히 같은 구도입니다. 「EDI란? 기업 간 수발주를 어떻게 편하게 만드는가」에서는 주문 데이터를 다루었지만, 디지털 인보이스는 그 청구서 버전이라고 생각하면 이해하기 쉽습니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 16건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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」「C4」의 C는 코너(corner, 모서리)이며, 네 명의 등장인물을 네 모서리에 빗댄 호칭입니다. 범례는 다음과 같습니다.

• C1(제1의 모서리) ＝ 판매자 ── 청구 데이터를 만드는 쪽의 사용자
• C2(제2의 모서리) ＝ 판매자 측 액세스 포인트 ── 판매자가 계약하는 송신 측 사업자
• C3(제3의 모서리) ＝ 구매자 측 액세스 포인트 ── 구매자가 계약하는 수신 측 사업자
• C4(제4의 모서리) ＝ 구매자 ── 청구 데이터를 받는 쪽의 사용자

위 그림의 화살표는 왼쪽 위의 C1에서 아래로, 아래단을 왼쪽에서 오른쪽으로, 그리고 오른쪽을 위로, 하는 U자 경로를 따릅니다. 즉 판매자(C1)는 자신이 계약한 액세스 포인트(C2)에 데이터를 넘기고, C2가 Peppol 네트워크를 통해 구매자 측 액세스 포인트(C3)로 송신하여, 구매자(C4)에게 도착합니다.

메일로 말하면 액세스 포인트가 메일 서버에 해당합니다. 상대가 어떤 메일 서비스를 쓰든 도착하는 것과 같이, 판매자와 구매자가 서로 다른 회계 소프트웨어·서비스를 쓰더라도, Peppol 대응끼리라면 청구 데이터를 주고받을 수 있습니다. 여기가, 거래처마다 개별 합의가 필요해지기 쉬운 기존의 EDI와의 큰 차이입니다.

3.2．JP PINT ── 일본 표준의 문서 사양

Peppol 네트워크에서 주고받는 청구 데이터의 일본 표준 사양이 JP PINT입니다. 디지털청이 공표하고 있으며, 인보이스 제도의 적격청구서에 대응한 항목 정의를 가지고 있습니다.

이름 뒷부분의 PINT는 Peppol International의 약칭으로, OpenPeppol이 각국 공통의 원형으로서 정한 국제적인 청구 모델을 가리킵니다. 각국은 이 PINT를 바탕으로 자국 제도에 맞춘 사양을 만드는 구조이며(EU용·호주/NZ용 등이 공개되어 있습니다), 그 일본판이 JP PINT입니다. 「일본 독자 규격을 만들었다」가 아니라 「국제 모델에 일본의 세제를 옮긴 것」으로 보면 위치를 잘못 잡지 않습니다.

대상 문서는 청구서만이 아닙니다. 2026년 7월 시점에, 다음 세 종류의 사양이 공표되어 있습니다.

사양은 지속적으로 갱신되며, 디지털청의 공표에서는 2026년 6월 8일에 위 3사양 모두가 Ver. 1.1.3으로 갱신되었습니다.

「자사에서 이 사양을 읽어 구현해야 하는가」하고 긴장할 필요는 없습니다. 제8장에서 말하듯이, 많은 회사에게 JP PINT는 대응 소프트웨어 안쪽에 있는 존재이며, 직접 다루는 쪽은 소프트웨어를 개발·제공하는 측입니다.

4．디지털 인보이스에서는 무엇이 「데이터」로 흐르는가

「구조화 데이터」라고 해도 그려지기 어려우니, 한 걸음 더 구체적으로 갑니다.

디지털 인보이스에서 흐르는 항목의 중심은, 제2장에서 든 적격청구서의 기재 사항 그 자체입니다. 같은 정보라도, PDF와 데이터에서는 「그다음에 무엇을 할 수 있는가」가 전혀 다릅니다.

4.1．등록번호 대조를 자동화할 수 있다

이 표 안에서 실무상 효과가 알기 쉬운 것이 등록번호의 취급입니다.

인보이스 제도에서는, 받은 청구서의 발행자가 정말로 적격청구서발행사업자인지를 확인하기 위해, 국세청의 적격청구서발행사업자 공표 사이트에서 등록번호를 검색하는 작업이 생깁니다. PDF 청구서 운용에서는 사람이 번호를 쳐서 확인하고 있습니다.

국세청은 이 공표 시스템에 Web-API 기능을 마련해 두었으며, 지정한 등록번호의 공표 정보나 지정 기간의 갱신 정보를 시스템에서 직접 가져올 수 있습니다(이용에는 애플리케이션 ID 발행 신청이 필요합니다. 무료).

등록번호가 「PDF에 인쇄된 문자」가 아니라 「데이터 항목」으로 도착한다면, 이 대조는 시스템의 일로 만들 수 있습니다. 신규 거래처의 등록 확인이나, 기존 거래처의 등록 상태를 정기적으로 점검하는 식으로 넣는 방식입니다. 회계 소프트웨어에 따라서는 이런 대조 기능을 처음부터 갖춘 것도 있으므로, 먼저 자사 소프트웨어의 기능을 확인하고, 자사 개발 시스템에 넣고 싶을 때 Web-API를 검토하는 순서가 현실적입니다.

4.2．「읽기」에서 「검증하기」로

등록번호에 국한하지 않고, 데이터로 도착한다는 본질은 확인 작업의 성격이 바뀐다는 점입니다.

PDF 운용에서 경리의 일은 「읽고, 옮겨 적고, 눈으로 확인하는」 것이었습니다. 데이터로 도착하면 전사는 사라지고, 확인은 「시스템이 검증한 결과 가운데, 걸린 것만 본다」는 형태로 바뀝니다. 세율별 금액이 맞는지, 지급 기한은 언제인지, 과거 같은 거래처의 청구와 비교해 이상이 없는지 ── 이런 점검은 사람보다 시스템이 더 빠르고, 빠짐없이 해내는 종류의 일입니다.

5．디지털 인보이스로 무엇이 편해지는가

5.1．받는 쪽 ── 입력과 대조가 줄어든다

효과가 가장 알기 쉬운 것은, 청구서를 받는 쪽의 경리 업무입니다.

PDF 청구서의 경우, 경리 담당자는 다음과 같은 작업을 하고 있습니다.

• 메일에서 청구서를 찾아 연다
• 거래처명·금액·날짜·등록번호를 확인한다
• 회계 시스템에 입력한다
• 입력 내용을 다시 확인한다
• 지급 예정에 반영한다

디지털 인보이스에서는 청구 데이터가 시스템에 직접 들어오므로, 이 흐름의 중심에 있던 「보고, 입력하고, 확인하는」 일이 원칙적으로 필요 없어집니다. 사람의 일은 들어온 내용의 승인이나, 금액이 맞지 않음·본 적 없음 같은 예외 처리로 바뀝니다.

월말에 청구서가 몰리는 회사일수록 이 차이는 커집니다. 전사 실수나 이중 입력이 줄어드는 논리는 수발주의 EDI와 같습니다.

효과의 크기는 자사 매수로 대략 계산할 수 있습니다. 예를 들어 가령, 받은 청구서 1장당 「열고·확인하고·입력하고·다시 보는」 데 5분이 걸린다고 하면,

• 월 300장 × 5분 = 1,500분 = 월 25시간
• 연간으로는 300시간

이 양이 됩니다. 물론 이게 통째로 0이 되는 것은 아니고, 승인과 예외 처리는 남습니다. 다만 「우리 청구 업무는 전자화가 끝났다」고 여기는 회사에서도, 이 25시간의 내역을 세어 보면 그 대부분이 PDF를 보면서 하는 전사였던 일은 드물지 않습니다. 숫자는 자사 매수와 실측 소요 시간으로 바꿔 넣으시기 바랍니다. 판단 재료가 되는 것은 시간의 총량이 아니라 「그 가운데 몇 할이 전사인가」의 비율입니다.

5.2．발행하는 쪽 ── 「문서를 만들어 보내는」 공정이 사라진다

발행 쪽에서는, 판매관리 시스템이나 청구 시스템에서 만든 청구 데이터를 인쇄해 봉입·우편하거나, PDF로 변환해 메일에 첨부하는 공정이 없어집니다.

보낸 뒤의 「도착했습니까」「재송해 주세요」라는 왕래도 줄일 수 있습니다. 수신처 오류, 첨부 파일 누락, 비밀번호가 걸린 ZIP 취급처럼 메일 첨부에 따라붙는 문제에서도 멀어질 수 있습니다(메일 첨부 청구서 운용이 안은 문제는 「왜 메일 보안에서 PPAP는 안 되는가. 올바른 방법은?」에서도 다룹니다).

5.3．그 앞 ── 지급·입금 반제와의 연결

청구 정보가 구조화 데이터로 흐르게 되면, 그 앞의 업무에도 이어집니다. 구매자 쪽에서는 지급 예정 작성과 이체 데이터로의 반영, 판매자 쪽에서는 입금 반제와의 대조입니다.

이는 수발주 글에서 말한 「EDI는 수주를 입구로 재고·출하·청구까지 잇는 토대가 된다」는 이야기의, 청구 쪽에서 본 모습입니다. 주문부터 청구·지급까지를 통째로 데이터로 이었을 때, 기업 간 사무 작업은 가장 작아집니다.

6．전자장부보존법과의 관계

디지털 인보이스 이야기를 하면, 반드시 전자장부보존법(電帳法)이 옆에 나옵니다. 관계를 간단히 정리합니다.

국세청의 전자장부 등 보존 제도 안내대로, 2024년 1월 1일 이후, 청구서나 영수증 등을 전자 데이터로 주고받은 경우(전자거래), 그 데이터는 전자 그대로 보존하는 것이 의무입니다. 보존에 있어서는 크게 다음 두 가지가 요구됩니다.

• 진실성 확보 ── 타임스탬프나 정정 삭제 기록·방지 등, 위변조를 막는 조치
• 가시성 확보 ── 날짜·금액·거래처로 검색할 수 있는 상태로 두고, 화면이나 서면으로 출력할 수 있게 해 둘 것

디지털 인보이스의 수수도 전자거래에 해당하므로, 이 보존 의무의 대상입니다. 즉 디지털 인보이스를 도입한다면, 받은 데이터·보낸 데이터를 어떻게 보존할지도 동시에 정하게 됩니다.

실무상으로는 Peppol 대응 회계·청구 소프트웨어 대부분이 보존 요건에 대응하는 기능을 갖추고 있으므로, 「대응 소프트웨어를 쓰고, 그 보존 기능의 설정과 운용을 확인한다」가 기본 진행입니다. 다만 자사 보존 방법이 요건을 충족하는지의 최종 판단은 세무 영역이므로, 세무사나 관할 세무서에 확인하시기 바랍니다.

7．자주 있는 오해를 정리한다

디지털 인보이스 이야기를 할 때, 반복해서 나오는 오해가 있습니다. 먼저 정리해 둡니다.

특히 첫 번째는 중요합니다. 의무가 아닌 이상, 「대응하지 않으면 곤란하다」가 아니라 자사 청구 업무의 수고가 얼마나 줄어드는가로 도입을 판단하게 됩니다. 그래서 다음 장의 「어떻게 시작하는가」는 제도 대응이 아니라 업무 개선 이야기로 읽어 주시기 바랍니다.

한편, 거래처로부터 「디지털 인보이스로 보내 달라(받고 싶다)」는 말을 들을 가능성은 앞으로 높아집니다. 임의이기 때문에, 먼저 대응한 쪽이 거래 조건 대화를 이끄는 구도가 되는 점은, FAX에서 Web 수주로의 이행과 같습니다.

8．중소기업은 어떻게 시작하는가

8.1．현실적인 입구는 「대응 소프트웨어를 쓰는 것」

디지털 인보이스라고 하면 새로운 시스템을 구축하는 이야기로 들리지만, 많은 중소기업에게 현실적인 입구는 이미 쓰고 있는(또는 앞으로 고를) 회계·청구 소프트웨어가 Peppol에 대응하는지 확인하는 것입니다.

EIPA는 Peppol 디지털 인보이스에 대응이 끝난 서비스 목록을 공표하고 있습니다. 또한 디지털청은 일본에서의 인정 Peppol 서비스 프로바이더 목록을 공개하고 있습니다. 자사 소프트웨어가 대응하고 있다면, 큰 개발 없이 송수신을 시작할 가능성이 있습니다.

목록을 열기 전에, 「자사가 확인해야 할 것은 어떤 종류의 소프트웨어인가」를 정리해 두면 헤매지 않습니다. 디지털 인보이스에 관여하는 소프트웨어·서비스는 대략 다음 범주로 나뉩니다.

많은 중소기업에게 가장 짧은 경로는, 이미 쓰는 회계 소프트웨어나 청구서 발행 서비스의 옵션 기능으로 시작할 수 있는지를 먼저 확인하는 것입니다. 새 서비스를 하나 계약하는지, 기존 계약 범위로 충분한지가 이야기의 규모를 완전히 바꿉니다.

확인 순서는 다음과 같습니다.

1. 자사의 회계·청구 소프트웨어가 Peppol(디지털 인보이스)에 대응하는가
2. 대응하는 경우, 송신·수신 중 어디에 대응하는지, 이용 요금은 어떠한가
3. 주요 거래처가 받을 수 있는 상태에 있는가(상대 쪽에도 대응 소프트웨어나 서비스가 필요)
4. 받은 데이터의 보존(전자장부보존법 대응)이 소프트웨어 쪽에서 어떻게 다루어지는가

2번의 「이용 요금」은 서비스마다 과금 형태가 달라, 금액만 늘어놓아도 비교가 되지 않습니다. 시세로 일률 제시할 숫자는 없으므로, 다음 항목이 견적의 어디에 들어 있는지를 맞춘 뒤에 비교하시기 바랍니다.

• 초기 비용(설정·등록 작업비)이 있는가
• 월 기본 요금에 송신·수신 중 어디까지 포함되는가
• 건수 상한과, 초과분의 과금이 있는가
• 전자장부보존법에 대응한 보존 기능은 기본 요금 안인가, 별도 요금인가
• 자사 시스템과의 CSV 연계나 API 연계는 표준 기능인가, 개별 대응(개발비)인가

기존 소프트웨어의 옵션으로 시작할 수 있는 경우와, 액세스 포인트 사업자와 직접 계약하는 경우는 비용의 자릿수가 달라집니다. 우선 전자로 부족한지를 확인하는 것이 순서입니다.

8.2．자사 개발 시스템이 있는 경우

판매관리나 청구 관리를 자사 개발 시스템으로 운용하는 회사에서는, 한 단계 더 검토가 필요합니다.

그렇다고 JP PINT 사양서를 읽어 스스로 Peppol 액세스 포인트에 접속한다는 이야기로 보통은 가지 않습니다. 현실적인 것은 다음과 같은 구성입니다.

• 자사 시스템에서 청구 데이터를 CSV나 API로 Peppol 대응 청구 서비스·회계 소프트웨어에 넘기고, 송신은 그쪽에 맡긴다
• 수신도 대응 소프트웨어 쪽에서 하고, 가져온 데이터를 자사 시스템으로 연계한다

즉 자사 시스템의 수정 지점은 「Peppol 대응」 자체가 아니라, 대응 소프트웨어와의 사이에서 데이터를 정확히 주고받는 연계 부분입니다. 여기는 수발주의 Web 이행에서 말한 「CSV 가져오기라는 중간 형태」(「FAX 수주를 Web으로 옮기려면」)와 완전히 같은 생각으로 설계할 수 있습니다.

8.3．서두를 필요는 없지만, 무시하지도 않는다

디지털 인보이스는 2026년 시점에 「쓰지 않으면 업무가 멈춘다」는 것이 아닙니다. 거래처가 PDF 청구서를 원하면, 당분간은 PDF와의 병용이 이어집니다. 수발주의 FAX·Web 병용과 같이, 이행은 단계적으로 진행됩니다.

한편, 규모가 큰 거래처나 지자체·관공서와의 거래에서 디지털 인보이스 이용이 화제가 되는 장면은 앞으로 늘어갑니다. 디지털청도 정부 조달이나 기업 간 거래에서의 활용 사례 공표를 진행하고 있습니다. 「거래처가 요구했을 때, 자사 소프트웨어로 받을 수 있는가」를 한 번 확인해 두는 것만으로도, 대비로서는 충분히 의미가 있습니다.

8.4．검토 우선도를 판단하는 체크리스트

「우리는 언제 움직여야 하는가」의 기준으로, 다음 항목에 해당할수록 검토 우선도는 높아집니다.

• 청구서의 수령·발행이 월에 수십 장 이상 있다
• 월말 월초에, 청구서 입력·대조·발행 작업으로 경리가 잔업하고 있다
• 받은 청구서의 등록번호 확인을 수작업으로 하고 있다
• 입력 실수나 이중 지급의 아찔한 경험이 있다
• 주요 거래처나 업계 단체에서, 디지털 인보이스나 Peppol 이야기가 나오기 시작했다
• 마침 회계·청구 소프트웨어 교체나, 자사 개발 시스템 수정을 계획하고 있다

반대로, 청구서가 월에 몇 장이고 거래처도 고정적이라면, 서두를 이유는 없습니다. 소프트웨어 갱신 시기에 「다음 소프트웨어는 Peppol 대응인가」를 선정 조건에 더해 두는 정도로 충분합니다.

중요한 것은, 도입 자체를 목적으로 하지 않는 것입니다. 제4장·제5장에서 든 「어떤 수작업이 줄어드는가」를 자사 업무에 대입해 세었을 때, 줄어드는 작업이 구체적으로 보이면 진행할 가치가 있고, 보이지 않으면 시기상조, 그뿐입니다.

9．수발주 디지털화의 전체 지도 안에서

이 글은 수발주 주변의 데이터 연계를 다루는 시리즈의 세 번째입니다. 전체의 위치 관계를 정리해 둡니다.

EDI가 「기업 간 데이터 교환」이라는 큰 생각이고, 그 수주 쪽의 실천이 FAX 수주의 Web 이행, 청구 쪽의 표준화된 형태가 디지털 인보이스, 라는 관계입니다.

어디부터 손을 대야 하는지는 회사마다 다릅니다. 수주 입력의 부담이 크면 수주 쪽부터, 청구서 발행·수령 매수가 많으면 청구 쪽부터, 가 솔직한 판단입니다. 공통되는 것은, 「같은 정보를 사람이 몇 번 입력하고 있는가」를 세는 곳에서 시작한다는 점입니다.

정리

• 디지털 인보이스란, 청구 정보를 판매자의 시스템에서 구매자의 시스템으로, 사람을 거치지 않고 직접 데이터 연계하여 자동 처리하는 구조입니다
• PDF 청구서는 문서의 「전자화」이며, 받는 쪽의 입력 작업은 남습니다. 디지털 인보이스는 구조화 데이터로 업무를 잇는 「디지털화」입니다
• 인보이스 제도(세제)와 디지털 인보이스(데이터 교환의 구조)는 별개의 이야기입니다. 제도 대응이 끝났어도, 디지털 인보이스 이용은 이제부터인 회사가 대부분입니다
• 토대는 Peppol이라는 국제 표준이며, 일본에서는 디지털청이 Peppol Authority로서 관리하고, 일본 표준 사양으로 JP PINT를 공표하고 있습니다
• 액세스 포인트를 거치는 4코너 모델에 의해, 상대와 다른 소프트웨어를 쓰더라도 주고받을 수 있는 점이, 기존의 개별 EDI와의 차이입니다
• 흐르는 것은 적격청구서의 기재 사항 그 자체입니다. 등록번호 대조(국세청 공표 시스템의 Web-API)나 세율별 금액 검산 등, 사람이 눈으로 하던 확인을 시스템의 검증으로 바꿀 수 있습니다
• 받은 디지털 인보이스는 전자장부보존법의 전자거래에 해당하며, 전자 데이터 그대로의 보존이 필요합니다
• 이용은 임의이며, 의무가 아닙니다. 「대응하지 않으면 곤란하니까」가 아니라, 자사 청구 업무에서 어떤 수작업이 줄어드는가로 판단합니다
• 중소기업의 현실적인 입구는 Peppol 대응 회계·청구 소프트웨어의 이용입니다. 자사 개발 시스템이 있는 경우는, 대응 소프트웨어와의 데이터 연계 부분을 설계합니다

청구 업무·수발주의 데이터 연계를 검토하시는 분께

청구서 발행이나 수령의 사무 부담을 줄이고 싶지만, 자사 판매관리 시스템이나 청구 업무의 어디부터 손을 대면 될지 모를 때는, 먼저 현재 청구 데이터의 흐름을 정리할 필요가 있습니다.

판매관리 시스템에서 어떻게 청구 데이터를 만들고, 어떻게 거래처로 보내며, 받은 청구서를 어떻게 회계 시스템에 입력하고 있는지를 확인하면, 디지털 인보이스나 대응 소프트웨어와의 연계로 자동화할 수 있는 범위가 보입니다.

合同会社小村ソフト에서는, 자사 개발 업무 시스템과 회계 소프트웨어·Peppol 대응 서비스와의 연계를 포함해, 청구·수발주 주변의 데이터 연계에 대해 현황 정리나 실현 방법 검토를 상담하실 수 있습니다.

전면 개편을 전제로 하지 않고, 현재 구조를 남기면서, 데이터의 출입구만 단계적으로 잇는 구성도 검토할 수 있습니다.

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

디지털 인보이스와 전자 인보이스(PDF 청구서)는 무엇이 다른가요?

PDF 청구서는 사람이 읽기 위한 문서를 전자 파일로 만든 것으로, 받는 쪽은 내용을 보면서 회계 시스템에 다시 입력해야 합니다. 디지털 인보이스는 청구 정보 자체를 표준화된 구조화 데이터로 보내기 때문에, 구매자의 시스템이 직접 가져와 처리할 수 있습니다. 종이를 파일로 바꾸는 '전자화'와, 업무 처리를 데이터로 연결하는 '디지털화'의 차이입니다.

인보이스 제도에 대응이 끝났다면 디지털 인보이스에도 대응이 되어 있는 건가요?

별개의 이야기입니다. 인보이스 제도(적격청구서 등 보존방식)는 소비세의 매입세액공제에 관한 세제상의 제도로, 적격청구서는 종이로도 PDF로도 교부할 수 있습니다. 디지털 인보이스는 그 청구 정보를 시스템 간에 주고받기 위한 데이터 형식과 유통 구조(Peppol·JP PINT)로, 제도 대응과는 별개로 이용할지 여부를 판단하는 것입니다.

중소기업이 디지털 인보이스를 사용하기 시작하려면 무엇이 필요한가요?

현실적인 입구는 Peppol에 대응하는 회계·청구 소프트웨어를 사용하는 것입니다. 디지털 인보이스 추진 협의회(EIPA)가 대응이 끝난 서비스 목록을 공표하고 있으며, 자사가 사용 중인 소프트웨어가 대응하고 있다면 설정을 활성화하는 것만으로 송수신을 시작할 수 있는 경우도 있습니다. 자사 개발 판매관리 시스템을 사용하는 경우에는 대응 소프트웨어나 서비스 프로바이더와의 연계 방법을 검토하게 됩니다.

받은 디지털 인보이스는 어떻게 보존해야 하나요?

디지털 인보이스의 수수는 전자장부보존법상의 전자거래에 해당하므로, 2024년 1월 이후에는 전자 데이터 그대로, 위변조 방지 조치(진실성 확보)와 날짜·금액·거래처로 검색할 수 있는 상태(가시성 확보)를 충족하여 보존해야 합니다. 많은 Peppol 대응 소프트웨어가 보존 요건에 대응하는 기능을 갖추고 있지만, 자사의 운용이 요건을 충족하는지는 세무사나 관할 세무서에 확인하시기 바랍니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.