송장을 손으로 작성하는 것에 지쳐서 JSON에서 형식 청구서, 차변 메모 및 대변 메모를 생성하는 API를 만들었습니다.

마침내 루틴을 깨뜨린 순간은 화요일 오후였고, 세 개의 별도의 송장 템플릿이 세 개의 별도 응용 프로그램에서 열려 있었습니다. 한 회사는 독일 클라이언트를 위해 표준 VAT 송장이 필요했습니다. 다른 하나는 배분자와의 선급금 계약을 위해 형식 송장이 필요했습니다. 세 번째는 이전 분기의 과다 청구를 수정하기 위해 대변 메모가 필요했습니다. 세 개의 회사, 세 개의 문서 유형, 세 개의 완전히 다른 워크 플로우 및 그 중 어느 것이든 보내기 전에 약 2 시간의 수동 데이터 입력이 필요합니다. 숫자는 이미 계산되었습니다. 클라이언트 세부 사항이 이미 알려져 있습니다. 라인 항목은 스프레드시트에 있습니다. 그럼에도 불구하고 해당 숫자를 올바르게 형식화된 전문적으로 설계된 PDF로 가져오는 실제 프로세스는 책상에 앉아있는 프린터가있을 때 손으로 소설을 필사하는 것처럼 느껴졌습니다.

이것은 일회성 불편 함이 아니었습니다. 그것은 월간 의식이었습니다. 모든 청구 주기는 동일한 지루한 순서를 가져 왔습니다: 템플릿을 열고, 송장 번호를 수동으로 업데이트하고 (시퀀스가 실수로 재사용되지 않았는지 확인), 클라이언트의 주소를 작성하고, 라인 항목을 하나씩 복사하고, 세금 계산을 확인하고, PDF로 내보내고, 전송합니다. 세 개의 회사와 서로 다른 브랜딩, 서로 다른 VAT 요금, 서로 다른 번호 매기기 시퀀스 및 서로 다른 법률 요구 사항을 곱하면 월간 송장 작성 프로세스는 업무 일의 상당 부분을 소비했습니다. 매달 온종일 창조적 또는 전략적 가치가없는 순수 데이터 형식 지정 작업에 전념합니다.

존재하던 도구는 올바른 문제를 해결하지 못했습니다. QuickBooks, FreshBooks, Zoho Invoice 등은 모두 비즈니스의 전체 회계 백본이 되기를 원했습니다. 그들은 은행 연결, 비용 추적, 급여 통합 및 특권을 위해 월간 구독을 원했습니다. 필요한 것은 훨씬 간단했습니다: 안에 구조화된 데이터를 보내고, 아름답게 형식화된 PDF를 얻으세요. 더 이상 없습니다. 대시 보드 없음, 원장 없음, 12 단계 온 보딩 없음. JSON을 수락하고 문서를 반환하는 함수 일 뿐입니다.

세 회사와 월간 청구가 만드는 혼란

여러 회사를 운영하는 것은 LinkedIn 게시물이 만드는 것처럼 매력적이지 않습니다. 운영 오버 헤드는 즉시 명확하지 않은 방식으로 증가하며 송장 작성은 가장 교활한 범인 중 하나입니다. 각 회사는 자신의 법인, 자신의 세금 식별 번호, 자신의 은행 세부 사항, 자신의 로고 및 자신의 클라이언트 기반을 가지고 있습니다. 한 회사에서 완벽하게 작동하는 단일 송장 도구는 VAT 구조가 다르거나 한 회사가 유로로 청구하고 다른 회사가 현지 통화로 청구하거나 법적 바닥글 요구 사항이 통합 관할권에 따라 변경되기 때문에 다른 회사에 완전히 잘못 될 수 있습니다.

수동 접근 방식은 각 회사에 대해 Word 문서 템플릿을 유지하는 것과 관련이 있었습니다. 이러한 템플릿은 로고, 글꼴 선택, 색상 강조 및 신중하게 배치된 필드로 세심하게 형식화되었습니다. 업데이트하는 것은 악몽이었습니다. 회사 전화 번호가 변경되면 해당 변경 사항이 모든 템플릿 변형에 전파되어야합니다: 송장, 형식 송장, 대변 메모, 차변 메모 및 영수증. 5 개의 문서 유형 곱하기 3 개의 회사는 15 개의 템플릿을 유지하는 것과 같으며 각각은 오류의 잠재적 원천입니다. 은행 세부 사항의 오타, 잘못된 VAT 등록 번호, 오래된 주소. 문서가 수년 후에 감사될 수있는 법적 기록 인 경우 이것은 사소한 실수가 아닙니다.

