목 차 1. 지침의상태및개요 지침의상태 연혁 작성자 감수자 지침의개요 목적 적용범위 대상 구성 관련규격 4 2. 전

Transcription

1 표준전자 ( 세금 ) 계산서 (v3.0) 개발지침 v

2 목 차 1. 지침의상태및개요 지침의상태 연혁 작성자 감수자 지침의개요 목적 적용범위 대상 구성 관련규격 4 2. 전자 ( 세금 ) 계산서프로세스 개요 전자 ( 세금 ) 계산서발급프로세스 시스템구성개요 전자 ( 세금 ) 계산서발급 전자 ( 세금 ) 계산서재발급 전자 ( 세금 ) 계산서전송권장기한 전자 ( 세금 ) 계산서구문구조 국세청연동프로세스 국세청연동개요 연동프로세스 전자 ( 세금 ) 계산서항목 표준정의절차 전자 ( 세금 ) 계산서전자문서항목 전자 ( 세금 ) 계산서전자문서항목 관리정보 (ExchangedDocument) 전자 ( 세금 ) 계산서전자문서항목 전자서명 (Signature) 전자 ( 세금 ) 계산서전자문서항목 기본정보 (TaxInvoiceDocument) 전자 ( 세금 ) 계산서전자문서항목 거래처정보-공급자 (InvoicerParty) 전자 ( 세금 ) 계산서전자문서항목 거래처정보-공급받는자 (InvoiceeParty) 전자 ( 세금 ) 계산서전자문서항목 거래처정보-수탁사업자 (BrokerParty) 전자 ( 세금 ) 계산서전자문서항목 결제정보 -결제방법별금액 (SpecifiedPaymentMeans) 전자 ( 세금 ) 계산서전자문서항목 결제정보 -Summary(SpecifiedMoneySummation) 전자 ( 세금 ) 계산서전자문서항목 상품정보 (TaxInvoiceTradeLineItem) 30

3 4. 국세청응답문서 개요 응답문서구조 전자 ( 세금 ) 계산서접수증 처리결과문서 국세청응답문서코드표 처리상태코드 전송메시지처리실패원인코드 처리결과코드 응답문서코드 문서보안 개요 수행주체 주요표준 본인확인방법 전자 ( 세금 ) 계산서서명및암호화업무흐름 전자서명 개요 XML 정규화 알고리듬 전자서명의대상 전자서명수행및검증정보추가 XML 전자서명의예 전자서명의검증 암호화 개요 암호화대상데이터 EnvelopedData의구성 EnvelopedData의생성 메시지에대한 OID 정의 암호화알고리듬 국세청인증서의획득과검증 EnvelopedData의구성 전자 ( 세금 ) 계산서통신 개요 통신규약표준의범위 통신프로세스및메시지구조 62

4 통신프로세스개요 전자 ( 세금 ) 계산서송 / 수신처리절차 메시지기본구조 업무별 Request, Response data 및첨부문서구조 송수신문서코드표 전송보안 전송보안개요 메시지전자서명항목 75

5 부록 78 A. 전자문서유형별항목표 78 A.1. KEC표준전자 ( 세금 ) 계산서 v3.0 항목표 78 A.2. 국세청응답문서항목표 83 B. 전자 ( 세금 ) 계산서관련표준문서 (Schema) 및예제 84 B.1. 표준전자 ( 세금 ) 계산서루트스키마 (TaxInvoiceSchemaModule_1.0).xsd 84 B.2. 국세청응답문서루트스키마 (TaxInvoiceResponseSchemaModule_1.0).xsd 86 B.3. 재사용 ABIE 스키마 (ReusableAggregateBusinessInformationEntitySchemaModule_1.0.xsd) 88 B.4. 한정데이터타입스키마 (QualifiedDataTypesSchemaModule_1.0).xsd 97 B.5. 코드리스트스키마 (CodeListSchemaModule_1.0).xsd 131 B.6. 전자 ( 세금 ) 계산서샘플문서 147 B.7. 국세청응답문서중접수증샘플문서 153 B.8. 국세청응답문서중처리결과샘플문서 154 C. 메시지예제및관련 WSDL 156 C.1. 전자 ( 세금 ) 계산서제출메시지예제 156 C.2. 전자세금계산서제출처리 WSDL 161 C.3. 전자 ( 세금 ) 계산서처리결과전송 WSDL 166 C.4. 전자 ( 세금 ) 계산서처리결과요청 WSDL 171 D. 용어정의 176 D.1. 용어목록 176 D.2. 약어목록 178

6 1. 지침의상태및개요 1.1. 지침의상태 연혁 이지침은국세청이제안하여한국전자문서표준위원회 (KEC) 산하공통 ( 전자세금계산서 ) 표준화그룹 (SG) 에서, UN/CEFACT/TRADE/22의공개개발프로세스 (Open Development Process) 에따라개발하였다. 이지침은정보통신산업진흥원에서개발한 XML 전자문서개발지침 v3.5에서제시하고있는방법론을완전히준용하였다. 이지침은부가가치세법및소득세법, 법인세법에의거, 사업자가전자 ( 세금 ) 계산서를국세청에신고하기위하여시스템을개발할때, 사용자의편의성을높이고이해를쉽게하기위하여개발되었다. 현재버전 : KEC 표준전자 ( 세금 ) 계산서 (v3.0) 개발지침 v 작성자 소속직급성명 국세청사무관최원봉 cbj1195@nts.go.kr 국세청사무관함민규 ham2160@nts.go.kr 케이엘넷부장안경림 krahn@klnet.co.kr 토피도상무이정남 jnlee@torpedo.co.kr 훈솔루션대표심재훈 neolook@gmail.com SK C&C 부장이충섭 shortpig@skcc.com SK C&C 차장최정 chj71@skcc.com 정보통신산업진흥원책임이경록 lkr0211@nipa.kr 연락처 : 한국인터넷진흥원, 전자문서유통팀,

7 감수자 소속직급성명 국세청분석관이승신 국세청분석관이현진 국세청조사관강준원 노틸러스효성과장김삼진 토피도팀장이윤수 한양사이버대학교교수박찬권 SK C&C 위원김범중 SK C&C 부장문신철 정보통신산업진흥원단장강현구 정보통신산업진흥원팀장이중구 정보통신산업진흥원수석강동현 정보통신산업진흥원책임이상타 - 2 -

8 1.2. 지침의개요 목적 본지침은사업자가 KEC표준전자 ( 세금 ) 계산서 v3.0에기반을두고전자 ( 세금 ) 계산서시스템의개발과정에실제적으로적용할수있는기준과절차를제공하기위한것이다. 본지침은국내전자 ( 세금 ) 계산서시스템개발자들에게시스템개발에필요한세부절차와방법을제공함으로써, 보다효과적인전자 ( 세금 ) 계산서시스템의개발을지원하고자한다 적용범위 본지침은부가가치세법및소득세법, 법인세법에의거하여시스템사업자 ( 이하 사업자 라 한다 ) 가국세청신고를위하여개발하는전자 ( 세금 ) 계산서시스템에대해적용한다 대상 본지침은국내전자 ( 세금 ) 계산서시스템개발및운영업체, 기타의이해관계자들을대상으로하며, 본지침에앞서아래관련규격에제시된 KEC XML 전자문서개발지침 v3.5" 등관련기술규격을먼저읽을것을권고한다. 본지침과관련해서문의나교육이필요한경우에는앞서기술된연락처를이용한다 구성 본지침은 6개의장과부록으로구성되었으며, 본문에서는개발에직접관련된내용을기술하고, 부록에서는개발과간접적으로관련된사항을기술하고있다. 개발과직접관련된부분은 전자 ( 세금 ) 계산서프로세스, 전자 ( 세금 ) 계산서항목, 전자 ( 세금 ) 계산서보안관련지침, 그리고 전자 ( 세금 ) 계산서통신 등으로이루어진다. 2장에서는전자 ( 세금 ) 계산서생성에서국세청신고까지의전체프로세스에대해기술하고있다. 3장에서는사업자가국세청에전송하기위한전자 ( 세금 ) 계산서의각항목에대해기술하고있다. 4장에서는국세청에서사업자에게전송하는응답문서 ( 접수증, 결과통보 ) 의각항목에대해기술하고있다. 5장에서는전자 ( 세금 ) 계산서보안 ( 전자서명, 암호화등 ) 관련지침에대하여기술하고있다. 6장에서는사업자와국세청간에전자 ( 세금 ) 계산서및관련전자문서의송 수신방법과그에이용되는메시지구조에대해기술하고있다. 부록에서는본지침과관련된제반참고자료가제공된다

9 관련규격 KEC XML 전자문서개발지침 v3.5, 정보통신산업진흥원, 2008 KEC 표준전자 ( 세금 ) 계산서 v3.0, 2009 KEC CCL08, 정보통신산업진흥원, 2008 Core Component Technical Specification v2.01, UN/CEFACT TMG, 2003 XML Naming and Design Rule, UN/CEFACT ATG, 2004 Data Type Catalogue v2.1, UN/CEFACT ATG, 2008 XML Signature Syntax and Processing, W3C/IETF, 2002 Simple Object Access Protocol v1.1, W3C, 2000 Simple Object Access Protocol v1.2, W3C, 2007 SOAP Message with Attachment, W3C, 2000 Web Service Addressing v1.0-core, W3C, 2006 Web Service Security v1.1, OASIS, 2004 Cryptographic Message Syntax, IETF, 비트블록암호알고리듬 SEED, TTA, 비트블록암호알고리듬 ARIA, KS,

10 2. 전자 ( 세금 ) 계산서프로세스 2.1. 개요 부가가치세법제32 조에는사업자가전자적인방법으로세금계산서를발급하여국세청에전송하는전자세금계산서제도의내용이포함되어있다. 법인사업자와발급의무자인개인사업자는대통령령으로정하는전자적방법에의해세금계산서 (" 전자세금계산서 ") 를발급하여야만한다. 또한, 소득세법시행령 211조의2에는사업자가전자적인방법으로계산서를발급할수있도록하는전자계산서제도의내용이포함되어있다. 이에따라관련법령에서계산서를발급할수있는사업자는전자적방법에의해계산서 (" 전자계산서 ") 를발급할수있다. 전자 ( 세금 ) 계산서는공급사업자와공급받는자사이에발생하는상거래에의해업무가처리될때, 상호간의지불에대한업무를처리하는과정에서기발급하는 ( 세금 ) 계산서를전자적으로발급하는경우에사용되는전자문서를의미한다. 본장에서는공급사업자와공급받는자또는수탁사업자와공급받는자사이에발급되는전자 ( 세금 ) 계산서발급프로세스와발급된전자 ( 세금 ) 계산서를국세청으로전송하는처리프로세스를설명한다. 전자 ( 세금 ) 계산서업무에사용되는전자문서는 ebxml 스키마형태이며국제표준과국내표준을기반으로정의하였다. 사용되는표준규격으로는 CCTS v2.0.1과 XML NDR 그리고 UN/CEFACT CCL08A와 KEC XML 전자문서개발지침 v3.5, KEC CCL08이있다. 전자 ( 세금 ) 계산서를발급하는공급사업자 ( 또는대행사업자 ) 와국세청사이의데이터교환을위한통신규약은웹서비스에서권고하는표준통신규약 SOAP v1.1과 v1.2를채택하였다. 이에본장에서도전자 ( 세금 ) 계산서처리프로세스를정의하기위해국내표준으로정의된사항을기반으로작성하였다. 전자 ( 세금 ) 계산서를발급하는시스템은사용자가자체적으로시스템을보유하고발급하는경우와 ASP 서비스를사용하는경우로구분하였다

11 2.2. 전자 ( 세금 ) 계산서발급프로세스 시스템구성개요부가가치세법및소득세법에의해사업자가전자 ( 세금 ) 계산서를발급하기위한시스템의기본구성은다음 [ 그림 2-1] 과같다. [ 그림 2-1] 전자 ( 세금 ) 계산서시스템구성예 발급시스템은크게 3가지로구분할수있다. (1) 전자 ( 세금 ) 계산서를작성하기위해 KEC 표준전자 ( 세금 ) 계산서 v3.0을생성하기위한모듈과전자 ( 세금 ) 계산서의신뢰성을위한전자서명모듈 (2) 사업자와국세청간안정적이고신뢰할수있는통신을위해암호화, WS-Security 그리고 SOAP 엔진 (3) 전자 ( 세금 ) 계산서데이터를보관하기위한데이터베이스와전자서명및암호화를위한사업자의공인인증서필요한모듈과 S/W 그리고 H/W는사업자및사용자의환경에따라구성하면되고시스템및소프트웨어의구성또한환경에따라다양하게조직될수있다. 사업자가전자 ( 세금 ) 계산서를발급하는경우발급되는전자 ( 세금 ) 계산서는 XML 형식이여야하며, UTF-8 인코딩을기본으로한다 전자 ( 세금 ) 계산서발급전자 ( 세금 ) 계산서를발급하는사용자는자체적으로시스템을보유하고발급하는경우와 ASP 서비스를사용하는경우로구분할수있다. 먼저 [ 그림 2-2] 와같이자체시스템을보유하고있는사용자의경우이다

12 [ 그림 2-2] 자체시스템보유사용자전자 ( 세금 ) 계산서발급 회사내부사용자는자체회계시스템의클라이언트프로그램을이용하여자사정보시스템에데이터를입력한다. 담당자가입력한후즉시전자 ( 세금 ) 계산서를발급하거나관리자승인후에발급할수도있다. 관리자는승인요청된내용을검토한후이상이없다고판단되면승인작업을하게된다. 승인이완료된전자 ( 세금 ) 계산서는본격적으로전자적발급프로세스를거치게된다. 본지침에서는담당자가데이터를 ERP 등에입력하고, 관리자가승인한후에전자 ( 세금 ) 계산서를발급하는것으로간주한다. 입력된데이터에대해 KEC 표준전자 ( 세금 ) 계산서v3.0 문서로생성한다. 이때, 생성된전자 ( 세금 ) 계산서문서에는전자서명법에근거한법적효력을부여하고데이터의무결성과발급자의인증을보장하기위해전자서명이포함되어야한다. 전자서명은전자 ( 세금 ) 계산서원문에해시함수를적용함으로써얻어진해시값에, 다시공급사업자의개인키를사용한전자서명을수행함으로써이루어진다. 마지막으로생성된전자서명은전자 ( 세금 ) 계산서에다시포함되어공급받는자에게발급한다

13 [ 그림 2-3] ASP 서비스사용자전자 ( 세금 ) 계산서발급 다음은 [ 그림 2-3] 에보이는것처럼 ASP 서비스를이용하는사용자의경우이다. ASP 서비스사용자는웹브라우저를통하여해당 ASP 서비스시스템에접속한다음전자 ( 세금 ) 계산서발급페이지로이동한다. 이때거래내역을신규로입력하여발급할수도있고기존에발급된전자 ( 세금 ) 계산서내용을수정하여발급할수도있다. 여기서는신규입력에의해발급하는경우에대해설명하겠다. 공급받는자형태는다시 ASP 서비스를사용하는경우와자체시스템을보유한경우로구분할수있다. 먼저자체시스템을보유한경우, 서명이포함된전자 ( 세금 ) 계산서를수신받은공급받는자는서명을생성한공급사업자를인증하고데이터무결성을위해전자서명을검증할수있다. [ 그림 2-4] 는이러한흐름을보여주고있다. 즉전자서명을제외한전자 ( 세금 ) 계산서원문에공급사업자와동일한해시함수를적용해서얻어진해시값과, 전자서명을공급자의공개키로복호화해서얻어진해시값을비교한다. 이두해시값이동일할경우전송도중변조가없었다는것과정당한사용자로부터발급되었다는것을확인할수있다

