# HAV Seafood Finance Treasury, Banking & Cash Framework v1

## Purpose

This workbook defines the static **Treasury, Banking & Cash architecture** for HAV Seafood. It belongs to **Phase 1 — Business Architecture** and defines how bank institutions, bank accounts, payment/receipt routes, liquidity planning, banking authority, reconciliation and Treasury controls are structurally designed.

It intentionally contains **no operational or historical cash activity** such as bank balances, payments, customer receipts, bank statements, reconciliations, FX conversions, fees, interest, cash forecasts or borrowing activity.

## Core architecture model

`Company -> Bank Institution -> Bank Account -> Currency / Purpose -> Payment or Receipt Route -> External Bank Movement -> ERP Reconciliation`

Liquidity planning follows:

`Bank Cash + Expected Receipts - Approved Payments - Payroll - Tax - CapEx -> Forecast Liquidity Position`

The most important boundaries are:

- `Bank Account != GL Account`
- `AP Payment Eligibility != Payment Proposal != Payment != Bank Movement`
- `AR Receipt != Bank Movement != AR Settlement`
- `Bank Balance != GL Cash Balance`
- `Cash Position != Cash Forecast`
- `Exchange Rate != FX Conversion`
- `Authorization Rule != Approval Event`
- `Reconciliation Rule != Reconciliation Result`

## Architecture counts

- **1 bank institution**, extending existing Shared Enterprise organization `ORG-EXT-023 CoastLedger Bank`;
- **7 bank-account masters**;
- **6 bank-account types**;
- **7 Treasury payment methods**;
- **8 payment-channel rules**;
- **7 payment-routing rules**;
- **4 receipt methods**;
- **4 current customer receipt-routing rules**;
- **9 cash-position categories**;
- **5 liquidity horizons**, including a 13-week tactical cash forecast;
- **9 cash-forecast categories**;
- **4 liquidity-control rules**;
- **6 banking authority classes**;
- **5 position-to-banking-authority mappings**;
- **6 dual-authorization controls**;
- **4 bank-detail controls**;
- **5 reconciliation profiles**;
- **11 bank-transaction categories**;
- **6 reconciliation matching rules**;
- **7 reconciliation statuses**;
- **11 Treasury exception types**;
- **9 exception-routing rules**;
- **4 internal-transfer rules**;
- **6 FX-conversion rules**;
- **4 funding-facility types**, with **no active funding facility defined**;
- **6 bank-charge types**;
- **8 Treasury GL mappings**;
- **7 Treasury calendar rules**.

## Bank-account architecture

The seven current bank-account masters are:

- `BA-001` — DKK Operating Account
- `BA-002` — EUR Operating Account
- `BA-003` — SEK Receipt Account
- `BA-004` — NOK Receipt Account
- `BA-005` — Payroll Account
- `BA-006` — Tax and Statutory Account
- `BA-007` — Liquidity Reserve Account

These are synthetic internal Treasury masters. No real bank account numbers, balances or transaction history are included.

All bank accounts reference the existing Shared Enterprise bank identity `ORG-EXT-023` through `BANK-001`.

## Currencies

Treasury reuses the existing Finance/Shared Enterprise currency architecture. Current bank-account coverage is designed for:

- DKK
- EUR
- SEK
- NOK

Treasury does not redefine currency identity or actual exchange rates. FX rules reference exchange-rate types from the Tax, Currency & Financial Documents framework.

## Payment architecture

Accounts Payable remains authoritative for whether a payable is eligible for payment and for the approved payment instruction. Treasury owns the cash-routing and external banking layer.

Conceptually:

`AP Open Item -> Payment Eligibility -> Approved Payment Instruction -> Treasury Route -> Bank Submission -> External Bank Movement -> AP Settlement`

Payment routing separates domestic, foreign-currency, payroll, tax/statutory, emergency and internal-transfer contexts.

## Receipt architecture

Accounts Receivable remains authoritative for customer open items and settlement. Treasury owns the external bank receipt and the route through which cash arrives.

The current four customers are mapped to default receiving accounts according to their authoritative commercial currency:

- SEK customer -> `BA-003`
- NOK customer -> `BA-004`
- EUR customers -> `BA-002`

Actual receipts remain Phase 3.

## Liquidity and cash forecasting

Treasury defines five planning horizons:

1. Daily Liquidity
2. 7-Day Liquidity
3. 30-Day Liquidity
4. 13-Week Cash Forecast
5. Monthly Annual Outlook

Liquidity controls use **relative policy thresholds** instead of dated cash amounts. For example, the operating liquidity target is expressed as weeks of forecast operating outflows. This defines policy without implying a current liquidity position or business-story problem.

## Banking authority and segregation of duties

Banking authority is attached to HR positions rather than named employees.

Key positions include:

- Accounts Payable / Receivable Coordinator — payment preparation;
- Financial Accountant — review/reconciliation;
- Management Accountant / Controller — Treasury control/approval;
- Finance & Administration Manager — primary Treasury approval/release authority;
- Managing Director — escalated/executive approval where later monetary rules require it.

The architecture requires separation between payment preparation and final approval/release. Supplier bank-detail maintenance is also separated from payment approval.

Actual monetary thresholds are deliberately deferred to the future **Finance Process, Authority & Internal Control** architecture.

## Bank reconciliation

The existing enterprise system ownership model is preserved:

- `ESYS-013 Online Banking Portal` is authoritative for external bank transactions and statements;
- `ESYS-001 Core ERP` is authoritative for accounting, payment instruction and bank reconciliation;
- `ESYS-009 Power BI` is reporting/analytics only.

