Back to Details

saas-accounting-system

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Required Plugins

所需插件

Superpowers plugin: MUST be active for all work using this skill. Use throughout the entire build pipeline — design decisions, code generation, debugging, quality checks, and any task where it offers enhanced capabilities. If superpowers provides a better way to accomplish something, prefer it over the default approach.
Superpowers插件： 在使用本技能开展所有工作时必须激活。在整个构建流程中使用——包括设计决策、代码生成、调试、质量检查，以及任何它能提供增强能力的任务。如果Superpowers提供了更优的实现方式，请优先使用它而非默认方法。

SaaS Accounting System

SaaS会计系统

Overview

概述

This skill implements a hidden accounting engine inside business applications. End users never see debits, credits, or journal entries — they enter sales, record payments, move inventory. Under the hood, every transaction auto-posts balanced journal entries that accountants and auditors can query at any time.
Philosophy: Users think in business terms. The system thinks in double-entry.
本技能可在业务应用中实现一个隐藏式会计引擎。终端用户无需查看借方、贷方或日记账分录——他们只需录入销售、记录付款、转移库存即可。在后台，每一笔交易都会自动生成平衡的日记账分录，会计师和审计人员可随时查询。
设计理念： 用户以业务视角操作，系统以复式记账逻辑运行。

Core Architecture

核心架构

┌─────────────────────────────────────────────────┐
│  USER LAYER (Friendly)                          │
│  Sales, Purchases, Payments, Inventory, Expenses│
│  → User sees: "Sale #1042 to Customer X: $500"  │
└──────────────────────┬──────────────────────────┘
                       │ auto-posts
┌──────────────────────▼──────────────────────────┐
│  ACCOUNTING ENGINE (Hidden)                     │
│  Journal Entries, Ledger Postings, Trial Balance│
│  → Engine posts: DR Accounts Receivable $500    │
│                  CR Sales Revenue      $500     │
└──────────────────────┬──────────────────────────┘
                       │ aggregates
┌──────────────────────▼──────────────────────────┐
│  REPORTING LAYER (Dual)                         │
│  User Reports: Sales Summary, Aging, P&L Simple │
│  Accountant Reports: Trial Balance, BS, IS, CF  │
└─────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────┐
│  USER LAYER (Friendly)                          │
│  Sales, Purchases, Payments, Inventory, Expenses│
│  → User sees: "Sale #1042 to Customer X: $500"  │
└──────────────────────┬──────────────────────────┘
                       │ auto-posts
┌──────────────────────▼──────────────────────────┐
│  ACCOUNTING ENGINE (Hidden)                     │
│  Journal Entries, Ledger Postings, Trial Balance│
│  → Engine posts: DR Accounts Receivable $500    │
│                  CR Sales Revenue      $500     │
└──────────────────────┬──────────────────────────┘
                       │ aggregates
┌──────────────────────▼──────────────────────────┐
│  REPORTING LAYER (Dual)                         │
│  User Reports: Sales Summary, Aging, P&L Simple │
│  Accountant Reports: Trial Balance, BS, IS, CF  │
└─────────────────────────────────────────────────┘

The Golden Rule

黄金法则

Every transaction MUST produce balanced journal entries. No exceptions.
SUM(debits) = SUM(credits)  — ALWAYS
This is enforced at the database level via stored procedure or trigger. If entries don't balance, the entire transaction rolls back.
每一笔交易必须生成平衡的日记账分录，无例外。
SUM(debits) = SUM(credits)  — 始终成立
这一规则通过数据库存储过程或触发器强制执行。如果分录不平衡，整个交易将回滚。

Chart of Accounts (COA)

会计科目表（COA）

The COA is the backbone. Every account has a type that determines its normal balance.
TypeCode RangeNormal BalanceExamples
Asset1000-1999DebitCash, Bank, AR, Inventory, Equipment
Liability2000-2999CreditAP, Loans, Tax Payable, Unearned Revenue
Equity3000-3999CreditOwner's Equity, Retained Earnings
Revenue4000-4999CreditSales, Service Income, Interest Income
COGS5000-5999DebitCost of Goods Sold, Direct Materials
Expense6000-6999DebitRent, Salaries, Utilities, Marketing
Setup rules:
  • Tenant gets a default COA on creation (seeded from template)
  • Accounts are tenant-scoped (
    franchise_id
    )
  • Accounts cannot be deleted if they have posted entries
  • Sub-accounts supported (e.g., 1100 Cash → 1101 Petty Cash, 1102 Main Bank)
