商业票据台账：收票、背书、贴现与到期托收

痛点：票在谁手上、哪天到期，靠本子和记性

做制造业和贸易的企业，几乎都收承兑汇票。客户不给现钱，给一张六个月后到期的银行承兑汇票——这在行业里是常态。问题不在"收票"这个动作，而在票进来之后的半年里：它现在在谁手上、有没有背书出去、哪天到期该去托收、贴现回来多少钱、万一退票怎么追。

多数企业这一段是靠一本纸质票据登记本、一个保险柜和几个人的记性撑起来的。具体的乱通常长这样：

• 票的位置说不清。销售从客户那里拿回票、交给财务经理、财务经理锁进柜子、出纳拿去银行托收——经三四个人手，谁手上有几张票、合计多少金额，问三个人可能得到三个答案。
• 到期日靠便利贴。票面到期日是印在票上的，落到登记本上经常只写"三个月"或"下季度"。真正要去提示付款的那几天，靠的是当初收票的人还记得。过期没提示的后果不小，但具体时效以票据法和开户银行规定为准，系统不能替你判断。
• 背书出去没留痕。为了付供应商货款，把一张大票背书转让出去，登记本上可能只写"背书给某供应商"。半年后这张票在最后一手持票人那里出了问题，一路追索回来，企业需要说清"这张票是谁、什么时候、背书给了谁"——登记本上找不到这一行。
• 分拆背书后余额对不上。一张一百万的票，背书三十万给甲、四十万给乙，剩下的还想留着贴现。纸质台账没法表达"一张票的余额在流动"，最后变成在备注里写几个数字，谁都算不清还剩多少可用。
• 贴现后账上还有这张票。票已经卖给银行拿到钱了，台账没销，下个月统计在手票据时又把它算进去一次，资金口径直接虚高。
• 月底统计全靠人工数。老板要问"现在手上还有多少票、多少是商承、这个月要到期多少"，出纳翻柜子数票、按计算器，两天才能给出一版，而且和上周那一版往往对不上。

这些问题的共同点：票据需要一份自己的、按张记录的、事件累加的台账。它不是财务总账，也不是银行网银的替代品，而是"每一张票从进来到核销的完整经历"这一层记录。

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

用 Inkwell AI 构建器搭票据台账之前，先把边界钉死。上线后职责打架，八成是因为一开始就指望它替掉网银或财务软件。

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

1. 不直连银行或票据交易所系统。票的承兑、提示付款、贴现申请都在银行侧完成；台账负责登记与跟踪，两边的关联靠"票号 + 金额 + 日期"这类事实字段对上，不靠系统自动回传。
2. 不识别票面、不验真伪。纸质票或电子票面的内容由人录入（存量部分可以从 Excel 导入），系统不承诺从照片里读票号或金额，也不做票据真伪核验——那是银行和票据交易所的能力。
3. 不替代票据法与银行规定的判断。什么时候必须提示付款、过了期限还能不能追索、背书是否连续有效，以票据法、司法解释与开户银行要求为准。系统只记录"你做了什么决定、什么时候做的"。

把这三句摆在前头，后面的设计会清爽很多：台账的定位是让票据这件事查得到、追得回、对得上，而不是变成一个票据交易引擎。

和发票台账、应收应付台账怎么分工

这三件事经常被混为一谈，实际上管的是三个不同的对象：

• 发票台账管的是"业务和财务之间开票这件事"——开票申请、销项发票、进项发票、作废红冲。参见开票申请与发票台账。
• 应收应付台账管的是"客户欠我多少、我欠供应商多少"的动态余额与核销。参见应收应付台账。
• 票据台账管的是"客户用一张承兑汇票付了这笔款之后，这张票的后续半年"。

三者通过票号与业务单据相互引用，但绝不合表。最关键的一条：客户交来一张承兑汇票时，应收台账里应记一笔"回款方式=承兑"，同时在票据台账登记这张票；票据到期真正收到钱时，不能再往应收台账里记一次回款，否则同一笔钱被核销两次。这条口径在上线前就要和财务对齐。

