Back to Details

k2f-invoice

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

K2F Invoice — AI-Native Aesthetic Design

K2F 发票 — AI 原生美学设计

Purpose

目的

Teach agents to blueprint invoices before layout: legally and operationally complete party and reference data, a reconciled line-item and tax math story, and visual hierarchy that surfaces what is owed, by when, and how to pay—without inventing banking, tax IDs, or amounts the user did not supply.
教会 Agent 在排版前先规划发票蓝图：完善法律和业务层面的参与方与参考数据，构建可核对一致的明细项和税额计算逻辑，并建立能够突出应付多少、何时支付以及如何付款的视觉层级——绝不虚构银行信息、税务 ID 或用户未提供的金额。

Built on K2F

基于 K2F 构建

This skill produces invoices as 
.K2F
packages. Follow the k2f skill for authoring: unpack or init a workspace, edit the semantic tree, run pack/verify, then export. K2F keeps agents on meaning (parties, line roles, totals, payment block)—not pixel coordinates—while the engine compiles layout, typography, and theme into consistent output across PDF and other formats.
Before you build, install the core skill: 
npx skills add suzheng/k2f --skill k2f
.
此 skill 会生成 
.K2F
包。请遵循 k2f skill 进行创作：解包或初始化工作区，编辑语义树，运行 pack/verify，然后导出。K2F 让 Agent 专注于语义（参与方、明细行角色、总计、付款区块），而不是像素坐标；引擎则负责将布局、排版和主题编译为在 PDF 及其他格式中保持一致的输出。
构建之前，请安装核心 skill：
npx skills add suzheng/k2f --skill k2f
。

When to Use

使用场景

  • Issuing a new invoice from a quote, timesheet, contract, or pasted line items.
  • Rebuilding a messy or generic AI invoice so math, references, and payment details align.
  • Pro forma or deposit invoices where due date and amount semantics differ from a standard bill.
  • 根据报价单、工时表、合同或粘贴的明细项开具新发票。
  • 重新整理凌乱或千篇一律的 AI 发票，使金额计算、参考信息和付款详情协调一致。
  • 开具 pro forma 发票（形式发票）或押金/部分付款发票，其到期日和金额语义与标准账单不同。

Workflow

工作流

Step 1. Generate the content_and_design.md

步骤 1. 生成 content_and_design.md

Single blueprint for semantic content and aesthetic intent. Use labeled blocks the k2f skill can map to regions later.
Sub-steps
  1. Invoice type & jurisdiction lock — Standard bill, pro forma, deposit/partial, or credit-style adjustment. Note currency, locale (date and number formatting), and whether tax is inclusive or exclusive. Omit sections the type does not need (e.g., skip “amount due” hero on non-collecting pro forma).
  2. Party & identity block — Seller: legal name, address, contact, logo intent, tax/VAT ID only if user provided. Buyer: bill-to name and address; optional ship-to or attention line. Never fabricate registration numbers or bank details.
  3. Reference metadata — Invoice number, issue date, due date (or explicit “Due on receipt / Net N”). PO, project, contract, or customer reference when supplied. One currency code for the whole document; flag missing due date before layout.
  4. Line-item architecture — Table-first, not prose paragraphs. Per row: clear description, quantity, unit, unit price, line amount. Group optional sections (services vs expenses, milestones) only when the user’s data already splits that way. Discounts as explicit negative lines or percent note tied to a subtotal rule—never hidden in copy.
  5. Totals story (write the math in the doc) — Subtotal → each tax/discount line with rate label → total → optional amount paid / balance due. State rounding rule (per line vs invoice-level) and reconcile: line sums, tax base, and total must match within one cent of stated rule. If inputs conflict, mark 
    NEEDS USER CONFIRMATION
    instead of guessing.
  6. Payment & compliance footer — Payment terms in plain language; methods the user named (wire, ACH, card link, check). Bank/wallet fields verbatim from user; pay-link call-to-action when a hosted URL exists. Late-fee or remittance notes only if provided. Keep legal boilerplate minimal unless user supplied text.
  7. Design intent — Document tone, hierarchy, density, palette for the engine:
    • Tone: calm, trustworthy B2B; no marketing fluff on a collection document.
    • Hierarchy: document title + invoice number scannable in header; amount due and due date strongest emphasis in totals/payment zone; line table secondary; footer tertiary.
    • Density: generous table row rhythm; right-align money columns; tabular numerals for all amounts; avoid more than one short notes block.
    • Palette: restrained neutrals with one accent on total/due; WCAG AA; logo space without decorative clutter.
Rules & constraints
  • Payability gate: no send-ready blueprint without invoice number, dates, currency, reconciled total, and user-confirmed pay instructions when payment is expected.
  • Single source of truth: line items drive subtotal; tax rates apply to the documented base only.
  • Reference discipline: PO/project IDs appear once in metadata and optionally on lines—not repeated in random paragraphs.
  • Honesty gate: mark missing tax treatment or FX; never infer statutory rates without user input.
Common failure modes
  • Paragraph line items → rewrite as table rows with qty/rate/amount.
  • Tax on wrong base or double-counted → restate base, rate, and rounded tax lines explicitly.
  • Generic “Invoice” with no due date or number → fill from user or flag gaps.
  • Amount due buried below fold in design intent → promote total/due in hierarchy notes.
  • Invented IBAN, VAT, or pay links → strip and replace with 
    TBD — user must supply
    .
  • Mixed currencies on one invoice → split or escalate unless user confirms FX line.
