This handbook describes the evidence required before the partner-wide Finance Management hub can be called certified. The hub covers partner-only activity and every event owned by that partner. It does not move money or replace bank and provider records; it records, controls, reconciles, and traces finance work.
The deterministic disposable-local suite, in-app-browser empty/denied/error/recovery states, and linked current-history Finance schema/runtime inspection pass. Hosted synthetic mutation canary, native restore, provider-sandbox, additional-browser, and independent-review gates remain required before the complete certification gate can pass. A local or linked-schema pass must never be presented as a production certification.
Certification states are not_run, passed, failed, blocked, and accepted_exception. Only passed contributes to coverage. Retried critical tests remain failed until the retry cause is understood and closed.
The route inventory covers Overview, Transactions, Outflows, Reconciliation, Events, Audit trail, Automation, Settings, Payables, Receivables, Expenses and custody, Budgets, Close and assurance, and Integrations. Eleven distinct dialog types cover manual entries, outflow requests, periods, statement preview/review, notification routing, operational records and actions, custody open/manage, and integration profiles.
The machine-readable route/API inventory is maintained with the dashboard certificate. It currently maps 14 routes, 14 unique modal selectors, and 54 API contracts. The approved Design 2 route gallery, rendered implementation gallery, modal evidence, and same-frame comparisons are retained with the local certification artifacts.
All monetary calculations use an explicit three-letter currency and two-decimal canonical input at API boundaries. Unlike currencies are never silently summed. Stored journal values retain database numeric precision; display rounding must not change the authoritative value.
| Display or control | Definition | Sign and exclusions |
|---|---|---|
| Book cash | Cash-account opening balances + posted cash debits − posted cash credits at the cutoff | One currency; excludes drafts and forecasts |
| Restricted cash | Opening and posted cash effects for restricted accounts | Reported separately; not available to spend |
| Committed outflow | Approved amounts reserved but not yet posted as cash movement | Excludes submitted/unapproved requests |
| Available cash | Book cash − restricted cash − committed outflow | A coverage warning remains visible when reconciliation is incomplete |
| Money in | Posted cash inflows at the selected cutoff | One currency and current partner/event filter |
| Money out | Posted cash outflows at the selected cutoff | Positive display magnitude |
| Net movement | Money in − money out | Transfers contribute zero to income/expense result |
| Event result | Event income − event expense plus approved event allocation | Partner-only activity stays separate |
| Partner result | Partner-only result + owned-event results | No duplicate event source projection |
| Payable outstanding | max(0, gross − valid credits − paid) | Per document currency |
| Receivable outstanding | max(0, gross − valid credits − collected − approved write-off) | Overpayment cannot make open AR negative |
| Budget available | Original + revisions + transfers in − transfers out − actual − commitments | Forecasts remain projections |
| Expected cash close | Opening float + paid in + positive adjustments − paid out − safe drops − negative adjustments | One custody session and currency |
| Cash variance | Counted close − expected cash close | Positive is overage; negative is shortage |
| Statement closing | Statement opening + inflows − outflows | Imported population must reconcile |
| Unreconciled difference | Statement closing − cleared book balance | A non-zero value requires match or explanation |
The complete field-level formula catalogue, including allocation, aging, forecast, event-performance, advance, reconciliation-coverage, numeric-boundary, UI/API scope, and test identifiers, is stored as certification/finance/formula-dictionary.md in the dashboard repository and is checksum-bound by the latest manifest.
The golden oracle uses integer cents, the Asia/Manila timezone, an explicit cutoff, and deterministic largest-remainder allocation. It includes two partners, four events each, a zero-activity event, partner-only records, PHP and USD, transfers, AP/AR, allocation residuals, budgets, custody, and reconciliation.
The signed-in identity and server time are authoritative. Browser-supplied actor identity, capability, time, partner, version, or status cannot replace server-derived values. Sensitive mutations acquire a short accountable checkout bound to resource, action, user, session, and lease token. A successful transaction consumes the checkout; closing a dialog releases it. Version checks reject stale actions.
Approval, settlement, reconciliation, custody supervision, and close controls use maker-checker separation. Records retain stable partner and event scope, source identity, before/after digests, reason, surface, receipt, journal lines, audit events, and provider delivery state.
Partner defaults and event inherit/override/disabled rules are separate for inflow and outflow. Telegram routes can address a group/forum topic. Discord routes can address a guild channel or thread. Action buttons require a currently linked platform identity, active partner membership, current capability, valid opaque action, and current record version.
Provider delivery is outside the ledger transaction. Retry, duplicate delivery, timeout, and message-edit failure cannot roll back or duplicate the authoritative finance mutation. Controlled provider destinations and redacted evidence are mandatory for the deployed certification gate.
The certification suite validates canonical JSON, ISO 20022 camt.053, UBL 2.3 Invoice, XBRL GL, and SAF-T-style profiles. Profiles are version-pinned and preserve currency, timestamps, canonical IDs, partner/event scope, line identity, source references, and digests. Import follows upload → parse → validate → preview → separate approval → idempotent commit.
Compatibility with a standard is not a third-party certification. Unsupported or malformed documents must produce explicit rejections; they must never be silently coerced into journal data.
The local certificate records fixture and artifact SHA-256 values, suite commands, run time, environment class, screenshot inventory, and final opinion in certification/finance/latest-manifest.json in the dashboard repository.
The complete gate additionally requires:
pnpm --dir ../partners.furries.ph run finance:certify:complete:local
pnpm --dir ../partners.furries.ph run finance:certify:complete
npm --prefix ../partners-api run finance:certify:complete
pnpm exec astro check
pnpm build
git diff --checkfinance:certify:complete fails closed until the external evidence file contains passed canary, provider, migration, restore, and signed-review evidence. Production deployment is never performed by this certificate.
finance:certify:linked-db separately verifies the linked current-history environment: required Finance migrations, Finance table/function counts, pgcrypto schema resolution, browser-role denial for privileged routines, service-role execution, and a rollback-only synthetic partner/journal mutation. The canary proves transactional write capability and leaves both row populations unchanged. It does not replace an authenticated API workflow or native backup restoration.
finance:certify:resilience verifies checksum-bound visual evidence for event-empty, access-denied, summary-service failure, rate-limited refresh, conflicting accountable checkout, and normal recovery states in the in-app browser.