14 [ 그림 2-4] 자체시스템보유사용자전자 ( 세금 ) 계산서검증 공급받는자가 ASP 서비스를사용하는사용자일경우는 [ 그림 2-5] 와같이 ASP 서비스시스템에접속하여발급된전자 ( 세금 ) 계산서의수신여부및상세내역을확인하고수신된전자 ( 세금 ) 계산서의무결성등을확인하기위하여전자서명을검증할수있다. 전자서명을검증하기위하여서는전자서명을제외한전자 ( 세금 ) 계산서원문에공급자와동일한해시함수를적용해서얻어진해시값과전자서명을공급사업자의공개키로복호화해서얻어진해시값을비교한다. 이두해시값이동일할경우전송도중변조가없었다 ( 데이터무결성 ) 는것과정당한사용자로부터발급되었다 ( 공급자인증 ) 는것을확인할수있다

15 [ 그림 2-5] ASP 서비스사용자전자 ( 세금 ) 계산서승인 전자 ( 세금 ) 계산서재발급부가세법령에따라세금계산서를발급하는공급자는전자서명이포함된전자세금계산서를공급받는자에게발급하고국세청에전송하여야만하며, 소득세법, 법인세법에따라전자서명이포함된전자계산서를발급한경우에는국세청에전송할수있다전자 ( 세금 ) 계산서재발급프로세스는국세청에서전자서명이포함된전자 ( 세금 ) 계산서를수신한후검증한결과, 오류가존재하는경우에해당한다. 공급자로부터수신한전자 ( 세금 ) 계산서에대해 XML 스키마검증, 전자 ( 세금 ) 계산서항목검증, 전자서명및암호화검증등에대해서오류가발생할경우국세청시스템은공급사업자 ( 전송사업자 ) 에게오류내역을통지한다. 오류통지된경우에는전자 ( 세금 ) 계산서가발급된것으로보지아니한다. 국세청에전송한전자 ( 세금 ) 계산서중오류내역이통지된전자 ( 세금 ) 계산서는오류원인을제거하여관련법령기한 ( 익월 10일 ) 내에재발급하여국세청에전송하여야한다. 발급마감일에전송하여오류가발생하여오류내역이통지된전자세금계산서는가산세대상이될수있으므로지침 2.2.4절에서설명하는발급및전송권장기한을참고하여야만한다. 또한재발급절차는지침2.2.2절에서설명한전자 ( 세금 ) 계산서발급프로세스를따른다

16 전자 ( 세금 ) 계산서발급및전송기한사업자가전송한전자 ( 세금 ) 계산서를국세청시스템의검증에의해오류를포함하지않는경우에한해정상적인전자 ( 세금 ) 계산서로접수되고, 비로소전송이완료된것으로간주된다. 이때부가가치세법에따라, 전자세금계산서는재화또는용역의공급시기 ( 표준전자 ( 세금 ) 계산서 v3.0의작성일자 ) 를기준으로익월 10일까지발급되어야하며, 발급된전자세금계산서는발급일의다음날까지전송되어야한다. 단, 발급기한및전송기한이토요일또는공휴일인경우에는그다음날로연장된다. 한편국세청시스템으로부터검증결과통보는사업자가전자 ( 세금 ) 계산서를전송한익일이후에이루어질수있으므로, 검증결과에따라전자 ( 세금 ) 계산서의재발급프로세스가수반될경우발급마감기한내에발급이완료될수없는경우가발생할수있다. 따라서발급기한을넘기지않도록사업자는익월 7일까지는전자세금계산서를발급하고발급즉시전송할것을권고한다. 또한국세청이전자 ( 세금 ) 계산서의전자서명값을검증하는시점 ( 전송일자기준익일 ) 에전자서명을수행한인증서가유효하지않으면정상적인세금계산서가될수없으므로사업자는전자 ( 세금 ) 계산서발급시전자서명을수행한인증서의유효기간관리를철저히할것을권고한다 전자 ( 세금 ) 계산서구문구조전자 ( 세금 ) 계산서는자체발급시스템또는 ASP 서비스시스템에서발급되며공급사업자의공인인증서로생성한전자서명을포함하는전자문서이다. 다음 [ 그림 2-6] 은전자 ( 세금 ) 계산서문서가생성된후, 전자서명을생성하고생성된전자서명을다시전자 ( 세금 ) 계산서원문내에포함시키는흐름과문서구조를보여주고있다. [ 그림 2-6] 전자 ( 세금 ) 계산서구문구조

17 2.3. 국세청연동프로세스 국세청연동개요부가가치세법에따라공급자는공급받는자에게전자세금계산서를발급하고그원본을국세청에전송하여야만하며, 소득세법또는법인세법에따라공급받는자에게전자계산서를발급한경우국세청에전송할수있다 연동프로세스 사업자와국세청간연동을위해사업자가국세청에전자 ( 세금 ) 계산서를전송하는프로세스는 다음 [ 그림 2-7] 전자 ( 세금 ) 계산서전송프로세스 와같다. [ 그림 2-7] 전자 ( 세금 ) 계산서전송프로세스 전송프로세스의각단계를살펴보면다음과같다. 전자 ( 세금 ) 계산서전송프로세스는 1 전자 ( 세금 ) 계산서전송단계, 2 처리결과 수신단계, 3 처리결과수신단계 ( 선택적방안 ) 라는 3 가지프로세스의조합으로 이루어진다. 여기서각단계는다음과같이구성된다

18 "1 전자 ( 세금 ) 계산서전송단계 ": 전자 ( 세금 ) 계산서제출 ( 전자 ( 세금 ) 계산서첨부 ) 과수신확인메시지 ( 접수증첨부 ) 수신이라는 2개의동기식트랜잭션으로구성 "2 처리결과수신단계 ": 처리결과메시지 ( 처리결과문서첨부 ) 수신과수신확인메시지전송이라는 2개의동기식트랜잭션으로구성 3 처리결과수신단계 ( 선택적방안 ) : 처리결과요청메시지전송과처리결과메시지 ( 처리결과문서수신 ) 수신이라는 2개의동기식트랜잭션으로구성 ( 단, 처리결과요청서비스는과세기간이내의접수완료된메시지에한함 ) 프로세스의각단계들은별도의트랜잭션으로처리가된다. 다시말해전자 ( 세금 ) 계산서전송단계가끝나면사업자는통신을끊고각자업무처리를하다가처리수신이필요한시점에다시통신을연결하고메시지를주고받게된다는의미이다. 사업자가처리결과를국세청으로부터수신할수있는환경이면처리프로세스는다음과같은조합으로이루어질수있다. - 1 전자 ( 세금 ) 계산서전송단계 2 처리결과수신단계 - 위의프로세스를기본으로하나, 처리결과수신시한이지난후에도처리결과를수신하지못한경우에는 3 처리결과수신단계 ( 선택적방안 ) 에의해사업자는국세청에처리결과를전송해줄것을요청하여받을수있다.( 다만, 3 처리결과수신단계 ( 선택적방안 ) 는전송권장기한 ( 익월 7일 ) 이후에는허용하지않는다 ) - 처리결과수신시한은전자 ( 세금 ) 계산서전송성공후익일을의미한다. 사업자가처리결과를국세청으로부터수신할수있는환경이아닌경우에는사업자의처리프로세스는다음과같은조합으로이루어질수있다. - 1 전자 ( 세금 ) 계산서전송단계 3 처리결과수신단계 ( 선택적방안 ) 에의해국세청에처리결과를전송해줄것을요청하여수신하거나국세청전자 ( 세금 ) 계산서관련홈페이지에서처리결과를확인할수있다.( 다만, 3 처리결과수신단계 ( 선택적방안 ) 는전송권장기한 ( 익월 7일 ) 이후에는허용하지않는다 ) - 처리결과수신시한및홈페이지확인은상기된시한과동일하다. 국세청으로부터문서를수신할수있는환경이아닌경우 : 1) 사업자가고정 IP를확보하지못한경우, 2) 방화벽등사업자의보안정책에의하여국세청에서오는메시지통로가차단된경우, 3) 실시간으로메시지를받을수있도록서버운영을할수없는경우등 사업자 à 국세청전송 1) 전자 ( 세금 ) 계산서제출부가가치세법에따른공급자는공급자의인증서로생성된전자서명이포함된전자세금계산서를발급하여다음날까지국세청으로전송하여야만하며, 소득세법또는법인세법에따라공급자의인증서로생성된전자서명이포함된전자계산서를발급한경우다음날까지국세청에전송할수있다국세청으로전송하기위해서는국세청에서제시하는표준규약을준수하여야만한다. 전자서명이포함된전자 ( 세금 ) 계산서를국세청으로전송하기전에표준에서규정한암호화알고리듬을사용하여콘텐츠암호화를하여야한다

19 표준통신규약은웹서비스의메시징표준인 SOAP v1.1 또는 v1.2를채택하였으며, 하부네트워크로 HTTP 통신을사용한다. 또한통신상안전하고신뢰할수있는전송을보장하기위해 WS-Security규약을채택하였다. 자체발급사업자또는 ASP 사업자는발급된전자 ( 세금 ) 계산서를국세청으로전송하기위해전자 ( 세금 ) 계산서를 SOAP 메시지로 Enveloping하여야한다. SOAP 메시지의헤더에는전송하는사업자에대한정보와수신자인국세청을명시하며, 그외에메시지전송시간, 업무명및메시지유형정보등을포함하고있다. 전자서명이포함된전자 ( 세금 ) 계산서는표준에서규정한암호화알고리듬을사용하여콘텐츠암호화를하고, 암호화된전자 ( 세금 ) 계산서는 SOAP 메시지의첨부문서로구성된다. 또한사업자와국세청간의안전하고신뢰할수있는전송을보장하기위해 WS-Security를사용하여야만한다. 즉, 사업자의공인인증서로전자서명을생성하고이를 SOAP 헤더에포함한다. 사업자와국세청에전자 ( 세금 ) 계산서를전송하고국세청이처리하여사업자에게통보하는처리절차를도식화하면다음 [ 그림 2-8] 전자 ( 세금 ) 계산서전송절차 와같다. [ 그림 2-8] 전자 ( 세금 ) 계산서전송및처리절차 각단계별로설명을하면다음과같다. 사업자가국세청에전자 ( 세금 ) 계산서를전송하는단계 - 1단계 : 전자 ( 세금 ) 계산서표준문서규약에맞게문서를생성한다.( 3. 전자 ( 세금 ) 계산서항목 부분참조 ) - 2단계 : 각전자 ( 세금 ) 계산서는발급사업자의공인인증서로전자서명을한다.( 5. 전자 ( 세금 ) 계산서보안관련지침 부분참조 )

20 - 3단계 : 전송하고자하는 1~100개의전자서명된전자 ( 세금 ) 계산서를하나의묶음으로하여한번에비밀키 ( 대칭키 ) 로암호화가되며, 비밀키는국세청의공개키로암호화되어교환된다.( 5. 전자 ( 세금 ) 계산서보안관련지침 부분참조 ) - 4단계 : 암호화된전자 ( 세금 ) 계산서묶음은 SOAP Message with Attachment 규약에따라 SOAP메시지의첨부로추가된다. 사업자는전송전에 SOAP 헤더내의요청메시지와암호화되어첨부된전자 ( 세금 ) 계산서를대상으로전자서명을한다.( 메시지전자서명항목 부분참조 ) - 5단계 : 전송프로토콜규약에따라메시지를전송한다. 전자 ( 세금 ) 계산서국세청전송을위한사업자처리절차를도식화하면다음 [ 그림2-9] 와같다. [ 그림 2-9] 전자 ( 세금 ) 계산서국세청전송을위한사업자처리절차 국세청이사업자로부터수신한메시지를처리하는단계 - 1단계 : 메시지를수신한후 SOAP 메시지구조를검증, 메시지에대한서명검증후첨부문서를추출한다. - 2단계 : 수신한문서에대해접수증을발급하고동기식응답메시지로전달한다. - 3단계 : 국세청내부에서는수신한메시지에서첨부문서를추출하고추출한전자 ( 세금 ) 계산서를복호화한다. - 4단계 : 복호화된전자 ( 세금 ) 계산서가묶음인경우에는 ( 세금 ) 계산서단위로분할한후각개별 ( 세금 ) 계산서에대해전자서명검증을수행한다

21 - 5단계 : 전자 ( 세금 ) 계산서의구조를검증하고, 국세청내부시스템과연계하여데이터검증을수행한다. 3~5단계는이해를돕기위해국세청이사업자에게처리결과메시지를전송하기전에내부시스템과연동하여처리하는과정을설명한것이다. 국세청으로전송하는방식은전자 ( 세금 ) 계산서가발급된후바로전송하는경우와배치로일괄전송하는방식으로구분될수있다. 사업자는각자시스템운영방식에따라국세청으로전송하면된다. 2) 처리결과요청메시지및수신확인메시지전송사업자가국세청으로부터처리결과를수신하지못한경우에처리결과를요청하는메시지를전송하는절차 ( 처리결과수신의선택적방안 ) 와, 국세청으로부터처리결과를수신한후수신확인메시지를전송하는절차는동일하다. 물론처리결과를요청하는메시지는 SOAP의 Request 메시지로전송되며, 처리결과수신에대한수신확인메시지는 SOAP의 Response 메시지로전송된다는점에서는차이가있으나, 사업자시스템에서메시지전송을위한처리과정과국세청내부에서메시지수신후처리과정은동일한처리절차에따라이루어진다. 이경우에는모두첨부문서는없이 SOAP Body에업무에따른 Request Data를실어서 SOAP규약에따라메시지를생성한후전송한다. [ 그림 2-10] 처리결과요청메시지및수신확인메시지전송절차사업자가국세청에전자 ( 세금 ) 계산서제출에대한처리결과를요청하는단계는다음과같다. - 1단계 : 전자 ( 세금 ) 계산서전송한후처리결과를확인하기위해처리결과를요청하는메시지를표준규약에맞게생성한다.( 업무별 Request, Response data 및첨부문서구조 부분참조 )

22 - 2단계 : 규약에따라 SOAP 메시지를생성하고, 전송전에 SOAP 메시지를대상으로전자서명을한다.( 메시지전자서명항목 부분참조 ) - 3단계 : 전송프로토콜규약에따라메시지를전송한다. 국세청으로부터메시지를수신한사업자는다음단계에따라처리를한다. - 1단계 : 메시지를수신한후 SOAP 메시지구조를검증, 메시지에대한서명검증을한다. - 2단계 : 요청메시지를내부시스템에전달한다 국세청 à 사업자전송 1) 수신확인메시지 ( 접수증첨부 ) 및처리결과메시지수신절차사업자로부터전자 ( 세금 ) 계산서제출메시지를수신한국세청은수신하였다는확인을위해접수증을발급하고이를 SOAP Response 메시지로사업자에게전송한다. 이는 Connection-Oriented 방식의통신방식과유사한것으로사업자가전송한트랜잭션에대해국세청이수신하였음을확인해주는절차이다. 사업자가이응답메시지를수신하지못했을경우에는국세청이전자 ( 세금 ) 계산서제출메시지를정상적으로수신하지못했다고판단하고반드시재전송하여야한다. 국세청은접수증을돌려주기전에수신한제출메시지의 SOAP 구조를검증하고, 제출자 ( 전송사업자 ) 의공인인증서로 WS-Security 규약에따라전자서명된메시지의서명만을검증한후접수증을발급해준다. [ 그림 2-11] 수신확인메시지및처리결과수신절차