송장 번호 매기기 문제는 자체 단락을 받을 자격이 있습니다. 실제 비즈니스 결과를 초래했기 때문입니다. 순차적 송장 번호 매기기는 많은 관할권에서 법적 요구 사항입니다. 시퀀스의 간격은 감사 중에 빨간 깃발을 올립니다. 중복은 더 나쁩니다. 5 개의 문서 유형 전체에서 3 개의 회사에 대한 별도의 번호 매기기 시퀀스를 유지하는 것은 15 개의 다른 카운터를 수동으로 추적하는 것을 의미했습니다. 공유 스프레드시트는 이러한 시퀀스에 대한 "레코드 시스템"으로 사용되었으며, 송장이 이미 전송된 후 스프레드시트가 여러 번 업데이트되어 송장 번호 2024-0047이 실제로 발행되었는지 또는 여전히 보류 중인지에 대한 혼동을 초래했습니다. 송장 생성기는 궁극적으로 이 혼란을 대체했으며 회사 및 문서 유형별로 자동 번호 매기기를 처리하여 전체 부기 오류 범주를 제거합니다.

또한 문서 관계의 문제도있었습니다. 형식 송장은 작업이 시작되기 전에 발행됩니다. 최종 송장은 해당 형식 송장을 참조합니다. 수정이 필요한 경우 대변 메모는 원본 송장을 참조합니다. 차변 메모도 언더 빌링에 대해 동일한 작업을 수행합니다. 이러한 문서는 체인을 형성하며, Word 문서 및 스프레드시트 전체에서 이 체인을 수동으로 유지하는 것은 제어된 혼란의 연습입니다. 잘못된 참조 번호 하나와 감사 추적이 끊어집니다.

API가 실제로하는 일과 JSON이 모든 것을 바꾸는 이유

송장 API는 송장이 필요한 모든 구조화된 데이터를 포함하는 JSON 페이로드를 수락합니다: 판매자 세부 정보, 구매자 세부 정보, 수량 및 단가를 포함한 라인 항목, 세금 요율, 통화, 지불 조건, 메모 및 송장 번호 및 발행 날짜와 같은 문서 메타 데이터. 해당 페이로드를 처리하고 완전히 렌더링된 PDF 문서를 반환합니다. 전체 왕복은 몇 초 정도 걸립니다. 열 템플릿이 없고, 입력할 필드가 없으며, 확인할 수동 계산이 없습니다.

동일한 끝점 제품군에서 5 개의 문서 유형이 지원됩니다. 표준 송장이 가장 일반적이지만 형식 송장 생성기는 문서가 송장처럼 보이고 느껴야하지만 법적 무게를 운반하지 않는 선급금 시나리오를 처리합니다. 대변 메모는 원본 송장 번호를 참조하고 조정된 금액을 표시하여 환불 및 수정을 처리합니다. 차변 메모는 반대의 경우를 처리합니다. 원본 송장이 발행된 후 추가 요금을 문서화해야합니다. 영수증은 거래를 종료하고 거래를 종료하기 위해 지불을 받았음을 확인합니다. 5 가지 유형 모두 약간의 변형을 가진 동일한 JSON 구조를 공유합니다. 즉, 통합 작업이 한 번 수행되고 모든 문서 유형이 무료로 제공됩니다.

JSON 접근 방식은 시스템을 단순히 사후 생각으로 API를 볼트로 더 진정으로 유용하게 만드는 것입니다. 입력이 양식 필드가 아닌 구조화된 데이터이기 때문에 어디서나 올 수 있습니다. 전자 상거래 플랫폼은 주문이 배송될 때 자동으로 송장을 생성할 수 있습니다. CRM은 거래가 특정 단계로 이동할 때 형식 송장을 트리거할 수 있습니다. 스프레드시트 내보내기는 간단한 스크립트로 일괄 송장으로 변환될 수 있습니다. 데이터 소스는 중요하지 않습니다. 유효한 JSON을 생성할 수있는 한, API는 유효한 문서를 생성합니다. 이 합성 가능성은 인간이 항상 양식 앞에 앉아 버튼을 클릭한다고 가정하는 기존 송장 작성 소프트웨어에 비해 근본적인 장점입니다.

더 만족스러운 통합 중 하나는 송장 API를 문서 스캐너와 연결합니다. 공급자의 수신 송장이 스캔되고 라인 항목, 금액 및 공급자 세부 정보를 추출하기 위해 구문 분석됩니다. 추출된 데이터는 송장 API에 직접 공급되어 해당하는 나가는 문서를 생성합니다. 지불 영수증 또는 청구를 분쟁하는 대변 메모. 용지에서 구조화된 데이터로 생성된 문서로의 루프는 체인의 어느 지점에서도 수동 데이터 입력없이 닫혀 있습니다.

