finance-module-audit

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.

Finance Module Audit

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, [phone].

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:

1. Loads this SKILL.md and the four reference files in this folder.
2. Loads the canonical doctrine at <engine-root>/skills/_doctrine/accounting-finance-doctrine.md (skills-web-dev path) or <engine-root>/doctrine/accounting-finance-doctrine.md (other engines).
3. Loads the relevant doctrine reference files under doctrine/references/.
4. 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).
5. Runs the audit workflow below.
6. 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)

1. This SKILL.md.
2. references/audit-protocol.md.
3. references/scorecard.md.
4. references/report-template.md (when writing the final report).
5. references/remediation-master-plan.md (when assembling the plan).
6. The canonical doctrine: accounting-finance-doctrine.md and its references/ plus the governance/finance-accounting-quality-gate.md.

Audit workflow

1. Establish scope. System name, modules, repositories, data stores, integrations, jurisdiction, reporting framework, sectors, users, deployment environment, intended audience.
2. Inventory artefacts. Source code, database schema, migrations, seed data, tests, SRS / SDS, proposal, business-plan finance section, screenshots, reports, exports, deployment settings, dashboards, prints.
3. Map money flows. Sales, receipts, purchases, supplier payments, payroll, inventory, bank, POS, mobile money, refunds, chargebacks, grants, assets, taxes, closing entries.
4. Test accounting integrity. Posting boundary, double-entry invariants, immutable journals, reversals, idempotency, period locks, audit logs, subledger tie-outs, report traceability, drilldown chain.
5. 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.
6. 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.
7. 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.
8. 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.
9. Score findings. Apply references/scorecard.md - every doctrine rule maps to a check.
10. Classify blockers. Per the finance / accounting quality gate.
11. 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.