사용법
상단에서 **문서 유형**을 선택합니다 — `견적서`, `청구서`, `세금계산서` — 양식이 그에 맞게 라벨을 다시 표시합니다(견적서는 "유효 기간", 청구서는 "지급 기한"이 표시됩니다). **공급자**(나의 사업체: 상호·사업자등록번호·대표자·주소·연락처 이메일)와 **공급받는 자**(상대 사업체: 같은 필드)를 기재합니다. 설명·수량·단가·선택적 메모가 있는 **항목**을 추가합니다. 소계·세액·총액이 미리보기 창에서 실시간으로 갱신됩니다. **통화**(KRW·JPY·USD·EUR·GBP·CNY), **세율**(KR/JP 기본 10%, EN 기본 0% — 필요에 따라 조정), **템플릿 로케일**(kr / jp / en)을 선택합니다. 이는 최종 PDF의 라벨 언어와 날짜 형식을 제어하며 페이지 UI 언어와 독립적입니다.
**PDF 다운로드**를 클릭하면 pdf-lib와 CJK 대응 폰트 번들로 A4 벡터 PDF를 생성합니다. 한글·한자·가나·중국어 문자가 모두 또렷하게 렌더링됩니다. 일반적인 청구서(15행 이하)는 단일 페이지로, 긴 문서는 자동으로 페이지가 분할됩니다. 본 도구는 양식을 **localStorage**에 영속화하므로 페이지를 새로 고쳐도 작업이 사라지지 않습니다. 문서 본문과 재사용 가능한 공급자 정보는 별도 스토리지 키로 분리되어 있어 고객을 바꾸어도 자기 사업 정보를 다시 입력할 필요가 없습니다. PDF는 클라이언트 측에서 생성되며 **고객 데이터·항목·사업자등록번호는 브라우저를 떠나지 않습니다**. 청구서에 상업적으로 민감한 항목이나 가격이 들어가는 B2B 청구에서 중요한 부분입니다.
자주 묻는 질문
견적서·청구서·세금계산서의 차이는?
**견적서(Quote, Estimate, 見積書)**는 계약 성립 *전*의 작업과 가격에 대한 구속력 없는 제안이며 유효 기간(보통 30일)이 있고 세무 문서가 아닙니다. **청구서(Invoice, 請求書)**는 작업 납품 *후*(또는 선불의 경우 납품 전)의 지급 요청이며 미지급 금액과 지급 기한을 명시합니다. **세금계산서 / 適格請求書(Tax Invoice)**는 부가세·소비세 공제에 필요한 특별한 법적 형식의 청구서로, 판매자의 세무 등록번호와 항목별 세액 내역을 포함하며 구매자의 매입세액 공제 청구권을 트리거합니다. 대부분의 관할 구역에서는 일반 청구서가 필수 필드를 포함하면 세무 청구서를 겸합니다. 한국과 일본에는 엄격한 형식 요건을 갖춘 별도의 공식 세무 청구서 체계(세금계산서와 適格請求書)가 있습니다. 본 도구에서 문서 유형을 전환하면 필드가 재라벨링되고 유효 기간·지급 기한 프롬프트가 그에 맞게 조정됩니다.
각 국가의 사업자번호 형식은?
**한국**: 사업자등록번호는 국세청이 발급하는 **10자리 `XXX-XX-XXXXX` 형식**(예: `123-45-67890`)입니다. 첫 3자리는 세무서, 다음 2자리는 사업 종류, 마지막 5자리는 검증 자릿수가 포함된 일련번호입니다. **일본**: 법인번호는 국세청이 발급하는 **13자리**(예: `1234567890123`)이며 관련 인보이스 제도 등록번호는 같은 13자리에 `T`를 접두로 붙입니다(예: `T1234567890123`). **미국**: EIN(고용주 식별번호)은 IRS가 발급하는 **9자리 `XX-XXXXXXX` 형식**(예: `12-3456789`)입니다. **EU**: VAT 번호는 국가별로 다릅니다. 독일은 `DE` + 9자리, 프랑스는 `FR` + 11자, 영국은 `GB` + 9자리. 모두 2자 ISO 국가 코드로 시작합니다. **중국**: 统一社会信用代码는 2015년 개혁 후 부여된 **18자 영숫자**입니다. 본 도구는 형식 검증 없이 입력된 것을 그대로 저장하지만(어느 국가든 동작하도록), kr·jp 템플릿은 현지 형식의 플레이스홀더 힌트를 표시합니다.
왜 래스터화가 아닌 벡터 PDF를 생성하나요?
벡터 PDF(텍스트는 텍스트 객체로, 선은 선 객체로)는 세 가지 이유로 청구서에 적합한 형식입니다. **텍스트 검색 가능성**: 회계 소프트웨어(QuickBooks·freee·더존)와 이메일 첨부 스캐너는 벡터 PDF에서 청구 번호·금액·날짜를 읽을 수 있지만 래스터화된 이미지에서는 읽지 못합니다. 즉 고객이 수동 데이터 입력 없이 파일을 AP 시스템에 넣을 수 있습니다. **인쇄 품질**: 벡터 PDF는 임의의 해상도로 스케일됩니다. 고객 사무실의 600 DPI 프린터는 또렷한 텍스트와 선을 인쇄하지만 150 DPI 래스터화된 PDF는 인쇄 시 흐릿하게 보입니다. **파일 크기**: 일반 청구서는 벡터 PDF로 50~200 KB, 래스터화된 PNG-in-PDF로는 500 KB~2 MB — 경리팀이 연 1,000건 이상 청구서를 아카이브할 때 의미 있는 5~10배 차이. 트레이드오프는 PDF가 한국어·일본어·중국어 텍스트를 정확하게 렌더링하려면 CJK 폰트를 임베드해야 한다는 점입니다. 본 도구는 임베드된 폰트를 작게 유지하면서 일반 문자를 지원하도록 Noto Sans CJK의 부분 집합을 번들로 제공합니다.
공급자 정보를 저장해서 매번 다시 입력하지 않아도 되나요?
네 — 본 도구는 공급자 정보를 문서 본문과 별도의 키 아래 **localStorage**에 영속화합니다. 사업 정보를 한 번 채우면(상호·등록번호·주소·연락처·은행 정보) 지울 때까지 세션 간 유지됩니다. 새 문서를 시작하면 고객 필드는 비어 있지만 공급자 블록은 사전 입력됩니다. 사업체를 전환하려면(예: 개인 사업자로도 LLC로도 운영) 가장 간단한 방법은 공급자 블록을 수동으로 지우고 다시 채우거나 — 두 개의 다른 브라우저·프로필을 사용하는 것입니다. 데이터는 **브라우저를 떠나지 않습니다**. IndexedDB 형식의 로컬 스토리지에 존재하며 어디에도 동기화되지 않습니다. 브라우저 데이터 삭제, 기기 전환, 시크릿 모드 사용 시 저장된 상태는 사라집니다. 크로스 디바이스 영속성에는 우회책으로 개인 노트 앱에서 공급자 블록을 매번 복사·붙여넣기. 향후 개선으로 JSON 내보내기·가져오기가 가능합니다. 현재 도구는 상태를 최소화하고 로컬로 유지합니다.
하나의 청구서에서 복수 세율을 처리하려면?
현재 도구는 청구서 전체에 단일 세율을 적용합니다. 대부분의 서비스 전업 사업에 적합합니다. 면세 품목과 과세 품목을 혼합한 청구서(일본의 식품과 비식품이 8%와 10%, 한국의 특정 의료·교육 서비스에서 흔함)에는 우회책으로 두 개의 별도 청구서를 만들거나 세율별 소계를 수동으로 계산해 메모 필드에 넣습니다. 일본의 인보이스 제도는 단일 문서에 세율별 내역을 명시적으로 요구합니다. 그 경우 현재 단일 세율 도구는 완전 준수 솔루션이 아니며 수동 재정의가 필요합니다. 향후 버전은 항목별 세율 선택을 추가할 수 있습니다. 현재 실용적 조언은: 가능하면 청구서를 단일 세율로 유지하고, 복잡한 세무 시나리오에는 회계 소프트웨어(freee·MoneyForward·더존 ERP)를 사용하라는 것입니다.
청구서에 번호를 매겨야 하나요? 어떤 번호 체계가 권장되나요?
네 — 연속적이고 고유한 청구서 번호는 대부분의 관할 구역에서 세무 준수를 위해 **법적으로 필수**입니다(일본의 인보이스 제도는 발행자별 고유 번호 부여를 명시적으로 요구, EU VAT 규칙은 고유 연번을 요구, 미국 세법은 강력히 권장). 일반적인 체계: **YYYYMM-NNN**(예: `202605-001` — 정렬하기 쉽고 발행 월이 명확함), **YYYY-NNNN**(예: `2026-0142` — 연간 리셋, 더 단순함), **단순 증가**(예: `INV-1042` — 동작하지만 연도 경계를 찾기 어려움). 소규모 사업자에게는 YYYYMM-NNN 형식이 실용적인 스위트 스팟입니다. 매월 001부터 번호 부여를 재개할 수 있고, 월별로 청구서를 빠르게 찾을 수 있으며, 빠진 번호 감사가 쉽습니다. 본 도구는 기본으로 문서 번호를 `Q-{YYMMDD}-001`로 시드하지만, 기존 번호 부여에 맞게 덮어써야 합니다. 청구서 전반의 일관성이 특정 형식보다 더 중요합니다.
관련 개념
청구서 발행은 기록된 가장 오래된 상업 관행 중 하나입니다. **메소포타미아의 기원전 3000년경 점토판**은 판매자 마크가 있는 곡물과 가축의 항목별 목록을 기록했으며 본질적으로 세계 최초의 청구서입니다. 현대 청구서 형식은 르네상스 이탈리아의 **복식 부기(Luca Pacioli, 1494년)**에서 출현해 청구서·원장·계좌 잔액의 관계를 공식화했습니다. 현재 글로벌 B2B 청구서는 수세기에 걸쳐 쌓인 3개의 구조 계층을 가집니다. **중세 상인 헤더**(당사자·날짜·문서 번호), **복식 부기 이탈리아 본문**(항목·수량·단가·소계), **현대 세무 관리 푸터**(세무 등록 번호·세액 내역·규제 공시). 다른 관할 구역은 다른 계층을 강조합니다. 미국 청구서는 세금 푸터를 가볍게 다루고(판매세는 다르게 징수됨), EU 청구서는 강조하며(VAT 준수), 한국과 일본 청구서는 2010년대 이후 비공식 경제의 탈세 대처를 위해 세금 푸터를 공식화하는 방향으로 움직였습니다.
2010~2020년대의 **전자 청구서 물결**은 문서를 재구성하고 있습니다. **이탈리아**는 2019년에 모든 B2B 거래에 구조화된 XML 전자 청구서를 의무화했습니다. 수신자는 세액 공제 가능 비용에 대해 종이나 PDF를 더 이상 받지 않습니다. **멕시코**·**브라질**·**칠레**는 2010년대에 비슷한 의무화가 있었으며 VAT 징수 격차를 메우기 위해 동기 부여되었습니다. **한국**은 연매출 1억 원 초과 사업자에게 필수 채택인 **국세청 e-세금계산서 시스템**을 2010년부터 운영합니다. **일본**은 인보이스 제도 개혁과 병행하여 2023년에 **PEPPOL 기반 일본 e-Invoice(デジタルインボイス)**를 출범시켰습니다. **PEPPOL**(범유럽 공공 조달 온라인)은 현재 글로벌하게 채택된 4-코너 메시징 네트워크입니다. 발신자 → 발신자 접근점 → 수신자 접근점 → 수신자. 국가를 가로지른 전자 청구서의 와이어 형식을 표준화합니다. 본 도구는 전자 청구서 시스템과 함께 동작하는 사람이 읽을 수 있는 PDF를 생성하지만 아직 PEPPOL XML을 출력하지는 않습니다. PEPPOL을 통한 제출이 필요한 사업자에게는 전용 전자 청구서 플랫폼(Trustweaver·Tradeshift·Pagero·freee·MoneyForward·더존)이 필요합니다.
3가지 **사업 운영 인접 개념**이 청구서 생성과 교차합니다. **외상매출금(AR) 에이징**은 미수 청구서를 지급 기한 경과 일수(0~30 / 31~60 / 61~90 / 90+ 버킷)로 추적하는 관행입니다. 만성적인 60+ 일 버킷은 자기 측의 프로세스 실패(리마인더 주기 없음)나 고객 관계 문제(어려움 또는 분쟁 중)를 나타냅니다. **현금 전환 주기**는 입력에 돈을 쓸 때부터 출력의 지급을 받을 때까지의 일수를 측정합니다. 청구 속도(납품 주가 아닌 납품 직후 발행)는 소규모 사업자에게 가장 큰 레버입니다. **Net 30 / Net 60** 지급 조건은 30일 조건이 배송과 검수 시간을 고려했던 물리 재화 거래에서 계승되었습니다. 디지털 서비스에는 그 이유가 사라졌지만 관례는 지속됩니다. 많은 프리랜서와 B2B 서비스 사업자는 고객의 AP 시스템이 기대하기 때문에 Net 30을 기본으로 합니다. Net 15나 심지어 선불도 소규모 프로젝트에서 증가하고 있습니다. $5K 청구서를 30일 기다리는 비대칭 현금 흐름 부담은 1인 사업을 가라앉힐 수 있기 때문입니다.