See: 
references/chart-of-accounts.md
会计科目表（COA）是系统的核心支柱。每个科目都有对应的类型，决定了它的正常余额方向。
类型代码范围正常余额方向示例
资产1000-1999借方现金、银行存款、应收账款、库存、设备
负债2000-2999贷方应付账款、贷款、应交税费、预收收入
所有者权益3000-3999贷方所有者权益、留存收益
收入4000-4999贷方销售收入、服务收入、利息收入
销货成本（COGS）5000-5999借方销货成本、直接材料
费用6000-6999借方租金、工资、水电费、营销费用
设置规则：
  • 租户创建时会获取默认的COA（从模板导入）
  • 科目按租户隔离（通过
    franchise_id
    区分）
  • 已过账的科目无法删除
  • 支持子科目（例如：1100 现金 → 1101 备用金、1102 主银行账户）
参考：
references/chart-of-accounts.md

Auto-Posting Rules

自动过账规则

Users never create journal entries manually. Every business transaction has a posting rule.
用户无需手动创建日记账分录。每一项业务交易都对应一套过账规则。

Transaction → Journal Entry Map

交易→日记账分录映射

User ActionDebit AccountCredit Account
Record Sale (Invoice)Accounts ReceivableSales Revenue
Record Sale + TaxAR + Tax ReceivableSales Revenue + Tax Payable
Receive Payment (Cash)Cash/BankAccounts Receivable
Record PurchaseInventory/ExpenseAccounts Payable
Pay SupplierAccounts PayableCash/Bank
Record ExpenseExpense AccountCash/Bank or AP
Inventory Sale (COGS)Cost of Goods SoldInventory
Stock Adjustment (+)InventoryInventory Adjustment (Income)
Stock Adjustment (-)Inventory Adjustment (Expense)Inventory
Salary PaymentSalary ExpenseCash/Bank
Loan ReceivedCash/BankLoan Payable
Loan RepaymentLoan Payable + Interest ExpCash/Bank
DepreciationDepreciation ExpenseAccumulated Depreciation
Customer RefundSales ReturnsCash/Bank or AR
Multi-line entries: A single sale with tax and discount creates 3+ journal lines, all in one entry. The entry MUST balance.
See: 
references/journal-posting-rules.md
用户操作借方科目贷方科目
记录销售（发票）应收账款销售收入
记录含税销售应收账款+应收税费销售收入+应交税费
收到付款（现金）现金/银行存款应收账款
记录采购库存/费用应付账款
支付供应商货款应付账款现金/银行存款
记录费用费用科目现金/银行存款或应付账款
库存销售（结转销货成本）销货成本库存
库存调整（+）库存库存调整（收入类）
库存调整（-）库存调整（费用类）库存
支付工资工资费用现金/银行存款
收到贷款现金/银行存款应付贷款
偿还贷款应付贷款+利息费用现金/银行存款
计提折旧折旧费用累计折旧
客户退款销售退回现金/银行存款或应收账款
多行分录： 一笔含税费和折扣的销售会生成3条以上的日记账分录行，且全部包含在同一笔分录中，该分录必须保持平衡。
参考：
references/journal-posting-rules.md

Void & Reversal Mechanics

冲销与反转机制

Rule: Never delete a posted journal entry. Always create a reversing entry.
规则： 切勿删除已过账的日记账分录，始终创建反转分录。

Void Process

冲销流程