23 또한국세청은사업자에게접수증을돌려준이후에, 비동기식으로암호화된전자 ( 세금 ) 계산서묶음을복호화하고 ( 세금 ) 계산서단위로나눠서내부시스템과연동하여처리한후, 그처리결과를처리결과메시지로만들어사업자에게다시되돌려준다. 내부시스템과의연동과정에서국세청시스템은공급사업자의전자서명이포함된전자 ( 세금 ) 계산서에대해 XML 스키마검증, 전자 ( 세금 ) 계산서항목검증, 전자서명검증등을수행하게된다. 이와같은전자 ( 세금 ) 계산서검증결과는실시간으로즉시사업자에게전송하지않고익일전송을원칙으로한다. 국세청이사업자에게전송하는수신확인메시지 ( 접수증첨부 ) 및처리결과메시지수신절차를도식화하면다음 [ 그림 2-11] 수신확인메시지및처리결과메시지수신절차 와같다. 국세청이사업자에게전자 ( 세금 ) 계산서제출에대한수신응답으로서접수증을돌려주거나처리결과를돌려주는단계는다음과같다. - 1단계 : 전자 ( 세금 ) 계산서수신후접수증이나, 처리결과문서를표준규약에맞게생성한다.( 업무별 Request, Response data 및첨부문서구조 부분참조 ) - 2단계 : 생성한문서에대해국세청의공인인증서로전자서명을수행한다. - 3단계 : 서명된문서를첨부물로한 SOAP 메시지를생성하고, 전송전에 SOAP 메시지와첨부문서를대상으로전자서명을한다.( 메시지전자서명항목 부분참조 ) - 4단계 : 전송프로토콜규약에따라메시지를전송한다. 국세청으로부터메시지를수신한사업자는다음단계에따라처리를한다. - 1단계 : 메시지를수신한후 SOAP 메시지구조를검증, 메시지에대한서명검증후첨부문서를추출한다. - 2단계 : 추출한첨부문서 ( 접수증, 처리결과문서 ) 의전자서명을검증한다. - 3단계 : 첨부문서에대한메시지구조를확인한후내부시스템과연계한다. 앞서도언급하였지만, 국세청에서사업자에게보내는문서는내용에대한기밀성을요하지않으므로, 전자 ( 세금 ) 계산서와달리암호화단계를생략한다. [ 그림 2-12] 와같이국세청으로부터처리결과메시지를수신한사업자는처리결과메시지의첨부영역에서처리결과문서를추출한다. 추출된처리결과문서를분석 ( 4.3 처리결과문서 부분참조 ) 하여오류통지된전자 ( 세금 ) 계산서를파악한다. 오류로통지된전자 ( 세금 ) 계산서에대해오류원인을확인하고오류를수정한후전자 ( 세금 ) 계산서를재발급하여다시국세청으로전송하여야한다. 다만오류가발생한전자세금계산서에대해발급기한 ( 익월 10일 ) 내에국세청으로재전송하지않을경우이는발급하지않은것으로분류되어가산세대상이된다

24 [ 그림 2-12] 국세청으로부터응답내역수신및처리절차

25 3. 전자 ( 세금 ) 계산서항목 3.1. 표준정의절차 국세청에서권고하는표준전자 ( 세금 ) 계산서의항목과메시지구조는국제및국내표준지침에따라정의되었다. 본규격에서참고한표준지침으로는 KEC XML 전자문서개발지침 v3.5, UN/CEFACT CCL08A와 KEC CCL08을참고로하였다. 전자서명은 W3C의 XML DSig 규격을참고로하여정의하였다. 전자 ( 세금 ) 계산서항목은다음 [ 그림 3-1] 의절차에따라정의하였다. 자세한사항은 KEC XML 전자문서개발지침 v3.5를참조하기바란다. 먼저신규전자문서를설계하기위해기등록된 BP(Business Process) 가존재하는지를확인한다. 유사일치는일치하는 BP가존재할경우이를확장하여사용하도록하며, 적절한 BP가존재하지않을경우 BP 모델링을하고이를등록하여사용한다. [ 그림 3-1] 비즈니스정보발견절차

26 다음으로는사용가능한비즈니스정보개체를검토하여 BP 요구사항을충족하는지검토한다. 다음설명은비즈니스정보개체를발견하는절차에대해설명하고있다. 1단계 : 개발자가필요로하는비즈니스정보와동일한정의를가진기존 ABIE를찾기위하여 BIE 라이브러리를검색. 정확한일치 (Exact Match): 비즈니스요구를충족시키는정의와구성을가진 ABIE가있다면, 해당 ABIE를재사용하기위한재사용등록요청수행 유사한일치 (Similar Match): 비즈니스요구를완전히충족시키지못하며약간의수정이필요한 ABIE가있다면, ABIE 변경요청서를작성하여제출 비즈니스요구를충족시키는 ABIE가없으면, 2단계로감 2단계 : 신규 ABIE가기반으로할수있는적절한구조와정의를가진기존 ACC를 CC 라이브러리에서검색 비즈니스요구를충족시키는정의와구조를갖는 ACC가있다면, ACC의재사용등록요청을수행 비즈니스요구를완전히충족시키지못하며약간의수정이필요한 ACC가있다면, ACC 변경요청서를작성하여제출 비즈니스요구를충족시키는정의와구조를가진 ACC가없다면, 신규 ACC 요청서를작성하여제출전자문서를정의하기위해필요로하는비즈니스정보개체가있다면, 사용가능한 XML 스키마가존재하는지확인하여정의한다. 만족하는 XML 스키마가존재하지않을경우신규로정의하여등록요청을한다

27 3.2. 전자 ( 세금 ) 계산서전자문서항목 [ 그림 3-2] 는표준전자 ( 세금 ) 계산서 v3.0 의스키마구조를보여주고있으며, 자세한항목 설명은 부록 A. 표준전자 ( 세금 ) 계산서 v3.0 항목표 를참조하면된다. [ 그림 3-2] 표준전자 ( 세금 ) 계산서전자문서구조 전자 ( 세금 ) 계산서전자문서항목 관리정보 (ExchangedDocument) 관리정보는 [ 표 3-1] 에서설명하는것처럼사업자가전자 ( 세금 ) 계산서를이용할때서비스사업자와이용사업자가이용할수있는서비스번호 (ID) 등관리정보관련항목을포함하고있다. [ 표 3-1] 표준전자 ( 세금 ) 계산서전자문서항목 관리정보 (ExchangedDocument)" 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 서비스관리번호 ID S ASP 사업자또는 ERP 시스템에서관리하는식별체계 사업자관리번호 ReferenceDocument/ID S 발급전자 ( 세금 ) 계산서에부여하는식별체계 발급일시 Issue. Datetime N 전자서명생성일시및전자 ( 세금 ) 계산서발급일시

28 전자 ( 세금 ) 계산서전자문서항목 전자서명 (Signature) 전자서명은 [ 표 3-2] 에서설명하는것처럼전자 ( 세금 ) 계산서의무결성등을위하여공인인증서에기반을두어계산서정보를전자서명하는전자서명 (Signature) 항목을포함하고있다.( 5.2절전자서명 을참조 ) [ 표 3-2] 표준전자 ( 세금 ) 계산서전자문서항목 전자서명 (Signature)" 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 전자서명 Signature S 지침내 5.2 전자서명 참조 전자 ( 세금 ) 계산서전자문서항목 기본정보 (TaxInvoiceDocument) 기본정보는 [ 표 3-3] 에서설명하는것처럼전자 ( 세금 ) 계산서승인번호 (Issue. ID) 등기본정보관련항목을포함하고있다. [ 표 3-3] 표준전자 ( 세금 ) 계산서전자문서항목 기본정보 (TaxInvoiceDocument)" 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 승인번호 Issue. ID S 작성일자 Issue. Datetime N ( 세금 ) 계산서종류 Type. Code N 전자 ( 세금 ) 계산서에대한국세청에서식별하는식별체계형식 : 작성일자 ( 숫자 8 자리 )+ 국세청등록번호 ( 숫자 8 자리 )+ 식별자 (a~z 와숫자를조합한 8 자리 ) 전자 ( 세금 ) 계산서작성일자형식 : YYYYMMDD ( 세금 ) 계산서분류 (2 자리 ) : 01( 세금계산서 ), 02 ( 수정세금계산서 ), 03( 계산서 ), 04( 수정계산서 ) ( 세금 ) 계산서종류 (2 자리 ) : 01( 일반 ), 02 ( 영세율 ), 03( 위수탁 ), 04( 수입 ), 05( 영세율위수탁 ), 06( 수입납부유예 ) 영수 / 청구구분 Purpose. Code N : 영수, 02 : 청구 수정코드 AmendemntStatus. Code N 전자 ( 세금 ) 계산서수정사유코드 : 01( 기재사항의착오 정정, 세율을잘못적용한경우 ), 02( 공급가액변동 ), 03( 환입 ), 04( 계약의해제 ), 05 ( 내국신용장사후개설 ), 06( 착오에의한이중발급, 면세등발급대상이아닌거래등 ) 당초승인번호 OriginalIssue. ID S 당초전자 ( 세금 ) 계산서승인번호 비고 Description. Text S 회까지반복사용가능 수입 ( 세금 ) 계산서 관련정보 ReferencedImportDocument 지침 절참조

29 < 유의사항 1> 기본정보내 수정코드 (AmendemntStatus. Code) 는 KEC 표준전자 ( 세금 ) 계산서 v3.0 에서 선택항목으로정의하고있으나, ( 세금 ) 계산서종류 (Type. Code) 의코드에따라사용하지않거나 필수항목으로이용하여야한다. ( 세금 ) 계산서종류 (Type. Code) 의코드값 ( 세금 ) 계산서종류 수정코드항목사용여부 0101 일반세금계산서 사용안함 0102 영세율세금계산서 사용안함 0103 위수탁세금계산서 사용안함 0104 수입세금계산서 사용안함 0105 영세율위수탁세금계산서 사용안함 0106 수입납부유예세금계산서 사용안함 0201 수정일반세금계산서 필수항목 0202 수정영세율세금계산서 필수항목 0203 수정위수탁세금계산서 필수항목 0204 수정수입세금계산서 필수항목 0205 수정영세율위수탁세금계산서 필수항목 0206 수정수입납부유예세금계산서 필수항목 0301 일반계산서 사용안함 0303 위수탁계산서 사용안함 0304 수입계산서 사용안함 0401 수정일반계산서 필수항목 0403 수정위수탁계산서 필수항목 0404 수정수입계산서 필수항목 < 유의사항 2> 기본정보내 영수 / 청구구분 (Purpose. Code) 는 KEC 표준전자 ( 세금 ) 계산서 v3.0 에서선택항목으로정의하고있으나, ( 세금 ) 계산서종류 (Type. Code) 가 0104( 정기수입 ( 세금 ) 계산서 ), 0204( 수정수입 ( 세금 ) 계산서 ), 0304( 수입계산서 ), 0404( 수정수입계산서 ) 일때를제외하고필수항목으로기재할것을권고한다. < 유의사항 3> 기본정보내 승인번호 (Issue. ID) 는작성일자 ( 예 : ), 국세청등록번호 ( 예 : ), 일련번호 ( 예 : 또는 a534eg61 또는 axyzefqg) 를조합하여작성하여기재하여야한다. 작성일자는 ( 세금 ) 계산서를작성한일자정보를연월일 (yyyymmdd) 형식으로, 국세청등록번호는국세청에전자 ( 세금 ) 계산서시스템사업자로등록하였을때부여받은등록번호 ( 숫자 8자리 ) 를고정된값의형식으로, 일련번호는알파벳영문소문자 a~z와숫자 0~9를조합한형식으로작성하여야만한다. 또한승인번호는 ( 세금 ) 계산서별로유일한값을가져야만한다

30 전자 ( 세금 ) 계산서전자문서항목 기본정보 (TaxInvoiceDocument) 중 수입 ( 세금 ) 계산서관련정보 (ReferencedImportedDocument)" 기본정보-수입 ( 세금 ) 계산서관련정보 는 [ 표 3-4] 에서설명하는것처럼수입신고번호 (ID) 등수입 ( 세금 ) 계산서관련항목을포함하고있다. [ 표 3-4] 표준전자 ( 세금 ) 계산서전자문서항목 기본정보 (TaxInvoiceDocument) 중 수입 ( 세금 ) 계산서관련정보 (ReferencedImportedDocument)" 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 수입신고번호 ID S 수입신고서번호 일괄발급시작일 Acceptable. Period/Start. DateTime S YYYYMMDD 일괄발급종료일 Acceptable. Period/End. DateTime S YYYYMMDD 수입총건 Item. Quantity N 일괄발급수입총건 전자 ( 세금 ) 계산서전자문서항목 거래처정보-공급자 (InvoicerParty) 거래처정보-공급자 는 [ 표 3-5] 에서설명하는것처럼사업자등록번호 (ID) 등공급자관련항목을포함하고있다. [ 표 3-5] 전자 ( 세금 ) 계산서전자문서항목 거래처정보 - 공급자 (InvoicerParty) 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 사업자등록번호 ID S XXXXXXXXXX 형식 ("-" 불포함 ) 종사업장번호 SpecifiedOrganization/TaxRegistration. ID N 국세청부여거래처식별코드 상호 Name. Text S 대표자성명 SpecifiedPerson/Name. Text S 주소 SpecifiedAddress/LineOne. Text S 업태 Type. Code S 업종 Classification. Code S 담당부서명 DefinedContact/DepartmentName. Text S 담당자명 DefinedContact/PersonName. Text S 담당자전화번호 DefinedContact/Telephone. Communication S 담당자이메일 DefinedContact/URI. Communication S

