KSeF 연동 EZD만으로는 아직 송장 처리 흐름이 아니다

이 글은 공급업체로부터 "저희 EZD는 KSeF를 지원합니다"라는 말을 듣고, 이것으로 송장 처리 흐름 문제가 해결되는지 궁금한 사무국장(sekretarz)과 재무관(skarbnik)을 위한 것이다.

EZD와 KSeF 연동이 실제로 하는 일

2026년 2월 1일부터 관청은 국가전자송장시스템(KSeF)을 통해 구조화된 송장을 수신하게 된다. EZD RP를 포함한 일부 EZD급 시스템은 이러한 송장을 자동으로 수신하여 수신 문서로 표시할 수 있다. 이는 실질적인 이점이다. 송장이 이메일함에 묻히지 않고 KSeF 번호와 접수일이 부여되어 시스템에서 바로 확인할 수 있기 때문이다. 하지만 대개 곧바로 해당 사건으로 연결되지는 않는다. 먼저 접수실(biuro podawcze)이 이를 확인한 뒤 담당 부서로 전달하고, 그 부서가 비로소 송장을 해당 사건에 첨부한다. 그런데 접수실이 애초에 어느 부서로 이 송장을 배정해야 하는지 바로 알 수 있을까? 또한 송장의 메타데이터는 항목, 순액·총액, 부가가치세율 등 송장 자체를 설명할 뿐, 사무관리지침(instrukcja kancelaryjna)이 정한 수신 공문 등록 양식의 메타데이터 범위와 항상 일치하지는 않는다는 점도 기억해야 한다.

하지만 연동은 여기서 끝난다. 송장은 시스템에, 심지어 해당 사건에 들어가 있지만 아직 아무도 내용을 기술하지 않았고, 승인하지 않았고, 검증하지 않았고, 회계 처리도 하지 않았다. 이후 경로는 관청이 회계 문서 처리 흐름을 어떻게 설계했는지에 달려 있다. 많은 관청에서는 KSeF 도입 이전과 똑같은 방식이 이어진다. 출력, 뒷면이나 도장란에 서명, 재무 부서로 서류철 전달, 재무회계시스템에 수작업 입력.

접수부터 지급까지, 송장이 거치는 경로

모든 관청은 이러한 경로를 회계 문서의 처리 및 검증에 관한 지침(instrukcja obiegu i kontroli dokumentów księgowych)에 규정하고 있다. 세부 사항은 다르지만 단계는 대체로 비슷하다.