1. User clicks "Void" on a transaction (e.g., Sale Invoice #1042)
2. System marks the original transaction as VOIDED (status change)
3. System auto-creates a REVERSING journal entry:
   - Same accounts, opposite directions
   - Reference: "REVERSAL of JE-{original_id}"
   - Same date OR current date (configurable)
4. Original entry + reversal entry net to ZERO
5. All sub-ledger balances update automatically
1. 用户点击某笔交易的“冲销”按钮（例如：销售发票#1042）
2. 系统将原交易标记为已冲销（状态变更）
3. 系统自动生成一笔**反转日记账分录**：
   - 使用相同科目，方向相反
   - 备注：“REVERSAL of JE-{original_id}”
   - 日期与原分录相同或使用当前日期（可配置）
4. 原分录与反转分录的净额为零
5. 所有子分类账余额自动更新

Reversal Entry Example

反转分录示例

Original (Sale Invoice #1042):
  DR  Accounts Receivable    500.00
  CR  Sales Revenue           500.00

Reversal (Void of #1042):
  DR  Sales Revenue           500.00
  CR  Accounts Receivable    500.00

Net effect: ZERO
原分录（销售发票#1042）：
  DR  应收账款    500.00
  CR  销售收入           500.00

反转分录（冲销#1042）：
  DR  销售收入           500.00
  CR  应收账款    500.00

净额影响：零

Partial Void Rules

部分冲销规则

  • Partially paid invoices: Void remaining balance only
  • Payment already received: Must void payment first, then invoice
  • Inventory already delivered: Must reverse stock movement first
  • Cascade protection: System warns if dependent transactions exist
See: 
references/void-reversal-patterns.md
  • 已部分付款的发票：仅冲销剩余余额
  • 已收到付款的交易：必须先冲销付款，再冲销发票
  • 已发货的库存交易：必须先反转库存变动
  • 级联保护：若存在关联交易，系统将发出警告
参考：
references/void-reversal-patterns.md

Database Schema (Core Tables)

数据库架构（核心表）

sql
-- Chart of Accounts
accounts (id, franchise_id, code, name, type, parent_id,
          is_active, normal_balance, created_at)

-- Journal Entries (Header)
journal_entries (id, franchise_id, entry_date, reference_type,
                 reference_id, narration, is_reversal, reversed_entry_id,
                 posted_by, status, created_at)

-- Journal Entry Lines (Detail)
journal_entry_lines (id, journal_entry_id, account_id,
                     debit_amount, credit_amount, narration,
                     franchise_id, created_at)

-- Fiscal Periods
fiscal_periods (id, franchise_id, period_name, start_date,
                end_date, status, closed_by, closed_at)

-- Account Balances (Materialized for performance)
account_balances (id, franchise_id, account_id, period_id,
                  opening_balance, debit_total, credit_total,
                  closing_balance, updated_at)
Integrity constraints:
  • journal_entry_lines.debit_amount
    and 
    credit_amount
    are DECIMAL(15,2)
  • CHECK constraint: Each line has debit OR credit, never both, never both zero
  • Stored procedure validates SUM(debit) = SUM(credit) per entry
  • franchise_id
    on every table (multi-tenant isolation)
  • status
    enum: DRAFT, POSTED, VOIDED
See: 
references/schema-design.md
sql
-- Chart of Accounts
accounts (id, franchise_id, code, name, type, parent_id,
          is_active, normal_balance, created_at)

-- Journal Entries (Header)
journal_entries (id, franchise_id, entry_date, reference_type,
                 reference_id, narration, is_reversal, reversed_entry_id,
                 posted_by, status, created_at)

-- Journal Entry Lines (Detail)
journal_entry_lines (id, journal_entry_id, account_id,
                     debit_amount, credit_amount, narration,
                     franchise_id, created_at)

-- Fiscal Periods
fiscal_periods (id, franchise_id, period_name, start_date,
                end_date, status, closed_by, closed_at)

-- Account Balances (Materialized for performance)
account_balances (id, franchise_id, account_id, period_id,
                  opening_balance, debit_total, credit_total,
                  closing_balance, updated_at)
完整性约束：
  • journal_entry_lines.debit_amount
    和 
    credit_amount
    为DECIMAL(15,2)类型
  • CHECK约束：每一行分录只能有借方或贷方金额，不能同时存在，也不能均为零
  • 通过存储过程验证每笔分录的借方总额等于贷方总额
  • 所有表均包含
    franchise_id
    （多租户隔离）
  • status
    枚举值：DRAFT（草稿）、POSTED（已过账）、VOIDED（已冲销）
参考：
references/schema-design.md

Dual Reporting System

双轨制报告系统

User-Friendly Reports (Non-Accountant)

用户友好型报告（面向非会计人员）

ReportWhat User SeesData Source
Sales SummaryTotal sales by period, customer, productSales transactions
Outstanding InvoicesWho owes what, how oldAR sub-ledger
Expense ReportSpending by categoryExpense transactions
Profit & Loss (Simple)Revenue minus expensesIncome/expense accounts
Cash PositionMoney in bank/cashCash/bank accounts
Inventory ValueStock on hand with costInventory sub-ledger
报告用户可见内容数据源
销售汇总报告按期间、客户、产品统计的销售总额销售交易数据
未结清发票报告欠款方及欠款账龄应收账款子分类账
费用报告按类别统计的支出情况费用交易数据
简易利润表收入减去费用收入/费用科目
现金头寸报告银行/现金账户余额现金/银行科目
库存价值报告现有库存及成本库存子分类账

Accountant/Auditor Reports (Technical)

会计/审计人员报告（专业型）

ReportWhat It ShowsSource
Trial BalanceAll account balances (DR/CR columns)General Ledger
Balance SheetAssets = Liabilities + EquityGL (type 1-3)
Income StatementRevenue - COGS - Expenses = Net IncomeGL (type 4-6)
Cash Flow StatementOperating + Investing + FinancingCash account entries
General Ledger DetailEvery entry per accountJournal entries
Journal RegisterAll journal entries chronologicallyJournal entries
Aged ReceivablesAR aging (30/60/90/120 days)AR sub-ledger
Aged PayablesAP agingAP sub-ledger
Audit TrailWho posted what, whenJournal entries + audit log
See: 
references/financial-statements.md
报告展示内容数据源
试算平衡表所有科目的余额（借方/贷方列）总分类账
资产负债表资产=负债+所有者权益总分类账（类型1-3）
利润表收入-销货成本-费用=净利润总分类账（类型4-6）
现金流量表经营活动+投资活动+筹资活动现金流现金账户分录
总分类账明细每个科目的所有分录日记账分录
日记账登记簿所有日记账分录的 chronological 记录日记账分录
应收账款账龄报告应收账款账龄（30/60/90/120天）应收账款子分类账
应付账款账龄报告应付账款账龄应付账款子分类账
审计追踪报告过账人、过账时间及操作内容日记账分录+审计日志
参考：
references/financial-statements.md

Implementation Checklist

实施 checklist

Phase 1: Foundation (Must Complete First)

阶段1：基础搭建（必须优先完成）

  • Create 
    accounts
    table with COA seed data
  • Create 
    journal_entries
    and 
    journal_entry_lines
    tables
  • Create 
    fiscal_periods
    table
  • Build balance validation stored procedure
  • Build 
    postJournalEntry()
    service function
  • Write tests: balanced entry passes, unbalanced rejects
  • 创建
    accounts
    表并导入COA种子数据
  • 创建
    journal_entries
    和
    journal_entry_lines
    表
  • 创建
    fiscal_periods
    表
  • 构建余额验证存储过程
  • 开发
    postJournalEntry()
    服务函数
  • 编写测试：平衡分录通过验证，不平衡分录被拒绝

Phase 2: Auto-Posting Integration

阶段2：自动过账集成

  • Wire sales invoice → auto-post AR/Revenue entry
  • Wire payment received → auto-post Cash/AR entry
  • Wire purchase → auto-post Inventory or Expense/AP entry
  • Wire supplier payment → auto-post AP/Cash entry
  • Wire inventory movement → auto-post COGS/Inventory entry
  • Write tests: each transaction type posts correct entries
  • 对接销售发票→自动过账应收账款/销售收入分录
  • 对接收款→自动过账现金/应收账款分录
  • 对接采购→自动过账库存或费用/应付账款分录
  • 对接供应商付款→自动过账应付账款/现金分录
  • 对接库存变动→自动过账销货成本/库存分录
  • 编写测试：每种交易类型均生成正确的分录

Phase 3: Void & Reversal

阶段3：冲销与反转

  • Build void transaction service (creates reversing entry)
  • Handle partial void scenarios
  • Handle cascade dependencies (warn before void)
  • Write tests: void produces net-zero, balances correct
  • 开发交易冲销服务（生成反转分录）
  • 处理部分冲销场景
  • 处理关联依赖（冲销前发出警告）
  • 编写测试：冲销后净额为零，余额正确

Phase 4: Reporting

阶段4：报告系统

  • Build Trial Balance report (all accounts, DR/CR totals)
  • Build Balance Sheet (Assets = Liabilities + Equity)
  • Build Income Statement (Revenue - Expenses)
  • Build user-friendly summary reports
  • Build audit trail report
  • Write tests: reports match expected values from test data
  • 构建试算平衡表报告（所有科目，借方/贷方总额）
  • 构建资产负债表（资产=负债+所有者权益）
  • 构建利润表（收入-费用）
  • 构建用户友好型汇总报告
  • 构建审计追踪报告
  • 编写测试：报告数据与测试数据的预期值一致

Phase 5: Period Management

阶段5：期间管理

  • Build period open/close functionality
  • Prevent posting to closed periods
  • Build year-end closing entry (Revenue/Expense → Retained Earnings)
  • Write tests: closed period rejects entries
  • 构建会计期间开闭功能
  • 禁止向已关闭期间过账
  • 构建年末结账分录（收入/费用→留存收益）
  • 编写测试：已关闭期间拒绝接收分录

Cross-Skill Integration

跨技能集成

AreaSkillHow It Applies
Database schema
mysql-best-practices
DECIMAL(15,2), indexes, FK constraints
API endpoints
api-error-handling
Consistent error responses for failed postings
Multi-tenancy
multi-tenant-saas-architecture
franchise_id on all tables
UI reports
webapp-gui-design
DataTables for ledger, charts for P&L
Mobile reports
jetpack-compose-ui
Report screens with tables
PDF export
android-pdf-export
, 
report-print-pdf
Financial statement PDFs
Security
vibe-security-skill
Protect financial data, audit trail
Auth
dual-auth-rbac
Permission: who can post/void/view reports
Inventory link
inventory-management
COGS posting on stock movements
Testing
sdlc-testing
Test every posting rule, every reversal
Implementation
plan-implementation
Execute accounting phases with TDD
Audit
implementation-status-auditor
Verify accounting system completeness
领域技能应用方式
数据库架构
mysql-best-practices
使用DECIMAL(15,2)、索引、外键约束
API端点
api-error-handling
为过账失败场景提供一致的错误响应
多租户
multi-tenant-saas-architecture
所有表均包含
franchise_id
UI报告
webapp-gui-design
用DataTables展示分类账，用图表展示利润表
移动端报告
jetpack-compose-ui
开发带表格的报告界面
PDF导出
android-pdf-export
, 
report-print-pdf
生成财务报表PDF
安全
vibe-security-skill
保护财务数据，生成审计追踪
权限认证
dual-auth-rbac
控制谁可以过账/冲销/查看报告
库存对接
inventory-management
库存变动时自动过账销货成本
测试
sdlc-testing
测试每一条过账规则和反转逻辑
实施规划
plan-implementation
用TDD方式执行会计系统各阶段开发
审计
implementation-status-auditor
验证会计系统的完整性

Anti-Patterns

反模式

Don'tDo Instead
Let users enter journal entries directlyAuto-post from business transactions
Use FLOAT for moneyUse DECIMAL(15,2) always
Delete journal entriesCreate reversing entries (void)
Skip balance validationEnforce DR=CR in stored procedure
Store calculated balances onlyStore individual entries, calculate on demand
Mix accounting with business logicSeparate accounting engine as its own service layer
Hard-code account codesUse configurable COA with tenant-specific accounts
Skip audit trailLog every posting with user, timestamp, IP
Allow posting to closed periodsEnforce period status check before posting
Show debits/credits to end usersShow friendly labels (Income, Payment, etc.)
禁止操作正确做法
允许用户直接录入日记账分录从业务交易自动过账
使用FLOAT类型存储金额始终使用DECIMAL(15,2)
删除日记账分录创建反转分录（冲销）
跳过余额验证在存储过程中强制借方=贷方
仅存储计算后的余额存储单个分录，按需计算余额
将会计逻辑与业务逻辑混合将会计引擎作为独立服务层分离
硬编码科目代码使用可配置的COA，支持租户自定义科目
跳过审计追踪记录每一笔过账的用户、时间戳、IP地址
允许向已关闭期间过账过账前检查会计期间状态
向终端用户展示借方/贷方使用友好标签（如收入、付款等）

Accuracy Guarantee

准确性保障

Every implementation MUST pass these tests:
  1. Balance test: 
    SELECT SUM(debit) - SUM(credit) FROM journal_entry_lines
    = 0.00
  2. Entry test: Every journal entry has SUM(debit) = SUM(credit)
  3. Trial Balance test: Total debits = Total credits
  4. Balance Sheet test: Assets = Liabilities + Equity
  5. Reversal test: Voided transaction + reversal nets to zero
  6. Period test: No entries in closed periods
  7. Tenant test: No cross-tenant data leakage in any query
每一次实施必须通过以下测试：
  1. 余额测试： 
    SELECT SUM(debit) - SUM(credit) FROM journal_entry_lines
    = 0.00
  2. 分录测试： 每笔日记账分录的借方总额等于贷方总额
  3. 试算平衡表测试： 借方总额=贷方总额
  4. 资产负债表测试： 资产=负债+所有者权益
  5. 反转测试： 已冲销交易+反转分录的净额为零
  6. 期间测试： 已关闭期间无任何分录
  7. 租户测试： 任何查询均不会出现跨租户数据泄露

See Also

—
  • references/chart-of-accounts.md
    — COA templates and setup
  • references/journal-posting-rules.md
    — Complete posting rules per transaction
  • references/void-reversal-patterns.md
    — Void mechanics and edge cases
  • references/financial-statements.md
    — Report SQL queries and formats
  • references/schema-design.md
    — Complete database schema with constraints
—