数据怎么建：一张主档 + 一条只增不改的事件流水

AI 构建器的建模方式是：用业务话把表和表的关系讲清楚，平台据此生成带多租户隔离的数据结构和管理页面。票据台账最容易翻车的地方不是字段不够，而是一行记录代表什么没想清——一张票既会被收进来、又会被背书出去、还可能贴现，如果把这些动作都塞进主表的几个字段里，历史一定被覆盖。

推荐的结构是两层：票据主档（一票一行）+ 票据事件流水（一次动作一行，只增不改）。

1. 票据主档：一张票一行

核心字段：票据号码（唯一约束）、票种（字典：银行承兑 / 商业承兑 / 财务公司承兑）、出票人、承兑人、出票日期、票面到期日、票面金额、收款人、是否可转让、当前状态、当前持有人/当前位置、来源业务（引用客户档案与销售单或应收行，可空）。

三条设计要点：

• 票号必须做唯一约束。这是本方案的第一道闸：同一张票被销售和出纳各录一次、或者换个格式再录一次，保存时直接被拦下，并提示已存在的记录。没有这条约束，票据池的数字从第一天就是虚的。
• 到期日不手填，由出票日期加票面期限（月或天）算出，交给数据流规则在保存时执行。手填的到期日会错，而且错了没人发现——直到过期。
• "当前状态"和"当前持有人"只做展示，不允许人手改，只能由数据流规则在事件保存时刷新（见下条）。设计上把它当成"最新事件的投影"，而不是一个独立的业务字段。

2. 票据事件流水：一行一个动作，只增不改

事件类型走数据字典，建议一次定死这几态：收票、背书转让、贴现、质押、解除质押、托收申请、到期收款、退票、追索。

每行记：所属票据（引用主档）、事件类型、发生日期、对手方（引用往来单位档案，比如背书给谁、贴现给哪家银行）、本次发生金额、经办人、附件、备注。

配套的规则：

• 金额三列，各司其职：票面金额只在主档记一次；事件行记本次发生金额（背书多少、贴现多少）；"可用余额"由汇总计算得出，不落成一个手填字段。一张一百万的票背书出去三十万，余额自然变成七十万。
• 分拆背书靠余额校验兜底：事件保存时由数据流规则汇总该票已发生的背书与贴现金额，累计超过票面金额就拦截。这样"分三次背书超额"这种错误在录入那一秒就被挡住，不靠人事后核对。
• 状态由最新事件反推。收票入账后状态自动为"在库"；背书全额出去自动转"已背书"，部分背书转"部分背书"；贴现后转"已贴现"；托收申请后转"托收中"；银行到账登记后转"已收款"。人只录事实，状态自己跟着走。
• 退票与撤回不是删除。票被退回时新增一条"退票"事件，金额与影响写清楚，原事件保持不动。任何时候翻这张票的历史，都应看到完整时间线，包括那些"后来被推翻"的动作——这也是审计视角要的东西。

3. 附件挂在事件行上

票面照片、背书回单、银行托收凭证、贴现到账回单，统统挂在对应的那条事件下，而不是挂在票据主档上。原因很实在：查票时人是按动作找的（"这张票背书给甲的那次，回单还在不在"），附件挂在事件行才能一一对应；挂在主档上，一张票有七八个动作时，附件就成了一堆无归属的图片。

4. 到期提醒任务不单独建表

到期清单是"算出来"的，不落成一张需要人工维护的中间表：由定时任务每天扫一遍在手票据，按到期日与当前状态生成清单并推送。生成物与主档始终一致，不会出现"提醒表改了主档没改"的错位。如果企业确实需要跟踪托收办理过程（提交银行、银行受理、到账），那份记录应作为托收申请事件 + 到期收款事件落在事件流水里，而不是另建一张表去复制票据的到期日。