1. 접수. 송장은 KSeF를 통해 접수되지만 그것만은 아니다. 2026년 말까지는 일부 소규모 공급업체가 여전히 KSeF 외부에서 송장을 발행할 수 있으며, 해외 공급업체는 그 이후에도 계속 시스템 밖에서 송장을 발행한다. 송장은 여전히 이메일과 종이로도 접수되며, 종이 송장은 수작업 재입력을 피하기 위해 스캔하고 광학문자인식(OCR)으로 판독해야 한다. KSeF에는 일반적으로 첨부파일을 위한 공간이 없고(FA(3) 구조는 데이터 형태의 제한된 첨부파일만 허용하며, 이를 사용하려면 별도로 신고해야 한다), 그래서 공급업체는 흔히 같은 송장을 이메일로 한 번 더 보내면서 인수확인서, 작업내역서, 사양서 같은 관련 서류를 함께 첨부한다. 때로는 이미 KSeF에 등록된 송장의 출력본이나 PDF를 첨부파일 없이 보내오기도 한다. KSeF 장애 시나 오프라인 모드에서는 QR 코드가 포함된 송장이 시스템보다 먼저 관청에 도착한다. 따라서 관청은 해당 송장을 이미 보유하고 있다는 사실을 인지해 이중으로 처리하지 않도록 해야 한다. 게다가 송장만이 비용 문서인 것도 아니다. 보험증권, 민사계약에 따른 청구서, 전표, 수수료, 채권 결정 등도 비슷한 경로, 즉 내용 기술, 승인, 분류, 회계 처리, 지급의 과정을 거친다. 접수 경로와 종류에 상관없이 모든 비용 문서는 하나의 처리 흐름으로 들어와야 한다. 그렇지 않으면 관청은 KSeF로 들어온 송장을 위한 경로와 나머지 전부를 위한 별도의 종이 경로를 각각 운영하게 된다.
2. 계약 또는 발주와의 연결. 송장은 특정 계약, 주문 또는 발주와 관련이 있다. 때로는 계약과 연결하는 것으로 충분하다. 때로는 별도의 계약 없이 발주와만 연결해야 한다. 또 기본계약(framework agreement) 아래 여러 건의 발주가 이루어지고 송장이 그 중 하나에 해당하는 경우도 있어, 이때는 송장을 해당 발주와 연결하고 그 발주를 통해 다시 계약과 연결해야 한다. 제대로 연결되면 즉시 담당 부서, 정산할 금액, 그리고 해당 발주와 계약에서 남은 잔액이 드러난다. 계약 등록부와 발주 기록이 없으면 누군가 이를 수작업으로 찾아야 한다.
3. 내용 기술과 승인. 발주를 담당한 부서는 계약 또는 발주 내용에 따라 서비스가 수행되었거나 물품이 납품되었음을 확인한다. 하지만 여기서 끝나지 않는 경우가 많다. 구매가 여러 부서가 책임지는 여러 예산에서 조달된 경우, 각 부서는 자신의 예산에 부과되는 부분을 승인해야 한다. 지출이 정보통신 관련 성격을 띤다면, 담당 부서가 다른 부서라 하더라도 처리 지침상 보통 정보통신부서의 승인도 추가로 요구된다. 투자성 지출, EU 프로젝트, 공공조달의 경우도 비슷하다. 따라서 송장 하나에 세 번, 네 번의 승인이 필요할 수 있으며, 특히 종이로 이를 모두 모으는 일은 처리 과정 중 가장 지루한 부분이 되곤 한다. 송장은 휴가 중인 담당자의 책상 위에서 대기하거나, 빠진 서명을 받으러 되돌아오며, 지금 누구 손에 있는지 아무도 모르게 된다.
4. 재원과 예산 분류. 예산 분류 체계상의 항목(부·장·절)과 재정계획상의 과제를 지정해야 하며, 때로는 프로젝트와 재원까지 지정해야 한다. 누군가 계획상 해당 지출을 위한 예산이 있는지 확인한다.
5. 검증, 배정, 지급 승인. 회계 부서는 송장을 형식적·회계적 측면에서 검증하고, 수석 회계담당자(지방자치단체(JST)에서는 재무관(skarbnik))가 사전 통제를 확인한다. 이로써 증빙서류는 장부 기재 대상으로 분류된다. 재무관의 검증 이후에는 처리 지침상 담당 부서를 관할하는 집행부 구성원(게미나(기초자치단체)에서는 지자체장(시장) 또는 부단체장)의 추가 승인이 요구되는 경우가 많으며, 그가 부재 중일 때는 다른 집행부 구성원이 대신한다. 이는 또 한 명의 담당자, 또 하나의 서명, 그리고 처리 흐름이 누가 누구를 대리하는지 모를 경우 송장이 대기할 수 있는 또 다른 지점을 의미한다.
6. 재무회계시스템 기재. 승인된 송장은 회계 부서로 전달되어야 한다. 이는 시스템 간 접점 중 가장 중요한 지점이다. 여기에 연동이 없다면, 구조화된 파일 형태로 들어온 송장의 데이터를 누군가 출력물에서 다시 입력하게 된다.
7. 지급. 지급은 송장과 연결되어 있지만 그 일부는 아니며 별도의 과정이다. 보통 재무회계시스템이 이를 처리한다. 하나의 이체 묶음에는 여러 송장의 지급액이 함께 들어가며, 기한 관리와 필요한 경우 분할결제까지 포함된다. 송장 처리 흐름은 회계 부서에 완전한 데이터를 전달하고, 이후 해당 송장이 지급되었다는 사실을 인지하기만 하면 된다.
8. 보관. 내용 기술, 승인, 지급 확인이 모두 포함된 송장은 한곳에 보관되어 언제든 감사에 대비할 수 있어야 한다.

KSeF와 EZD의 연동이 담당하는 것은 첫 번째 단계와 여덟 번째 단계의 일부뿐이다. 나머지 여섯 단계는 그 바깥에서 이루어진다.

하나의 그림으로 보는 예시 프로세스

