Banking, Cash & Petty Cash

1. Bank Accounts and GL Linking

Managing bank accounts

SamvraCore ERP centralises bank account management on the BankAccountsPage, exposed through the backend route GET/POST /api/v1/banking/accounts. Each bank account record is more than a label: it is linked to a specific General Ledger (GL) account, so that every movement of money through the bank is reflected in the accounting books automatically.

This GL-account linking is the backbone of the banking module. Because the bank account maps directly to an account in the Chart of Accounts, cash transfers, petty-cash replenishments, and reconciliation entries all post to the correct ledger account without manual re-keying. The approach keeps the bank balance in the ERP aligned with the accounting balance for the same account.

Practical capabilities an accountant gains from this page include:

• Creating and maintaining the list of bank accounts the organisation operates.
• Associating each account with its GL account so postings flow through double-entry accounting.
• Providing the anchor record that downstream features — statement import, reconciliation, and cash transfers — depend on.

A typical setup workflow is: define the GL account in the Chart of Accounts, create the matching bank account on BankAccountsPage, link the two, and then begin importing statements and recording transfers. Once configured, the bank account becomes the single source of truth for that institution inside the ERP, and later modules reference it rather than duplicating the connection to the ledger.

2. Importing Bank Statements

Bringing external data into the ERP

The BankImportPage provides Bank Statement Import, the mechanism by which transactions recorded by the bank are brought into SamvraCore for matching against the organisation's own records. Rather than manually entering every line that appears on a bank statement, the import feature loads those lines in bulk so they can be processed systematically.

Statement import is the first stage of the reconciliation cycle. The imported statement lines represent the bank's view of activity on the account — deposits, withdrawals, fees and transfers — which may or may not already be recorded as journal entries inside the ERP. Loading them creates the working set that reconciliation then needs to resolve.

Why this matters:

• Accuracy — the bank's statement is the authoritative external record; importing it lets the ERP compare internal postings against reality.
• Volume — bulk import handles high transaction counts far more reliably than manual entry.
• Automation readiness — imported lines are exactly what the Bank Match Rules engine consumes to auto-match entries.

A typical flow is to import the period's statement on BankImportPage, then move to the reconciliation screen where imported lines are compared with ledger entries. Items that match are cleared; items that do not match surface as exceptions for the accountant to investigate, such as timing differences or unrecorded bank charges.

3. Bank Reconciliation and Match Rules

Clearing the account

Bank Reconciliation, on the BankReconciliationPage, is where imported statement lines are compared against the entries already posted in the ERP for a bank account. The goal of reconciliation is to confirm that the ERP's record of an account agrees with the bank's record, and to identify any differences that need action.

To reduce manual effort, SamvraCore provides Bank Match Rules on the BankMatchRulesPage. These rules drive auto-matching for reconciliation: they encode how incoming statement lines should be paired with existing ERP transactions, so that routine, high-confidence matches are resolved automatically instead of one by one.

The reconciliation workflow generally proceeds as follows:

1. Import the statement on BankImportPage.
2. Open BankReconciliationPage for the account and period.
3. Let the configured Bank Match Rules auto-match statement lines to ledger entries.
4. Review the unmatched remainder — these are the exceptions requiring human judgement.
5. Resolve each exception, for example by recording a missing bank fee or correcting a mistaken entry.

Separating auto-matched items from exceptions lets accountants focus their attention where it is genuinely needed. Match rules carry the repetitive load, while the reconciliation page gives a clear view of what remains open and keeps the bank account's ERP balance trustworthy.

4. Cash Transfers Between Accounts

Moving money inside the organisation

The CashTransfersPage records Cash Transfers, which cover the movement of funds between accounts as well as deposits, withdrawals, and petty-cash replenishment. Rather than treating each of these as an unrelated action, SamvraCore groups them as transfer operations against bank and cash accounts.

The supported transfer scenarios include:

• Between accounts — moving funds from one bank account to another.
• Deposits — placing cash into a bank account.
• Withdrawals — taking cash out of a bank account.
• Petty-cash replenishment — topping up a petty cash fund from a bank account.

Because bank accounts are linked to GL accounts, a cash transfer naturally produces the correct double-entry postings. The petty-cash replenishment case is a direct integration point with the Petty Cash module: when a fund is replenished, the transfer debits the petty cash account and credits the bank, keeping both sides of the organisation's cash position synchronised.

A typical example: an office needs to refill its petty cash tin. The accountant records a replenishment cash transfer from the operating bank account to the petty cash fund. The transfer both reduces the bank balance and increases the petty cash balance, and the linked GL accounts ensure the ledger reflects the movement without any separate journal entry having to be written by hand.

5. Petty Cash Funds and Categories

Setting up small-value cash control

The Petty Cash module manages small, routine cash outlays that would be impractical to run through full accounts-payable processing. It begins with Petty Cash Funds on the PettyCashFundsPage, where each fund carries an authorized limit — the maximum amount the fund is permitted to hold — and is linked to a GL account so that fund activity flows into the accounting books.

Alongside funds, Petty Cash Categories on the PettyCashCategoriesPage classify what the cash is spent on. These categories are linked to expense GL accounts, which means that when a disbursement is recorded against a category, the system knows which expense account to charge. Categories make petty cash spending analysable rather than an undifferentiated lump.

Key setup elements:

• Authorized limit per fund — bounds how much cash a fund can carry, supporting control and oversight.
• GL account linking on the fund — ties the physical cash to a ledger account.
• Expense-GL-linked categories — route each spend to the correct expense account.

A typical configuration is to create one fund per office or custodian, set its authorized limit, link it to the petty cash GL account, and define categories such as office supplies or travel that map to the relevant expense accounts. With this structure in place, day-to-day disbursements can be captured quickly while still producing proper accounting.

6. Petty Cash Transactions, Replenishment and Reconciliation

Running the fund day to day

Petty Cash Transactions on the PettyCashTransactionsPage capture disbursements and replenishments, each tracked with a category. The page supports actual-cash-count reconciliation, meaning the recorded balance can be checked against the physical cash counted in the tin.

When a fund runs low, the Replenishment Workflow — surfaced on the PettyCashReplenishmentsPage — covers request, approval, and payment tracking. A custodian requests a top-up, the request is approved, and the payment is recorded, restoring the fund toward its authorized limit.

At period end, Reconciliations on the PettyCashReconciliationsPage perform a cash count and track variance. The custodian counts the physical cash, enters the actual count, and the system compares it with the expected balance so that any shortfall or overage is identified and explained.

A representative cycle:

1. Record disbursements against categories as cash is spent.
2. Submit a replenishment request when the balance falls.
3. Approve and pay the replenishment to refill the fund.
4. Perform a period-end reconciliation, counting actual cash and recording the variance.

This disciplined loop keeps small cash spending controlled and auditable, while variance tracking makes discrepancies visible rather than letting them accumulate silently.

7. Journal Entry Integration for Petty Cash

How petty cash reaches the ledger

A defining feature of the Petty Cash module is automatic Journal Entry Integration: the significant cash events generate the correct double-entry postings without the accountant writing journals by hand. SamvraCore defines three standard postings.

At initial fund setup, cash moves from the bank into the fund, so Petty Cash is debited and Bank is credited. When a disbursement is approved, the relevant expense account — determined by the transaction's category — is debited and Petty Cash is credited, recognising the cost. When the fund is replenished, cash flows back in from the bank, debiting Petty Cash and crediting Bank.

These automatic entries connect petty cash to the wider accounting system and to the banking module, since the fund setup and replenishment postings both touch a bank account. Because the category chosen on each disbursement determines the expense account debited, the earlier setup of expense-linked categories directly shapes the ledger impact. The result is that even small, frequent cash spending produces complete, consistent accounting with minimal manual effort.