31 < 유의사항 1> 공급자내 사업자등록번호 (ID) 는 KEC표준전자 ( 세금 ) 계산서 v3.0에서최대길이를 13byte로정의하고있으나 10byte만을이용하여사업자등록번호만을입력하여야하며, 데이터타입을문자열 (String) 으로정의하고있으나숫자 (Number) 만을입력하여야한다. < 유의사항 2> 공급자내 종사업장번호 (SpecifiedOrganization/TaxRegistration.ID) 에는부가가치세법상의 사업자단위과세 를적용받는사업자의종사업장구분코드로국세청에서관리하는 사업자단위승인서, 사업자단위변경승인통지서 상의종사업장일련번호 4자리를기재하여야한다. ( 단, 2010년 1월 1일이후개업하는사업자의경우사업자단위과세적용을받는경우에는사업자등록증부표인 " 사업자단위과세적용종된사업장명세서 " 상의일련번호 4자리를말함 전자 ( 세금 ) 계산서전자문서항목 거래처정보-공급받는자 (InvoiceeParty) 거래처정보-공급받는자 는 [ 표 3-6] 에서설명하는것처럼사업자등록번호 (ID) 등공급받는자관련항목을포함하고있다. [ 표 3-6] 전자 ( 세금 ) 계산서전자문서항목 거래처정보 - 공급받는자 (InvoiceeParty) 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 사업자등록번호 ID S 형식 : nnnnnnnnnnnnn("-" 불포함 ) 사업자등록번호구분코드 SpecifiedOrganization/BusinessType. Code N ( 사업자등록번호 ), 02( 주민등록번호 ), 03( 외국인 ) 종사업장번호 SpecifiedOrganization/TaxRegistration. ID N 국세청부여거래처식별코드 상호 Name. Text S 대표자성명 SpecifiedPerson/Name. Text S 주소 SpecifiedAddress/LineOne. Text S 업태 Type. Code S 업종 Classification. Code S 담당부서명 1 PrimaryDefinedContact/DepartmentName. Text S 담당자명 1 PrimaryDefinedContact/PersonName. Text S 담당자전화번호 1 PrimaryDefinedContact/Telephone. Communication S 담당자이메일 1 PrimaryDefinedContact/URI. Communication S 담당부서명 2 SecondaryDefinedContact/DepartmentName. Text S 담당자명 2 SecondaryDefinedContact/PersonName. Text S 담당자전화번호 2 SecondaryDefinedContact/Telephone. Communication S 담당자이메일 2 SecondaryDefinedContact/URI. Communication S

32 < 유의사항 1> 공급받는자내 사업자등록번호 (ID) 는 사업자등록구분코드 (SpecifiedOrganization/ BusinessType. Code) 에따라공급받는자의정보 ( 사업자등록번호, 개인주민등록번호, 외국인 ) 를입력하여야하며, 데이터타입을문자열 (String) 으로정의하고있으나숫자 (Number) 만을입력하여야한다. 사업자등록구분코드 (SpecifiedOrganization/BusinessType. Code) 사업자등록번호 (ID) 기재내용 최대길이 (Byte) 01 사업자등록번호 주민등록번호 외국인 13 < 유의사항 2> 공급받는자내 사업자등록구분코드 (SpecifiedOrganization/ BusinessType. Code) 가 03( 외국인 ) 인경우, 사업자등록번호 (ID) 에 를입력한후비고에관련정보 ( 외국인등록번호, 여권번호등 ) 를기재하여야만한다. < 유의사항 3> 공급받는자연락처정보 (PrimaryDefinedContact, SecondaryDefinedContact) 는필요한경우 2 인까지기재할수있다. < 유의사항 4> 공급받는자내 종사업장번호 (SpecifiedOrganization/TaxRegistration. ID) 에는부가가치세법상의 사업자단위과세 를적용받는사업자의종사업장구분코드로국세청에서관리하는 사업자단위승인서, 사업자단위변경승인통지서 상의종사업장일련번호 4자리를기재하여야한다.( 단, 2010년 1월 1일이후개업하는사업자의경우사업자단위과세적용을받는경우에는사업자등록증부표인 " 사업자단위과세적용종된사업장명세서 " 상의일련번호 4자리를말함 전자 ( 세금 ) 계산서전자문서항목 거래처정보 - 수탁사업자 (BrokerParty) 거래처정보 - 수탁사업자 는 [ 표 3-7] 에서설명하는것처럼사업자등록번호 (ID) 등수탁 사업자관련항목을포함하고있다

33 [ 표 3-7] 전자 ( 세금 ) 계산서전자문서항목 거래처정보 - 수탁사업자 (BrokerParty) 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 사업자등록번호 ID S XXXXXXXXXX 형식 ("-" 불포함 ) 종사업장번호 SpecifiedOrganization/TaxRegistration. ID N 국세청부여거래처식별코드 상호 Name. Text S 대표자성명 SpecifiedPerson/Name. Text S 주소 SpecifiedAddress/LineOne. Text S 업태 Type. Code S 업종 Classification. Code S 담당부서명 DefinedContact/DepartmentName. Text S 담당자명 DefinedContact/PersonName. Text S 담당자전화번호 DefinedContact/Telephone. Communication S 담당자이메일 DefinedContact/URI. Communication S < 유의사항 1> 수탁사업자 (BrokerParty)" 정보는지침 절에서정의하고있는 ( 세금 ) 계산서종류 (Type. Code) 가 0103( 위수탁세금계산서 ), 0203( 수정위수탁세금계산서 ), 0303( 위수탁계산서 ), 0403( 수정위수탁계산서 ) 인경우에만수탁사업자정보의기재를위하여이용하여야만한다. < 유의사항 2> 수탁사업자내 사업자등록번호 (ID) 는 KEC표준전자 ( 세금 ) 계산서 v3.0에서최대길이를 13byte로정의하고있으나 10byte만을이용하여사업자등록번호만을입력하여야하며, 데이터타입을문자열 (String) 으로정의하고있으나숫자 (Number) 만을입력하여야한다

34 < 유의사항 3> 수탁사업자내 종사업장번호 (SpecifiedOrganization/TaxRegistration. ID) 에는부가가치세법상의 사업자단위과세 를적용받는사업자의종사업장구분코드로국세청에서관리하는 사업자단위승인서, 사업자단위변경승인통지서 상의종사업장일련번호 4자리를기재하여야한다.( 단, 2010 년 1월 1일이후개업하는사업자의경우사업자단위과세적용을받는경우에는사업자등록증부표인 " 사업자단위과세적용종된사업장명세서 " 상의일련번호 4자리를말함 전자 ( 세금 ) 계산서전자문서항목 결제정보 -결제방법별금액 (SpecifiedPaymentMeans) 결제정보-결제방법별금액 (SpecifiedPaymentMeans) 는 [ 표 3-8] 에서설명하는것처럼결제방법코드 (Type. Code) 등결제방법별금액관련항목을포함하고있다. [ 표 3-8] 전자 ( 세금 ) 계산서전자문서항목 결제정보 - 결제방법별금액 (SpecifiedPaymentMeans) 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 결제방법코드 Type. Code S : 현금, 20: 수표, 30: 어음, 40: 외상 금액 Paid. Amount N < 유의사항 > 결제정보 - 결제방법별금액 (SpecifiedPaymentMeans) 은결제방법별코드에따라결제방법 횟수만큼최대 4 회반복할수있다 전자 ( 세금 ) 계산서전자문서항목 결제정보 -Summary(SpecifiedMoneySummation) 결제정보-Summary(SpecifiedMoneySummation) 는 [ 표 3-9] 에서설명하는것처럼공급가액합계 (ChargeTotalAmount) 등전자 ( 세금 ) 계산서금액합계관련항목을포함하고있다. [ 표 3-9] 전자 ( 세금 ) 계산서전자문서항목 결제정보 -Summary(SpecifiedMoneySummation) 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 공급가액합계 ChargeTotal. Amount N 세액합계 TaxTotal. Amount N 총금액 GrandTotal. Amount N

35 < 유의사항 1> 결제정보 -Summary(SpecifiedMoneySummation) 내 " 세액합계 (TaxTotal. Amount)" 는 KEC 표준 전자 ( 세금 ) 계산서 v3.0 에서선택항목으로정의하고있으나 ( 세금 ) 계산서종류 (Type. Code) 의 코드에따라사용하지않거나필수항목으로이용하여야한다. ( 세금 ) 계산서종류 (Type. Code) 의코드값 ( 세금 ) 계산서종류세액합계항목사용여부 0101 일반세금계산서필수항목 0102 영세율세금계산서필수항목 0103 위수탁세금계산서필수항목 0104 수입세금계산서필수항목 0105 영세율위수탁세금계산서필수항목 0106 수입납부유예세금계산서필수항목 0201 수정일반세금계산서필수항목 0202 수정영세율세금계산서필수항목 0203 수정위수탁세금계산서필수항목 0204 수정수입세금계산서필수항목 0205 수정영세율위수탁세금계산서필수항목 0206 수정수입납부유예세금계산서필수항목 0301 일반계산서사용안함 0303 위수탁계산서사용안함 0304 수입계산서사용안함 0401 수정일반계산서사용안함 0403 수정위수탁계산서사용안함 0404 수정수입계산서사용안함 < 유의사항 2> 결제정보 -Summary(SpecifiedMoneySummation) 내항목들은 - 값을허용한다. < 유의사항 3> 결제정보-Summary(SpecifiedMoneySummation) 내항목들은지침 3.2.9절의 상품정보 (TaxInvoiceLineItem)" 의 " 단가 (TaxInvoice/UnitPrice/Unit. Amount)" 항목에서허용하고있는원단위이하금액을허용하지않는다 전자 ( 세금 ) 계산서전자문서항목 상품정보 (TaxInvoiceTradeLineItem) 상품정보 (TaxInvoiceTradeLineItem) 는 [ 표 3-10] 에서설명하는것처럼상품정보반복

36 횟수를보여주는 일련번호 (Sequence.Numeric)" 등상품정보관련항목을포함하고있다. [ 표 3-10] 전자 ( 세금 ) 계산서전자문서항목 결제정보 - 상품정보 (TaxInvoiceTradeLineItem) 내항목 국문 항목명 ( 경로포함 ) 영문 T L O 비고 일련번호 Sequence. Numeric N 상품정보반복횟수 (01~99) 를표현 공급년월일 PurchaseExpiry. DateTime N YYYYMMDD형식. 품목명 Name. Text S 규격 Information. Text S 비고 Description. Text S 수량 ChargeableUnit. Quantity N 단가 UnitPrice/Unit. Amount N 공급가액 Invoice. Amount N 세액 TotalTax/Calculated. Amount N < 유의사항 1> 상품정보 (TaxInvoiceLineItem) KEC 표준전자 ( 세금 ) 계산서 v3.0 에서선택항목으로정의하고있으나, ( 세금 ) 계산서종류 (Type. Code) 가 0104( 정기수입 ( 세금 ) 계산서 ), 0204( 수정수입 ( 세금 ) 계산서 ), 0304( 수입계산서 ), 0404( 수정수입계산서 ) 일때를제외하고상품정보의수에따라 1~99회까지반복하여기재할것을권고한다. < 유의사항 2> 수량 (ChargeableUnit. Quantity)" 항목은소수점 2 자리까지의표기를허용 ( 예 : 1/2 0.5 로 표현 ) 하며, - 값을허용한다. < 유의사항 3> 품목단위 ( 예 : BOX, EA 등 ) 의기재를원하는사업자는 수량 (ChargeableUnit. Quantity)" 항목의 속성 (attribute) 값으로표현한다. < 유의사항 4> 상품정보 - 단가 (UnitPrice/Unit. Amount) 는원단위이하소수점 2 자리까지표현할수있으며, - 값을허용한다. < 유의사항 5> 상품정보 - 공급가액 (InvoiceAmount) 및 상품정보 - 세액 (TotalTax/Calculated. Amount) 은원단위 이하금액을허용하지않으며, - 값을허용한다

37 4. 국세청응답문서 4.1. 개요 본장에서는국세청과사업자간연계중에서국세청이사업자에게전송하는문서를정의한다. 국세청이사업자에전송하는문서는두가지가있는데하나는전자 ( 세금 ) 계산서접수증이고나머지하나는접수한전자 ( 세금 ) 계산서에대한처리결과문서이다. 접수증은사업자가국세청에전자 ( 세금 ) 계산서를제출했을때, 국세청이전자 ( 세금 ) 계산서를성공적으로수신했음을알려주는문서이다. 그리고처리결과문서는국세청이수신한전자 ( 세금 ) 계산서에대한구조, 서명그리고데이터검증을끝낸후그처리결과를사업자에게알려주는문서이다. 국세청에서사업자로전달되는모든응답문서는 XML 형식이고 UTF-8 인코딩을기본으로한다. 또한국세청공인인증서로전자서명을한후통신규약에따라 SOAP 메시지에첨부되어전달된다. ( 지침 6절전자 ( 세금 ) 계산서통신참조 )

38 4.2. 응답문서구조 두가지국세청응답문서인접수증과처리결과는하나의응답문서구조를가진다. 국세청은 이러한하나의응답문서구조를바탕으로업무에맞게항목을조정하여응답문서를생성한다. 국세청응답문서의전체구조는다음과같다. 국문 항목명 ( 경로포함 ) 영문 [ 표 4-1] 국세청응답문서구조 비고 전자서명 Signature 지침내 5.2 전자서명 참조 제출아이디 접수번호 문서종류 ResultDocument/RefSubmit. ID ResultDocument/Receipt. ID ResultDocument/Type. Code 응답시간 ResultDocument/Response. DateTime 처리상태코드 ResultDocument/ProcessStatus. Code 처리불가원인코드 ResultDocument/FailReasonStatus. Code 총제출건수 처리성공건수 처리실패건수 승인번호 처리결과코드 < 유의사항 > ResultDocument/TotalCount. Quanity ResultDocument/SuccessCount. Quantity ResultDocument/FailCount. Quantity ResultDocument/ValidationDocument /Issue. ID ResultDocument/ValidationDocument /ResultStatus. Code 비고 ResultDocument/Description. Text 비고 사업자가전자 ( 세금 ) 계산서를제출했을때설정한 SubmitID 값 전자 ( 세금 ) 계산서접수번호 'NTS' + '-' + 년월일시분초 + '-' + 일련번호 5 자리 예 > NTS 응답문서구분코드 ( 표 4-6 응답문서코드표참조 ) 국세청이응답문서를생성한시간 YYYYMMDDHHMMSS 형식 ( 세금 ) 계산서처리상태코드 ( 표 4-2 송수신문서코드표참조 ) 전체처리실패원인 ( 표 4-4 전송메시지처리실패원인코드표참조,) 처리결과문서이고 ProcessStatusCode 가 03 인경우만존재 수신받은전자 ( 세금 ) 계산서전체건수 처리결과문서이고 ProcessStatusCode 가 01 인경우만존재 전체중검증결과값이성공인것의개수 처리결과문서이고 ProcessStatusCode 가 01 인경우만존재 전체중검증결과값이실패인것의개수 처리결과문서이고 ProcessStatusCode 가 01 인경우만존재 처리결과목록 처리결과문서이고 ProcessStatusCode 가 01 인경우만존재 처리결과 ( 표 4-5 처리결과코드표참조 ) 처리결과코드 (ResultStatus. Code) 의코드값이 "SYN004( 전자 ( 세금 ) 계산서스키마오류 ) 인경우는승인번호를 추출할수없으므로, 승인번호 (Issue. ID)" 의값이 xsderror" 라고표시된다

39 국세청응답문서전체스키마구조는 [ 그림 4-1] 과같다. [ 그림 4-1] 국세청응답문서스키마 전자 ( 세금 ) 계산서접수증 접수증개요사업자가국세청에전자 ( 세금 ) 계산서를제출하면국세청은 SOAP 메시지구조를검증하고 SOAP 메시지에적용된전자서명을통해메시지를전송한사업자에대한인증및 SOAP 메시지무결성을검증한다. 이때, 수신메시지가정상이면국세청은메시지를정상적으로수신하였음을확인하는문서즉, 접수증을발급하여이를사업자에게전달한다 접수증문서구조접수증은사업자가전자 ( 세금 ) 계산서를등록할때생성한 SOAP Body 내의 SubmitID에대한참조값과국세청이발부한접수번호로구성된다. 또한데이터무결성과발급보장을위해국세청전자서명이첨부된다. 스키마구조는 [ 그림 4-2] 와같다

40 [ 그림 4-2] 국세청접수증스키마 전자서명이생략된접수증의예시는다음과같다. 실제접수증은아래예시에전자서명이첨부된형식을가진다. <TaxInvoiceResponse> <ResultDocument> <RefSubmitID> be3cfa2c0b1e4e4697e8d41f3f0674cb</RefSubmitID> <ReceiptID>NTS </ReceiptID> <TypeCode>01</TypeCode> <ResponseDateTime> </ResponseDateTime> <DescriptionText> 성공적으로접수처리되었습니다. 처리결과는익일전송될예정입니다. </DescriptionText> </ResultDocument> </TaxInvoiceResponse> 처리결과문서 처리결과문서개요국세청은사업자로부터수신한암호화된전자 ( 세금 ) 계산서문서 ( 또는문서묶음 ) 를복호화한후구조검증, 서명검증그리고데이터검증등을수행하고그결과를다음과같은문서형식 ( 지침 4.3.2절처리결과문서구조부분참조 ) 으로작성하여해당사업자에다시전달한다. 국세청은하나의 SOAP 메시지내에첨부된전자 ( 세금 ) 계산서에대한처리가모두완료된후, 각 ( 세금 ) 계산서단위로처리결과를작성하여사업자에전달한다. 즉, 모든처리결과문서는처음사업자가전자 ( 세금 ) 계산서를제출한 SOAP 메시지단위로작성된다. 예를들면사업자 A가 50건, 70건의전자 ( 세금 ) 계산서를하나로묶어국세청에각각신고한경우, 처리결과문서는 50건에대한처리결과문서하나그리고 70건에대한처리결과문서하나가사업자 A에게각각전달된다

41 처리결과문서구조처리결과문서는전자 ( 세금 ) 계산서를제출할때첨부한전자 ( 세금 ) 계산서전체건수, 성공및실패건수그리고각전자 ( 세금 ) 계산서별처리결과코드값등으로구성된다. 또한데이터무결성을위해국세청전자서명이첨부된다. 처리결과는크게개별전자 ( 세금 ) 계산서에대한검증을수행할수없는경우와할수있는경우두가지로나뉜다. 개별전자 ( 세금 ) 계산서에대한검증을수행할수없는경우는시스템사업자인증오류, 첨부전자 ( 세금 ) 계산서복호화실패등개별전자 ( 세금 ) 계산서검증단계전에오류가발생하는경우인데 ( 표 4-4 참조 ) 이경우 " 처리상태코드 (ProcessStatus. Code) 는 처리불가 코드값인 03 으로설정되고해당오류코드가 처리불가원인코드 (FailReasonStatus. Code)" 에기록된다. 이때개별전자 ( 세금 ) 계산서에대한검증을수행할수없는경우중 연계사업자인증오류 는내부처리전발견되는오류이므로동기식으로바로사업자에게전달된다. 처리불가가아닌경우 ( 표 4-5 참조 ) 개별전자 ( 세금 ) 계산서검증결과가 " 처리결과코드 (ResultDocument/ValidationDocument/ResultStatus. Code)" 항목에기록된다. 케이스별스키마및예시는아래와같다. 실제처리결과는각예시에전자서명 ( 지침 5.2절문서보안부분참조 ) 이첨부된형식을가진다. 처리완료인경우 (ProcessStatus : 01) - 루트항목 TaxInvoiceResponse 하위로필수항목인 전자서명 (Signature)" 과 ResultDocument 경로아래의모든항목을갖는다. - ResultDocument는하위에필수항목인 제출아이디 (RefSubmit. ID), 접수번호 (Receipt. ID), 문서종류 (Type. Code)", " 응답시간 (Response. DateTime)", 처리상태코드 (ProcessStatus. Code), 총제출건수 (TotalCount. Quantity), 처리성공건수 (SuccessCount. Quantity), 처리실패건수 (FailCount. Quantity) 항목과 ValidationDocument 경로아래의모든항목을갖는다. - ValidationDocument 는하위에 승인번호 (Issue. ID), 처리결과코드 (ResultStatus. Code) 항목을갖는다. - ValidationDocument 는사업자가제출한전자 ( 세금 ) 계산서의수만큼반복된다. 처리완료인경우문서스키마구조는 [ 그림 4-3] 과와같다

42 [ 그림 4-3] 처리완료인경우처리결과스키마 - 처리완료인경우처리결과문서의실제예시는아래와같다. <TaxInvoiceResponse> <ResultDocument> <RefSubmitID> be3cfa2c0b1e4e4697e8d41f3f0674cb</RefSubmitID> <ReceiptID>NTS </ReceiptID> <TypeCode>02</TypeCode> <ResponseDateTime> </ResponseDateTime> <ProcessStatusCode>01</ProcessStatusCode> <TotalCountQuantity>5</TotalCountQuantity> <SuccessCountQuantity>3</SuccessCountQuantity> <FailCountQuantity>2</FailCountQuantity> <ValidationDocument> <IssueID> </IssueID> <ResultStatusCode>SUC001</ResultStatusCode> </ValidationDocument> <ValidationDocument> <IssueID> </IssueID> <ResultStatusCode>SUC001</ResultStatusCode> </ValidationDocument> <ValidationDocument> <IssueID> </IssueID> <ResultStatusCode>SUC001</ResultStatusCode> </ValidationDocument> <ValidationDocument> <IssueID> </IssueID> <ResultStatusCode>ERR001</ResultStatusCode> </ValidationDocument> <ValidationDocument> <IssueID> </IssueID> <ResultStatusCode>ERR001</ResultStatusCode> </ValidationDocument> </ResultDocument> </TaxInvoiceResponse>

43 처리중인경우 (ProcessStatus : 02) - 루트항목 TaxInvoiceResponse 하위로필수항목인 전자서명 (Signature)" 과 ResultDocument 경로아래의일부항목을갖는다. - ResultDocument는하위에필수항목인 제출아이디 (RefSubmit. ID), 접수번호 (Receipt. ID), 문서종류 (Type. Code)", " 응답시간 (Response. DateTime)", 처리상태코드 (ProcessStatus. Code)" 항목을갖는다. - 처리중인경우문서스키마구조는 [ 그림 4-4] 와같다. [ 그림 4-4] 처리중인경우처리결과스키마 - 처리중인경우처리결과문서의실제예시는아래와같다. <TaxInvoiceResponse> <ResultDocument> <RefSubmitID> be3cfa2c0b1e4e4697e8d41f3f0674cb</RefSubmitID> <ReceiptID>NTS </ReceiptID> <TypeCode>02</TypeCode> <ResponseDateTime> </ResponseDateTime> <ProcessStatusCode>02</ProcessStatusCode> </ResultDocument> </TaxInvoiceResponse> 처리불가인경우 (ProcessStatus : 03) - 루트항목 TaxInvoiceResponse 하위로필수항목인 전자서명 (Signature)" 과 ResultDocument 경로아래의일부항목을갖는다. - ResultDocument 는하위에필수항목인 제출아이디 (RefSubmit. ID), 접수번호 (Receipt. ID), 문서종류 (Type. Code)", " 응답시간 (Response. DateTime)", 처리상태코드 (ProcessStatus. Code), 처리불가원인코드 (FailReasonStatus. Code)" 항목을갖는다. - 처리불가인경우문서스키마구조는 [ 그림 4-5] 와같다

44 [ 그림 4-5] 처리불가인경우처리결과스키마 - 처리불가인경우처리결과문서의실제예시는아래와같다. <TaxInvoiceResponse> <ResultDocument> <RefSubmitID> be3cfa2c0b1e4e4697e8d41f3f0674cb</RefSubmitID> <ReceiptID>NTS </ReceiptID> <TypeCode>02</TypeCode> <ResponseDateTime> </ResponseDateTime> <ProcessStatusCode>03</ProcessStatusCode> <FailReasonStatusCode>SYN001</FailReasonStatusCode> </ResultDocument> </TaxInvoiceResponse>

45 4.3. 국세청응답문서코드표 처리상태코드국세청이먼저사업자에처리결과를전달할때는수신한전자 ( 세금 ) 계산서가모두처리된후이므로이값은항상처리완료를의미하는 '01' 값을갖는다. 반면에사업자가처리결과를요청하는경우에는해당전자 ( 세금 ) 계산서의처리상태에따라 [ 표 4-2] 와같은코드값을갖는다. [ 표 4-2] 처리상태코드표 식별코드항목명코드값 코드값정의 설명 01 처리완료 사업자가제출한전자 ( 세금 ) 계산서에대한모든검증작업이끝난경우 사업자가제출한전자 ( 세금 ) 계산서에대한 02 처리중 ProcessStatus. Code 검증작업이진행중인경우 사업자가제출한전자 ( 세금 ) 계산서가 03 처리불가 복호화오류, 건수오류그리고연계기관 인증오류등의사유로처리가불가능한경우 전송메시지처리실패원인코드국세청에서전송메시지를처리하는과정에서인증받지않은연계사업자가메시지를전송하거나첨부된전자 ( 세금 ) 계산서에대한복호화를수행할수없는경우등개별전자 ( 세금 ) 계산서에대한검증작업을수행할수없는경우처리결과문서의처리실패원인항목에 [ 표 4-3] 과같은코드값을기록한다. [ 표 4-3] 전송메시지처리실패원인코드표 식별코드항목명코드값 코드값정의 설명 SYS001 연계사업자인증국세청이승인하지않은사업자가전자 ( 세금 ) 계산서를오류제출하는경우, 동기식으로처리불가사유가바로전달됨 사업자가동일한 SubmitID로전자 ( 세금 ) 계산서를 SYS002 중복된 SubmitID 제출하는경우, 동기식으로처리불가사유가바로전달됨 FailReasonStatus. Code SYS003 존재하지않는사업자가존재하지않는 SubmitID 로결과전송요청을 SubmitID 하는경우, 동기식으로처리불가사유가바로전달됨 사업자가제출한암호화된전자 ( 세금 ) 계산서에 SYN001 복호화실패 대한복호화를실패한경우, 비동기식으로처리 불가사유가전달됨 < 유의사항 > 처리불가원인코드 (FailReasonStatus. Code) 의코드값이 SYS001( 연계기관인증오류 ) 인경우는 동기식으로바로오류가통보되며, SYN001( 복호화실패 ) 인경우는비동기식으로오류가통보된다

46 처리결과코드국세청에서는사업자가제출한전자 ( 세금 ) 계산서를처리한후, 그결과를처리결과문서의처리결과항목에처리결과코드속성값으로 [ 표 4-4] 와같은코드값을기록한다. [ 표 4-4] 처리결과코드표 식별코드 코드값 코드값정의 설명 SUC001 성공 모든검증과정을통과한경우 SYN002 공급사업자, 공급사업자전자서명또는위수탁 ( 세금 ) 계산서의수탁자전자서명오류경우수탁자전자서명이유효하지않은경우 SYN003 승인번호중복오류 승인번호가국세청에정상적인 ( 세금 ) 계산서로기등록되어있는경우 1. 유효하지않은전자 ( 세금 ) 계산서구조 ( 엘리먼트 SYN004 전자 ( 세금 ) 계산서스키마오류 중복, 필수엘리먼트미존재, 코드오류, 데이터유형오류, 승인번호형식오류등 ) 을가진경우 2. 계산서의종류코드가영세율일경우 ERR001 공급사업자사업자번호오류 국세청미등록사업자 ERR002 공급받는자사업자번호오류 국세청미등록사업자또는미등록주민등록번호인경우 ERR003 수탁사업자등록번호오류 수탁사업자존재시국세청미등록사업자 ResultStatus. Code ERR005 ERR006 ERR007 ERR008 ERR009 ERR010 발급일시오류작성일자오류공급가액, 세액오류코드유형오류폐업사업자발급오류국세청등록번호오류 1. 발급일시가유효하지않은경우 2. 발급일시가전송일시이후인경우 1. 작성일자가유효하지않은경우 2. 작성일자가발급일시이후인경우 4. 승인번호내의작성일자와작성일자가다른경우 1. 공급가액과세액의부호가다른경우 2. 수정 ( 세금 ) 계산서의환입또는계약의해제시 금액이정 (+) 의값인경우 3. 영세율 ( 위수탁 ) 세금계산서일때세액이 0 이 아닌경우 4. 계산서일때세액이 0 이아닌경우 5. 세액합계액이공급가액합계액의 10% 가아닌경우 ( 단, 단수조정으로공급가액의합계액과세액의합계액을각각 (+),(-)10 원이내의금액은허용 ) ( 세금 ) 계산서종류, 공급받는자사업자등록번호 구분코드, 수정세금계산서일때수정코드에 오류가있는경우 공급사업자가폐업신고일자이후계산서를 발급한경우 발급시스템승인번호의국세청등록번호와전송시스템의국세청등록번호가다른경우 ERR999 정의되지않은기타오류수정계산서의사유가내국신용장사후개설인경우 ERR011 당초승인번호오류 1. 수정세금계산서에입력된당초승인번호가존재하지않거나, 공급자의당초승인번호가아닌경우 2. 일반세금계산서일때당초승인번호가입력된경우

47 < 유의사항 > 처리결과코드 (ResultStatus. Code) 의코드값이 ERR010( 국세청등록번호오류 ) 인경우는전자 ( 세금 ) 계산서를교부시스템 (ERP) 또는교부를대행한시스템 (ASP) 과국세청에전송한시스템이불일치한경우발생하며, 비동기식으로오류가통보된다 응답문서코드국세청이보내는응답문서는크게접수증과처리결과문서로나뉜다. 각문서별코드값은 [ 표 4-5] 와같다. [ 표 4-5] 응답문서코드표 식별코드항목명 코드값 코드값정의 설명 Type. Code 01 접수증 02 처리결과문서 사업자가전송한메시지를정상적으로수신했음을알리는접수증코드값사업자가전송한전자 ( 세금 ) 계산서에대한처리결과를알리는처리결과문서코드값

48 5. 문서보안 5.1. 개요 사업자가국세청에전자 ( 세금 ) 계산서를전송하기위한프로세스중문서보안을위해다음과같은문서보안과정을필요로한다. 첫째, 전자 ( 세금 ) 계산서를발급한발급자의전자서명이필요하며, 둘째, 온라인데이터에대한보안을위한암호화과정을필요로한다. 본절에서는이를위한절차와메시지규격그리고표준의이용방법등을제시하고이를구현하기위한지침을제시한다 수행주체전자서명의목적은전자 ( 세금 ) 계산서에대한공급사업자본인확인, 무결성확보및부인방지이며따라서전자서명의주체는전자 ( 세금 ) 계산서를발급하는공급사업자 ( 또는위수탁 ( 세금 ) 계산서의경우 수탁사업자 ) 이다. 암호화의목적은전송사업자와국세청간의온라인전송시안전한데이터의전달이므로암호화의주체는실제국세청과연계되는전송사업자이다. [ 그림 5-1] 전자서명및암호화수행주체

49 주요표준전자 ( 세금 ) 계산서를생성하기위해 [ 표 5-1] 과같은표준을이용한다. [ 표 5-1] 전자 ( 세금 ) 계산서보안적용표준목록 용도 표준 사용목적 전자서명 XML 전자서명 W3C XML Signature Syntax and Processing" (RFC3275) 국제표준 TTAS.IF-RFC3075 확장성생성언어전자서명구문과 XML 전자서명처리 (XML-Signature Syntax and Processing) 국내표준 ( 한국정보통신기술협회, 2004년 ) 전자서명전 XML TTAS.IF-RFC3076( 제정일 : 2004년 12월 23일, [ 정규화문서에대한정규화 XML 버전 1.0(Canonical XML version 1.0]") 수행전자 ( 세금 ) 계산서 KCAC.TS.SIVID 식별번호를이용한본인확인기술규격 발급자와 (Subscriber Identification Based on Virtual ID) v1.11 전자서명인증서간의일치성확인 IETF RFC 3852 CMS (Cryptographic Message Syntax) 암호문구성 암호화 IETF RFC 3370 Cryptographic Message Syntax (CMS) Algorithm 암호문구성시 알고리듬정의 IETF RFC 4010 Use of the SEED Encryption Algorithm 암호문구성시 SEED in Cryptographic Message Syntax (CMS) 알고리듬정의 본인확인방법전자 ( 세금 ) 계산서의법적효력발생을위해전자서명을수행한다. 그러나전자 ( 세금 ) 계산서에있어서단지검증이된다고이를유효한문서라고볼수없다. 즉, 전자서명검증후전자 ( 세금 ) 계산서의공급사업자와전자서명문생성자가일치하는지를확인하여야하는과정이필요하며이는 vid 검증방법을통해수행하게된다. vid 검증을통한본인확인전자 ( 세금 ) 계산서의공급사업자와전자서명인증서의소유자가일치하는지를확인하기위하여 vid 검증을수행하여야한다. 단, 행정전자서명용인증서는이를검증할수있는방법이현재없으므로본인확인절차를수행하지않는다. 검증절차는한국인터넷진흥원규격인 식별번호를이용한본인확인기술규격 (Subscriber Identification Based on virtual ID) v1.11 을따른다

50 상기규격에따라전자 ( 세금 ) 계산서에대해전자서명수행후수신자측에서이를검증하기 위해필요한난수정보 ( 해당규격상의 R 정보 ) 는암호화하여전달하여야하므로아래 암호화대상데이터 에포함하여암호화하여전달하도록한다. [ 표 5-2] 는본인확인기술규격에제시된본인확인방법이다. [ 표 5-2] 본인확인방법 위방법을통해 R 정보가안전한방법으로전송되면전자 ( 세금 ) 계산서에포함된 IDN ( 사업자번호또는주민등록번호 ) 을추출하여 vid' 를생성한후인증서에포함된 vid 값과비교하여동일여부를확인하는절차를거친다. 공인인증서는전자 ( 세금 ) 계산서의 XML Digital Signature 형식에포함된인증서를이용하게된다 전자 ( 세금 ) 계산서서명및암호화업무흐름 [ 그림 5-2] 는전자 ( 세금 ) 계산서에대한전자서명수행및암호화에대한전체적인절차를나타내었다. 실제상세한내용은이후지침에서상세하게설명한다. 전체적인흐름은크게두가지로나누어진다. 첫번째는전자서명수행과정이다. 전자문서에대한정규화및전자서명대상정보추출로부터최종생성된 Signature를 XML에삽입하는과정에대한순서이다. 두번째는암호화과정으로생성된전자 ( 세금 ) 계산서에대해 100개내의데이터로패키징을수행하고암호화하는과정에서최종전송용암호문인 EnvelopedData의생성까지의순서이다

51 [ 그림 5-2] 전자서명및암호화프로세스

52 5.2. 전자서명 개요전자 ( 세금 ) 계산서의법적효력발생을위해전자서명을수행한다. 전자서명의방법은 W3C에서권고하는 XML Signature Syntax and Processing" 규약을준수하고, detached signature 형식으로생성하여야하며관련된국내표준을따라야한다. 또한처리에있어모호한상황을줄이고처리방법을명확히규정하기위해이용할수있는알고리듬, 처리방법의선택등은본지침에서정한것만을이용할수있다. 사업자및국세청은전자서명시법적효력을위해공인인증기관에서발급한전자서명용인증서 (NPKI) 만을이용하여야한다. XML Signature의구성다음그림은 XML Signature의스키마구조이다. SignedInfo는전자서명의대상이되는정보를가져오기위한각종알고리듬과대상데이터를해시 (Digest) 한값이들어가며 SignatureValue는실제전자서명한값이들어가고서명자의인증서는 KeyInfo의 X509Data에들어간다. [ 그림 5-3] XML Signature 의구성

53 XML 정규화 XML 전자서명은반드시정규화과정을거친후수행해야한다. 전자서명의대상이되는전자 ( 세금 ) 계산서는 XML 구조를가지고있으며, 이러한 XML 문서는다음과같은이유로정규화과정이필요하다. 논리적으로동일한문서에대해물리적으로여러가지표현이가능 논리적으로동일한 XML 문서에대한해시값이항상같음을보장할수없음 논리적으로동일한 XML 문서가하나의물리적인데이터로변환하는정규화필요 정규화의방법은정보통신단체표준인 TTAS.IF-RFC3076( 제정일 : 2004 년 12 월 23 일, [ 정규화 XML 버전 1.0(Canonical XML version 1.0]") 을이용하도록한다. 정규화의방법을요약하면다음과같다. 문서는 UTF-8 로인코딩된다. 행종료는구문분석 (parsing) 전에입력시 #xa 로정규화된다. 속성값들은검증처리기 (validating processor) 에서와같이정규화된다. 문자참조 (character references) 와파싱된개체참조 (parsed entity references) 는대치된다. CDATA 구역은문자콘텐트로대치된다. XML 선언과 DTD (document type declaration) 는제거된다. 비어있는요소는시작 / 종료태그쌍으로변환된다. 문서요소 (document element) 밖의공백문자 (whitespace) 와시작태그와종료태그사이의공백문자는정규화된다. 문자콘텐트안의모든공백문자는보존된다 ( 행종료정규화 (line feed normalization) 동안에제거되는문자들은제외함 ). 속성값구분자는인용부호 ("; double quote) 로설정된다. 속성값과문자콘텐트의특수문자들은문자참조로대치된다. 잉여 (superfluous) 이름공간선언은각요소에서제거된다. 기본 (default) 속성들이각요소에추가된다. 각요소의이름공간선언과속성들을사전순서로정렬한다 알고리듬전자 ( 세금 ) 계산서에 이용되는 주요 알고리듬은 다음과 같다. 알고리듬은 W3C XML-Signature Syntax and Processing (RFC3275) 의알고리듬부분 (6.0 Algorithms) 을 기본적으로따른다. 또한국내고유알고리듬을지원하기위해 TTAS.IF-RFC3075 확장성 생성언어전자서명구문과처리 (XML-Signature Syntax and Processing) ( 한국정보통신 기술협회, 2004년 ) 에서정의된알고리듬을이용한다

54 다음은전자 ( 세금 ) 계산서에서이용하는알고리듬목록이다. 이외의알고리듬은제한함으로써 전자 ( 세금 ) 계산서생성및검증시의모호성을없애도록한다. 전자서명 NameSpace <... xmlns:ds=" > 해시 (Digest) 데이터를축약하는데이용되는해시알고리듬은기존공인인증서를사용하는경우에는 SHA1 알고리듬을, 신규공인인증서를사용하는경우에는 SHA256 을반드시이용해야한다. <ds:digestmethod Algorithm=" 또는 <ds:digestmethod Algorithm=" 전자서명 (Signature) 전자 ( 세금 ) 계산서에대해서명자에대한본인확인, 데이터의무결성검증및부인방지기능을위해전자서명을수행한다. 사용되는알고리듬은기존공인인증서를사용하는경우에는 RSAwithSHA1 알고리듬을, 신규공인인증서를사용하는경우에는 RSAwithSHA256 을반드시이용해야한다. <ds:signaturemethod Algorithm=" 또는 <ds:signaturemethod Algorithm=" < 유의사항 > 2011 년 12 월까지갱신및발급되는기존공인인증서는 SHA1 으로전자서명된형태의공인인증서이고, 2012 년 1 월이후갱신및발급되는신규공인인증서는 SHA256 으로전자서명된형태의공인인증서이기때문에, 2012 년 1 년간두종류의공인인증서가혼용되는것에주의하여야하며, 2013 년이후는신규공인인증서만이용할수있으므로 2013 년이후에는 SHA256 해시알고리듬과, RSAwithSHA256 전자서명알고리듬만을이용하여야한다. 정규화 (Canonicalization) 논리적으로동일한문서에대해물리적으로여러가지표현이가능방식한 XML 의특성 으로인해같은문서에대해전자서명값이다르게나올수있다. 이러한현상을방지하기 위해반드시정규화과정을거쳐야한다. 정규화는주석없는정규 XML(Canonical XML, omits comments) 을사용하도록한다. 정규화는반드시국내규격인 TTAS.IF-RFC3076 을 준수하여야한다. <ds:canonicalizationmethod Algorithm="

55 변환 (Transform) 전체 XML 데이터중에서실제서명대상이되는데이터를가공하고선택하는과정을거치는알고리듬으로다양한변환알고리듬이존재하나그중에서 2가지만을이용하도록한다. 첫째는상기설명한정규화 (Canonicalization) 와서명대상정보를선택하는 XPath 필터링 (XPath Filtering) 이다. 또한전자 ( 세금 ) 계산서는 detached signature를이용하므로 Enveloped Signature( 알고리듬은사용해서는안된다. <ds:transform Algorithm=" 및 <ds:transform Algorithm=" <ds:xpath>not(self::*[name() = 'TaxInvoice'] ancestor-or-self::*[name() = 'ExchangedDocument'] ancestor-or-self::ds:signature)</ds:xpath> </ds:transform> 전자서명의대상 전자서명의대상전자 ( 세금 ) 계산서에생성시전자서명의대상이되는부분은기본정보 (TaxInvoiceDocument), 계산서정보 (TaxInvoiceTradeSettlement) 및상품정보 (TaxInvoiceTradeLineItem) 이며변환 (Transform) 알고리듬내에 XPath로정의되어있어야한다. 하나의전자서명대상에대해서다양한 XPath 표현이존재할수있지만각전자서명모듈간상호운용성보장을위하여반드시아래에나타난 XPath만을사용해야한다. <ds:transform Algorithm=" <ds:xpath>not(self::*[name() = 'TaxInvoice'] ancestor-or-self::*[name() = 'ExchangedDocument'] ancestor-or-self::ds:signature)</ds:xpath> </ds:transform> < 유의사항 > XPath 표현식중 default namespace를가지는 XML 문서의 null prefix를 XPath 형식으로표현하고자할때, XPath 규격의모호성으로인해전자서명모듈간해석의차이가발생하여 "not(self:::taxinvoice ancestor-or-self:::exchangeddocument ancestor-or-self::ds:signature)" 표현식의경우일부전자서명모듈을제외한대다수전자서명모듈에서는처리가불가능한것으로확인되었음. 따라서전자서명모듈간상호운용성보장을위하여 XPath 규격상논란의소지가없는 "not(self::*[name() = 'TaxInvoice'] ancestor-or-self::*[name() = 'ExchangedDocument'] ancestor-or-self::ds:signature)" 표현식만을사용해야함

56 전자서명수행및검증정보추가최종전자서명은 <SignedInfo> 노드에대해전자서명알고리듬에따라전자서명을수행한후결과값을 <SignatureValue> 에 Base64 인코딩하여저장하도록한다. 수신자측인국세청에서해당전자서명을검증하기위해전자서명자의인증서가필요하며이에따라인증서정보는 W3C XML-Signature Syntax and Processing (RFC3275) 에정의된 KeyInfo 구조체 ( 그림5-4, KeyInfo 의구조 참조 ) 중 X509Data 내의 X509Certificate 부분에넣어주어야한다. [ 그림 5-4] KeyInfo 의구조 X509Data( 그림 5-5, X509Data의구조 참조 ) 는 X509Certificate외에 X509 IssuerSerial, X509SubjectName 등이있으며이부분에해당값을넣어주는것은상관없다. 또한 [ 그림 5-5] 의다른부분, 예를들어 KeyValue 등에값을넣어주는것은관계없으나, 국세청에서는 X509Data 내의 X509Certificate 내에포함된인증서를이용하여데이터를검증할것이다. 인증서는최상위인증기관인증서로부터인증기관인증서, 실제사용자 ( 사업자 ) 인증서까지의체인구성을가지고있으며검증을위해서는이를모두필요로한다. 하지만최상위및인증기관인증서는국세청에서관리할것이므로실제 X509Certificate에는서명자인증서1개만넣어주면된다

57 [ 그림 5-5] X509Data 의구조 XML 전자서명의예 [ 그림 5-6] 은실제전자서명을수행한값의예이다. 전자서명의예를보여주기위한표현이므로 Name Space, 해시값, 인증서등은실제값과는다를수있다. 전자서명정보는 Signature 아래노드에저장이된다. [ 그림 5-6] XML 전자서명의예

58 전자서명의검증국세청에서사업자에게발급되는전자서명또한위전자서명의절차및기준과동일하게전자서명된문서이며사업자는이에대해필요시검증을수행한다. 또한전자서명시이용된전자서명인증서의검증은해당인증서를발급한인증체계의인증서검증방법을따르도록하며본개발지침에서는별도로정의하지않는다

59 5.3. 암호화 개요국세청에전송되는전자 ( 세금 ) 계산서는반드시기밀성을확보하여야하며이를위해다음과같은암호화과정을준수해야한다. 암호문은국내외에서각종표준으로이용되는 IETF RFC 3852 CMS(Cryptographic Message Syntax) 에서제시하는 ContentInfo 구조체로표현된 Enveloped-Data Content Type을사용한다. RFC 3852 CMS IETF는 TCP/IP와같은인터넷운영프로토콜의표준을정의하는주체이다. IETF는 IAB(Internet Architecture Board, 인터넷의기술적진화에대한 Internet Society의감독기구 ) 의감독을받으며, IETF 구성원들은 Internet Society 의개인또는조직의구성원들로부터선발된다. IETF에서제작된표준들은 RFC의형태로나타내어지며국내외많은 PKI 기반솔루션 ( 각종인증시스템, 타임스탬프, 공인전자문서보관소규격등 ) 은이러한 RFC 표준문서를기반으로만들어진다. CMS(Cryptographic Message Syntax) 는최초 RSA 사에작성한 PKCS#7 v1.5 를근간으로만들어졌으며, 이를 IETF에서규격화한 RFC 표준으로작성한것이 RFC2630이다. 최초 PKCS#7에는 key transfer( 암호화에이용된대칭키를 RSA를이용하여상대방에게전달 ) 방식만이있었으나 RFC2630의 CMS에서는 key agreement(dh 알고리듬을이용하여키를전달하는방식 ) 등이추가되었다. 후에알고리듬부분을별도분리및다양한키관리기법을적용한 RFC3369가 2002년도에제정되었으며, RFC3369의내용중문제가되는부분이많이보고되었고이를최종수정한버전이본지침에서적용한 RFC 3852이다. 추가적용표준암호문생성시 Content Encryption( 실제전송되는전자 ( 세금 ) 계산서패키지, 지침 절참조 ) 시사용되는알고리듬및알고리듬에해당하는파라미터등은 IETF RFC 3370 Cryptographic Message Syntax(CMS) Algorithm 및 IETF RFC 4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax(CMS) 을따른다 암호화대상데이터암호화하는대상은전자서명된전자 ( 세금 ) 계산서인 XML 형태의데이터이며, 단일또는복수의데이터를처리할수있도록하며최소 1개이상의전자 ( 세금 ) 계산서를포함하여야한다. 전자서명을생성한서명자가전자 ( 세금 ) 계산서공급사업자본인인지확인을할수있어야하며, 이를위해 vid 검증정보 (R value) 가전송되어야한다. vid 검증정보는개별전자 ( 세금 ) 계산서마다해당 vid 검증정보가세트로구성되고넣을수있는최대세트의개수는 100 개이다

60 다음은대상데이터의구성방법이다. 데이터는 ASN.1 Basic Encoding Rules(BER) 을 따르며 Distinguished Encoding Rules(DER) 를준수하도록한다. TaxInvoicePackage ::= SEQUENCE { count InvoiceCount, taxinvoiceset TaxInvoiceSet } InvoiceCount ::= INTEGER TaxInvoiceSet ::= SET SIZE (1..100) OF TaxInvoiceData TaxIvnoiceData ::= SEQUENCE { rvalue SignerRvalue, taxinvoice TaxInvoice } TaxInvoice ::= OCTET STRING SignerRvalue ::= OCTET STRING count 에는 TaxInvoice 의개수를넣어준다. taxinvoice 는개별전자 ( 세금 ) 계산서의 XML 데이터이다. rvalue 는해당하는 taxinvoice 서명검증시본인확인을위한 vid 검증용값이다. ( 지침 절참조 ) EnvelopedData 의구성 다음은 RFC 3852 의 EnvelopedData 의구성이다. EnvelopedData ::= SEQUENCE { version CMSversion, originatorinfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientinfos RecipientInfos, encryptedcontentinfo EncryptedContentInfo, unprotectedattrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } version 은 RFC 3852 의 syntax version number 구성을따른다. originatorinfo 는 key management 알고리듬을이용하지않고 CRL 을전송할필요가없으므로사용하지않는다. (RFC 3852 에정의되어있음 ) 현재이용할수있는암호용인증서의알고리듬이 RSA 이므로 RecipientInfos 의 KeyTransRecipientInfo 를통해수신자가복호화할수있는키 (content-encryption key) 를전달한다. encryptedcontentinfo 에는내부에정의된 Algorithm Identifier 의알고리듬을기반으로암호화한 TaxInvoicePackage 를넣어준다. unprotectedattrs 는이버전에서는별도로이용하지않으므로송신자측에서관리의목적으로값을넣어줄수있으나수신자측에서는이를풀어보거나값을이용할필요는없다

61 EnvelopedData 의생성 다음은 RFC 3852 의 EnvelopedData 의생성에있어주요부분에대한설명이다. encryptedcontentinfo 의생성 EncryptedContentInfo ::= SEQUENCE { contenttype ContentType, contentencryptionalgorithm ContentEncryptionAlgorithmIdentifier, encryptedcontent [0] IMPLICIT EncryptedContent OPTIONAL } - ContentType은 id-data( 암호화된데이터가어떤정보인지를알려주는구분자 -OID- 정보임 ) 를넣는다. - contentencryptionalgorithm 은지침 5.3.6절에정의된알고리듬중실제암호화에이용된대칭키알고리듬정보를넣는다. - encryptedcontent의입력은위정의된 TaxInvoicePackage 의 DER 인코딩된값을 contentencryptionalgorithm에정의된알고리듬방식으로암호화한 OCTET STRING(Binary 값 ) 이다. recepientinfo의생성 RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo RecipientInfo ::= CHOICE { ktri KeyTransRecipientInfo, kari [1] KeyAgreeRecipientInfo, kekri [2] KEKRecipientInfo, pwri [3] PasswordRecipientInfo, ori [4] OtherRecipientInfo } - 수신대상이하나이므로실제 RecipientInfos 는하위에 RecipientInfo 를하나만가진다. - 암호용인증서가 RSA 를이용하므로 ktri( 상대방 RSA 공개키등을이용하여데이터를 암호화한대칭키를보내는방식 ) 만을이용하여구성하도록한다 메시지에대한 OID 정의 메시지구성을위한 Object Identifier 는다음과같다. EnvelopedData Type RFC3852 CMS 에서실제데이터를전달하는포맷은 ContentInfo 라는구조체이며내부에있는데이터가어떤데이터인지를확인할수있도록 ContentType 에넣어주는정보이다. - id-envelopeddata - OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

62 EncryptedContentInfo의 ContentType 암호화된데이터를넣는구조체인 EncryptedContentInfo 구조체에서내부에있는데이터가어떤데이터인지를확인할수있도록 ContentType에넣어주는정보이다. - id-data - OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 암호화알고리듬암호화에서이용되는알고리듬은크게두가지로구분된다. 대상데이터를직접암호화하는데이용하는대칭키알고리듬과대칭키를수신자만복호화할수있게전달하는공개키알고리듬이다. 공개키알고리듬은이용되는인증서는 NPKI 체계의암호용인증서이므로 RSA 기반알고리듬을이용하게되며, 대칭키알고리듬에대해서는반드시아래에속한대칭키암호알고리듬세가지 (SEED, ARIA, 3DES) 중하나를택해서사용해야한다. 송신자측은대칭키암호알고리듬세가지중한가지만지원해도관계없으나, 수신자측은세가지알고리듬에대해모두지원이가능하여야한다. 비대칭키알고리듬비대칭키알고리듬 (RSA) 은랜덤하게생성되어데이터를암호화한대칭키정보를상대방에게안전하게암호화하여전달하는데이용된다. RSA Encryption - rsaencryption - OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 대칭키알고리듬 대칭키알고리듬 (SEED, ARIA, 3DES) 은랜덤하게생성되어실제전달데이터를암호화 하는데이용된다

63 Triple-DES CBC - des-ede3-cbc - OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionalgorithm(3) 7 } - Algorithm의파라미터는반드시존재해야하며 parameters는반드시 CBCParameter를가지고있어야한다. 또는 SEED CBC - id-seedcbc - OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) kisa(200004) algorithm(1) seedcbc(4) - Algorithm의파라미터는반드시존재해야하며 parameters는반드시 SeedCBCParameter를가지고있어야한다. 또는 ARIA CBC - id-aria128-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) gcma(100001) gpki-alg(1) aria128-cbc(20) } - id-aria192-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) gcma(100001) gpki-alg(1) aria192-cbc(21) } - id-aria256-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) gcma(100001) gpki-alg(1) aria256-cbc(22) } Algorithm의파라미터는반드시존재하여야하며 parameters는반드시 ARIACBCParameter를가지고있어야한다. ARIACBCParameter::= ARIAIV -- Initialization Vector ARIAIV ::= OCTET STRING(SIZE(16)) 국세청인증서의획득과검증 국세청인증서의획득암호문생성을위해서는실제데이터를복호화하려는수신자측의인증서를획득하여야만가능하다. 인증서의획득은웹에게시된인증서를이용하거나 LDAP 서버등인증서가게시된곳에서가져오거나또는프로토콜상에서상대방인증서를획득할수있는방법이있다. 사업자는위의다양한방법중향후국세청에서지정한방법을통해인증서를획득하여야한다. 국세청인증서의검증정보보호를위해상대방의인증서가유효한지상태확인을수행하여야한다. 상태확인시기는최초시점및 CRL 등인증서유효를확인하는정보의유효기간만료시각후최초이용시점이다