5 가지 문서 유형과 각각이 중요한 경우

이 5 가지 문서 유형 간의 구분은 많은 소규모 비즈니스 소유자가 어렵게 배우는 것이며 일반적으로 회계사 또는 세무 당국이 잘못된 유형이 사용되었음을 지적할 때입니다. 형식 송장은 세금 문서가 아닙니다. 표준 송장이 필요했던 곳에 하나를 발행하면 규정 준수 문제가 발생할 수 있습니다. 반대로, 상품이 배송되거나 서비스가 렌더링되기 전에 완전한 송장을 발행하면 수익 인식 문제가 발생할 수 있습니다. 어떤 유형을 사용할지, 언제 사용할지 이해하는 것이 필수적이며, 5 개의 별도 도구 또는 5 개의 별도 워크 플로우를 필요로하지 않고 모두 5 가지를 지원하는 시스템을 갖는 것은 마찰의 의미있는 원천을 제거합니다.

표준 송장은 "송장"이라는 단어를 들었을 때 대부분의 사람들이 생각하는 문서입니다. 그것은 완료된 거래를 기록하는 법적 지불 요청입니다. 고유 한 순차 번호, 양측의 전체 법적 세부 사항, 라인 항목의 분석, 적용 가능한 세금 및 지불 지침이 있습니다. 그것은 세금 신고서와 함께 제출되고 감사 중에 생성되는 문서입니다. 송장 API는 JSON 입력에서 입력된 모든 필수 필드로 이들을 생성합니다. 계산된 합계, 세금 분석 및 형식화된 통화 값을 포함합니다. 사용자가 수동으로 계산할 것은 아무것도 남지 않습니다.

형식 송장은 거의 동일하게 보이지만 다른 목적으로 사용됩니다. 거래가 발생하기 전에 가격 계약을 공식화하는 데 사용되는 인용문입니다. 국제 무역은 관세 선언 및 수입 허가를 위해 형식 송장에 크게 의존합니다. 프리랜서들은 작업을 시작하기 전에 보증금을 요청하기 위해이를 사용합니다. 주요 차이점은 형식이 해당하는 최종 송장이 발행될 때까지 회계 원장에 수익으로 입력되지 않는다는 것입니다. API는 문서 유형을 명확하게 헤더에 표시하고 지불 조건의 언어를 조정하여이 구분을 처리하므로 문서가 구속력있는 송장인지 또는 예비 추정인지에 대한 모호함이 없습니다.

대변 메모 및 차변 메모는 수정 문서이며, 여기에서 수동 송장 작성 프로세스가 가장 극적으로 실패합니다. 대변 메모는 구매자가 빚진 금액을 줄입니다. 보통 반품, 가격 책정 오류 또는 원본 송장이 발행된 후 협상된 할인 때문입니다. 차변 메모는 빚진 금액을 증가시킵니다. 아마도 추가 서비스가 제공되었거나 원본 송장이 계산 실수로 인해 언더 청구되었기 때문입니다. 둘 다 원본 송장 번호를 참조해야하며 둘 다 미결 잔액을 조정하기 위해 회계 시스템을 통해 흐름을 흘러야합니다. 이를 수동으로 생성하는 것은 원본 송장을 열고, 번호를 찾고, 올바른 형식으로 새 문서를 만들고, 조정 금액을 입력하고, 참조 체인이 그대로 있는지 확인하는 것을 의미합니다. API는 원본 문서 참조를 포함하는 단일 JSON 페이로드에서 이 모든 작업을 처리합니다.

영수증이 가장 간단한 유형이지만 대부분의 송장 도구에서는 놀랍게도 부족합니다. 영수증은 지불을 받았음을 확인합니다. 지불한 송장을 참조하고 지불의 금액과 날짜를 명시하며 구매자에 대한 거래의 증거로 사용됩니다. 많은 기업이 영수증을 완전히 건너뛰고 은행 전송 확인에 의존하지만, 현금이 많은 산업이나 공식 영수증이 세금 공제에 필요한 관할권에서는 적절한 영수증 생성 기능이 선택 사항이 아닙니다. API는 해당 송장의 시각적 브랜딩과 일치하는 영수증을 생성하여 동일한 회사에서 발행한 모든 문서에서 일관된 모양을 유지합니다.

자동 번호 매기기 및 그것이 보존하는 이성