字典维护走平台的数据字典能力：票种、状态、事件类型、背书方式都在一处集中维护，后面所有页面筛选、统计口径都从这一处取，避免同一个意思出现好几种写法。

页面怎么用：四个视角，各看各的那一屏

数据建好后，平台按模块自动生成管理页面（列表、表单、详情），菜单挂载与权限走内置的角色权限体系。票据台账的关键是按人分视角——同一个库，出纳看的是待办，财务主管看的是审批与敞口，老板看的是资金面。

出纳：我的票据库与今日待办

出纳是这套台账的日常主人，她最需要的不是"统计"，而是"今天该干什么"。

• 票据库列表：默认按到期日正序排，最上面就是最快到期的那几张。列显示票号后四位、客户、票种、票面金额、到期日、剩余天数、当前状态、当前所在位置。筛选器做四组：状态、票种、到期区间、客户。
• 今日待办：待收票确认（业务提交了客户交票，等出纳核对票面）、待办托收（已到期或临近到期的在库票）、待确认到账（已提交托收但未登记收款）。这三块用列表页的数据视图组织，不需要额外建表。
• 收票登记表单：这是最高频的动作，字段要短。票号、票种、出票人、承兑人、出票日、票面期限、票面金额、客户、附件（票面照片）。到期日不用填，保存后自动算出，出纳能在提交前就看到"这张票几月几号到期"，当场发现录入的期限填错了。

财务主管：审批、票据池与异常清单

• 背书与贴现审批：背书转让、贴现、质押都走审批流（平台内置的工作流能力，节点和条件用可视化编辑器配置，见工作流可视化编辑器）。审批卡片上必须带三件事：这张票的原貌（票号、金额、到期日）、本次动作的对手方与金额、动作后该票的余额与状态。审批人如果不看这三项就点通过，等于闭眼签字。
• 票据池视图：在手票面合计、按票种（银承 / 商承）的占比、按到期月份分布、已贴现未到期的敞口。这些是列表页之上的汇总卡片，数据全部来自主档与事件流水，不另存一份。
• 异常清单：状态与最新事件不一致的票、已过到期日仍在库未托收的票、部分背书后长期未处置的票。这份清单由定时任务每天生成，是财务主管每天早上该看的第一屏。

业务员：把自己经手的事交上去、看得见进度

业务员不该看到全部票据，但他需要做两件事：提交客户交票（客户在办公室把票给了销售，销售拍照上传提交，等出纳核对确认），以及查自己客户那几张票走到哪一步了——是不是已经入账、有没有贴现、客户问起来能答。权限上按"本人 + 本部门"收敛，避免销售能看到全公司票面金额。

老板：一屏看完资金面

老板关心的三个数：手上还有多少票没变现（在库票面合计）、这个月要到期多少（到期日历）、贴现出去多少还没到期（敞口）。再加一个"按客户的收票占比"，能看出哪些客户靠票据结账、账期实际被拉长了多少。这几张卡片放在模块首页，进模块第一眼就能看到。

自动化：四类规则让台账自己动起来

手工台账最容易死的地方，是"人得记得去提醒"。平台有四类自动化可以配，票据台账刚好把四类都用上。

一、审批流：把钱的动作管在轨道上

背书转让、贴现、质押、退票处置，这四类动作都会改变资金安全边界，应该走审批。配置上按金额分档：小额背书部门负责人批，大额加一道财务负责人。分档金额不设默认值，由企业按自身授权制度定，上线时一次性配好。审批通过后，平台按流程图继续推进状态，审批过程与意见都留痕在流程执行记录里。

二、数据流规则：算、校验、刷新状态

数据流规则是"条件触发的自动处理"，在保存那一刻执行，是这套台账真正的逻辑层：

