Finance Expert

Finance Expert

Money is not a number. A number can be recomputed; money is a claim, recorded at a point in time, owed by someone to someone, in a currency, under an accounting policy, subject to a regulator, and irreversible once it moves. Almost every serious defect in a financial system comes from having modelled the number and not the claim: a float column, a balance that is a mutable row, a retry that charges twice, a report that sums two currencies, a correction that overwrites history.

This skill encodes the model that survives contact with reality: an append-only, double-entry ledger is the source of truth; everything else — balances, reports, dashboards, KPIs — is derived from it and must be reproducible from it. Everything below follows from that.

Rule 0 — the ledger of record already exists

If the organisation already books money somewhere — a general ledger, an ERP, a PSP dashboard, the bank statement, even a spreadsheet the finance team closes each month — then that is the source of truth until a written decision says otherwise, and your system reconciles to it (M9). Do not introduce a second authoritative record. Two systems that both believe they hold the truth do not produce a discrepancy you can debug; they produce a monthly argument that no one can win.

Likewise, if an accounting policy exists (functional currency, rounding rule, revenue recognition treatment, close calendar, chart of accounts), it is decided. It belongs to the finance owner and the auditor, not to a code review. Extend it consistently; changing it is a costed proposal with a restatement plan, never a refactor.

1. Pick a mode

Modes compose and rarely arrive labelled. "Add a wallet to the app" is DESIGN plus OPERATE (someone will have to reconcile it) plus compliance framing. Never skip §2 because the request sounds small — "just store the user's balance" is a ledger, a currency policy, a concurrency model, an audit trail and a reconciliation process.

2. Frame before you model

Answer these nine before writing a column, a schema or a formula. If nobody can answer, that is the finding. If the work is unattended, state the assumption you took at the top of the deliverable.

1. Whose money, held by whom? You merely _record_ amounts (marketplace ledgering), you _instruct_ a regulated party (PSP, bank, EMI), or you _hold_ client funds. The third answer changes the licence, the safeguarding obligation, the audit and the architecture — and is the one teams discover accidentally.
2. What is the ledger of record, and who else believes they are it? List every system that holds an authoritative amount: PSP, acquirer, bank, ERP, tax engine, subscription billing, the spreadsheet. Draw the arrows now (Rule 0).
3. Currencies. Which transaction currencies, what functional/reporting currency, who supplies the rate, at which timestamp, and who bears the spread (M6)?
4. Rails, finality and reversal windows. Card auth/capture, ACH, SEPA, wire, RTP/Pix/UPI, wallet, stablecoin. Each has a different revocation window: a wire is effectively final, a card is contestable for months, an ACH debit can return weeks later. Design for the _longest_ reversal window on the path.
5. Accounting basis and calendar. Cash or accrual, IFRS or US GAAP or local, who closes, on which day, what is the cutoff rule, what is the materiality threshold (M10)?
6. What is the worst wrong number? A customer-visible balance, a payout, a tax filing, a regulatory return, an investor metric. Rank them; controls and test effort follow this ranking, not the code's complexity.
7. Regulatory perimeter. PCI DSS scope, PSD2/PSD3 and SCA, AML/KYC obligations, SOX if public, MiCA if crypto, DORA if EU financial entity, data residency and retention (see references/compliance-regulatory.md).
8. Volume and shape. Peak transactions/second, postings/day, retention horizon, close deadline, largest realistic report. A ledger that is correct and 40 minutes late for the close is not correct enough.
9. Who owns the numbers and who approves movement? Name the finance owner, the approver, and the separation-of-duties rule (M11). A money system with no named approver has no control, whatever the code says.

3. The domain map

finance-expert covers the whole money surface. Depth lives in the references; adjacent skills go deeper on their own axis and are named so you delegate deliberately rather than duplicating.