서명된 견적서에서 청구서까지, 다시 입력할 필요 없이

짧게 답하면: 서명된 견적서를 청구서에 절대 다시 입력하지 마세요. 다시 입력하는 과정에서 항목이 어긋나고, 세금이 다시 계산되고, 고객이 동의한 금액과 실제로 청구한 금액 사이에 어느새 숫자가 바뀝니다. 대신 견적서를 변환하면 항목과 세금, 고객 정보가 그대로 넘어가므로 청구서가 서명된 문서와 정확히 일치합니다.

화요일 밤 9시 40분, 부엌 식탁에서 청구서를 작성하고 있습니다. 서명된 견적서는 휴대폰 화면에 열려 커피잔에 기대어 세워져 있고, 그것을 한 줄씩 청구서에 옮겨 적고 있습니다. 같은 고객, 같은 주소, 같은 열네 개 항목, 같은 세금. 아홉 번째 줄에서 1,840달러를 1,480달러로 잘못 입력합니다.

아무도 이를 알아채지 못합니다. 고객은 이의 없이 청구서 금액을 지급하는데, 너무 적게 청구된 청구서에 불평하는 고객은 없기 때문입니다. 그리고 360달러의 마진이 그것이 존재했다는 사실조차 아무도 모른 채 증발합니다. 아니면 반대 방향으로 실수가 나서 고객이 발견하고, 이제 그 청구서의 다른 모든 숫자까지 의심받게 됩니다. 그 이메일이 오기 전까지는 완벽하게 진행된 공사였는데도요.

어느 쪽이든 실수는 9시 40분에 만들어진 게 아닙니다. 같은 열네 개 항목을 두 번 입력해야 하는 워크플로 그 자체에서 실수가 시작된 것입니다.

견적서를 다시 입력하면 왜 돈이 새어 나갈까요?

견적서를 청구서로 옮기는 일은 단순 사무 업무처럼 느껴지고, 바로 그래서 위험합니다. 지쳐 있을 때 하게 되고, 지루할 만큼 반복적이라 주의가 흐트러지며, 그 실패는 조용히 일어납니다.

과소 청구는 조용히 일어납니다. 자릿수가 뒤바뀐 숫자, 복사 과정에서 사라진 60달러짜리 항목, 12개가 2개로 바뀐 수량. 이 중 어느 것도 스스로 알려주지 않습니다. 고객은 청구서에 적힌 대로 지급하고, 작업 건은 종결되며, 나중에 작업 원가 계산에서 드러나는 마진 문제를 가격 책정 문제로 오진하게 됩니다.

과다 청구는 요란하게 드러납니다. 방향만 반대일 뿐 똑같은 오타가 발견되면, 진짜 비용은 그 360달러가 아닙니다. 이제 고객이 내 이름이 적힌 모든 것을 감사하기 시작한다는 점입니다. 청구서에 대한 신뢰는 이분법적이며, 숫자 하나가 잘못되면 그 신뢰는 뒤집힙니다.

세금 항목은 그 자체로 함정입니다. 다시 입력한다는 건 기억을 더듬어 세금 처리 방식을 다시 적용한다는 뜻입니다. 어떤 항목이 과세 대상인지, 어떤 세율로, 어느 부분에 적용되는지요. 이를 틀리면 납부 시점에 차액을 직접 부담하거나, 아무도 쓰고 싶어 하지 않는 정정 이메일을 고객에게 보내야 합니다.

게다가 재입력에는 일정상의 비용도 따릅니다. 다시 입력하는 방식의 청구는 성가신 잡일이므로 한가한 저녁까지 미뤄집니다. 성수기에는 한가한 저녁이 드물기 때문에 완료된 작업이 며칠씩 미청구 상태로 남습니다. 그 하루하루가 단지 데이터 입력이 귀찮다는 이유만으로 고객의 프로젝트를 이자 없이 대신 지원해주는 시간입니다.

