# Customer Credit, Billing & Receivables Architecture

## Purpose

This workbook defines the static **Customer Credit, Billing & Receivables** architecture for HAV Seafood.

It belongs to **Phase 1 — Business Architecture** and contains no customer invoices, receivable balances, receipts, aging results, credit-check events, collection activity or other operational history.

The core model is:

`Sales Customer -> Finance Customer Account -> Credit + Payment Terms + Billing -> Future Invoice -> Future AR Open Item -> Future Settlement / Collection`

## Files

- `hav_seafood_finance_customer_credit_billing_receivables_v1.xlsx` — authoritative Finance architecture for customer credit, payment terms, billing, receivables and collections.
- `hav_seafood_finance_customer_credit_billing_receivables_v1.md` — compact AI/human reference.

## Current architecture at a glance

- **4 Finance customer-account extensions**, one for each existing Sales customer;
- **4 credit-risk classes**;
- **4 reusable credit profiles**;
- **4 current credit assignments**;
- **5 credit statuses**;
- **8 credit-check rules**;
- **8 credit-exposure component definitions**;
- **5 Finance-owned payment terms**;
- **4 current payment-term assignments**;
- **4 billing profiles**;
- **4 current billing assignments**;
- **6 billing-trigger rules**;
- **12 invoice source rules**;
- **12 billing requirements**;
- **3 revenue-recognition profiles**;
- **7 AR open-item statuses**;
- **7 settlement rules**;
- **7 payment-difference rules**;
- **6 aging buckets**;
- **3 collection profiles** and **6 collection stages**;
- **9 dispute categories**;
- **7 AR adjustment rules**;
- **10 AR accounting mappings**.

## Authoritative ownership boundaries

### Sales remains authoritative for

- `Customer_ID` and customer commercial identity;
- customer market/channel/segment/territory;
- customer pricing and price lists;
- commercial discounts, rebates, minimum-order and freight terms;
- customer agreements;
- sales orders and commercial references;
- customer-service commercial intake.

Finance does not redefine those concepts.

### Finance is authoritative here for

- Finance customer-account extensions;
- credit profiles, credit limits and Finance credit status;
- payment-term master and current customer assignments;
- billing profiles and Finance billing rules;
- AR status, settlement, aging and collection architecture;
- Finance interpretation of disputes and adjustments;
- AR accounting mappings.

### Logistics / Quality boundaries

Logistics owns shipment and delivery facts. A shipment or delivery may provide billing evidence but is **not** an invoice.

Quality owns technical complaint/quality conclusions. Finance applies an approved financial consequence but does not independently decide technical product quality.

## Current customer Finance setup

The workbook extends the existing four customers without issuing replacement customer identities:

- `CUS-001` Nordmark Food Distribution — SEK;
- `CUS-002` Fjord & Field Retail — NOK;
- `CUS-003` Baltic Pantry — EUR;
- `CUS-004` Northline Grocers — EUR.

Each has one current Finance customer account, credit assignment, Finance payment-term assignment and billing assignment.

The credit limits and payment terms are **synthetic current master-data assumptions** for HAV Seafood. They are not external credit data, legal terms or deliberately seeded story anomalies.

## Credit architecture

Important distinctions:

`Credit Limit != Credit Exposure`

`Credit Status != Credit Check Event`

`Credit Hold Rule != Credit Hold Event`

The workbook defines what contributes to future exposure, including open invoices, confirmed uninvoiced orders and dispatched/unbilled shipments, but stores no actual exposure values.

The Sales order architecture's `OHT-CREDIT` Finance/Credit Hold is preserved. Finance owns the release decision; Sales may consume the result but cannot redefine or override Finance authority.

## Payment terms

Finance now provides the authoritative payment-term master that Sales previously represented as `FUTURE-FINANCE-PAYMENT-TERM`.

Five reusable terms exist, including Net 14, Net 30, Net 45, Net 60 and Prepayment. Only the required current customer assignments are active.

Actual due dates are operational invoice attributes and are not stored here.

## Billing architecture

Billing deliberately preserves the object boundaries:

`Sales Order != Shipment != Delivery != Invoice`

For current architecture, distributor billing is normally based on dispatch/shipment completion evidence, while direct-retail billing is normally based on confirmed delivery evidence.

The detailed operational shipment/delivery object remains Logistics-owned.

Invoice value sources are mapped explicitly so future operational generation can resolve:

- customer from Sales;
- currency and price from Sales pricing plus Finance currency rules;
- SKU from Sales/Production;
- billable quantity from Logistics;
- tax from Finance;
- payment term from Finance;
- GL/accounting mapping from the Finance foundation.

## Revenue recognition boundary

The workbook contains restrained synthetic revenue-recognition profiles to connect commercial/fulfilment evidence to Finance accounting.

These are **internal synthetic accounting architecture**, not a researched IFRS, Faroese legal or statutory conclusion. Formal accounting-policy accuracy should be researched separately if required later.

## Receivables and settlement

The workbook defines future AR lifecycle concepts including:

- open and partially settled items;
- disputes and holds;
- exact-reference and manual settlement;
- partial settlement and overpayment;
- unapplied cash;
- FX settlement differences;
- write-off/adjustment categories.

No actual AR open items, balances, receipts or settlement records exist in Phase 1.

## Collections

Aging buckets and collection stages are reusable rule structures only.

No current customer is intentionally modeled as overdue, delinquent, restricted, on credit hold or uncollectible.

This preserves story neutrality for Phase 2.

## Dispute routing

Finance owns the receivable/open-item record, but the underlying reason may belong elsewhere:

- price/discount -> Sales;
- quantity/delivery -> Logistics;
- product quality -> Quality;
- tax/accounting -> Finance;
- freight -> Sales + Logistics;
- duplicate invoice/payment allocation -> Finance.

An AR dispute does not automatically prove the customer's claim or authorize a credit note.

## Systems

- `ESYS-001 Core ERP` — authoritative system for Finance customer extensions, credit master, payment terms, invoices, AR open items and settlement/accounting records;
- `ESYS-006 Sales CRM` — customer commercial relationship and customer-service intake;
- `ESYS-013 Online Banking Portal` — authoritative external source for actual bank movements;
- `ESYS-009 Power BI` — reporting copy only.

## Important conceptual boundaries

`Sales Customer != Finance Customer Account`

`Credit Limit != Credit Exposure`

`Sales Order != Invoice`

`Shipment != Invoice`

`Invoice != Settlement`

`Customer Receipt != Bank Movement`

`Dispute Category != Dispute Case`

`Aging Bucket != Aging Result`

`Collection Stage != Collection Event`

`Credit Note != Invoice Deletion`

`Write-Off Rule != Write-Off Event`

## Operational data intentionally excluded

This workbook contains no:

- credit checks or credit-review events;
- current credit exposure/utilization;
- order credit-hold events or releases;
- invoices or invoice lines;
- receivable balances or open items;
- aging results;
- receipts or bank movements;
- cash applications or settlements;
- payment differences;
- overdue events;
- reminders, collection calls or letters;
- disputes or dispute correspondence;
- credit notes, refunds or write-offs;
- revenue amounts;
- AR journal postings;
- approvals or workflow history.

Those belong to Phase 3 after business stories have been designed.

## Recommended AI navigation

- Customer Finance setup -> `Customer_Finance_Accounts`.
- Credit policy -> `Credit_Profiles` + `Credit_Check_Rules`.
- Current credit master -> `Customer_Credit_Assignments`.
- What counts toward exposure? -> `Credit_Exposure_Definition`.
- Payment terms -> `Payment_Terms` + `Customer_Payment_Terms`.
- How/when to invoice -> `Billing_Profiles` + `Billing_Trigger_Rules`.
- Where invoice fields come from -> `Invoice_Line_Source_Rules`.
- Required invoice information -> `Billing_Requirements`.
- Revenue accounting trigger -> `Revenue_Recognition_Profiles`.
- AR lifecycle -> `AR_Open_Item_Statuses` + `Settlement_Rules`.
- Overdue treatment -> `Aging_Buckets` + `Collection_Profiles` + `Collection_Stages`.
- Dispute ownership -> `Dispute_Categories`.
- Credit/refund/write-off logic -> `AR_Adjustment_Rules`.
- Accounting treatment -> `AR_Accounting_Mappings`.
- System/source precedence -> `System_Data_Ownership` + `Source_Mappings`.

## Overall role

Together, these sheets form HAV Seafood's static **customer financial-account, credit, billing and receivables control layer**.

They convert the existing Sales customer/commercial architecture into Finance-ready rules without creating operational accounting history and provide the stable foundation for later synthetic invoices, receivables, collections, settlements and cross-functional credit stories.