아래는 동일한 경로를 표준 프로세스 표기법인 BPMN으로 나타낸 것이다. 각 레인(lane)은 관청 내 하나의 역할을 뜻한다. 검은색 화살표는 누가 누구 다음에 작업하는지를 보여주고, 점선은 처리 흐름 밖에 있는 시스템들, 즉 KSeF, 거래처 카드(kartoteka kontrahentów), 계약·발주 등록부, 재무회계시스템과의 데이터 교환을 나타낸다. 톱니바퀴 아이콘이 있는 작업은 사람의 개입 없이 시스템이 수행할 수 있다. 움직이는 표시는 송장 한 건의 경로, 즉 KSeF에서 시작해 여러 승인 단계를 거쳐 회계 기재에 이르는 과정을 보여주며, 작은 표시들은 그 과정에서 시스템과 주고받는 데이터를 나타낸다. 이는 하나의 예시일 뿐 표준 양식은 아니다. 각 관청마다 레인, 승인 단계, 연동 방식은 조금씩 다를 것이다.

이러한 그림은 도구를 선택하기 전에 자신의 관청을 대상으로 직접 그려보는 것이 좋다. 승인 단계가 몇 개인지, 송장이 어디에서 대기할 수 있는지, 그리고 데이터가 시스템 간에 몇 군데에서 오가는지를 한눈에 파악할 수 있다.

송장 한 건이 거치는 시스템은 몇 개인가

송장의 경로를 상세히 그려보면, 그것이 KSeF, EZD급 시스템, 거래처 카드, 계약 등록부와 발주 기록(있는 경우), 재정계획과 예산시스템, 재무회계시스템, 전자뱅킹, 그리고 때로는 프로젝트나 공공조달을 위한 별도 시스템까지 거친다는 것을 알 수 있다. 여기에 더해 각 부서가 독자적으로 계약과 예산 집행 현황을 관리하는 엑셀 시트들도 있다.

연결되지 않은 시스템 간의 모든 전환은 곧 수작업을 의미한다. 번호 재입력, 금액 복사, 출력, 스캔, 확인 전화. 이러한 작업은 판단을 요구하지 않지만 여러 부서에 속한 여러 사람의 시간을 소모한다. 각자 자신의 일부만 수행하기 때문에 전체 과정을 보는 사람은 아무도 없다.

시간은 실제로 어디에서 사라지는가

내용 승인이나 재무관의 검증은 판단이 필요한 행위이므로 사람이 계속 담당해야 한다. 시간은 다른 곳, 즉 보조적인 작업에서 사라진다.

• 송장이 다른 경로로 이미 접수되지 않았는지 확인하는 일
• KSeF를 통하지 않고 들어온 종이 및 이메일 송장과 기타 비용 문서를 재입력하는 일
• 계약이나 발주, 그리고 발주한 부서를 찾는 일
• 계약서에서 이미 확인 가능한 예산 분류를 다시 기입하는 일
• 여러 부서로부터 승인을 받으러 서류철을 들고 다니고 지금 송장이 누구에게 있는지 확인하는 일
• 동일한 거래처를 두 개의 시스템에 각각 등록하는 일
• 송장 데이터를 재무회계시스템에 재입력하는 일

바로 이러한 작업들이야말로 자동화할 가치가 있다. 어려워서가 아니라, 송장 한 건마다 반복되며 관청에서는 연간 수천 건씩 발생하기 때문이다.

송장 처리 흐름에 현명하게 접근하는 방법

순서가 중요하다. 먼저 프로세스, 그다음 도구다.

목표는 전자 송장 처리 흐름을 도입하는 것이 아니다. 목표는 반복적인 보조 작업을 시스템이 수행할 수 있는 세상에서 비용 문서를 다루는 방식 자체를 바꾸는 것이다. 이는 여러 사람의 업무 방식을 바꾸는 일이며, 업무 방식의 변화는 지금과 다르게 할 수 있다는 상상에서 시작된다. 이것이 바로 디지털 전환의 본질이며, 모든 정보시스템 투자에서 이 원칙을 지킬 가치가 있다. 시스템을 구매하는 것 자체는 아직 변화가 아니다.

접수부터 지급까지 흐름을 기술한다. 재무관, 회계 부서, 사무국장, 그리고 몇몇 담당 부서가 함께 참여한다. 누가 무엇을 어떤 시스템에서 하는지, 얼마나 걸리는지, 송장이 어디서 대기하는지를 정리한다. 이런 기술 작업을 해보면 종이 시절 지침에 남아 있지만 이제는 아무도 그 이유를 기억하지 못하는 단계들이 종종 드러난다. 시스템 선택에 앞서 이러한 기술 작업을 어떻게 준비할지는 니즈 분석 페이지에서 다루고 있다.