A bank statement balance and a GL cash balance are separate records that should reconcile; neither is silently substituted for the other.

## Funding boundary

The workbook defines funding-facility types such as overdrafts, revolving facilities, equipment loans and finance leases, but **no active funding facility, commitment limit, drawdown or debt balance is seeded**.

This preserves story neutrality.

## Sheet guide

### Banking masters
- `Bank_Institutions` — Finance extension of the shared bank identity.
- `Bank_Account_Types` — controlled account-purpose taxonomy.
- `Bank_Accounts` — authoritative Treasury bank-account master.
- `Bank_GL_Mappings` — bank-account to Finance GL-control relationships.

### Payments and receipts
- `Treasury_Payment_Methods` — Treasury execution methods.
- `Payment_Channel_Rules` — method/currency/account channel combinations.
- `Payment_Routing_Rules` — normal liability-to-bank routes.
- `Receipt_Methods` — allowed receipt methods.
- `Receipt_Routing_Rules` — customer/currency receiving routes.

### Cash and liquidity
- `Cash_Position_Categories`
- `Cash_Position_Definition`
- `Liquidity_Horizons`
- `Cash_Forecast_Categories`
- `Cash_Forecast_Rules`
- `Liquidity_Control_Rules`

### Banking authority and controls
- `Banking_Authority_Classes`
- `Position_Banking_Authority`
- `Dual_Authorization_Rules`
- `Bank_Detail_Control_Rules`

### Reconciliation and exceptions
- `Reconciliation_Profiles`
- `Bank_Transaction_Categories`
- `Reconciliation_Matching_Rules`
- `Reconciliation_Status_Model`
- `Treasury_Exception_Types`
- `Treasury_Exception_Routing`

### Transfers, FX and funding
- `Internal_Transfer_Rules`
- `FX_Conversion_Rules`
- `Funding_Facility_Types`
- `Funding_Facility_Framework`
- `Bank_Charge_Types`
- `Treasury_GL_Mappings`
- `Treasury_Calendar_Rules`

### Architecture and lineage
- `System_Data_Ownership`
- `Responsibility_Mappings`
- `Source_Mappings`
- `Relationship_Catalog`
- `Architecture_Notes`
- `Control_Parameters`
- `Data_Dictionary`

## Cross-domain ownership

### Shared Enterprise
Authoritative for external-organization identity, enterprise systems and shared currency/reference identities.

### Finance Accounting Foundation
Authoritative for ledger, chart of accounts, GL account identity and posting classes.

### Tax, Currency & Financial Documents
Authoritative for Finance currency applicability, exchange-rate types and financial-document architecture.

### Accounts Receivable
Authoritative for customer Finance accounts, receivables, receipt settlement rules and credit/billing structures.

### Accounts Payable
Authoritative for supplier Finance accounts, payable eligibility, AP payment proposals/instructions and supplier settlement rules.

### HR
Authoritative for positions and incumbency. Treasury authority is position-based; no employee-specific banking authority is stored here.

### Treasury
Authoritative for bank-account financial masters, Treasury payment/receipt routing, liquidity structure, banking authority requirements, bank reconciliation architecture and Treasury controls.

## Architecture boundaries — operational data intentionally excluded

This workbook does **not** contain:

- bank balances;
- bank statements;
- bank transactions;
- customer receipts;
- supplier payments;
- payroll payments;
- tax payments;
- payment files;
- payment approvals;
- bank confirmations;
- FX conversions or actual FX rates;
- bank fees or interest transactions;
- cash-forecast values;
- liquidity shortages;
- reconciliation results;
- unmatched transaction cases;
- bank-detail changes;
- rejected or failed payments;
- active borrowing balances;
- loan repayments;
- Treasury approval history.

These belong to Phase 3 after business stories have been selected in Phase 2.

## Story neutrality

The architecture does not deliberately seed:

- cash shortages;
- payment failures;
- fraudulent bank-detail changes;
- unauthorized transfers;
- duplicate payments;
- chronic reconciliation differences;
- FX losses;
- bank-service deterioration;
- covenant problems;
- borrowing stress.

These should be introduced deliberately during Phase 2/3 if selected as business stories.

## Recommended AI navigation

- Bank/account question -> `Bank_Institutions` / `Bank_Accounts`
- GL mapping -> `Bank_GL_Mappings` / `Treasury_GL_Mappings`
- How should a payment be routed? -> `Payment_Routing_Rules`
- How should customer cash arrive? -> `Receipt_Routing_Rules`
- What constitutes cash position? -> `Cash_Position_Definition`
- Cash-forecast structure -> `Cash_Forecast_Rules`
- Liquidity limits -> `Liquidity_Control_Rules`
- Who may prepare/review/approve/release? -> `Position_Banking_Authority`
- Segregation of duties -> `Dual_Authorization_Rules`
- Bank-detail change controls -> `Bank_Detail_Control_Rules`
- Reconciliation logic -> `Reconciliation_Matching_Rules`
- Treasury exception -> `Treasury_Exception_Types` / `Treasury_Exception_Routing`
- FX cash conversion -> `FX_Conversion_Rules`
- Ownership/source precedence -> `System_Data_Ownership` / `Source_Mappings`

## Overall role

Together, these structures form HAV Seafood's static Treasury, Banking & Cash layer. They connect AR/AP obligations and other Finance cash requirements to controlled bank-account routing, external banking execution, reconciliation and liquidity management while preserving existing system-of-record and cross-domain ownership boundaries.
