Finance

The Finance section is available when the finance module is enabled. It supports general ledger-style work: chart of accounts, funds (for system administrators where applicable), accounting entries, general ledger, trial balance, ledger audit, and a built-in Finance guide.

What this area is for

Use Finance tools to:

Maintain the chart of accounts and, where your setup uses them, funds.
Record and review accounting entries (sometimes labeled “Entries” in the menu).
Run general ledger and trial balance reports for a period.
Perform ledger audit reviews as your controls require.

Access is permission-based: some users view only; others manage journal entries; others manage the chart of accounts and funds; some can approve and post entries. Your administrator maps these to roles under Roles & permissions.

Finance guide (in the product)

The ERP includes an in-application Finance guide screen that explains finance concepts and how to use the finance features in more detail than this document.

Recommendation for staff: Open Finance → Finance guide inside the ERP for step-by-step context, definitions, and notes that ship with the product.

This operations doc stays short on purpose so it does not duplicate that guide.

Practical tips

Agree on period close and who may post entries so everyone follows the same calendar.
Keep chart-of-account changes controlled: document major restructures outside the system if your auditors require it.
Use Ledger audit as part of your control framework if your compliance team expects periodic reviews.

NAV-fund subscriptions, redemptions, and trades

This is a separate product from the existing investment flow you may already be familiar with. The existing flow — fixed-tenor Mudarabah investments where customers transfer money for 90/180/365 days at an agreed profit rate — is unchanged. Three new ERP screens add a different product alongside it: a NAV-priced unit fund, where customers buy units whose value moves with the underlying portfolio.

Fund Subscriptions lets staff record that a customer has wired money to subscribe to a unit fund. Two steps: first record the cash receipt (the wire has arrived), then on the next NAV publish, allocate units to the customer at the just-published NAV. The customer's unit balance grows on their statement.
Redemptions lets staff process a customer's request to redeem some or all of their units. The request moves through four states: submitted (requested) → approved → priced at the next NAV → paid. The customer's unit balance shrinks; cash leaves the bank.
Trades is the fund manager's blotter for buying and selling stocks (equity) and sukuk on behalf of the fund. Every trade is automatically checked against the active Shariah rules before any money moves — unscreened or haram-screened securities are blocked at the moment of trade, not after.

For now, all three flows are operated by staff in the ERP. The customer-portal stays as-is: customers continue using the existing investment flow they're familiar with. When the time comes to expose these new flows to customers, the back-office machinery is already in place.

NAV (Net Asset Value)

The NAV screen is where staff calculate, freeze, and publish the unit price for each fund. NAV — Net Asset Value — is the answer to "what is one unit of this fund worth today?" The formula is total assets minus total liabilities, divided by units outstanding. The system runs the 12-step calculation automatically, but staff control when it's locked in.

Each calculation produces a snapshot — a dated record of the calculation that moves through three states:

Draft — calculation has run; operations can review every line (every holding, every cash balance, every fee accrual). Re-running on the same date replaces the draft.
Frozen — locked. Shariah board / compliance reviews. No further edits.
Published — official. NAVPU is what every subscription and redemption priced today will use; it appears on the investor portal.

The detail page shows the line-by-line breakdown so staff can audit why the NAV is what it is. Any holding priced from data older than the staleness threshold is highlighted; publish is blocked until prices are refreshed (or an approver explicitly overrides with a warning).

Daily cadence: ops or the scheduler runs Run + Freeze at the cut-off time. After Shariah / compliance sign-off, the snapshot is Published. That moment is when pending subscriptions and redemptions get priced.

The NAV sidebar entry shows the history for any fund. Each row links to the detail page.

Shariah rules

The Shariah Rules screen lists the AAOIFI-aligned rules the system uses to gate every journal posting. Approvers can enable or disable individual rules — for example, temporarily relaxing the impure-income threshold while the Shariah board reviews a new security — without a code change. Each rule has a clear description so reviewers can confirm what it does before toggling.

The same screen lets approvers screen a security: enter the security id, its sector, and the three AAOIFI ratios (debt, cash, impure income). The system stores the result with a timestamp and uses it the next time the security is traded. Trades against a haram-screened security are automatically blocked at the point of posting; trades against a "requires purification" security go through but flag the impure portion of any dividends for purification later.

Rules apply automatically to every posting routed through the new posting engine. Operators don't need to remember to invoke them — the engine refuses to post when any active rule says no.

Reconciliation

The Reconciliation screen shows daily checks that compare what the subledgers say (per-client cash, per-fund unit counts, custodian-held positions, pending broker trades) against the matching control accounts in the General Ledger. When the two views agree, the day's run records zero exceptions. When they disagree by more than ₦0.01, the discrepancy becomes a tracked exception that operations must act on.

Each exception lists the check, the control account, the expected balance (from the subledger), the actual balance (from the GL), and the difference. You can filter by status (open / acknowledged / resolved). Acknowledging an exception confirms someone is looking at it; resolving it requires a written note describing what was done to correct the discrepancy. Resolution notes are audit-logged.

The system runs the daily check automatically each night at 23:00. You can also trigger an extra run from the screen at any time. Exceptions persist across runs — running the check again does not clear yesterday's open items.

Reversing a posted entry

Posted entries cannot be edited — that would break the audit trail. To correct a mistake, open the entry's detail page and use Reverse. The system creates a new entry that exactly cancels the original (debits and credits swapped) and links the two together so anyone reviewing the original can see how it was corrected. Both entries remain in the ledger forever; the reversal is the record of the correction.

You will be asked for a reason — this becomes part of the new entry's narration and is reviewed in audit. Reversing requires the approver permission. You cannot reverse a draft (edit it directly), you cannot reverse a reversal, and you cannot reverse the same entry twice.

Ledger audit (automated daily check)

Each night the system independently re-verifies every posted journal entry: it recomputes the cryptographic hash on each entry, checks that the chain of hashes is unbroken, and checks that every entry's debits and credits balance. The result is recorded as a run log. The Ledger audit screen shows the latest run at the top so any tampering or corruption surfaces within a day. You can also run an on-demand check from the same screen.

The check is read-only — it does not modify entries. If it finds problems, it lists which entries failed and why; an administrator then investigates.

Investments — when money movement links to investment products.
People and access — finance permissions.
System — troubleshooting via logs when something fails unexpectedly.