밤 9시 40분에 더 조심스럽게 입력하는 것은 해결책이 아닙니다. 두 번째 입력 자체를 아예 없애는 것이 해결책입니다.

작업 수익성 계산기를 이용하면 완료된 작업이 견적한 만큼의 이익을 실제로 냈는지 확인할 수 있습니다.

변환: 청구서는 승격된 견적서입니다

Zeus에서는 서명된 견적서가 곧바로 청구서로 변환됩니다. 항목은 견적된 그대로 정확히 넘어갑니다. 설명, 수량, 단가까지요. 세금 처리 방식도 함께 넘어옵니다. 고객과 작업 건도 함께 넘어오는데, 청구서가 견적서와 같은 작업 건 위에서 생성되기 때문입니다. 다시 주소를 입력해야 하는 별도 문서가 아닙니다.

예전에는 저녁 시간을 잡아먹던 잡일이 이제는 작업의 마지막 30초가 됩니다. 트럭이 도로변을 떠나기 전, 진입로에서 바로 고객이 서명한 같은 기록을 바탕으로 청구서를 생성할 수 있습니다.

여기에는 놓치기 쉬운 두 번째 이점이 숨어 있습니다. 고객이 청구서를 알아본다는 것입니다. 청구서가 고객이 서명한 문서와 같은 항목, 같은 표현, 같은 총액으로 도착하면, 그것은 새로 뜯어봐야 할 문서가 아니라 확인 문서로 읽힙니다. 익숙한 청구서는 빨리 지급받고, 낯선 청구서는 오래 검토받습니다. 표현을 다시 쓰고, 항목 순서가 바뀌고, 총액은 얼추 비슷하지만 어딘가 다른 다시 입력한 청구서는 모든 숫자가 맞더라도 검토를 부릅니다.

변환한다고 해서 수정이 막히는 것은 아닙니다. 때로는 청구서가 정당하게 다른 경우도 있습니다. 공사 도중 고객이 취소한 항목, 재료 대체 같은 것들입니다. 보내기 전에 조정할 수 있습니다. 핵심은 출발점입니다. 백지에서 시작해 기억으로 재구성하려 애쓰는 대신, 서명된 문서에서 시작해 실제로 바뀐 것만 바꾸는 것입니다.

변경 주문은 같은 작업 건에 합류합니다

청구서 재구성이 정말로 잘못되는 지점은 작업 도중의 변경 사항입니다. 견적서에는 8,400달러라고 적혀 있었습니다. 그런데 고객이 콘센트 하나를 추가하고, 울타리 한 구간을 승인하고, 창고 선반은 취소했습니다. 세 번의 대화와 하나의 문자 스레드에 걸쳐 모두 합의된 내용입니다. 청구할 때가 되면, 다시 입력하는 시공업자는 기억과 화면 스크롤을 뒤져 최종 금액을 조합하는 고고학자가 되어 있습니다.

변경 사항이 같은 작업 건에서 변경 주문서로 작성되어(가격이 매겨지고, 서명되고, 원래 견적서와 함께 보관되어) 있으면, 최종 청구서는 더 이상 재구성의 결과물이 아닙니다. 그것은 서명된 견적서에 승인된 변경 사항을 더한 것이며, 각각은 고객이 이미 서명한 문서입니다. 청구서에는 새로운 정보가 하나도 없습니다.

그러면 인계 대화가 완전히 달라집니다.

"청구서는 4일에 서명하신 견적서에, 승인해 주신 세 가지 변경 사항, 즉 11일의 추가 콘센트, 15일의 울타리 구간, 그리고 취소하신 창고 선반을 반영한 금액입니다. 서류에 있는 것과 같은 숫자이고, 새로운 항목은 없습니다."

손으로 만든 청구서와 세 번의 현장 대화에 대한 기억만으로 이런 대화를 나눠보려 해보세요. 차이는 예의의 문제가 아닙니다. 한쪽은 10초 안에 서명들과 대조할 수 있고, 다른 한쪽은 그럴 수 없다는 것입니다.