승인이 어디에서 이루어질지 정한다. 반드시 EZD일 필요는 없다. 승인은 EZD급 시스템, 별도의 워크플로 도구, 또는 재무회계시스템의 모듈에서 이루어질 수 있다. 중요한 것은 모든 승인이 한곳에서 완전한 기록과 함께 이루어지고, 그 결과가 재입력 없이 다음 단계로 전달되는 것이다. 잘 설계된 처리 흐름은 지출의 재원과 성격에 따라 스스로 승인 경로를 결정하고, 순서가 중요하지 않은 경우에는 병렬로 승인을 진행하며, 휴가 기간에는 대리 승인자를 둔다. 프로세스 시스템과 회계 시스템의 차이는 BPM과 업무전용 시스템에 관한 글에서 다루고 있다.

처리 흐름을 재무회계시스템과 연동한다. 가장 중요한 연동이다. 승인이 완료된 송장의 데이터, 즉 내용 기술, 분류, 승인 내역이 출력물이 아니라 완성된 문서 형태로 회계 부서에 전달되어야 한다. 이는 세 가지 방식으로 구현할 수 있다. 가장 좋은 방법은 시스템 공급업체가 제공하는 프로그래밍 인터페이스(API)다. 두 번째는 회계시스템 데이터베이스에 직접 기록하는 방식인데, 이는 오류가 발생해도 나중에 발견하기 어렵기 때문에 공급업체의 동의와 참여가 필요하다. 세 번째는 시스템에 인터페이스가 없을 때 사용하는 로봇(RPA)이다. 이는 사람이 하듯 화면을 통해 사용자를 대신해 송장을 입력하는 단순한 프로그램이다. 로봇은 초기 도입이 빠르고 저렴할 수 있지만 취약하다. 업데이트 이후 화면 구성이 바뀌면 멈춰버릴 수 있기 때문이다. 공급업체가 인터페이스를 제공할 때까지의 임시 다리로 보는 것이 바람직하다. 지급과 이체 묶음 처리는 지금처럼 재무회계시스템에 그대로 둘 수 있다.

거래처 카드를 일치시킨다. 회계상의 송장은 올바른 거래처와 연결되어야 하므로 처리 흐름과 재무회계시스템은 동일한 대상을 가리켜야 한다. EZD급 시스템에는 보통 훨씬 더 많은 거래처가 등록되어 있다. 주민, 신청인, 그리고 송장을 발행할 일이 전혀 없이 관청에 문서를 보내는 기관들까지 포함되기 때문이다. 반면 재무회계시스템에는 관청과 실제 정산 관계가 있는 주체만 존재한다. 따라서 처음부터 관청 내 시스템에서 거래처 데이터의 생애주기에 관한 명확한 규칙, 즉 누가 언제 어느 시스템에 거래처를 등록하는지, 누가 언제 데이터를 갱신하는지, 한 시스템에서의 변경이 어떻게 나머지 시스템으로 전파되는지가 필요하다. 또한 예를 들어 사업자등록번호(NIP)를 기준으로 동일한 공급업체를 식별하는 방법도 필요하다. 그래야 송장에 등장한 새로운 공급업체가 회계 부서에서 중복 수작업 등록 없이 처리될 수 있다.

송장을 계약·발주 등록부와 연결한다. 이러한 연결은 담당 부서, 예산 분류, 그리고 계약에서 아직 정산되지 않은 잔액을 자동으로 알려준다.

처리지침을 갱신한다. 지침에 명시되지 않은 전자 승인은 결국 "형식을 갖추기 위해" 송장이 다시 출력되는 결과로 끝난다. 프로세스와 지침을 바꿀 때는 먼저 이상적인 상태, 즉 아무도 불필요한 보조 작업을 하지 않는 업무 방식을 그려보는 것이 좋다. 지침의 조문은 그 이후에 그 모습에 맞춰 조정해야 하며, 그 반대가 되어서는 안 된다.

참고 자료

• 재무부: 의무적 KSeF 적용 범위
• 1994년 9월 29일 회계법, ISAP (제21조, 제22조)
• 2009년 8월 27일 공공재정법, 하원 사무처 통합본 (제54조)
• Krogis 의무 일정표: KSeF, e-Doręczenia, EZD

2026년 10월 30일 기준 법령 현황입니다.