开票申请与发票台账：开了哪些、进项有没有到

痛点：开票这件事，业务记一半、财务记一半

在多数企业里，"发票"是两个部门各拿一半的活。业务侧关心的是"客户催我开票了，开了没有"；财务侧关心的是"这张票号码是多少、有没有作废、进项那几张到了没"。两边各有一本账，中间靠微信、口头和一张贴在显示器上的便利贴衔接。

具体的乱，通常是这几种样子：

• 开票申请在路上。销售在群里发"客户A要开票，合同xx，金额xx"，财务照着录。谁先谁后、批没批、开完没有，全都靠问。月底客户投诉"票还没收到"，回头查聊天记录才发现那条申请被消息淹了。
• 销项发票只有一张纸。票开出来、拍照发给客户，然后这张照片就散在个人微信里。三个月后客户说这张票有问题要红冲，财务翻不出当时的开票口径：开的是哪份合同、对应哪笔发货、税率是多少、谁申请的。
• 作废与红冲没留痕。会计把台账里那一行改成新号码，旧的作废记录被覆盖了。年底一对税，账面张数与实际张数差了几张，谁都说不清差在哪。
• 进项发票全靠催。"这批货款已经付了，供应商的票什么时候开过来"——采购以为财务在追，财务以为采购在追。等到季度末要认证抵扣，才发现有几张票还压在对方财务那里。
• 抬头信息每次重填。客户的开户行、账号、税号、注册地址，每家都不一样，业务每次抄一遍，抄错一个字就要作废重开。

这些问题的共同点：发票需要一个自己的台账，而不是挂在聊天记录、个人相册或者一个共享表格里。它不是财务总账，也不是税控系统的替代品，而是"每一张票的业务来龙去脉"这一层记录。

先划边界：这张台账管什么、不管什么

用 Inkwell AI 构建器搭发票台账之前，把边界说清楚，避免上线后职责打架。很多团队失败不是因为做不出来，而是因为一开始就指望它替掉财务软件。

再说清三件"不做"的事，这几句请在上线时同步给参与的人：

1. 不直连税控设备或电子发票平台。票是在开票系统里开出来的，台账负责登记与跟踪；两边的关联靠"号码 + 金额 + 日期"这类事实字段对上，不靠系统自动回传。
2. 不做发票的自动识别录入。纸质票、PDF 票的内容由人登记（或从 Excel 导入存量），系统不承诺从图片里读金额。
3. 不替代税务判断。什么情况该作废、什么情况该红冲、进项能不能抵扣，以财税规定与属地税务要求为准，系统只记录你做的决定和发生的时间。

把这三句摆在前头，后面所有设计都会清爽很多：台账的定位是让"发票这件事"可查、可追、对得上，而不是变成一个财税引擎。

数据怎么建：五张表，先想清楚"一行代表什么"

AI 构建器的建模方式是：你用业务话把表与表的关系说清楚，平台据此生成带多租户隔离的数据库结构和管理页面。发票台账最容易翻车的地方不是字段不够，而是一行记录代表什么没想清——一次申请开了三张票、一张票被红冲成两张新票，如果都塞在同一张表里，统计一定重复计数。

推荐的底表结构，五张表：

1. 开票抬头档案（客户/供应商侧）。一行一家开票对象：名称、统一社会信用代码、注册地址、开户行、账号、开票联系人、默认税率、常用票种。这张表的价值是只录一次、以后引用，避免每张票重填抄错。同一客户有多个抬头（比如集团下不同主体）就一个主体一行，不要合并成一行。

2. 开票申请单（主表，一次申请一行）。谁申请的、给谁开、依据哪份合同或哪张销售单、申请金额（含税）、税率、票种、期望开票日期、当前状态、备注。状态用数据字典集中管理，建议固定几态：待审批 / 审批通过待开具 / 已开具 / 部分开具 / 已驳回 / 已作废。状态一旦定死，后面所有列表筛选、超期统计都干净。

3. 销项发票（一次开票动作一行，一张票一行）。与申请单是父子关系：一份申请可能开出一张票（最常见），也可能分几张开（跨月、分批），还可能一张都没开就被驳回。字段：发票号码、开票日期、金额（不含税）、税额、价税合计、票种、开票人、交付方式（字典：电子交付 / 快递 / 客户自取）、关联申请单。作废与红冲单独一行，不覆盖原行——这是本方案最重要的一条设计决定，后文单独讲。

4. 进项发票（收到的票，一张一行）。供应商、发票号码、开票日期、收票日期、金额与税额、对应采购单/入库单、认证状态（字典：待认证 / 已认证 / 不抵扣 / 已转出）、原件存放位置（谁保管、放哪）。采购侧最常问的一句"这批货的票到了没"，答案就从这张表按采购单反查。

