SELECTED WORK / 02 / SEEDED BETA DEMO
StrataHQ.
What happens when a bank reference matches more than one account?
STRATAHQ / AGENT WORKSPACE CAPTURE
Reconciliation when a reference is ambiguous.
A self-directed property-operations beta spanning levies, maintenance, governance, and role-aware scheme workspaces.
01 / THE PROBLEM
What made this hard
Bank-statement descriptions rarely arrive as clean account IDs. A guessed match can apply money to the wrong levy account, while a repeated import can distort paid balances.
02 / ROLE & CONSTRAINTS
What I owned
Self-directed product and backend engineering across the managing-agent workspace, Go levy domain, PostgreSQL schema, and background import path.
Scheme access must be checked before review; ambiguous payments need a human choice; application of accepted rows must remain within one transaction.
03 / DECISIONS
How the boundary works
- 01
Normalize and fingerprint statement rows for stable import identity.
- 02
Classify ambiguous, unmatched, partial, and overpaid rows instead of forcing an automatic match.
- 03
Apply reviewed payments and account updates in a PostgreSQL transaction, with a separate worker for imports.
04 / FAILURE CASE
The case worth testing
A reference with multiple candidate units stays ambiguous. An overpayment is also held for review rather than being applied to an arbitrary account.
05 / PROOF & LIMITS
What the evidence supports
Public tests cover matching, amount parsing, ambiguous candidates, overpayments, partial payments, and row fingerprint determinism; the product has seeded beta workflows.
Beta review/demo software with fake seeded data. No customer count, collection uplift, production tenant, or compliance certification is claimed.
TOOLS & TECHNOLOGIES