# HAV Seafood — Finance & Administration Architecture

## Purpose

This folder contains the static **Finance & Administration business architecture** for **HAV Seafood**, the fictional Faroese seafood manufacturer used in the synthetic business dataset.

The project follows the sequence:

**1. Business architecture → 2. Stories → 3. Operational dataset**

Everything in this folder belongs to **Phase 1 — Business Architecture**.

The files define how HAV Seafood structures accounting, financial documents, customer receivables, supplier payables, inventory costing, fixed assets, Treasury, budgeting, management reporting, Administration, financial authority and internal control.

They intentionally do **not** represent historical or current operating results.

There are no actual journal entries, invoices, payments, bank balances, budgets, forecasts, depreciation runs, management reports, approval events, control failures, administrative requests or other dated operational records in this folder.

---

## Folder contents

The folder contains **10 architecture workbooks**, each with a companion Markdown reference file.

### 1. Accounting Foundation & Financial Dimensions

**Workbook:** `hav_seafood_finance_accounting_foundation_dimensions_v1.xlsx`  
**Reference:** `hav_seafood_finance_accounting_foundation_dimensions_v1.md`

This is the financial backbone for the entire folder.

It defines:

- the company ledger;
- chart of accounts;
- fiscal calendar;
- account classes and groups;
- **114 GL accounts**;
- financial-statement hierarchy;
- all **12 existing HAV Seafood cost centers**;
- financial dimensions;
- dimension-use rules;
- posting classes;
- responsibility centers;
- Finance identifier conventions;
- Finance system and data ownership.

Core model:

`Company → Ledger → Chart of Accounts → GL Account → Financial Statement Structure`

extended by:

`GL Account + Cost Center + Conditional Financial Dimensions`

This workbook is authoritative for the **financial use of cost centers and Finance accounting structures**.

Shared Enterprise remains authoritative for organizational identity, departments, locations and non-Finance master identities.

---

### 2. Tax, Currency & Financial Documents

**Workbook:** `hav_seafood_finance_tax_currency_document_framework_v1.xlsx`  
**Reference:** `hav_seafood_finance_tax_currency_document_framework_v1.md`

Defines the common financial-document, currency and tax architecture.

Major structures include:

- DKK, EUR, SEK and NOK transaction currencies;
- exchange-rate types and conversion rules;
- synthetic tax categories and codes;
- tax determination and GL mapping;
- **27 financial document types**;
- document numbering;
- document status models;
- correction/reversal relationships;
- cross-domain source-to-Finance interfaces.

Core model:

`Business Source Object → Financial Document → Currency / Tax Treatment → Posting Class → Ledger / Subledger`

This workbook defines document and treatment rules, not actual financial documents or exchange-rate history.

---

### 3. Customer Credit, Billing & Receivables

**Workbook:** `hav_seafood_finance_customer_credit_billing_receivables_v1.xlsx`  
**Reference:** `hav_seafood_finance_customer_credit_billing_receivables_v1.md`

Defines the Finance extension of the existing Sales customer architecture.

Major structures include:

- Finance accounts for all **4 current customers**;
- credit-risk classes and profiles;
- credit limits and credit statuses;
- credit checks;
- Finance-owned payment terms;
- billing profiles and billing triggers;
- invoice source rules;
- revenue-recognition profiles;
- AR open-item lifecycle;
- settlement and payment-difference rules;
- aging buckets;
- collections architecture;
- dispute categories;
- AR adjustment and accounting mappings.

Core model:

`Sales Customer → Finance Customer Account → Credit / Terms / Billing → Future Invoice → Future AR Open Item → Settlement / Collection`

Sales remains authoritative for customer and commercial identity. Finance owns the financial extension, credit treatment, receivables and accounting rules.

---

### 4. Supplier Payables & Payments

**Workbook:** `hav_seafood_finance_supplier_payables_payment_framework_v1.xlsx`  
**Reference:** `hav_seafood_finance_supplier_payables_payment_framework_v1.md`

Defines the Finance extension of Procurement supplier relationships and the Accounts Payable architecture.

Major structures include:

- Finance extensions for all **13 current suppliers**;
- Finance-owned supplier payment terms;
- AP profiles;
- invoice matching rules;
- tolerance and exception logic;
- invoice holds;
- payment eligibility;
- payment proposal architecture;
- settlement rules;
- prepayments;
- duplicate-invoice controls;
- AP accounting mappings.

Core model:

`Procurement Supplier / Purchase / Receipt → Supplier Invoice → AP Open Item → Payment Eligibility → Treasury Execution → Settlement`

Procurement remains authoritative for supplier identity, sourcing and commercial purchasing decisions. Finance owns invoice accounting, AP control and payment eligibility.

---