64 EnvelopedData 의구성 [ 그림 5-7] 은실제국세청에전달해야할암호화된 ( 세금 ) 계산서의구성이다. [ 그림 5-7] 을 통해실제값들의연계관계에대해보다정확하게파악할수있을것이다. [ 그림 5-7] EnvelopedData 의구성 ContentInfo ContentInfo는 RFC 3852에표현된것으로 RFC 3852의구성데이터인 SignedData, EnvelopedData, EncryptedData 등을넣어주는일종의컨테이너이다. 구조체의 contenttype은 content가어떤정보인지를가리킨다. 본지침에서는 id-envelopeddata 라는구분자 (Object Identifier) 를넣어주어야한다. EnvelopedData 암호화정보를전달하기위한구조체 ( 본절의설명참조 )

65 EncryptedContentInfo 암호화된정보를보관하는구조체이다. 구조체의 contenttype은 encryptedcontent가어떤정보인지를가리킨다. 본지침에서는 id-data 라는구분자 (Object Identifier) 를넣어주어야한다. contentencryptionalgorithm 은 SEED, ARIA, 3DES 중의하나에대한구분자 (OID) 를넣어주어야하며 encryptedcontent에랜덤하게생성된비밀키를이용하여해당알고리듬으로암호화한데이터를 OCTET STRING( 바이너리데이터 ) 으로넣어준다. TaxInvoicePackage 실제국세청에암호화하여전달할전자 ( 세금 ) 계산서리스트이다. 포함되는값은전체개수와전자 ( 세금 ) 계산서및해당전자 ( 세금 ) 계산서에대한본인확인을위한정보들의 SET로구성된다. RecipientInfo 어떤방법을이용하여수신자가복호화할지를선택하는구조체이다. 본지침에서는 KeyTransRecipientInfo를이용해야한다. KeyTransRecipientInfo 수신자 ( 국세청 ) 이복호화할수있도록위에서서술한 encryptedcontent 를암호화한랜덤한비밀키를수신자의공개키를이용하여암호화하여전달하는데이용하는구조체이다. 암호화한비밀키는 encryptedkey에넣어주며, 누구의공개키를이용하였는지에대한정보인 RecipientIdentifier 및비밀키를암호화하는데이용한알고리듬정보인 KeyEncryptionAlgorithmIdentifier 등을포함한다

