agentleFS
peterbamuhigirepeterbamuhigire/chwezi-dev-engine/skills/finance-accounting/accounting-engine/SKILL.md

accounting-engine

Skill31 starsChanged 18 days agoMITView on GitHub

Use when designing or implementing double-entry accounting policy and an embedded ledger engine for invoices, payments, stock, balanced postings, mapped accounts, idempotency, reversals, period locks, audit trails, and financial statements.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read and search are required.

    line 43
  2. Very specific:

    NEVER let a business module write directly to gl_entries, journal_lines, journal_entries, or any ledger table.

    line 81
  3. Very specific:

    ALWAYS write ledger records through one service: LedgerPostingService::post(JournalEntry $entry) or the project-equivalent single posting …

    line 82
  4. Distinctive:

    NEVER update, delete, or soft-delete posted journal lines.

    line 83
  5. Distinctive:

    NEVER store authoritative balances that cannot be rebuilt from journal lines.

    line 84
  6. Distinctive:

    NEVER hardcode account codes in business logic.

    line 85
  7. Distinctive:

    NEVER use LIFO for IFRS or IFRS for SMEs tenants.

    line 86
  8. Distinctive:

    MUST reject posting when required account mappings are missing, inactive, cross-tenant, or not valid for the source document.

    line 87
  9. Very specific:

    Every accounting table MUST carry tenant_id, unless the product is explicitly single-tenant.

    line 116
  10. Distinctive:

    Run these per tenant and per accounting period from day one:

    line 160
  11. Distinctive:

    No journal exists in a locked period unless it is a permitted reopening workflow with approval evidence.

    line 169
  12. Distinctive:

    No ledger table has rows written outside the posting service.

    line 170

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Accounting Engine

<!-- dual-compat-start -->

Evidence Produced

CategoryArtifactFormatExample
CorrectnessLedger invariant test packMarkdown plus transaction fixturesbalanced posting, idempotency, reversal, period lock, subledger tie-out, and audit trail
<!-- dual-compat-end -->

Inputs

ArtefactRequired?Purpose
Transaction event and tenant contextyesDefine the event and isolation boundary
Account mapping and doctrine policyyesResolve balanced ledger accounts
Existing ledger and lock stateyesPrevent duplicate or closed-period posting

Outputs

ArtefactConsumerAcceptance condition
Posting contract and journal evidenceFeature services and finance reviewBalanced, idempotent, traceable, tenant-scoped

Capability contract

Read and search are required. Database writes, migrations, backfills, reversals, and period operations require explicit authority and a verified compensating path.

Degraded mode

Fallback without doctrine, mappings, or database access: return a posting design and unresolved control list; do not invent accounts or claim ledger correctness.

Decision rules

ConditionPosting actionFailure avoided
New valid economic eventAppend balanced journalMissing financial record
Duplicate idempotency keyReturn prior resultDouble posting
Error in posted journalPost linked reversal/correctionDestruction of audit history
Closed periodReject or use authorised later-period adjustmentPeriod integrity breach

Domain anti-patterns

  • Posting directly from controllers. Fix: use one posting service and contract.
  • Updating or deleting journals. Fix: reverse and repost with links.
  • Guessing accounts from feature names. Fix: require mapping-layer resolution.
  • Retrying without idempotency. Fix: persist and enforce the event key.
  • Mixing tenants in one posting context. Fix: require tenant scope on every ledger operation.
  • Generating journal or invoice numbers in a trigger, with MAX+1, or outside the posting transaction. Fix: allocate from the tenant counter inside the posting transaction, journal counter locked last (tenant-document-numbering).

Use When

  • The product handles money, inventory value, payroll, tax, customer balances, supplier balances, assets, grants, donations, loans, refunds, wallet balances, or financial reporting.
  • A SaaS must replace routine bookkeeping in external products such as QuickBooks, Xero, Sage, Pastel, Tally, Zoho Books, or Wave.
  • You need architecture, schema, posting rules, tests, documentation, or review findings for ledger-backed business software.

Do Not Use When

  • The task is only financial analysis or projections without software architecture; use accounting-finance-controller or the business-plan finance skills.
  • The system only displays imported accounting reports and does not create business events or postings.
  • A jurisdiction requires a licensed accountant, auditor, or tax practitioner to exercise professional judgement; design the system support, but do not claim the software replaces that judgement.

