To define the foundational data structure for the Chart of Accounts (COA) that will serve as the backbone for the 3Books accounting system. This chapter establishes the core financial accounts that all transactions will reference, ensuring the system can support standard financial reports, our bespoke Monthly Performance Report (MPR), and a wide variety of operational, audit, and customer reports.

• account_id: A unique, system-generated identifier for each account (UUID).
• account_name: A user-defined, human-readable name of the account (string, max 255 chars, unique).
• account_number: An optional, user-defined number for the account (string, max 20 chars, nullable).
• account_type: Mandatory classification from an enum: Asset, Liability, Equity, Revenue, Expense.
• account_subtype: A mandatory, more granular classification (e.g., Current Asset, Cost of Goods Sold).
• description: An optional field for a detailed explanation (string, max 1000 chars, nullable).
• is_active: A boolean flag indicating if the account is currently in use (boolean, default true).
• created_at & updated_at: System-generated timestamps.

• CRUD Operations with Permissions: The system must provide an interface for users with appropriate permissions to Create, Read, Update, and "soft delete" accounts.
• Default COA Generation: Upon initial setup, the system shall pre-populate a standard Chart of Accounts.
• Validation Rules: account_name must be unique. account_type and account_subtype must be from a predefined list. Accounts with transactions cannot be hard-deleted.
• Audit Trail: All changes to an account's data must be recorded in an audit trail.

• Data Migration: Support for importing a Chart of Accounts from .csv or .xlsx.
• Transaction Feeds: The COA is the primary destination for transactions from integrated sources like bank feeds or Stripe.

To define the foundational data model for all financial transactions. This structure is designed to support all financial reports, including the custom MPR with forecasted data from the Track3 CRM.

• transaction_id: Unique identifier for each transaction (UUID).
• transaction_date: The date on which the transaction occurred (date).
• event_month: The month and year to which the transaction belongs for MPR purposes.
• description: A human-readable description (string, max 255 chars).
• debit_account_id & credit_account_id: Foreign keys to the Account entity.
• amount: The value of the transaction (positive decimal).
• transaction_type: Enum of BOOKED or TRACK3_FORECAST.
• confidence_level: A numeric value (0-100) for forecasted transactions (integer, nullable).

• CRUD Operations: Standard CRUD with soft deletes recorded in the audit trail.
• Double-Entry Validation: All BOOKED transactions must adhere to double-entry accounting principles.
• MPR Logic: UI must include an option to toggle the inclusion of TRACK3_FORECAST transactions.

To define the data models and workflows for managing customers, sales, and accounts receivable, with integration into our CRM (Track3) and authentication system (FIRM).

Defines entities for Customer, Invoice, InvoiceLineItem, and Quote, detailing all fields like IDs, dates, status enums, amounts, and foreign key relationships.

• Invoice/Quote Management: Allow creation, editing, and sending. Quotes must be convertible into invoices.
• Customization: Support for templates, discounts, and taxes.
• Payment Matching: Automatically match incoming payments to invoices.
• Automated Reminders: Send reminders for overdue invoices.

To define the models and workflows for managing expenses, vendor bills, and accounts payable, including receipt capture and forecasted expenses from the CRM.

Defines entities for Vendor, Bill, Expense, and Receipt, including fields for source type (BOOKED vs. TRACK3_FORECAST) and confidence levels.

• Receipt Capture and OCR: Support upload of receipt images with OCR to extract data and match to records.
• Approval Workflows: Allow for simple approval workflows before bills can be paid.
• Automated Matching: Use bank feed data to automatically match transactions to bills and expenses.

To define the deployment strategy for a single-tenant application on a pair of Linux laptops (primary + backup), managed via a simple bash script.

• Environment: Ubuntu 24.04+ on two laptops.
• Components: A single Go binary backend (serving API and static Next.js assets) and a local PostgreSQL instance.
• Packaging: Distributed as a GitHub repository with an install.sh script.
• Systemd Services: The install script will create services for the application and database.

• Updates: Users run git pull and re-run the install.sh script, which handles migrations.
• Backups: Hourly rsync of the PostgreSQL data directory to the secondary laptop, plus a daily pg_dump.
• Failover: Manual promotion of the secondary laptop in case of primary failure.