Control and audit
Who can change what, and what happened when
A spreadsheet has one permission level and no memory. This is the part of fund administration that a file on a shared drive cannot give you at all: enforced roles, months that stop being editable, and a record of what happened.
No credit card. Nothing is charged until your first 30 days are over.
Four roles, enforced below the interface
Administrator, editor, viewer and reviewer. What each one may do is enforced by database policy rather than by which buttons the interface renders, so hiding a control is never the only thing standing between a viewer and a write.
- Everyone with access reads; editors write bookkeeping
- Fund configuration and destructive actions are administrator only
- Reviewer is read-only by design, for the person who verifies rather than prepares
Locking, and what it costs to undo
A locked month is immutable at the database level. Corrections go through an administrator reopening it with a written reason, or through the current month, which is how a fund administrator would work anyway.
- Writes to a locked period are rejected by the database, not by a screen
- Reopening is administrator only and requires a reason, which is stored
- Exactly one month per fund is ever open, so there is no doubt where you are working
- Forcing a lock past a failing check is administrator only and deliberately awkward
Two people, when it matters
Turn on NAV confirmation and the person who prepares the month submits it instead of locking it. Somebody else confirms. For a fund with an external reviewer or a second admin, this is the control that makes the monthly sign-off real.
- A setting per fund, not a plan upgrade
- The preparer cannot be the confirmer
- The period sits in review until the second person acts
The trail
An audit trigger is attached to every business table in both schemas, writing to a log no application user can read or alter. Separately, the change history for each participant is surfaced in the app, searchable and paged.
- Period events (open, submit, lock, reopen) are recorded as they happen
- Participant history is visible in the app, with search and filters
- Every statement send is a delivery row with its own status and retry
What this is really about
A spreadsheet has one permission level and no memory. Anyone who can open it can change any figure in any month, including months that have already been reported, and nothing anywhere records that it happened. For a fund administering other people's money, that is the gap between what the internal control description says and what is actually true.
The controls here sit below the interface rather than in it. Four roles are enforced by database policy, so hiding a button is never the only thing standing between a viewer and a write. A locked period is immutable at the database level, and exactly one month per fund is ever open, so there is no ambiguity about where you are working. Every business table carries an audit trigger. Turn on NAV confirmation and the person who prepares the month cannot be the one who signs it off.
Questions about this
Are the roles enforced or just reflected in the interface?
Enforced, by row-level security policy in the database. Administrator, editor, viewer and reviewer: everyone with access reads, editors write bookkeeping, fund configuration and destructive actions are administrator only, and reviewer is read-only by design for the person who verifies rather than prepares. A request that the policy forbids fails at the database regardless of which screen it came from.
Can a locked month ever be changed?
Only by an administrator reopening it, which requires a written reason that is stored with the event. Until that happens the database rejects writes to the period outright. Forcing a lock past a failing reconciliation check is also administrator only, and deliberately awkward, because it should be a decision somebody takes rather than a button somebody clicks.
The rest of the product
Every part of FundFlow works on the same monthly cycle. These are the neighbouring pieces.
The controls are on by default
Row-level security, locking and the audit trail are not a tier. Start a trial and they are already there, so the only thing left to do is try to get around them.
In your first session
- Create the fund and invite a second person, giving them the reviewer role.
- Turn on NAV confirmation so the month has to be submitted by one person and confirmed by another.
- Close and lock a month, then try to edit it and watch the database refuse rather than the screen.
No credit card. Nothing is charged until your first 30 days are over.