청구서 번호에 빈틈이 생기면 어떻게 될까요?

사소해 보이지만 세금 신고 시점에는 결코 사소하지 않은 것, 바로 번호 매기기입니다.

직접 번호를 매기는 청구서는 어긋나기 마련입니다. 번호를 건너뛰거나, 재사용하거나, 휴대폰과 노트북이 각자 다음 번호를 알아서 매기는 바람에 두 개의 시퀀스가 동시에 돌아갑니다. 검토가 업무인 누군가(기장 담당자, 연말 회계사, 세무 조사관)가 1047번 청구서에 무슨 일이 있었냐고 묻기 전까지는 별문제로 보이지 않습니다. 시퀀스에 생긴 빈틈은 삭제된 청구서처럼 보이고, "그냥 건너뛴 것 같아요"는 자기 매출 기록에 대해 하고 싶은 답이 아닙니다.

Zeus는 청구서 번호를 서버에서, 사업체 전체를 위한 단일한 빈틈 없는 시퀀스로 부여합니다. 번호를 직접 고르는 일은 없고, 두 기기가 같은 번호를 두고 충돌할 일도 없으며, 시퀀스에는 설명해야 할 빈틈이 존재하지 않습니다. 설계상 따라오는 실용적인 참고 사항 하나는, 서버가 번호를 부여하기 때문에 오프라인 상태에서 작성한 청구서는 동기화될 때 최종 번호를 받는다는 것입니다. 어떤 기기도 번호를 추측할 수 없기에 시퀀스는 정확히 깨끗한 상태를 유지합니다.

짝이 되는 규칙은 이것입니다. 실수는 삭제가 아니라 무효 처리됩니다. 무효 처리된 청구서는 무효로 표시된 채 기록에 남아 시퀀스를 온전하게 유지하고 기록을 정직하게 지킵니다. 조용히 삭제할 수 있는 청구 시스템은 보고서를, 자신의 것조차, 온전히 신뢰할 수 없는 시스템입니다.

금요일에 밀린 청구서를 한 번에 처리하기

변환 기능이 있어도 실제 한 주는 늘 쌓인 채로 끝납니다. 월요일 이후 마무리된 작업 네 건이 아직 청구되지 않았습니다. 각 작업이 끝날 때마다 바로 다음 작업이 기다리고 있었기 때문입니다.

일괄 청구 기능은 정확히 이런 더미를 위해 존재합니다. 완료된 작업을 하나씩 처리하는 대신, 여러 작업의 청구서를 한 번에 생성할 수 있습니다. 각각은 자신의 서명된 견적서와 승인된 변경 주문에서 만들어지고, 각각 순서대로 번호가 매겨져 발송 준비를 마칩니다. 금요일에 밀린 일은 계속 미루던 저녁 하나에서 몇 분으로 줄어듭니다.

이 셈법은 지루하지만 현실적입니다. 작업이 끝난 당일 발송된 청구서는 즉시 시계를 작동시키고, 그 공사(그리고 시공자에 대한 호감)가 고객의 머릿속에 여전히 생생할 때 도착합니다. 여전히 결과물에 감탄하고 있는 고객에게 보낸 청구서는, 2주 뒤 낯선 사람의 청구서처럼 도착하는 청구서보다 더 좋은 대우를 받습니다. 어느 쪽이 고객의 받은편지함에 더 오래 머무를지는 통계 없이도 알 수 있습니다.

이 방식이 해결해주지 않는 것

이 점은 솔직히 짚고 넘어갈 가치가 있습니다. 모든 것을 고쳐준다고 주장하는 도구는 사실 아무것도 고치지 못하는 법이니까요.