### 5. Inventory Costing & Manufacturing Accounting

**Workbook:** `hav_seafood_finance_inventory_costing_manufacturing_accounting_v1.xlsx`  
**Reference:** `hav_seafood_finance_inventory_costing_manufacturing_accounting_v1.md`

Defines how the existing Production and Procurement architecture is interpreted financially.

The workbook covers all **175 existing inventory/manufacturing items**:

- 13 seafood raw materials;
- 52 ingredients and processing materials;
- 68 packaging materials;
- 18 intermediate products;
- 24 finished-goods SKUs.

It also includes:

- valuation classes;
- costing methods and profiles;
- cost components;
- purchased and landed-cost rules;
- manufacturing costing profiles;
- BOM and routing costing rules;
- labor cost classes;
- costing structures for all **55 work centers**;
- overhead pools and allocation rules;
- yield, loss, scrap and by-product treatment;
- inventory and manufacturing posting rules;
- manufacturing variance types;
- standard-cost version/build architecture;
- COGS recognition;
- inventory impairment;
- Finance GL mappings.

Core boundary:

`Production / Procurement own physical item, BOM, routing, yield and sourcing facts.`

`Finance owns valuation, costing, variance, COGS and impairment treatment.`

No current inventory cost, actual production cost, COGS or variance history is contained here.

---

### 6. Fixed Assets & CapEx

**Workbook:** `hav_seafood_finance_fixed_assets_capex_framework_v1.xlsx`  
**Reference:** `hav_seafood_finance_fixed_assets_capex_framework_v1.md`

Defines Finance treatment of long-lived assets and investment governance.

It includes:

- **88 Finance asset references** linked one-to-one to existing Production equipment;
- fixed-asset classes;
- asset/source mappings;
- asset responsibility;
- capitalization policy;
- capitalizable cost types;
- repair-versus-capital rules;
- depreciation methods and profiles;
- component accounting rules;
- CapEx categories and project types;
- CapEx lifecycle/status architecture;
- CapEx cost categories;
- CIP rules;
- acquisition and capitalization requirements;
- disposal and impairment architecture;
- Maintenance-to-Finance bridge rules;
- fixed-asset posting rules.

Core boundary:

`Operational domains own physical asset identity and technical use.`

`Finance owns capitalization, financial asset classification, depreciation, impairment, disposal accounting and CapEx financial governance.`

No acquisition costs, accumulated depreciation, book values, actual CapEx spending or disposal history is included.

---

### 7. Treasury, Banking & Cash

**Workbook:** `hav_seafood_finance_treasury_banking_cash_framework_v1.xlsx`  
**Reference:** `hav_seafood_finance_treasury_banking_cash_framework_v1.md`

Defines HAV Seafood's banking, cash-routing, liquidity and Treasury control architecture.

It includes:

- the existing external bank identity `ORG-EXT-023 CoastLedger Bank`;
- **7 bank accounts**;
- DKK, EUR, SEK and NOK account/routing structures;
- payment methods and channels;
- payment-routing rules;
- receipt-routing rules;
- cash-position categories;
- liquidity horizons including a **13-week cash forecast** structure;
- cash-forecast categories and rules;
- liquidity-control rules;
- banking authority classes;
- dual-authorization controls;
- bank-detail change controls;
- bank-reconciliation architecture;
- Treasury exception routing;
- internal transfer and FX conversion rules;
- funding-facility taxonomy;
- bank-charge and Treasury GL mappings.

Important distinctions include:

`AP eligibility != payment proposal != payment != bank movement`

and:

`Bank balance != GL cash balance`

No balances, payments, receipts, bank transactions, reconciliations, FX trades or borrowing history are included.

---

### 8. Budgeting & Management Reporting

**Workbook:** `hav_seafood_finance_budget_management_reporting_v1.xlsx`  
**Reference:** `hav_seafood_finance_budget_management_reporting_v1.md`

Defines how HAV Seafood will plan, forecast, report and analyse financial performance.

It includes:

- **6 planning/budget types**;
- **5 planning scenarios**;
- budget responsibility for all **12 cost centers**;
- 24 budget-line types;
- **20 planning drivers**;
- driver-source ownership across Sales, HR, Production, Logistics, Finance and other domains;
- driver-based budget rules;
- revenue and profitability structures;
- **14 recurring management-report definitions**;
- report sections and drilldown rules;
- **48 KPI definitions**;
- KPI calculation rules;
- variance definitions and significance rules;
- management commentary requirements;
- reporting responsibilities and cadence;
- reporting-data source precedence;
- Budget-to-Management-Report bridges.

Core operating concept:

`ERP actuals + controlled planning workbooks + Power BI reporting`

This workbook defines how budgets and reports are structured. It contains no actual budget numbers, forecasts, KPI results, variances or management reports.