Hard Rules

  • NEVER let a business module write directly to gl_entries, journal_lines, journal_entries, or any ledger table.
  • ALWAYS write ledger records through one service: LedgerPostingService::post(JournalEntry $entry) or the project-equivalent single posting service.
  • NEVER update, delete, or soft-delete posted journal lines. Corrections are reversing journals linked to the original entry.
  • NEVER store authoritative balances that cannot be rebuilt from journal lines. Materialized balances are caches with a documented rebuild command.
  • NEVER hardcode account codes in business logic. Use account mappings resolved at posting time.
  • NEVER use LIFO for IFRS or IFRS for SMEs tenants.
  • MUST reject posting when required account mappings are missing, inactive, cross-tenant, or not valid for the source document.

Canonical Architecture

Business modules emit events. A mapper turns events into balanced JournalEntry value objects. The posting service validates and writes the entry atomically. Reports, subledgers, balances, tax schedules, and dashboards are deterministic projections of the ledger.

Sales / Stock / Payroll / Assets / Payments / Grants
        -> business event
        -> account resolver and posting-rule mapper
        -> JournalEntry value object
        -> LedgerPostingService::post()
        -> append-only journal_entries + journal_lines
        -> reports, subledgers, tax schedules, dashboards

Required Model

Core tables:

  • chart_of_accounts
  • account_mappings
  • journal_entries
  • journal_lines
  • accounting_periods
  • posting_rule_versions
  • accounting_integrity_runs
  • accounting_audit_log

Every accounting table MUST carry tenant_id, unless the product is explicitly single-tenant. If legacy files use franchise_id, treat it as a project-specific tenant alias and document the mapping.

Posting Service Contract

<?php
declare(strict_types=1);

final readonly class JournalEntry
{
    public function __construct(
        public int $tenantId,
        public string $idempotencyKey,
        public DateTimeImmutable $entryDate,
        public string $sourceType,
        public string $sourceId,
        public string $description,
        /** @var list<JournalLine> */
        public array $lines,
        public ?int $reversesJournalId = null,
    ) {}
}

final readonly class JournalLine
{
    public function __construct(
        public int $accountId,
        public string $currency,
        public string $debitMinor,
        public string $creditMinor,
        public array $dimensions = [],
    ) {}
}

interface LedgerPostingService
{
    public function post(JournalEntry $entry): PostedJournal;
}

The service validates tenant scope, account status, open period, debit-credit equality, currency policy, idempotency, source document state, and mapping completeness before insert.

Integrity Checks

Run these per tenant and per accounting period from day one:

  • Debits equal credits per journal_entry_id.
  • Trial balance total debits equal total credits.
  • AR control account equals customer-tagged journal line balance.
  • AP control account equals supplier-tagged journal line balance.
  • Inventory control account equals stock-on-hand value by item/location/cost layer.
  • Fixed asset control account equals asset-register cost less disposals.
  • Payroll liability accounts equal unpaid statutory and employee deductions.
  • No journal exists in a locked period unless it is a permitted reopening workflow with approval evidence.
  • No ledger table has rows written outside the posting service.
  • Materialized balances rebuild to the same values as stored cache rows.

User Experience Principle

Non-accountants record business actions: Record Sale, Receive Payment, Buy Stock, Run Payroll, Record Asset Purchase, Receive Grant, Close Month. The system posts accounting behind the scenes. Accountant-facing roles get journals, CoA, mappings, period close, manual journal, and report exports.

Companion Skills

  • ledger-posting-engine-core (chwezi-accounting-doctrine) for IFRS-aligned industry templates.
  • inventory-costing-and-stock-accounting (chwezi-accounting-doctrine) for IAS 2 stock valuation and COGS flows.
  • payroll-and-statutory-postings-east-africa (chwezi-accounting-doctrine) for PAYE/NSSF/LST payroll journal shapes.
  • fixed-assets-and-depreciation for IAS 16 asset lifecycle.
  • multicurrency-and-fx for IAS 21 currency handling.
  • multi-tenant-saas-architecture, api-design-first, and advanced-testing-strategy for platform integration.

References

  • references/posting-engine-contract.md
  • references/integrity-invariants.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.