| name | finance-module-audit |
| description | Use when auditing any software, SRS, proposal, POS, ERP, SaaS, mobile app, or workflow that touches money, billing, payments, tax, payroll, banking, mobile money, inventory, statutory compliance, financial reports, or accounting records. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Finance Module Audit
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- Audit a finance-touching system or artefact for ledger integrity, control
effectiveness, source-state discipline, reconciliation, and release evidence.
Do Not Use When
- The scope has no money, accounting record, financial report, tax, payroll,
banking, or control consequence; use the owning domain skill instead.
Required Inputs
- Finance context, reporting basis, jurisdiction, artefacts inspected, available
tests, source-register state, intended outputs, and reviewer boundary.
Workflow
- Establish scope, inspect evidence, trace money flows, test invariants and
controls, classify gaps, and issue the decision record with acceptance evidence.
Quality Standards
- Do not certify from screenshots or claims alone. Preserve source-state caveats,
reviewer accountability, segregation of duties, and audit-trace evidence.
Anti-Patterns
- Do not treat draft statutory values as current, close findings on prose alone,
or claim a passing release without observable evidence.
Outputs
- Produce a finding register, standards scorecard, remediation plan, decision,
acceptance evidence, and residual-risk statement.
References
- Load the directly linked audit protocol, scorecard, report template,
remediation plan, canonical doctrine, and finance quality gate.
Auto-run trigger (read first)
This skill auto-runs. If you, the agent, are asked to do anything substantive with a software system, codebase, product proposal, SRS / SDS / test plan, business plan, or any artefact, and the target has any element listed in the description above, load this skill before responding. The threshold is intentionally low - false positives are cheap; missing a finance element in a "world-class" deliverable is not.
When the auto-run fires, the agent:
- Loads this
SKILL.md and the four reference files in this folder.
- Resolves the canonical Chwezi doctrine from the active repository's
AGENTS.md, README.md, or global engine-routing table, then loads doctrine/accounting-finance-doctrine.md. Do not assume a consumer-specific _doctrine mirror.
- Loads the relevant doctrine reference files under
doctrine/references/.
- Loads any specialist finance skill from the new skill suite that matches the target (e.g.
bank-and-mobile-money-reconciliation if mobile money is in scope; finance-ui-pattern-library if UI work is involved).
- Runs the audit workflow below.
- Emits the finding register, scorecard, and master plan in the conventional output format.
If the trigger fires but the user explicitly says "skip the audit", note the skip in the artefact manifest and proceed - but always flag the skip in the final response so the user can revoke it.
Overview
Use this skill to determine whether a software system makes finance and accounting easy for ordinary users while still producing audit-ready, standards-aligned records and reports. Target bar: a neighbourhood grocer, cashier, or family member can use the POS or finance workflows safely; the underlying records are robust enough for a Big Four review.
Required first reads (in order)
- This
SKILL.md.
references/audit-protocol.md.references/scorecard.md.references/report-template.md (when writing the final report).references/remediation-master-plan.md (when assembling the plan).- The canonical doctrine:
doctrine/accounting-finance-doctrine.md and its doctrine/references/ plus governance/finance-accounting-quality-gate.md.
Audit workflow
- Establish scope. System name, modules, repositories, data stores, integrations, jurisdiction, reporting framework, sectors, users, deployment environment, intended audience.
- Inventory artefacts. Source code, database schema, migrations, seed data, tests, SRS / SDS, proposal, business-plan finance section, screenshots, reports, exports, deployment settings, dashboards, prints.
- Map money flows. Sales, receipts, purchases, supplier payments, payroll, inventory, bank, POS, mobile money, refunds, chargebacks, grants, assets, taxes, closing entries.
- Test accounting integrity. Posting boundary, double-entry invariants, immutable journals, reversals, idempotency, period locks, audit logs, subledger tie-outs, report traceability, drilldown chain.
- Test user friendliness. Role-specific workflows for non-accountants, safe defaults, guided corrections, exception queues, accountant / auditor drill-down, role-conditioned shell, status taxonomy use, print fidelity.
- Test compliance posture. IFRS or IFRS for SMEs alignment, local statutory treatment, live-rate verification, tax / payroll source hierarchy, country-extension design, tax-return-pack capability, VAT-inclusive decomposition.
- Test operational accounting. Reconciliation (bank, mobile money, POS, card, cash), month-end close playbook, audit-ready reporting pack, internal controls, migration / opening balances, management accounting dimensions, sector annexes.
- Test UI / UX. Two surface modes, semantic colour discipline, drilldown affordance, money-cell triplet (net / tax / gross), status chips, print stylesheets, accessibility, mobile and low-bandwidth tolerance.
- Score findings. Apply
references/scorecard.md - every doctrine rule maps to a check.
- Classify blockers. Per the finance / accounting quality gate.
- Master plan. Per
references/remediation-master-plan.md - phased, with owners and acceptance evidence.
Evidence rules
- Do not certify a system from screenshots or claims alone. Inspect source artefacts or mark the evidence gap.
- Treat all rates, thresholds, statutory defaults, and exchange rates as live facts requiring current-source verification.
- Mark every unsupported implementation assertion as a gap or inference.
- Never claim 100 % compliance unless every required control is evidenced, tested, and current-source verified.
Backbone rule
Treat payroll, expenses, purchases, stock / inventory, POS, banking, mobile money, grants, assets, and tax as part of accounting and finance whenever they touch the Chart of Accounts, subledgers, postings, rates, reconciliations, approvals, or financial reports. The Chart of Accounts is the backbone of the finance system: every money-touching workflow must map cleanly to accounts, control accounts, dimensions, evidence, permissions, and reports.
Tax is not an afterthought. Audit whether the system can produce tax reports and tax-return packs for the applicable authority, including URA and KRA where relevant. VAT-inclusive sales or purchases must be split by the posting service into net revenue / expense and tax control-account balances so the ledger, tax report, and return data agree.
Output standard
Produce a report with findings first, then a standards scorecard, then the master plan. Every finding states:
standard - doctrine, IFRS / SME, ledger integrity, controls, reconciliation, compliance, UX, reporting, migration, or sector requirement.evidence - file path, schema object, test, screen, report, export, source URL, or observed gap.risk - what can go wrong in accounting, audit, tax, user workflow, or business operations.severity - blocker, high, medium, low.fix - concrete implementation action.acceptance evidence - what proves the fix is complete.
Release decision
The audit ends with one of: pass, pass-with-caveats, fail. Decision is recorded against the target and posted into the engine's _finance-audit-log/.
Auto-run examples
| Prompt pattern | Auto-run fires? |
|---|
| "Audit this ERP" | Yes. |
| "Refactor the POS code" | Yes (POS touches money). |
| "Build me a school management system" | Yes (fees, receipts, payroll). |
| "Build me a school timetable system" | Maybe - confirm with the user; if it stores no money, no. |
| "Write an SRS for a clinic management system" | Yes (billing, receipts, claims, payroll). |
| "Replace this client's QuickBooks" | Yes. |
| "Write a business plan for a hardware retailer" | Yes (revenue model, taxes, inventory, payroll). |
| "Write a mobile app for a taxi service" | Yes (fares, driver payouts, statutory). |
| "Build a CMS for a magazine" | Maybe - confirm; if any subscription / billing element, yes. |
| "Document the chemistry of soda manufacturing" | No. |
When in doubt, load the skill and ask one clarifying question rather than skip silently.
Companion references
references/audit-protocol.md - full procedure and evidence collection plan.references/scorecard.md - scoring model, blocker list, pass / fail criteria.references/report-template.md - report structure for audit deliverables.references/remediation-master-plan.md - master-plan format and sequencing rules.
Last reviewed: 2026-05-12. Next review due: 2026-11-12.
Prerequisites
- Load
doctrine/accounting-finance-doctrine.md before applying this skill.
- Load
governance/finance-accounting-quality-gate.md when the output is a release, client artefact, SRS, SDS, proposal, business plan, or implementation plan.
- Use
doctrine/source-register/ for final statutory, tax, payroll, FX, EFRIS, eTIMS, or authority-template values.
Inputs
| Artifact | Produced by | Required? | Validation |
|---|
| Finance context map | finance-module-audit | Required | Entity, framework, jurisdiction, modules, users, and deployment context are named. |
| Doctrine baseline | Doctrine owner | Required | Doctrine version and reporting framework are stated. |
| Source-register snapshot | tax-statutory-source-register-and-country-packs | Required for final statutory output | Entries are verified-current or reviewer-approved verified-with-caveat. |
| Ledger/posting context | ledger-posting-engine-core | Required when postings are affected | Posting boundary, CoA mappings, control accounts, dimensions, and period state are known. |
Outputs
| Artifact | Consumed by | Acceptance evidence |
|---|
| Skill-specific decision record | Implementer, reviewer, quality gate | Scope, assumptions, chosen treatment, rejected alternatives, and caveats are recorded. |
| Implementation or workflow contract | Software, SRS, SDS, proposal, or business-plan engine | Contract names inputs, outputs, controls, evidence, and failure conditions. |
| Acceptance evidence | Finance quality gate | Tests, fixtures, examples, source links, reviewer sign-off, or evidence-pack references are present. |
| Plain-language explanation | Client, owner, manager, operator | Business meaning is stated before technical accounting treatment where client-facing. |
Decision Rules
- Prefer IFRS for SMEs for typical SME entities unless full IFRS, local law, donor requirements, or client policy requires otherwise.
- Treat every money-touching workflow as ledger, control, reconciliation, evidence, and reporting scope.
- Do not finalize statutory values without source-register support and reviewer status.
- Use business-language output for operators and accountant-language output for ledger, reporting, and audit users.
- Escalate uncertain framework, tax, or statutory interpretations to the required reviewer role instead of presenting them as final.
Acceptance Evidence
- Inputs and outputs above are present or explicitly marked not applicable.
- Relevant quality-gate blockers have been checked and no blocker remains unresolved.
- Examples or fixtures cover at least one happy path and one failure or caveat path for this skill's domain.
- Reviewer role, review date, and open caveats are recorded for release-grade artefacts.
Anti-Patterns
- Treating draft planning assumptions as final statutory or accounting facts.
- Hiding tax, payroll, FX, or authority-template caveats in prose instead of source-register state.
- Producing technically correct accounting output without a plain-language layer for non-accountant users.
- Closing a remediation or implementation item without observable evidence.
Required References
doctrine/accounting-finance-doctrine.md.governance/finance-accounting-quality-gate.md.docs/reference-manifest.md for declared reference states.- Domain-specific references listed earlier in this skill.
Examples
- Include at least one normal workflow example for this skill's domain.
- Include at least one exception, rejection, reversal, stale-source, or reviewer-caveat example where the domain can fail.
Review Metadata
Last reviewed: 2026-05-15. Next review due: 2026-11-15.