자동 번호 매기기 기능만으로 전체 개발 노력을 정당화했습니다. 각 회사는 자신의 번호 매기기 시퀀스를 유지합니다. 해당 회사 내 각 문서 유형은 자신의 부분 수열을 유지합니다. 송장 번호는 한 패턴을 따르고, 형식 송장은 다른 패턴을 따르며, 대변 메모는 세 번째를 따릅니다. 시퀀스는 생성된 모든 문서로 자동으로 증가하며 형식은 구성 할 수 있습니다: 일부 회사는 001, 002, 003과 같은 단순 숫자 시퀀스를 선호하고 다른 회사는 2026-001과 같은 연도 접두사를 원하며 다른 회사는 ABC-INV-001과 같은 회사 코드 접두사를 원합니다. API는 회사 구성의 템플릿 문자열을 통해 이러한 모든 형식을 수용하며 실제 카운터는 서버 측에서 관리되므로 중복 번호 또는 우발적 간격의 위험이 0입니다.

이것은 사소한 세부 사항처럼 들릴지 모르지만, 송장 시퀀스의 간격을 세무 검사관에게 설명해야했던 모든 사람에게는 사소한 것과 거리가 멉니다. 여러 유럽 국가에서 송장 번호 매기기의 간격은 보험료 소득 증거로 취급됩니다. 입증의 부담이 사업으로 전환되어 간격이 거래를 숨기기위한 시도보다는 실수 였음을 입증합니다. 자동화된 서버 관리 카운터는이 위험을 완전히 제거합니다. 모든 숫자는 순차적이고, 모든 숫자가 사용되며, 감사 추적은 스프레드시트와 불완전한 메모리를 가진 인간이 아닌 시스템에 의해 유지됩니다.

번호 매기기 시스템은 또한 문서 유형 간의 관계를 처리합니다. 대변 메모가 송장 2026-042에 대해 발행되면 대변 메모는 자신의 시퀀스에서 자신의 번호를 소유합니다 (예: CN-2026-008), 하지만 원본 송장에 대한 참조도 저장합니다. 원본 송장 ID가 JSON 페이로드에 포함될 때이 교차 참조는 자동입니다. 생성된 대변 메모 PDF는 두 번호 모두 눈에 띄게 표시하여 나중에 문서를 검토하는 사람이 누구인지 즉시 선명한 감사 추적을 만듭니다. 구매자의 미지급금 부서, 외부 감사원 또는 6 개월 후 책을 조정하려고하는 비즈니스 소유자입니다.

이것이 개인 수정 이상이 된 이유

개인 송장 작성 두통에 대한 솔루션으로 시작된 것이 문제가 보편적이라는 것이 명백 해졌을 때 상당히 광범위해졌습니다. 모든 프리랜서, 모든 소규모 대행사, 여러 벤처를 운영하는 모든 단일 설립자는 동일한 도전의 일종에 직면합니다. 기존 도구는 너무 복잡하거나 (몇 주간의 설정과 지속적인 유지 관리가 필요한 전체 회계 제품군) 너무 간단 (자동화가없는 기본 Word 문서)입니다. 여러 회사 및 문서 유형을 처리할 수있을 정도로 강력하지만 단일 API 호출과 통합 될 정도로 충분히 간단한 중간 지대는 단순히 존재하지 않았습니다.

API는 설계에 따라 해당 중간 지대에 있습니다. 회계 시스템이 되려고 시도하지 않습니다. 지불을 추적하거나, 비용을 관리하거나, 은행 계정을 조정하지 않습니다. 정확히 한 가지를 수행합니다: 구조화된 데이터를 전문적으로 형식화된 재무 문서로 변환합니다. 이 좁은 초점은 그것을 신뢰할 수있게 만들고 비즈니스가 이미 사용하고있는 다른 시스템과 구성 할 수있게 만드는 것입니다. Notion에서, Airtable에서, 사용자 지정 CRM에서, Shopify 웹 후크에서, 데이터베이스를 읽는 cron 작업에서 데이터를 파이프합니다. API는 데이터가 어디에서 오는지 신경 쓰지 않습니다. 데이터가 필수 필드가있는 유효한 JSON이고 보낼 준비가된 PDF를 반환하는지 신경을 씁니다.

향후 계획에는이 API 위에 완전한 송장 작성 SaaS 응용 프로그램을 구축하는 것이 포함되어 있습니다. 회사, 클라이언트 및 문서 기록 관리 대시 보드와 함께 그러나 API는 기초로 남아있을 것입니다. 다른 도구를 사용한 몇 년의 좌절로부터 배운 교훈은 인터페이스가 병목이 되어서는 안된다는 것입니다. 데이터가 준비되면 문서가 준비됩니다. 양식을 클릭하거나, 시스템이 이미 알고있는 드롭 다운 값을 선택하거나, "PDF 생성" 버튼을 누를 수 있도록 페이지가로드 될 때까지 기다릴 필요가 없습니다. JSON, PDF, 송장 완료입니다.