1. 到期日计算：出票日 + 票面期限 → 到期日。录入即算，不留手填口子。
2. 余额与超额校验：保存背书或贴现事件时，汇总该票已发生金额，累计超过票面金额直接拦截；同时把剩余可用余额回显在表单上，让经办人当场看到"这张票还能背出去多少"。
3. 状态与位置刷新：事件保存成功后，按最新事件更新主档的状态与当前位置。人手改不了，避免了"状态说是已背书、其实票还在柜子里"这类矛盾。
4. 贴现实收金额校验：贴现时登记票面金额、贴现息、实收金额，规则校验"实收 = 票面 − 贴现息"等式成立，不成立就不让提交。利率与贴现息由银行给出，系统只做等式校验，不计算也不建议利率。
5. 跨台账口径提示：客户交票时，如果关联的应收行尚未登记回款方式，规则可在保存后提示经办人回补，避免票据和应收两本账各走各的。

三、定时任务：到期清单与巡检

平台内置的定时任务能力（Cron 配置 + 执行记录，见工作流与定时任务）在这里承担两件日常活：

• 每日扫到期：按到期日与当前状态生成"即将到期"和"已到期未托收"两份清单，提前天数（比如提前 30 天、7 天）作为任务参数由企业自己配，平台不内置天数。每次执行都有记录，哪天没跑成功查得到。
• 每周巡检一致性：扫一遍"主档状态与最新事件不符"、"在库但无附件"、"已贴现但贴现息为空"这类数据，生成待处理清单推给财务主管。这类巡检不拦单据，只暴露问题——它的价值是把"月底才发现"提前到"每周都知道"。

四、通知：推给该看的人，而不是群里刷屏

清单生成后有两条路：站内信与邮件。到期提醒推给"当前持有人 + 财务主管"，超期未处理第二天再推一次。这里要注意的是不要全公司群发——票据金额是敏感信息，通知内容只写"票号后四位 + 到期日 + 动作要求"，具体金额在系统里点进去看。谁收到什么通知，由权限体系和通知模板一起控制。

移动端：收票现场与审批在手机上完成

票据这件事有两个动作发生在工位上之外：在客户那里拿到票，和审批的人不在电脑前。这两块是移动端最值得做的部分。

• 现场收票登记：业务员或出纳在客户办公室拿到票，掏出手机拍票面、填票号与金额、选客户，提交。附件在手机上直接拍直接传，回到公司不用再补录一遍。平台的处理方式是 PC 模块建好后移动端同步生成对应页面，权限与 PC 一致，见移动端使用指南。
• 移动审批：背书与贴现审批推送到手机，审批卡片上同样是那三项关键信息（票的原貌、本次动作、动作后余额与状态），通过或驳回都能填意见。财务负责人在银行办业务排队时就能把字签掉，不必等回办公室。
• 到期待办随手查：本周到期的票有哪些、哪几张该去托收，在手机上按到期日排一列，出纳在去银行的路上就能看。

需要说清的是移动端不做什么：不在手机上做票据识别的自动填单（票面文字不自动读取），也不承诺离线填写后再自动同步。现场没有网络时，稳妥的做法是先用手机拍照留存，回到有网络的地方补录，附件补齐后再提交。这两点都在"不做什么"里再强调一次。

上线前查什么：八条清单

系统建好不等于能用起来，票据台账上线前建议逐条过一遍。

