Bank, Cash, and Treasury

Where money physically moves. Also where fraud happens, which is why this area has the heaviest controls in the ERP.

House banks and account IDs

house_bank(id, company_id, bank_key, bank_name, country, swift_bic)
house_bank_account(house_bank_id, account_id, gl_account, iban, account_number,
                   currency, overdraft_limit, payment_methods[])

A house bank is a bank you hold accounts with. Each account maps to a GL account. Payment methods (transfer, cheque, direct debit) are enabled per account, and the payment run picks the account by currency, country, and method.

The bank clearing pattern

Never post payments directly to the bank GL account. Use clearing accounts:

100000  Bank — main account          ← only bank statement postings touch this
100010  Bank — outgoing clearing     ← payment run posts here
100020  Bank — incoming clearing     ← customer receipts posted here
100030  Bank — cheques issued

Flow:

Day 1: Payment run
  Accounts payable        Dr 50,000
    Bank outgoing clearing   Cr 50,000     ← we've instructed the bank

Day 3: Bank statement shows the debit
  Bank outgoing clearing  Dr 50,000        ← clears
    Bank main account        Cr 50,000     ← now the GL matches the bank

Why: the GL bank account balance then always equals the actual bank balance. Anything in a clearing account is money in flight. An aged clearing balance means a payment that never landed — investigate immediately.

Bank statement processing

Formats you will meet

Format	Region / use
MT940 / MT942	SWIFT, global, end-of-day / intraday. Text, semi-structured, painful to parse
CAMT.053 / .052 / .054	ISO 20022 XML — statement / intraday / debit-credit notification. The modern standard
BAI2	US
CSV / proprietary	Local banks everywhere, especially in emerging markets
API	Open Banking (PSD2 in the EU/UK), bank-specific APIs, aggregators (Plaid, TrueLayer)

Processing steps

Import statement file (or pull via API)
Validate: opening balance = previous closing balance; no gaps in statement numbers
For each line: interpret the transaction using bank transaction codes
Determine posting rules from the code + text patterns
Auto-post and auto-clear what can be matched
Route the rest to a manual post-processing worklist
Reconcile: statement closing balance = GL bank account balance

Bank transaction codes

Banks classify each line (SWIFT :61: codes, ISO 20022 BTC codes, or the bank’s own). Configuration maps each code to a posting rule:

Code    Meaning                Posting rule
NTRF    Transfer credit        Dr Bank, Cr Incoming clearing (then match to AR)
NDDT    Direct debit           Dr Bank, Cr Incoming clearing
NCHK    Cheque                 Dr Outgoing clearing, Cr Bank
NCHG    Bank charges           Dr Bank charges expense, Cr Bank
NINT    Interest               Dr/Cr Interest, Cr/Dr Bank
NRTI    Returned item          Reverse the original clearing

Text interpretation: the free-text field on incoming transfers is where the invoice number hides. Regex/pattern rules extract it. This is where cash-application auto-match rates are won or lost. See Accounts Receivable.

Bank reconciliation

The control that proves the ledger matches reality:

Balance per bank statement                  1,250,000
+ Deposits in transit (received, not cleared)  80,000
− Outstanding cheques/payments not cleared    (145,000)
± Bank errors                                       0
= Adjusted bank balance                     1,185,000

Balance per GL                              1,190,000
− Bank charges not yet booked                  (5,000)
= Adjusted book balance                     1,185,000   ✓ must match

With the clearing-account pattern above, this reconciliation becomes almost automatic: the clearing account balances are the reconciling items.

Payment file generation

ISO 20022 pain messages

The global standard:

Message	Purpose
pain.001	Customer credit transfer initiation (you pay someone)
pain.002	Payment status report (bank tells you accepted/rejected)
pain.007	Reversal request
pain.008	Direct debit initiation (you collect)
camt.053	Bank-to-customer statement
camt.054	Debit/credit notification

Regional formats: NACHA (US ACH), BACS/Faster Payments (UK), SEPA CT/DD (Europe), NEFT/RTGS/UPI (India), BEFTN/RTGS (Bangladesh), PIX (Brazil).

Security around payment files

The file is a set of instructions to move money. Treat it as such:

Digital signature or hash on the file, verified by the bank
Dual authorisation — two named approvers before release
Positive pay — you send the bank the list of valid cheques/payments; anything else is rejected
No editing after approval — the file the bank receives must be exactly what was approved
Segregation: whoever creates the payment proposal must not be able to release the file
Encrypted transport (SFTP with key auth, EBICS, host-to-host, or bank API with mTLS)
Never store bank credentials in application config or source control

Cash management and liquidity

Beyond bookkeeping, treasury wants forward-looking cash visibility:

Cash position (today):   bank balances + confirmed intraday movements
Liquidity forecast:      + AR due dates (risk-adjusted by payment behaviour)
                         − AP due dates
                         − payroll
                         − tax payments
                         ± loan / investment maturities
                         ± forecast operational flows

Horizon: daily for 4 weeks, weekly for 3 months, monthly for a year.

Cash pooling

Concentrating cash across group entities:

Physical pooling / zero balancing — money is actually swept to a master account nightly. Creates real intercompany loans that must be booked and bear interest (transfer pricing rules apply).
Notional pooling — balances are offset for interest calculation only; no money moves.

In-house bank

Large groups run an internal bank: subsidiaries hold accounts with treasury instead of external banks, and treasury nets intercompany payments (netting runs). Reduces external transaction costs and FX conversions dramatically.

Petty cash

Small, but every ERP has it: a cash journal per location, with receipt and payment postings, a physical count reconciliation, and an imprest top-up. Controls: single custodian, spending limit, receipt required, surprise counts.

Financial instruments (treasury proper)

Beyond core ERP but adjacent:

FX forwards / swaps — lock in a future exchange rate
Interest rate swaps — swap floating for fixed
Commodity hedges — lock in cotton, oil, metal prices
Hedge accounting (IFRS 9 / ASC 815) — designation, documentation, effectiveness testing, so gains/losses on the hedge land in the same period as the hedged item. Heavily rule-bound.
Loans, deposits, guarantees, letters of credit