5. 发票附件。扫描件、PDF、快递单号截图挂在发票那一行（不是挂在申请单上）。原因很实在：查票时人是按发票号找的，附件必须能从票反查到；挂在申请单上，一张申请开了三张票时就分不清哪份附件配哪张票。

表间关系一句话概括：申请单向下挂发票，发票向上挂申请、向外挂抬头，附件挂发票。 抬头是档案（被引用），申请单是流程单据（有状态），发票是事实记录（只增不改）。三类东西的"脾气"完全不同，混在一张表里就等着出错。## 关键设计决定：为什么作废与红冲要另起一行

发票台账出错最多的地方，不是少录了一张票，而是改历史。会计发现一张票开错了，最顺手的动作是打开那一行把号码改掉、金额改掉。改完在系统里看一切正常，可三个月后要对"这个月一共开了多少张、作废了几张"，答案已经不存在了。

所以这套台账有一条硬规则：事实记录只增不改，更正另起一行。

具体到四种场景：

实现上，销项发票表需要有这样几个字段：记录类型（字典：正常 / 作废 / 红冲）、冲抵原发票号（红冲时填）、更正原因、操作时间。这样一张票的完整生命是"一行一行读出来的"，而不是被覆盖成最后状态。

统计口径也随之干净：本月实开金额 = 正常票合计 − 红冲票合计；作废票不计入实开，只计入作废张数。这个公式要写进报表说明，不能留给每个人自己理解——否则财务、业务、老板三个数字又对不上。

金额怎么存：分档记录，不合并覆盖

发票金额天然是分档的：申请表上写的是"申请开票金额"，票开出来是"不含税金额 + 税额 = 价税合计"，客户改口后可能"实际开票金额"又不同。常见错误做法是用一个"金额"字段，每次往后覆盖。

推荐做法是一列一义，都保留：

• 申请金额（含税）：业务提申请时填的那个数，是审批依据，后续不覆盖。
• 开票金额（不含税）、税额、价税合计：发票上的三个数，按票面填。
• 差异原因：申请金额与价税合计不一致时写一句人话（"客户要求分两张开"、"去掉运费"）。

金额字段按平台的金额约定以整数分存储，页面上显示为元，导出也是元，业务人员无感，同时避免小数舍入导致的"合计对不上"。税额与价税合计的校验交给数据流规则（平台内置的规则引擎，可按条件在保存时执行计算与校验）：价税合计 = 不含税金额 + 税额，不成立就阻止保存并提示"请核对税额"。这条规则写一次，所有录入入口（PC、手机、导入）都受约束。

税率不要做成自由输入。用一个数据字典统一维护可选值，字典项按企业实际适用的税率维护——具体税率以财税规定与你所在属地主管部门要求为准，系统不内置法定值，字典由财务一次性维护好，业务只能选不能填。这样"13%"、"0.13"、"百分之十三"三种写法混在一个字段里的经典问题从源头消失。

审批流怎么串：一次申请，三个卡点

开票申请的审批普遍有两个诉求：金额大的要有人复核，抬头或税率异常的要看一眼。用平台的审批流能力（工作流定义与执行，节点支持条件分支），把这几个卡点串成一条固定线：

1. 业务提交：选抬头（从档案里选，不手填）、填合同或销售单、填申请金额与税率、附上客户的开票要求截图。
2. 部门负责人审批：看金额与业务真实性，超权限可驳回并写理由。
3. 财务复核：核对抬头与税率、确认票种、看是否重复申请（同一张合同已经开过票的，这里要能一眼看到）。
4. 财务开具后回填：拿到发票号码，登记到销项发票行，申请单状态自动推进到"已开具"或"部分开具"。

两处细节值得在建模时就说给 AI 听：

• 驳回要有理由字段，且是必填。没有理由的驳回，业务只能重新猜一遍，来回三轮是常态。
• 审批动作要留痕。平台的审批执行记录与操作审计日志会把谁在什么时候点了什么记录下来，事后追"这单谁批的"不用再问人。对于财务类台账，这个留痕本身就是合规价值。

自动化：四类容易被忘的动作交给系统

人工最容易漏的，不是不会做，而是忘了做。这四件事让平台替你盯着：