내가 시키지 않는 한 대신 돈을 독촉해주지는 않습니다. 자동 연체 알림 기능은 있습니다. "연체 청구서 독촉"은 청구서 기한이 지난 뒤 3일, 7일, 14일에 고객에게 이메일을 보내고 거기서 멈춥니다. 다만 내가 직접 켜기 전까지는 꺼져 있고, 대부분의 시공업자는 꺼둔 채로 씁니다. 미납 청구서는 처리가 필요한 항목이 모이는 알림에 뜨고, 채권 연령 보고서에도 나타나므로 아무것도 눈에서 사라지지 않습니다. 하지만 후속 전화나 메시지는 여전히 직접 해야 합니다. 결제 정보가 담긴 채로 작업 종료 당일 발송된 청구서는 고객의 마찰을 줄여줄 뿐, 15일째 되는 날 직접 내는 목소리를 대신하지는 못합니다.

잘못된 견적서를 있는 그대로 재현합니다. 변환은 서명된 그대로 복사합니다. 견적서가 공사비를 낮게 책정했다면, 청구서도 완벽한 서식을 갖춘 채 똑같이 낮게 책정됩니다. 견적의 정확성은 상류 공정에 달려 있으며, 어떤 청구 메커니즘도 그것을 대신 고쳐주지 않습니다.

계약금은 잔액을 바꿀 뿐, 청구 방식을 바꾸지는 않습니다. 작업 건에 기록된 계약금과 부분 지급액은 미수금에 반영되므로, 고객은 이미 지급한 금액에 대한 크레딧을 확인할 수 있습니다. 다만 이는 대금이 실제로 들어왔을 때 그때그때 기록되어야만 작동합니다. 시스템은 부기를 반영할 뿐, 대신 수행해주지는 않습니다.

자주 묻는 질문

최종 금액이 서명된 견적서와 다르면 어떻게 하나요?

범위가 바뀌어서 달라졌다면, 답은 변경이 일어난 그 순간에 변경 주문서를 작성하는 것입니다. 서명받고, 가격을 매기고, 작업 건에 첨부하면, 청구서는 자동으로 견적서에 승인된 변경 사항을 더한 값이 됩니다. 변환 시점에 항목을 수정하는 것도 가능하고 때로는 옳은 선택입니다(취소된 항목, 재료 대체 같은 경우). 다만 모든 수정은 고객이 서명한 것과의 차이이므로, 청구서를 보낼 때 조용히 지나칠 차이가 아니라 한 문장으로 설명해줄 가치가 있습니다.

작업이 끝나기 전에 일부를 청구할 수 있나요?

네. 계약금, 부분 지급, 대금 일정은 큰 공사에서 흔한 방식입니다. 착공 전 선지급, 마일스톤 시점의 기성금, 완공 시 잔금 형태로요. 각 지급을 해당 작업 건에 기록해두면 진행 중인 잔액이 정확하게 유지되므로, 최종 청구서 대화는 나머지 금액에 관한 것이 되지 총액을 재협상하는 자리가 되지 않습니다.

왜 제가 직접 청구서 번호를 고를 수 없나요?

청구서 시퀀스의 가치는 그것이 지루하다는 데 있기 때문입니다. 하나의 시리즈, 빈틈 없음, 중복 없음, 기장 담당자나 세무 조사관에게 설명할 것이 없습니다. 서버가 번호를 부여하는 방식이야말로 여러 기기와 오프라인 사용이 가능한 앱 전체에서 이 보장을 유지시켜줍니다. 이 절충안(오프라인에서 작성한 청구서는 동기화 시점에 번호를 받는다는 것)이 바로 시퀀스를 흠결 없이 유지시켜주는 요소입니다.

고객이 이미 계약금을 지급했습니다. 청구서에 반영되나요?

네, 계약금을 받았을 때 기록해두었다면요. 기록된 지급액은 작업 건의 잔액에 반영되므로, 고객은 원래 금액, 이미 지급한 금액, 그리고 남은 금액을 확인할 수 있습니다. 이것이야말로 질문에 답해주는 청구서와 전화 통화를 불러일으키는 청구서의 차이입니다.