---

### 9. Administration, Records & Services

**Workbook:** `hav_seafood_administration_records_services_framework_v1.xlsx`  
**Reference:** `hav_seafood_administration_records_services_framework_v1.md`

Defines the common Administration support and records layer for the company.

It includes:

- 12 record categories;
- **46 controlled record types**;
- record ownership and lifecycle architecture;
- synthetic retention classes;
- confidentiality and business-access expectations;
- repository/source precedence;
- correspondence types and routing;
- generic administrative templates;
- recurring administrative obligations;
- **12 Administration service types**, covering all 12 departments;
- service-request types;
- travel administration;
- visitor/reception support;
- meeting administration;
- administrative register types;
- insurance administration;
- Administration responsibility mappings.

Central rule:

**Administration may coordinate, route, store or support a record without becoming the authoritative owner of its business content.**

Examples:

- Finance owns financial records;
- HR owns HR records;
- Procurement owns supplier commercial records;
- Sales owns customer commercial records;
- Quality owns controlled Quality records;
- Production owns production execution records;
- IT owns technical identity/access records.

Microsoft 365 (`ESYS-007`) is the primary general office/collaboration repository, but specialist systems retain authority for specialist records.

---

### 10. Finance Process, Authority & Internal Control

**Workbook:** `hav_seafood_finance_process_authority_internal_control_v1.xlsx`  
**Reference:** `hav_seafood_finance_process_authority_internal_control_v1.md`

This is the final governance layer across the Finance architecture.

It defines:

- **50 Finance processes**;
- **300 process steps**;
- Finance authority classes;
- position-based Finance authority;
- monetary approval levels;
- **12 synthetic DKK monetary threshold types**;
- process authority rules;
- specialist review rules;
- **48 internal controls**;
- control frequencies;
- control evidence requirements;
- **20 explicit segregation-of-duties rules**;
- Finance master-data governance;
- journal controls;
- period-close architecture;
- reconciliation architecture;
- Finance exception and escalation structures;
- controlled override rules;
- control-monitoring definitions;
- cross-domain authority bridges;
- system/control mappings.

This workbook is the authoritative Finance source for **company-wide financial monetary approval thresholds** and resolves authority gaps deliberately left in earlier Sales, Procurement, Treasury, CapEx and other architectures.

Important distinctions:

`Responsibility != Authority != Approval Event`

`Control != Control Execution`

`SoD Rule != SoD Violation`

`Exception Type != Exception Case`

`Override Rule != Override Event`

No actual approvals, control executions, reconciliations, overrides, audit findings or exception cases are included.

---

## Recommended reading order

For a complete understanding of the folder, read the architecture in this order:

1. `hav_seafood_finance_accounting_foundation_dimensions_v1.md`
2. `hav_seafood_finance_tax_currency_document_framework_v1.md`
3. `hav_seafood_finance_customer_credit_billing_receivables_v1.md`
4. `hav_seafood_finance_supplier_payables_payment_framework_v1.md`
5. `hav_seafood_finance_inventory_costing_manufacturing_accounting_v1.md`
6. `hav_seafood_finance_fixed_assets_capex_framework_v1.md`
7. `hav_seafood_finance_treasury_banking_cash_framework_v1.md`
8. `hav_seafood_finance_budget_management_reporting_v1.md`
9. `hav_seafood_administration_records_services_framework_v1.md`
10. `hav_seafood_finance_process_authority_internal_control_v1.md`

The Markdown files are intended to give humans and AI systems enough context to identify which workbook should be consulted before loading detailed spreadsheet content.

---

## Core Finance architecture relationships

At a high level, the Finance architecture connects as follows:

`Shared Enterprise / Sales / Procurement / HR / Production / Logistics`

`↓`

`Finance Accounting Foundation`

`↓`

`Financial Documents + AR + AP + Costing + Fixed Assets + Treasury`

`↓`

`Budgeting & Management Reporting`

`↓`

`Finance Process, Authority & Internal Control`

Administration operates alongside this flow as a cross-company support/custody layer rather than as a financial transaction system.

---

## Authoritative systems

The Finance & Administration architecture preserves the existing Shared Enterprise systems model.

Key systems include:

- `ESYS-001 Core ERP` — authoritative system for core Finance accounting, purchasing/sales financial transactions, inventory accounting and Finance master structures;
- `ESYS-005 People & Payroll` — authoritative HR/payroll operational source;
- `ESYS-007 Microsoft 365` — general office documents, collaboration and controlled Finance/Administration working files where no specialist system overrides it;
- `ESYS-009 Power BI` — analytical and management-reporting layer only;
- `ESYS-013 Online Banking Portal` — authoritative external banking execution and bank-movement source.