• 进项未到票提醒（定时任务）：采购单已入库、货款已付，但进项发票超过约定天数还没收到 → 定时任务扫描生成一条通知给采购经办与财务，并按周汇总成清单。这里的天数按企业与供应商的约定自行设定，系统只负责"到期可见"。
• 申请超期未开（定时任务）：审批通过超过 N 天仍未登记发票号码的申请单，列成待办提醒财务开票岗。
• 状态联动（数据流规则）：申请单下的所有发票行都完成登记后，主单自动置"已开具"，不需要人手工改状态；反之，只要有一张还没开，就停在"部分开具"。
• 重复申请提示（数据流规则）：同一合同同一金额的申请在 N 天内重复提交时给出提示，交财务复核判断，不直接拦截——真实业务里确实有分次开票的情况，规则只把异常亮出来。

存量数据的迁移别硬录。如果企业现在用一张 Excel 管销项、另一张管进项，平台支持把 Excel 表格直接建成模块（表头即字段、行即数据），先把历史数据搬进来，再在上面补字段、补状态、补审批。这一步做扎实，上线第一天台账就是完整的一本账，而不是从零开始。## 页面怎么用：五个角色，各看各的那一屏

数据建好后，平台会按模块生成管理页面，菜单挂载与访问权限走内置的角色权限体系。发票台账不需要一个大而全的首页，按角色拆开，每屏只回答一个问题：

业务/销售：我的申请开到哪了。 一屏两张表——"我提交的申请"（按状态分组，审批通过未开具的排最上面）和"我的客户开票记录"（按客户看历史开过哪些票、什么税率）。新增申请是这个角色的主入口，做成"选客户 → 带出抬头与历史税率 → 填金额 → 提交"三步，其余字段自动带出。

采购：我负责的供应商票到了没。 一屏是"待收票清单"：采购单号、供应商、入库日期、已付金额、约定收票天数、超期天数。这张表是做进项催收的抓手，按超期天数倒序排，第一行就是要打电话的那家。

财务开票岗：今天要开哪几张。 一屏是"待开具队列"（审批通过、未登记号码的申请），一条一行，点开看到申请单全部信息与客户要求。开完票回填号码，行从队列里消失。旁边放一个"待复核"区，处理抬头或税率异常的申请。

财务主管/税务岗：这个月开了多少、红冲了几张。 一屏是统计视角：按月的开票张数与价税合计、按票种与税率的分布、作废与红冲清单（每一张都能点开看原因与关联原票）、进项已认证与待认证的金额对比。这里的每个数字都要能下钻到明细行——只能看总数不能点开的报表，最终没人信。

老板：两个数就够了。 本月价税合计开了多少、还有多少申请压着没开（这直接影响回款节奏）、进项未到票金额多少。三个数字加一条趋势，不需要更多。

列表页有两个设计细节值得在建模块时前置说明，否则用起来第一周就会返工：一是可筛选、可排序的字段要在建模时就定下来（比如按开票日期、按状态、按客户、按超期天数），事后加筛选要改页面；二是导出要带上关键金额列，财务做月度汇总时几乎一定会导出到 Excel 做二次加工。

移动端：手机上只做三件短动作

PC 上构建的模块会在移动端同步出现同一套页面，接入平台的移动端工作台。但发票台账在手机上不该追求"全功能"，按场景收敛成三件短动作最实用：

1. 业务在客户现场提交开票申请：选客户、填金额、拍一张客户的开票要求截图上传，提交。附件通过平台的文件上传能力挂在申请上。
2. 财务在外回填发票号码：打开待开具队列，登记号码与金额、选交付方式，两分钟完成。
3. 管理者审批：审批流在移动端可视，看到金额、客户与合同摘要，通过或驳回并写理由。

进项收票登记也适合在手机上做——收到快递当场拍照、填号码、关联采购单，比攒一堆回办公室补录靠谱。

关于附件与照片，有一点要在上线时说明白：附件是凭据，不是发票本身的法律效力载体。纸质原件仍需按财务制度归档保管，系统里存的是电子副本与存放位置索引。

和别的台账怎么接：一张票至少牵三处

发票从来不是孤立的。上线时把这三处衔接说清楚，台账才真正嵌进业务：

• 与合同：申请开票时选合同，票就天然挂到了合同下。合同到期提醒、收付款节点在合同台账与到期预警里已经讲清，本文不重复；发票台账补上的是"这份合同到底开了多少票、开了多少钱"。
• 与销售：从报价到回款的链路在销售管理里，发票是这条链上的一个节点。建议在销售订单上直接能看到"已开票金额 / 未开票金额"，业务不必跳两个系统对。
• 与应收应付：发票与应收是两本账、两个口径——发票按张记，应收按客户挂账核销。两者的衔接与差异处理在应收应付台账里讲得很细，本篇只提醒一句：不要让发票台账去承担回款核销的职责，否则同一笔钱会被记两次。
• 与采购：进项发票关联采购订单或入库单，"付款了但票没到"才查得出来。采购侧的请购、订单、入库、对账一条线见采购管理。