66 6. 전자 ( 세금 ) 계산서통신 6.1. 개요 사업자가국세청에전자 ( 세금 ) 계산서를온라인으로전송하기위해서는전송및응답을위한기본통신규약이필요하다. 본절에서는이를위한 ( 세금 ) 계산서통신프로토콜, 메시지교환패턴 (MEP: Message Exchange Pattern), 메시지구조및전송보안에대해서표준을제시하고이를구현하기위한지침을제시한다 통신규약표준의범위사업자가국세청에전자 ( 세금 ) 계산서를전송하고, 전송결과에대한응답을받기위해서는전달하고자하는문서를싸고있는메시지봉투, 전송프로세스및전송처리방식에대해서통신표준을제시하여야한다. 본지침에서는이러한통신표준으로는기본적으로다음과같은국제 e-비즈니스표준규약을기본으로한다. SOAP v1.1 또는 v1.2 SOAP Messages with Attachment WS-Security v1.1 WS-Addressing v1.0 본지침에서는이러한규약을기반으로국세청과연계를위한상세통신프로세스및전송메시지구조, 전송보안등의방안등을제시한다

67 6.2. 통신프로세스및메시지구조 통신프로세스개요국세청에전자 ( 세금 ) 계산서를전송하기위해서가장중심이되는프로세스는 ( 세금 ) 계산서전송과이에대한처리결과를수신하는것이다. 이를위해사업자들은메시지통신프로토콜로 SOAP v1.1 또는 SOAP v1.2를채택하여국세청과연계하여야하며, 세부적인메시지교환은 1) 사업자가국세청에전자 ( 세금 ) 계산서를전송하는단계, 2) 사업자가국세청으로부터처리결과를수신하는단계로처리되는것이일반적이다. 만약사업자가처리결과를국세청으로부터직접수신할수없는경우나처리결과수신에실패한경우에는선택적방안으로 3) 사업자가국세청에처리결과를보내줄것을요청하고처리결과문서를수신하는단계를추가할수있다. 각단계는 SOAP Request-Response 메시지교환양식 (MEP: Message Exchange Pattern) 에따라동기식요청과응답메시지로구성되며, 각단계들간에는비동기식으로처리가이루어진다. 전송프로세스에대한전체흐름은 [ 그림 2-7] 전자 ( 세금 ) 계산서전송프로세스 을참조한다 전자 ( 세금 ) 계산서송 / 수신처리절차 1) 전송처리절차 사업자가전자 ( 세금 ) 계산서를국세청에전송하기위한상세절차는 [ 그림 6-1] 과같다. [ 그림 6-1] 전자 ( 세금 ) 계산서전송절차

