简短的答案： 永远不要把一份已签报价单重新敲成发票。重新输入正是行项目会跑偏、税费会被重新计算、客户当初同意的数字和你最终开出的数字悄悄出现差异的地方。改用转换的方式，行项目、税费和客户信息都会原封不动地带过去，发票就能和当初签署的那份文件保持一致。
周二晚上九点四十，你正坐在厨房餐桌前开发票。已签的报价单开在手机上，靠在一个咖啡杯边，你正在逐行把它抄进发票里：同一个客户，同一个地址，同样的十四行，同样的税费。抄到第九行，你把 1,840 美元打成了 1,480 美元。
没人发现。客户毫无异议地付了这张发票，因为客户不会去投诉一张金额偏低的发票，于是 360 美元的利润就这么悄无声息地蒸发了，没人知道它曾经存在过。或者错误往另一个方向发生，客户发现了，于是发票上其他每一个数字都开始被怀疑——而在那封邮件之前，这个项目本来一切顺利。
不管哪种情况，错误都不是在九点四十那一刻造成的，而是从这套工作流程要求你把同样的十四行内容打两遍的那一刻，就已经注定了。
为什么重新输入一份报价单会让你亏钱？
把报价单抄进发票，感觉像是一件文书工作，而这恰恰是它危险的原因：它总发生在你疲惫的时候，枯燥到让人注意力涣散，而它出错的方式又总是悄无声息的。
少收的钱是无声的。 一个位数抄错、一个 60 美元的行项目在抄的过程中不知怎么就没了、数量 12 变成了 2。这些错误都不会自己冒出来提醒你。客户按发票上写的付钱，项目结案，等你之后做项目成本核算时，看到的是一个利润问题，你却会把它误判成定价问题。
多收的钱是响亮的。 同样方向反过来的一个笔误，很快会被发现，而代价并不是那 360 美元。代价是，客户从此开始审查每一张印着你名字的单据。发票上的信任是非黑即白的，一个数字错了就足以把它推翻。
税费这一行自成一个陷阱。 重新输入意味着要凭记忆重新套用税务处理方式：哪些行需要征税、税率是多少、按哪部分计算。一旦出错，你要么在结算时自己吃掉这个差额，要么就得给客户发一封谁都不喜欢写的更正邮件。
而重新打字本身还有一笔进度成本。 因为靠重打的开票方式本身就是件苦差事，它会一直拖到一个清闲的夜晚才做。旺季里清闲的夜晚很稀有，于是完工的项目就这样一天天堆着没开票。堆着的每一天，都是你在纯粹因为数据录入太麻烦，而免费替客户的项目垫资。
在晚上九点四十打字打得再仔细，都不是真正的解法。彻底取消“再打一遍”这个步骤才是。
项目盈利计算器能显示一个已完工项目，是否真的赚到了你报价时打算赚的那份利润。
转换：让发票成为“升级版”的报价单
在 Zeus 里，一份已签报价单可以直接转换成发票。行项目会完全按照报价单上的样子带过来：描述、数量、单价。税务处理方式也会一并带过来。客户信息和项目信息同样会一并带过来，因为发票是直接建在报价单所在的那个项目上的，而不是一份需要你重新填地址的独立文件。
原本一整晚的苦差事，变成了项目收尾时最后三十秒的事。你可以在车还没离开路边的时候，就在客户家门口直接从客户签署的同一份记录生成发票。
这里还藏着一个容易被忽略的额外好处：客户会认出这张发票。 当一张发票上的行项目、措辞和总金额都和客户签署的文件一致时，它读起来像是一次确认，而不是一份需要仔细审视的新文件。眼熟的发票，客户直接就付了；陌生的发票，则会被拿来细细研究。一张重新打过的发票，措辞被改写、行项目顺序被打乱、总金额接近却又莫名其妙不一样，即使每个数字都是对的，也会引来这种审视。
转换并不会锁死你，让你没法再修改。有时候发票确实会和报价单有出入：项目中途被客户取消的一行，或者一次材料替换。你完全可以在发送前调整。关键在于起点：你从已签署的文件出发，只改动真正发生变化的部分，而不是从一张空白页开始，指望能凭记忆把它重建出来。
变更单归入同一个项目
项目进行中的变更，正是发票重建最容易出问题的地方。报价单写的是 8,400 美元。然后客户加了一个插座、批准了一段围栏，又取消了棚屋的置物架——这一切分别在三次对话和一条短信里达成一致。到了开票的时候，靠重打的承包商这时就成了考古学家，得从记忆和翻聊天记录里拼出最终的数字。
当变更以变更单的形式记录在同一个项目上（定价、签字、和原始报价单归档在一起）时，最终的发票就不再是一次重建的过程。它就是已签报价单加上已批准变更的总和，其中每一项都是客户已经亲笔签过字的文件。发票上没有任何一项是新信息。
这会彻底改变项目交接时的对话方式：
“这张发票和你 4 号签的报价单一致，外加你批准的三项变更：11 号加的那个插座、15 号那段围栏，还有取消掉的棚屋置物架。数字和文件上的一模一样，上面没有任何新东西。”
换成一张手工拼凑的发票，外加对三次现场对话的模糊记忆，你试试这段话还说不说得出口。区别不在于礼貌与否，而在于一个版本能在十秒内和签字文件核对，另一个不能。
发票号出现断号会怎样？
一件小事，到报税季却会变得不小：编号。
手工编号的发票会漂移。你会跳过一个号、重复用一个号，或者因为手机和电脑各自有一套自己的编号逻辑，最终跑出两套序列。这一切看起来都无伤大雅，直到某个以审查为职责的人（记账员、年终对账的会计、税务审查员）问起 1047 号发票去哪了。发票序列里出现一个缺口，看起来就像是一张被删除的发票，而“我大概是漏掉了吧”，不是你愿意拿来解释自己营收记录的答案。
在 Zeus 里，发票号由服务器为整个公司统一分配，形成一个不留缺口的单一序列。你永远不需要自己挑号码，两台设备也不可能撞号，这个序列也就没有需要解释的漏洞。由此产生的一个实用细节是：由于号码是由服务器发放的，一份离线草拟的发票，会在同步时才拿到它最终的编号。序列之所以能保持干净，恰恰是因为没有任何一台设备被允许自己去猜号码。
配套的规则是：出错的发票要作废，而不是删除。一张作废的发票依然会留在记录里，标注为“作废”，让序列保持完整，也让这段历史不失真。一个能让你悄悄删掉内容的开票系统，它出的报表你自己也不敢全信。
集中处理周五的积压发票
即使有了转换功能，真实的一周结束时往往还是会积压一堆：周一以来完工的四个项目都还没开票，因为每次收尾之后，下一个项目已经在等着。
批量开票正是为了应对这种堆积。你不用一次处理一个已完工项目，而是一次性为多个项目批量生成发票：每一张都基于各自已签署的报价单和已批准的变更单建立，都按顺序编号，随时可以发送。周五的积压发票，就这样从一个你不断推迟的夜晚，变成了几分钟的事。
这背后的经济账很朴素也很真实：项目一完工当天就发出的发票，能立刻启动收款倒计时，而这时项目本身（以及你积累下来的那份口碑溢价）在客户心里还很新鲜。发票在客户还欣赏着成果的时候到，待遇就好；拖两周才到，它读起来就像陌生人寄来的一张账单。你不需要任何统计数据，也能判断出哪一种发票会在客户的收件箱里躺得更久。
这套流程解决不了什么
有必要说清楚，因为一个号称能解决一切的工具，其实什么都解决不了。
除非你开口让它做，否则它不会替你去催账。 自动逾期提醒是有的——“催收逾期发票”会在发票逾期第 3、7、14 天给客户发一封提醒邮件，然后就停下来——但它默认是关着的，得你自己去打开，而大多数承包商都让它一直关着。未付的发票会出现在“提醒”里——也就是那个专门收拢需要你处理的事项的队列——也会出现在你的应收账款账龄表里，这样就不会有任何一笔钱悄悄从视线里消失。但那通跟进电话或消息，依然得由你来发。一张在项目完工当天就发出、并附上收款方式的发票，能降低客户付款的阻力；但它不能替代你在第十五天该说的那句话。
它会原封不动地复制一份错误的报价单。 转换复制的是已经签署的内容。如果报价单本身低估了项目价格，发票也会一模一样地低估它，而且格式还完美无缺。估价这门功课要在报价那一步就做好，任何开票机制都补不回来。
定金改变的是余额，而不是开票逻辑。 记录在项目下的定金和部分付款，会体现在应付余额里，客户能看到自己已付的钱被如实抵扣。但这一切的前提是，付款真正到账的时候要被记录下来。这套系统反映的是你的记账工作，而不会替你完成记账。
常见问题
如果最终价格和已签报价单不一样怎么办？
如果是因为范围发生了变化，答案是在变更发生的当下就出一份变更单，签字、定价，并附在项目下，这样发票自然就是报价单加上已批准变更的总和。在转换时调整行项目也是可以的，有时候也确实需要（一行被取消的项目、一次替换），但每一次调整都是对客户所签内容的一次偏离，所以在发送发票时值得附一句解释，而不是让客户悄悄自己发现一个差异。
能不能在项目完工之前先开一部分发票？
可以。对于较大的项目，定金、部分付款和分期付款计划都是很正常的形式：先付一笔预付款，到某个节点再收一笔，完工时收尾款。把每一笔付款都记录在对应的项目下，能让实时余额保持准确，这样最终的发票对话谈的是剩余尾款，而不是重新协商总价。
为什么我不能自己选发票编号？
因为发票序列的价值恰恰在于它足够“无聊”：一套序列、没有缺口、没有重复，不需要向记账员或税务审查员解释任何东西。由服务器统一分配编号，正是让这份保证能在多台设备和一个支持离线使用的应用之间始终成立的原因。而这背后的取舍——一份离线草拟的发票要等同步时才拿到编号——恰恰是让这套序列无可挑剔的关键所在。
客户已经付过定金了，发票上会显示吗？
会，前提是定金在收到的当下就被记录了。已记录的付款会计入项目余额，这样客户能看到最初的金额、已经付了多少、还剩多少，而这正是一张能主动回答问题的发票，和一张会引来一通电话的发票之间的区别。
ZEUS