四个衔接点的共同做法是：用引用关系指向已有单据，不复制字段。引用机制在页面上表现为下拉选择与名称快照（源头改名不影响历史单据可读），数据上仍是各自一张表，谁的字段谁负责。## 上线前查什么：八条自检

模块建完、页面挂上菜单，别急着宣布上线。按下表逐条走一遍，能挡掉后面八成返工：

1. 字典先定死。票种、状态、交付方式、认证状态、税率、更正原因——六个字典项一次性维护齐。字典不齐的后果是同一状态出现三种写法，后面所有筛选都漏数。集中维护的做法见数据字典。
2. 抬头档案去重。导入或录入前先按统一社会信用代码去一次重，同一客户留一行。这一步做了，以后所有"按客户统计"才有意义。
3. 金额校验规则实测。手工造三条数据：价税合计对得上、对不上、红冲为负。看系统是否正确拦截与放行。规则写好后，把所有录入入口都试一遍（PC 新增、手机新增、Excel 导入），口径必须一致。
4. 存量发票有基线。把历史发票导入为初始数据，并记一个"截至某日的张数与金额"作为基线。没有基线的台账，第一个月的报表一定被质疑"怎么比我去年的少"。
5. 权限按最小可用配。业务只看自己的申请与客户开票记录，采购只看自己负责的供应商，财务看全量，金额类字段对不该看的角色隐藏。角色与权限的配置方法见角色与权限配置。
6. 审批流程走一遍真实单。用一张真实的小额申请从头走到尾，包括驳回一次再重提。跑不通的流程上线当天一定会被绕过。
7. 提醒规则确认收件人。进项未到票提醒发给谁、申请超期提醒发给谁，要指名到岗不指名到人——人一调岗，提醒就消失了。定时任务的配置方式见工作流与定时任务。
8. 移动端真机过一遍。在售人员手机上的提交、拍照、审批各做一次。移动端的使用说明在移动端指南，工作台的入口与模块同步机制见移动端。

之后怎么延伸：三条自然长出来的路

台账跑顺一两个月，通常会往三个方向长出需求，按顺序做比较稳：

• 往合同/订单的方向长：把"合同金额 → 已开票 → 已回款"三个数摆在同一个视图里，合同履约情况一目了然。这一步依赖合同台账与应收台账先建好，引用关系接上即可。
• 往供应商评价的方向长：把进项到票及时率作为一项指标算进供应商评分，采购议价时多一个事实依据。指标从台账里算出来，不需要额外录数据。
• 往月度对账的方向长：每月固定时点由定时任务生成"本月开票汇总"与"进项认证汇总"两张待办，财务核对后归档。归档动作可以用平台的模块归档能力处理旧数据，不删记录、只归档。

延伸的共同前提是：基础台账的数据干净。数据不干净的台账上加多少视图都不好看。

不做什么：这份方案的边界

诚实地说清边界，比夸大能力更省事。以下这些不在这套台账的承诺范围内：

• 不直连税控设备、电子发票服务平台或任何税务系统。发票的开具动作仍在原有开票系统里完成，台账只登记结果、跟踪状态。两边的一致性靠人工登记纪律与月度对账保证。
• 不做发票自动识别（OCR）。扫描件与照片是附件凭据，金额、税号、号码由人录入或从 Excel 导入，系统不承诺从图片中读出发票要素。
• 不判断能不能抵扣、该不该红冲。系统只记录"你做了哪个决定、什么时候做的、原因是什么"，判断依据以财税规定与属地税务主管部门要求为准。
• 不替代财务软件。不生成凭证、不做科目余额、不出版财务报表；发票台账是业务层的一本明细账，与财务软件的衔接靠导出与月度对账。
• 不保证开票时限。系统能提醒"该开了"、"该催了"，但对外承诺的开票时效由企业自己与服务对象约定，不是平台能力。
• 不承担纸质原件的归档保管责任。电子副本只是索引，原件归档按财务制度执行。

把这六条写进上线通知里，能省掉后面无数次"你们这个系统怎么不能……"的解释。

一句话记法

发票台账的全部设计，可以压成四句话：

申请单管"要不要开"，发票行管"开了什么"，作废红冲另起一行不改历史，提醒交给定时任务不靠人记。

需要看这套思路在别的台账上怎么落地，可以从应收应付台账和合同台账与到期预警接着读——三者共用同一套"主表管状态、记录表只增不改、时间节点交给提醒"的骨架。