68 2) 처리결과메시지수신절차 사업자가국세청으로부터전자 ( 세금 ) 계산서처리후처리결과를수신하기위한상세절차는 [ 그림 6-2] 와같다. [ 그림 6-2] 처리결과수신절차 메시지기본구조국세청과사업자간의연계를위한요청및응답메시지는 SOAP v1.1 또는 v1.2 규약을준수해야한다. 사업자측에서보내는전송메시지가 SOAP v1.1인경우에는국세청이보내는응답메시지도 v1.1로생성되고, 전송메시지가 SOAP v1.2인경우에는응답메시지도 v1.2로생성되어전달된다. SOAP메시지의상세한구조및항목은 w3.org에서제시하는표준규약을참조하면되는데, SOAP v1.1은 에서 SOAP v1.2는 를통해확인할수있다. 요청및응답메시지는 "SOAP Messages with Attachments"( 규약에따라기본적으로 Multipart-MIME 형식으로구성된다. 첫번째 MIME Part에는 SOAP Envelope 메시지가들어가고두번째 MIME Part에는전자 ( 세금 ) 계산서, 접수증그리고처리결과와같은업무문서가들어간다. 두번째 MIME의 Content-Type은 application/octet-stream" 으로설정하고첨부문서는encoding하지않은 binary형태로첨부한다. 업무에따라첨부문서가없는처리결과요청메시지나처리결과수신확인메시지와같은경우에는두번째 MIME이없이메시지가구성된다

69 SOAP Envelope 메시지는전송을위한메타데이터를담고있는 SOAP Header와업무정보를담고있는 SOAP Body로구성된다. 국세청과사업자간의연계시일어나는모든업무는본장에서제시하는메시지구조를통해정의되며모든메시지는 UTF-8 인코딩을기본으로한다. 요청및응답메시지기본구성 [ 그림 6-3] 메시지구조 SOAP Envelope SOAP Envelope은 SOAP 메시지의 Root 항목으로 SOAP 메시지내의각종 Namespace 들을선언한다. 선언해야할 Namespace는 [ 표 6-1] 과같다. [ 표 6-1] Namespace 항목 항목 Namespace URL SOAP Digital Signature WS-addressing Web Services Security -secext-1.0.xsd Web Services Security Utility -utility-1.0.xsd XML Schema XML Schema Instance KEC

70 SOAP Envelope의실제예시는다음과같다. <SOAP:Envelope xmlns:soap=" xmlns:ds=" xmlns:wsa=" xmlns:wsse=" xmlns:wsu=" xmlns:xsd=" xmlns:xsi=" xmlns:kec=" xsi:schemalocation=" </SOAP:Envelope> SOAP Header SOAP Header는내부적으로 WS-Addressing, Message Header 그리고 Security 로구성되는데세부구성은 [ 표 6-2] 와같다. 이때각항목들은반드시 [ 표 6-2] 에기술된순서대로구성되어야한다. [ 표 6-2] SOAP Header 엘리먼트구조 항목명 MessageID RelatesTo To Action 설명 메시지전송시 Unique 하게생성되어메시지를식별하는 ID 값 생성규칙 : 생성년월일시분초 (millisecond 까지 ) + '-' + (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f) 중임의로하나를 선택한것을 32 번반복, 즉 16 진수형식으로 32 자리기재 예 > YYYYMMDDHHmmssSSS-be3cfa2c0b1e4e4697e8d41f3f0674cb 요청에대한응답메시지에만필요한항목 이전요청메시지의 MessageID 값을설정 메시지수신자의주소정보 예 1> 사업자가국세청으로메시지를보내는경우국세청의 메시지수신 Endpoint 를입력 예 2> 국세청이사업자로메시지를보내는경우사업자의 메시지수신 Endpoint 를입력 필수항목으로서반드시기술되어야함 전송메시지유형별로정의된 action 값을기술 기정의된 action 전자 ( 세금 ) 계산서전송 : 전자 ( 세금 ) 계산서수신확인 : 반복회수 유형길이 1..1 S S S 최대 S 최대

71 Message Header Security 전자 ( 세금 ) 계산서처리결과전송 : 처리결과에대한수신확인 : 처리결과전송요청 : 처리결과전송요청에대한수신확인 : 전송하는메시지에대한추가정보를담아서기술함 MessageHeader 의하위엘리먼트에대한상세구조는 [ 표 6-3] 에서상세하게기술 WS-Security 규약에의해메시지에대한전자서명정보를기술함 이항목에대한상세정보는 지침 6.3.2절전자서명 부분참조 SOAP Header의실제예시는다음과같다. <SOAP:Header> <wsa:messageid> be3cfa2c0b1e4e4697e8d41f3f0674cb</wsa:messageid> <wsa:to> <wsa:action> <kec:messageheader> ~~~~ </kec:messageheader> <Security> ~~~~ </Security> </SOAP:Header> Message Header Message Header 는메시지에대한추가적인정보로구성되어있다. 상세구조는 [ 표 6-3] 과같다. 이때각항목들은반드시 [ 표 6-3] 에기술된순서대로구성되어야한다. [ 표 6-3] Message Header 엘리먼트구조 항목명 설명 반복회수 유형길이 Version 전자 ( 세금 ) 계산서통신규약버전 이번지침에서는 3.0 으로설정 1..1 S 3 From 메시지전송사업자의정보를기술 1..1 PartyID 전송하는측의사업자등록번호 ( 국세청또는사업자 ) 사업자등록번호의경우 '-' 제외 1..1 S 10 PartyName 전송하는측의사업자명 1..1 S 최대

72 To 메시지수신사업자의정보를기술 1..1 PartyID 수신하는측의사업자등록번호 ( 국세청또는사업자 ) 사업자등록번호의경우 '-' 제외 1..1 S 10 PartyName 수신하는측의사업자명 1..1 S 200 전자 ( 세금 ) 계산서처리결과를비동기식으로 ReplyTo 받을사업자의메시지수신 Endpoint 사업자가전자 ( 세금 ) 계산서를국세청에전송할 때는반드시이정보를기술하여야함 0..1 S 최대 256 OperationType 메시지송 / 수신업무명 ( 표 6-12 송수신문서코드표참조 ) 1..1 N 2 SOAP Request-Response MEP 기준으로봤을때 MessageType TimeStamp 요청메시지인지, 응답메시지인지여부를기술 ( 표 6-12 송수신문서코드표참조 ) 메시지전송시간을기술 UTC 형식으로입력 예 > T09:30:05.801Z 1..1 N S 24 Message Header 의실제예시는다음과같다. <kec:messageheader wsu:id="msgheader"> <kec:version>3.0</kec:version> <kec:from> <kec:partyid> </kec:partyid> <kec:partyname> 한국인터넷진흥원 </kec:partyname> </kec:from> <kec:to> <kec:partyid> </kec:partyid> <kec:partyname> 국세청 </kec:partyname> </kec:to> <kec:replyto> <kec:operationtype>01</kec:operationtype> <kec:messagetype>01</kec:messagetype> <kec:timestamp> t09:32:05.801z</kec:timestamp> </kec:messageheader> SOAP Body SOAP Body는요청 / 응답에따라 Request/Response 또는 Fault 메시지로구성된다. Request/Response 에대한상세구조는 지침 절업무별 Request, Response data 및첨부문서구조 에서기술하고있으며, Fault 구조는 지침 SOAP Fault 에서기술하고있다

73 SOAP Fault 국세청이나사업자는 SOAP 통신오류가발생하거나, 수신한메시지가 SOAP 메시지의기본구조에맞지않거나, WS-Security 규약에따라 SOAP 메시지에추가된전송사업자의전자서명이유효하지않은경우 SOAP Fault 오류를생성하여전송사업자에게다시전달한다. SOAP 오류가발생한경우에는 SOAP Fault 메시지는 SOAP Body 안에포함되어전송되며, SOAP Fault 엘리먼트는 SOAP Body 엘리먼트하위에한번만존재한다. SOAP 규약버전에따라다음과같은구조를갖는다. 1) SOAP Fault - v1.1 SOAP 규약 v1.1인경우에는 [ 표 6-4] 와같이구성되어야한다. [ 표 6-4] SOAP Fault 구조 -v1.1 항목명 설명 반복횟수 유형길이 Fault SOAP Fault 메시지의루트 1..1 faultcode faultstring Fault 를식별하는코드로서 code 값은 3) SOAP Fault Code 및설명 부분을참조 이용자가인지할수있도록 Fault 를설명하는스트링으로 3) SOAP Fault Code 및설명 부분을참조 1..1 S S 최대 50 2) SOAP Fault - v1.2 SOAP 규약 v1.2 인경우에는 [ 표 6-5] 와같이구성되어야한다. [ 표 6-5] SOAP Fault 구조 -v1.2 항목명 설명 반복횟수 유형길이 Fault SOAP Fault 메시지의루트 1..1 Code SOAP Fault 코드정의 1..1 Value Reason Subcode Fault 를식별하는주코드 SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) 참조 Fault 를식별하는세부코드. code 값 3) SOAP Fault Code 및설명 부분을참조 이용자가인지할수있도록 Fault 를설명하는스트링으로 3) SOAP Fault Code 및설명 부분을참조 1..1 S 최대 S S 최대