Operational systems such as MES, QMS, CMMS and CRM remain authoritative for their respective source-domain records.

A copy, export, spreadsheet or dashboard does not become authoritative merely because it contains replicated data.

---

## Cross-domain ownership principles

Finance extends other domains financially without redefining their master data.

### Sales

Sales owns:

- customer identity;
- commercial organization;
- pricing and agreements;
- sales demand;
- commercial order facts.

Finance owns:

- customer credit treatment;
- Finance payment terms;
- billing/accounting rules;
- receivables;
- settlement;
- financial write-offs and credit authority.

### Procurement

Procurement owns:

- supplier identity and sourcing;
- supplier-item relationships;
- purchasing/commercial conditions;
- procurement process facts.

Finance owns:

- supplier Finance extension;
- AP accounting;
- invoice-control treatment;
- payment eligibility;
- payment authority;
- supplier banking controls.

### Production / Logistics / Quality / Maintenance

Operational domains own:

- physical inventory;
- production activity;
- BOMs and routings;
- yields and losses;
- physical equipment;
- maintenance events;
- quality decisions;
- physical logistics events.

Finance owns:

- valuation;
- standard costing;
- COGS;
- manufacturing variances;
- inventory financial adjustments/write-offs;
- financial asset treatment;
- CapEx accounting.

### HR

HR owns:

- employee identity;
- positions and incumbency;
- employment terms;
- compensation structures;
- payroll source information.

Finance owns:

- payroll accounting;
- financial reconciliation;
- budget interpretation;
- Finance authority assignments to HR-owned positions.

---

## Phase boundary

These files are architecture, not operational datasets.

### Phase 1 — Architecture — current folder

Defines:

- entities;
- relationships;
- IDs;
- classifications;
- rules;
- ownership;
- authority;
- controls;
- standard structures;
- system boundaries.

### Phase 2 — Stories — future

Cross-functional business patterns will later be designed deliberately.

Potential Finance-related stories may involve themes such as:

- customer credit pressure;
- margin deterioration;
- supplier price changes;
- inventory write-downs;
- production cost variance;
- delayed collections;
- payment or reconciliation anomalies;
- CapEx decisions;
- liquidity pressure;
- budget variance;
- control exceptions.

These stories should be designed **after** the architecture is complete. The architecture itself should remain neutral and should not deliberately contain those anomalies.

### Phase 3 — Operational dataset — future

Operational data can later include realistic records such as:

- GL journals and balances;
- sales invoices and credit notes;
- AR open items and receipts;
- supplier invoices and AP items;
- payment proposals and bank payments;
- bank statements and reconciliations;
- inventory values and cost transactions;
- production variance records;
- fixed-asset acquisitions and depreciation;
- CapEx requests and spending;
- budgets and forecasts;
- management reports and KPI results;
- approval records;
- control evidence;
- exception and escalation cases;
- administrative correspondence and service records.

All operational records should reference the IDs, ownership rules and control structures established in Phase 1.

---

## Guidance for AI use

When using this folder as context for an AI task:

1. Start with this README to determine the relevant Finance area.
2. Read the companion `.md` for that workbook before loading the spreadsheet.
3. Load detailed workbook sheets only when the task requires their exact entities, IDs or rules.
4. Preserve existing authoritative IDs rather than generating substitutes.
5. Do not treat derived reporting copies as source-of-truth records.
6. Do not invent Phase 3 historical activity while working on Phase 1 architecture.
7. When generating future operational records, maintain all cross-domain ownership and authority boundaries documented here.

Useful routing examples:

- Chart of accounts / cost center / posting class → **Accounting Foundation**
- Tax / currency / financial document type → **Tax, Currency & Financial Documents**
- Customer credit / billing / AR → **Customer Credit, Billing & Receivables**
- Supplier invoice / AP / payment eligibility → **Supplier Payables & Payments**
- Inventory valuation / manufacturing cost / COGS → **Inventory Costing & Manufacturing Accounting**
- Asset / depreciation / CapEx → **Fixed Assets & CapEx**
- Bank accounts / payment routing / liquidity / reconciliation → **Treasury, Banking & Cash**
- Budget / forecast / KPI / management report → **Budgeting & Management Reporting**
- Records / correspondence / travel / visitor / office service → **Administration, Records & Services**
- Approval authority / monetary threshold / internal control / SoD / close → **Finance Process, Authority & Internal Control**

---

## Current architectural status

The Finance & Administration architecture is now structurally complete enough to support **Phase 2 story design** and, after stories are finalized, detailed Phase 3 operational-data generation.

The next Finance-related work should therefore generally focus on either:

- designing cross-functional stories that use these structures; or
- later defining the exhaustive operational datasets, logs, communications and document artifacts required to express those stories.