Quality checklist
  • Parties and tax IDs match user-supplied data only.
  • Line amounts × qty reconcile to subtotal under stated rounding.
  • Tax/discount lines sum to total; balance due correct if partial payment noted.
  • Due date and payment instructions align with terms.
  • Design intent names emphasis for amount due, table, and payment block.
  • All figures traceable to user inputs or explicit formulas in the doc.
使用单一蓝图统一承载语义内容和美学意图。采用带标签的区块，方便 k2f skill 后续映射到相应区域。
子步骤
  1. 发票类型与司法辖区锁定 — 标准账单、pro forma 发票、押金/部分付款发票或贷项调整。注明币种、区域设置（日期和数字格式），以及税额为含税还是未税。省略该发票类型不需要的区块（例如，对于不用于收款的 pro forma 发票，不显示“应付金额”主视觉区）。
  2. 参与方与身份区块 — 卖方：法定名称、地址、联系方式、标志设计意图，以及用户提供的 tax/VAT ID。买方：账单接收方名称和地址；可选的收货方或经办人信息。绝不虚构注册号或银行详情。
  3. 参考元数据 — 发票编号、开具日期、到期日期（或明确写明“收到即付 / Net N”）。如有提供，填写 PO、项目、合同或客户参考信息。整份文档使用同一币种代码；排版前标记缺失的到期日期。
  4. 明细项结构 — 以表格为先，而不是散文式段落。每行包含：清晰的描述、数量、单位、单价、行金额。只有当用户数据本身已按相应方式拆分时，才将可选部分分组（服务与费用、里程碑等）。折扣应写为明确的负数行，或与小计规则关联的百分比说明——绝不能隐藏在文案中。
  5. 总额计算逻辑（在文档中写出计算过程） — 小计 → 每一条带税率标签的税费/折扣行 → 总计 → 可选的已付金额/应付余额。注明舍入规则（按行舍入还是按发票整体舍入），并进行核对：各行合计、计税基数和总计之间的差异必须符合所述规则，最多不超过一分钱。若输入相互冲突，应标记 
    NEEDS USER CONFIRMATION
    ，而不是自行猜测。
  6. 付款与合规页脚 — 用直白语言说明付款条款；采用用户指定的支付方式（电汇、ACH、卡片链接、支票）。银行/钱包字段必须逐字照录；存在托管 URL 时，加入付款链接 CTA。仅在用户提供时加入逾期费用或汇款附言。除非用户提供了相应文本，否则法律样板文字应保持精简。
  7. 设计意图 — 为引擎指定文档基调、信息层级、内容密度和配色：
    • 基调：平静、可信的 B2B 风格；收款单据不使用营销话术。
    • 层级：页眉中让文档标题和发票编号易于扫读；在总计/付款区域中重点突出应付金额和到期日；明细表为次要层级；页脚为第三层级。
    • 密度：保持宽松的表格行节奏；金额列右对齐；所有金额使用 tabular numerals；最多保留一个简短说明区块。
    • 配色：采用克制的中性色，并仅在总计/到期信息处使用一种强调色；符合 WCAG AA；为 logo 留出空间，同时避免装饰性杂乱。
规则与约束
  • 可付款性门槛：缺少发票编号、日期、币种、经核对的总额，以及预期收款时经用户确认的付款说明，就不能生成可发送的蓝图。
  • 单一事实来源：小计由明细项驱动；税率仅适用于文档中明确记录的计税基数。
  • 参考信息纪律：PO/项目 ID 在元数据中只出现一次，也可在明细行中选择性出现——不得在任意段落中反复出现。
  • 真实性门槛：标记缺失的税务处理方式或 FX；未经用户输入，绝不推断法定税率。
常见失败模式
  • 段落式明细项 → 改写为包含数量/费率/金额的表格行。
  • 计税基数错误或重复计税 → 明确重述计税基数、税率及舍入后的税额行。
  • 只有通用“Invoice”标题且缺少到期日或编号 → 根据用户提供的信息补齐，或标记缺失项。
  • 设计意图中应付金额被埋在页面折叠线以下 → 在层级说明中提升总计/到期日的优先级。
  • 虚构 IBAN、VAT 或付款链接 → 移除，并替换为 
    TBD — 用户必须提供
    。
  • 同一张发票中混用多种币种 → 拆分处理或提交确认，除非用户确认 FX 行。
质量检查清单
  • 参与方和税务 ID 与用户提供的数据完全一致。
  • 各行的单价 × 数量与按既定舍入规则计算的小计一致。
  • 税费/折扣行合计正确得出总计；如有部分付款说明，余额正确。
  • 到期日和付款说明与付款条款一致。
  • 设计意图明确指出应付金额、明细表和付款区块的视觉重点。
  • 所有数字均可追溯至用户输入或文档中的明确公式。

Step 2. Use the content_and_design.md and k2f skill to generate a K2F file and export to an appropriate file format.

步骤 2. 使用 content_and_design.md 和 k2f skill 生成 K2F 文件并导出为适当格式

Follow k2f to instantiate the invoice from the blueprint, apply roles from design intent, verify, and export the payment-ready deliverable.
遵循 k2f，根据蓝图实例化发票，按设计意图应用各区块的角色，执行验证并导出可付款的交付成果。