1. 字典先定死，后建单据。票种、状态（在库 / 部分背书 / 已背书 / 已贴现 / 已质押 / 托收中 / 已收款 / 已退票）、事件类型，一次配置到位。字典事后改，历史数据的筛选口径就会裂开。
2. 票号唯一约束生效并实测。用同一张票号录两次，确认第二次被拦下且有明确提示。这是整套台账的基石，不实测一遍不算过。
3. 到期日自动计算实测。录一张"出票日 + 6 个月"的票，核对算出来的到期日与票面是否一致；再录一张按天计期的，验证两种期限类型都覆盖。日期算错是这类台账最贵的错。
4. 余额校验实测。人为录三次背书，累计超过票面金额，确认第三次被拦截。顺带验证"部分背书"状态下余额显示是否正确。
5. 期初存量导入。存量票据用 Excel 导入（做法见用 Excel 一步建模块），但必须包含三类：在库的票、已背书出去但未到期的票、已贴现未到期的票。只导在库的，票据池一上线就是错的，而且错得没人知道。导入后逐张核对票号与票面金额，这一步的人工对账不能省。
6. 权限按角色配到位。出纳看全量还是只看自己经手、业务员只能看本人与本部门、财务主管有审批权但未必有删除权、老板看汇总卡片但不改数据。平台的角色与权限配置支持从内置角色出发再自定义。特别注意：金额字段的可见性，一线业务员未必需要看到全公司票面总额。
7. 审批阈值与提醒天数按企业制度配。背书金额分档、到期提前提醒天数、超期升级层级，这三项不内置默认值，由企业授权制度与资金管理要求定。
8. 发布预检与双端核对。模块发布前走一遍预检（菜单挂载、页面可达、移动端同步），做法见模块的测试与发布。发布后录一张真实票据跑完整链路：收票 → 背书 → 贴现 → 托收 → 到账，确认每一跳的状态与余额都对，再把期初数据正式导入。

另外建议把审计日志打开：谁改了哪张票的状态、谁审批的、什么时候导出的清单，都能在审计日志里查到。票据台账一旦涉及资金，事后追责的路径必须是现成的。

之后怎么延伸

这套结构起来之后，几张表能往外长：

• 和应收应付联动：客户交票时，在应收台账里体现出"回款方式=承兑、尚未到账"，票到期收到钱后再把应收行核销掉。两边靠票号关联，一笔钱只核销一次。
• 供应商付款用票：反向背书给供应商时，同一张票的事件流水里多一条背书事件，对手方换成供应商档案，付款与票据在一条时间线上。
• 质押融资台账：把质押、解除质押、融资到账几个事件补全，就能看到"多少票被压在银行、融了多少钱、什么时候要解押"。
• 票据成本视角：把贴现息按客户或业务线归集，能看出"哪些客户用票结账时，实际让我多付了多少贴现成本"——这个数在谈价时是有分量的。
• 与合同、销售单三向对照：一张票对应哪份合同哪批货，查一笔业务从签单到收票到变现的完整链路。

这些都建立在同一套主档 + 事件流水上，不需要重做数据模型——这也是先把"一票一档、事件只增不改"设计对的价值。

不做什么：这些事请在会上说清楚

边界写在这里，是为了避免上线后被赋予它做不到的任务：

1. 不直连银行或票据交易所做提示付款、发起贴现。台账登记事实与状态，不发送真实指令。若企业后续要做银行直连，需要单独的系统对接工作，不在本方案范围。
2. 不做票面识别与验真。纸质票、电子票的内容由人录入或从 Excel 导入；票据真伪、背书连续性由银行与票据交易所核验。移动端不承诺拍照自动识别票号或金额。
3. 不做追索权时效的法律判断。到期该怎么提示付款、超期还能不能追索，以票据法、司法解释与开户银行要求为准；系统只保证"到期这件事被提前提醒过、有人处理过、处理过程留了痕"。
4. 不生成会计凭证、不替代财务软件。票据台账不做分录、不做科目余额，与总账的衔接靠期初对齐与定期对账。
5. 不做贴现利率比较与融资决策。贴现息与实收金额由银行给出、人工登记，系统只校验等式与留痕，不建议"该不该贴现"。
6. 不做银行账户余额的自动取数。账户资金以银行侧为准，台账不与其自动对账。
7. 不承诺资金安全结论。台账能保证的是每一张票查得到、每一次流转追得回、每一个数字对得上；它不会让票据风险消失。

如果你正在把票据登记从纸质本子搬到系统里，可以先从"收票登记 + 到期提醒"这两个最小动作起步，跑顺一个月，再把背书、贴现纳进来。用 Inkwell AI 构建器搭这套东西，第一版通常从一个字段清单和一句业务描述开始就够——剩下的结构，前面几节已经讲清楚了。