74 3) SOAP Fault Code 및설명 SOAP Fault 메시지는 [ 표 6-6] 과같은코드값과설명을위한값을갖는다. [ 표 6-6] SOAP Fault Code 및설명 faultcode(value) faultstring(reason) 설명 WSM001 SOAP Message 통신오류 VersionMismatch MustUnderstand SOAP 메시지처리도중유효하지않은 SOAP Envelope namespace 발견시 SOAP 헤더중 mustunderstand 값이 1 로설정되었으나이항목을수신측에서이해하지못하거나처리하지못하는경우 WSM002 SOAP Message 구조오류 DataEncodingUnknown Soap header 나 body 내에받는쪽노드가지원하지않는 data encoding 을요구하는엘리먼트가있는경우발생 InvalidSOAPHeader SOAP Header 구조가규격에맞지않는경우 InvalidSOAPBody SOAP Body 구조가규격에맞지않는경우 WSM003 SOAP Message 전자서명오류 InvalidSignature 서명검증에서검증값이유효하지않은경우 업무별 Request, Response data 및첨부문서구조 국세청과사업자간의연계업무는크게전자 ( 세금 ) 계산서제출, 처리결과전송그리고처리 결과요청으로나눌수있고, 각업무별로 SOAP Body 및첨부문서는다른구조를가진다 전자 ( 세금 ) 계산서제출업무전자 ( 세금 ) 계산서제출업무는사업자가국세청에전자 ( 세금 ) 계산서를전송하는업무이다. 본업무는사업자가국세청으로전자 ( 세금 ) 계산서를보내는요청업무와국세청이해당전자 ( 세금 ) 계산서제출에대한접수증을보내는응답업무로구성된다. 이러한전자 ( 세금 ) 계산서전송 ( 요청 )/ 접수증교부 ( 응답 ) 업무는동기식메시지교환방식으로이루어진다. 1) 요청메시지구조가 ) SOAP Body 사업자가국세청에전자 ( 세금 ) 계산서를제출할때 SOAP Body는 [ 표 6-7] 과같이구성되어야한다

75 항목명 [ 표 6-7] 전자 ( 세금 ) 계산서제출업무요청메시지의 SOAP Body 구조 설명 RequestMessage 요청메시지루트 1..1 SubmitID 제출, 수신확인및처리결과수신을포함하여 한번의제출에따른전체프로세스를 구분하기위한 ID 제출단위로 unique 한값부여 국세청등록번호 + '-' + 년월일 + '-' + (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f) 중 임의로하나를선택한것을 32 번반복, 즉 16 진수형식으로 32 자리기재 예 > yyyymmdd-be3cfa2c0b1e4e4697 e8d41f3f0674cb 반복회수 유형길이 1..1 S 50 TotalCount 첨부전자 ( 세금 ) 계산서의총개수 1..1 N 3 ReferenceID 첨부 MIME Header 의 Content-ID 값 1..1 S 최대 50 실제예시는다음과같다. <kec:requestmessage> <kec:submitid> be3cfa2c0b1e4e4697e8d41f3f0674cb</kec:submitid> <kec:totalcount>100</kec:totalcount> <kec:referenceid> </kec:referenceid> </kec:requestmessage> 나 ) 첨부문서 전자 ( 세금 ) 계산서제출업무에대한첨부문서는암호화된전자 ( 세금 ) 계산서파일이다. 암호화하는방식및방법에대해서는 지침 5.3 절암호화 에서상세하게기술하고있다. 2) 응답메시지구조 가 ) SOAP Body 사업자가국세청에전자 ( 세금 ) 계산서를제출하면국세청은접수증을교부하는데이때응답 메시지의 SOAP Body 는 [ 표 6-8] 과같이구성되어야한다. 항목명 설명 ResponseMessage 응답메시지루트 1..1 RefSubmitID [ 표 6-8] 전자 ( 세금 ) 계산서제출업무응답메시지의 SOAP Body 구조 사업자가전자 ( 세금 ) 계산서를제출했을때 설정한 SubmitID 값 반복회수 유형길이 1..1 S

76 실제예시는다음과같다. <kec:responsemessage> <kec:refsubmitid> be3cfa2c0b1e4e4697e8d41f3f0674cb</kec:refsubmitid> </kec:responsemessage> 나 ) 첨부문서 접수증교부메시지에대한첨부문서는전자서명된접수증이다. 접수증의구조는 지침 절전자 ( 세금 ) 계산서접수증 에서상세하게기술하고있다 처리결과전송업무처리결과전송업무는국세청이사업자에전자 ( 세금 ) 계산서처리결과를전송하는업무이다. 본업무는국세청이사업자에처리결과메시지를보내는요청업무와사업자가처리결과수신확인메시지를보내는응답업무로구성된다. 이러한처리결과전송 ( 요청 )/ 수신확인 ( 응답 ) 업무는동기식메시지교환방식으로이루어진다. 1) 요청메시지구조가 ) SOAP Body 국세청이사업자에처리결과를전송할때 SOAP Body는 [ 표 6-9] 와같이구성되어야한다. [ 표 6-9] 처리결과전송업무요청메시지의 SOAP Body 구조 항목명 설명 반복회수 유형길이 RequestMessage 요청메시지루트 1..1 ResultID 처리결과송수신을구분하기위한 ID 제출전자 ( 세금 ) 계산서단위로 unique한값부여 년월일 + (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f) 중임의로하나를선택한것을 32번반복, 즉 16진수형식으로 32자리기재 예 >yyyymmddb93fc588ad141b58cf9f063a S 40 ReferenceID 페이로드 MIME Header 의 Content-ID 값 1..1 S 최대 50 실제예시는다음과같다. <kec:requestmessage> <kec:resultid> b93fc588ad141b58cf9f063a </kec:resultid> <kec:referenceid> </kec:referenceid> </kec:requestmessage>

77 나 ) 첨부문서 처리결과전송업무에대한첨부문서는전자서명이적용된결과목록으로구성되어야 한다. 세부구성은 지침 절처리결과문서 에서상세하게기술하고있다. 2) 응답메시지구조 가 ) SOAP Body 국세청이사업자에처리결과를전송하면사업자는응답으로수신확인메시지를보내야하는데이응답메시지의 SOAP Body 는 [ 표 6-10] 과같이구성되어야한다. [ 표 6-10] 처리결과전송업무응답메시지의 SOAP Body 구조 항목명 설명 반복회수 유형길이 ResponseMessage 응답메시지루트 1..1 RefResultID 국세청이처리결과를보냈을때설정한 ResultID 값 1..1 S 40 실제예시는다음과같다. <kec:responsemessage> <kec:refresultid> b93fc588ad141b58cf9f063a </kec:refresultid> </kec:responsemessage> 나 ) 첨부문서 첨부문서없음 처리결과요청업무 처리결과요청업무는사업자가제출한전자 ( 세금 ) 계산서의처리결과전송을국세청에 요청하는업무이다. 본업무는사업자가국세청에처리결과요청메시지를보내는요청업무와 국세청이처리결과메시지를보내는응답업무로구성된다. 이러한처리결과요청전송 ( 요청 )/ 처리결과전송 ( 응답 ) 업무는동기식메시지교환방식으로이루어진다. 1) 요청메시지구조 가 ) SOAP Body 사업자가국세청에전자 ( 세금 ) 계산서처리결과를요청할때 SOAP Body 는 [ 표 6-11] 과같이구성되어야한다. [ 표 6-11] 처리결과요청업무요청메시지의 SOAP Body 구조 항목명 설명 반복회수 유형길이 RequestMessage 응답메시지루트 1..1 RefSubmitD 사업자가전자 ( 세금 ) 계산서를제출했을때설정한 SubmitID 값 1..1 S

78 실제예시는다음과같다. <kec:requestmessage> <kec:refsmitid> be3cfa2c0b1e4e4697e8d41f3f0674cb</kec:refsubmitid> </kec:requestmessage> 나 ) 첨부문서 첨부문서없음 2) 응답메시지구조가 ) SOAP Body 국세청이사업자에처리결과를전송할때 SOAP Body는 [ 표 6-12] 와같이구성되어야한다. [ 표 6-12] 처리결과요청업무응답메시지의 SOAP Body 구조 항목명 설명 반복 회수 유형길이 ResponseMessage 요청메시지루트 1..1 처리결과송수신을구분하기위한 ID 제출전자 ( 세금 ) 계산서단위로 unique 한값부여 ResultID 연월일 + (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f) 중임의로하나를선택한것을 32번반복, 즉 16진수형식으로 32자리기재예 >yyyymmddb93fc588ad141b58cf9f063a S 40 ReferenceID 페이로드 MIME Header 의 Content-ID 값 1..1 S 최대 50 실제예시는다음과같다. <kec:responsemessage> <kec:resultid> b93fc588ad141b58cf9f063a </kec:resultid> <kec:referenceid> </kec:referenceid> </kec:responsemessage> 나 ) 첨부문서 처리결과전송업무에대한첨부문서는전자서명이적용된결과목록으로구성되어야 한다. 세부구성은 지침 절처리결과문서 에서상세하게기술하고있다

79 송수신문서코드표 [ 표 6-13] 송수신문서코드표 식별코드항목명코드값코드값정의 01 전자 ( 세금 ) 계산서제출업무 OperationType 02 처리결과전송업무 03 처리결과요청업무 MessageType 01 요청 (Request) 02 응답 (Response)

80 6.3. 전송보안 전송보안개요국세청과사업자간주요메시지 ( 전자 ( 세금 ) 계산서 ) 는문서를생성하고첨부하는과정에서이미전자서명과암호화가이루어진다. 이경우기밀성은보장이되어추가로암호화를하지는않으나, 전자 ( 세금 ) 계산서의발급자와국세청전송사업자가다를수있으므로전송단계에서는전송에대한신뢰성확보를위해전송메시지는전송사업자에의해다시한번전자서명이이루어진후전송하게된다. 반대로국세청에서수신확인및처리결과를보낼때는내용에대한기밀성을요하지않는문서이므로, 전송시에별도의보안처리 ( 암호화 ) 를하지않는것으로한다. 이때전송메시지에대한전자서명은 WS-Security v1.1 규약을기준으로생성되어야한다. 프로세스의각처리단계별로전자서명및암호화가적용되는절차는 지침 2.3.2절연동프로세스 를참조한다 메시지전자서명항목사업자가국세청으로메시지를전송하는경우나, 국세청이사업자에게메시지를전송하는경우모두 "SOAP" 과 "SOAP Messages with Attachments" 규약에따라메시지를생성하고나면, 메시지를전송하기전에각각의개인키로전송메시지에대해전자서명을한다. 메시지에 WS-Security 기반의전자서명이수행되는구조는 [ 그림 6-4] 와같다. [ 그림 6-4] 메시지전자서명적용구조