# Supplier Payables & Payments Framework

## Purpose

This workbook defines the static **Supplier Payables & Payments architecture** for **HAV Seafood**.

It belongs to **Phase 1 — Business Architecture** of the synthetic business dataset project:

**1. Business architecture -> 2. Stories -> 3. Operational dataset**

The workbook defines how Procurement suppliers are extended into Finance, how supplier invoices are expected to be validated and matched, how payable items become eligible for payment, how payment proposals and payment lifecycle states are structured, and how payments/credits/prepayments later settle AP open items.

It contains **no operational supplier invoices, AP balances, payment proposals, payments, bank movements, holds, duplicate cases, settlements, disputes or approval history**.

---

## Core model

The principal architecture chain is:

`Procurement Supplier`

`-> Finance Supplier Account`

`-> Payment Term + AP Profile + Matching Profile`

`-> Future Supplier Invoice`

`-> Invoice Validation / Match`

`-> Future AP Open Item`

`-> Payment Eligibility`

`-> Payment Proposal`

`-> Approved Supplier Payment`

`-> External Bank Movement`

`-> AP Settlement`

Important boundaries are:

`Supplier != Finance Supplier Account`

`Purchase Order != Supplier Invoice`

`Goods Receipt != Supplier Invoice`

`Supplier Invoice != AP Open Item`

`AP Open Item != Payment Proposal`

`Payment Proposal != Supplier Payment`

`Supplier Payment != Bank Movement`

`Bank Movement != AP Settlement`

`Quality Restriction != AP Hold`

---

## Current architecture scope

The workbook contains:

- **13 current Supplier Finance Accounts**, one for each Procurement supplier;
- **6 Finance-owned supplier payment terms**, with the current Procurement assumptions reconciled into Finance;
- **5 reusable AP profiles**;
- **3 invoice-matching profiles**;
- **13 current supplier matching assignments**;
- **12 matching elements**;
- **8 static matching tolerance rules**;
- **14 invoice validation rules**;
- **12 AP hold types** and matching routing rules;
- **8 invoice accounting rules**;
- **13 AP accounting mappings** to the existing Finance chart of accounts;
- **7 AP open-item statuses**;
- **6 AP aging buckets**;
- **4 payment profiles** and **4 payment methods**;
- **13 current supplier payment assignments**;
- **10 payment-eligibility rules**;
- **9 payment-proposal rules**;
- **11 payment lifecycle statuses**;
- **8 settlement rules**;
- **6 payment-difference rules**;
- **4 supplier prepayment rules**;
- **5 duplicate-check rules**;
- cross-domain responsibility, system ownership, source mapping and relationship reference layers.

The current static supplier terms preserve the existing Procurement assumptions:

- the four Faroese seafood raw-material suppliers use **Net 14 Days**;
- the other ingredient, packaging and specialist-service suppliers use **Net 30 Days**.

These are synthetic internal HAV Seafood terms, not market or legal claims.

---

## Authoritative ownership

### Finance owns

- Finance Supplier Account extension;
- supplier payment-term master;
- AP processing profiles;
- invoice validation and financial matching rules;
- AP hold and release control;
- payable accounting;
- AP open-item architecture;
- payment eligibility and proposal rules;
- supplier payment accounting instruction;
- AP settlement rules;
- supplier prepayment financial treatment;
- duplicate supplier-invoice control design.

### Procurement / Shared Enterprise remain authoritative for

- supplier identity;
- supplier status and sourcing relationships;
- procurement categories;
- approved Supplier + Item relationships;
- purchase orders and purchasing commitments;
- commercial supplier relationship and sourcing evidence.

### Supply Chain / Logistics remain authoritative for

- physical goods receipt;
- received quantities;
- receiving evidence;
- physical receipt discrepancies.

### Quality remains authoritative for

- technical supplier restrictions;
- supplier/material quality evidence;
- technical acceptance/rejection decisions.

Finance may create an AP hold based on a Quality restriction, but does not replace the technical decision.

### HR remains authoritative for

- positions;
- incumbency;
- enterprise authority backbone.

This workbook references positions, not named employees.

### Treasury boundary

This workbook defines **what is eligible to be paid and the high-level payment method/process**.

The later Treasury & Banking architecture should remain authoritative for:

- bank-account masters;
- bank-account purpose and currency;
- liquidity routing;
- cash-position structures;
- bank authorization architecture;
- detailed bank-reconciliation architecture.

`ESYS-013 Online Banking Portal` is treated as the authoritative external source for actual bank movement, while `ESYS-001 Core ERP` remains authoritative for AP accounting and settlement.

---

## Matching architecture

### Physical stock suppliers

Seafood raw materials, ingredients, processing inputs and packaging use:

`Purchase Order + Goods Receipt + Supplier Invoice`

This is the `MATCH-3W-STOCK` three-way match profile.

### Service suppliers

Technical maintenance and calibration services use:

`Purchase Order + Supplier Invoice + Service Completion / Approval Evidence`

This is `MATCH-2W-SVC`.

A warehouse goods receipt is not artificially created for a service merely to make three-way matching possible.

### Non-PO invoices

`MATCH-NONPO-EXC` exists only as a controlled exception architecture. No current supplier is assigned to it as a normal default.

---

## Supplier invoice controls

The architecture separates:

- invoice validation;
- evidence matching;
- tolerance rules;
- AP holds;
- root-cause ownership;
- Finance hold/release authority.

Examples:

- a **price mismatch** is normally rooted in Procurement/commercial evidence;
- a **quantity/receipt mismatch** depends on Procurement and Logistics evidence;
- a **Quality restriction** remains technically owned by Quality;
- a **tax issue** is Finance-owned;
- a **duplicate invoice suspicion** is Finance-owned;
- a **bank/payment-routing change** requires independent Finance verification.

The quantitative matching tolerances are synthetic internal controls and should not be interpreted as external standards.

---

## Payment and settlement architecture

A future payable becomes eligible for payment only when static eligibility rules are satisfied, including:

- valid posted payable;
- required approvals complete;
- no unresolved blocking AP hold;
- supplier active;
- due/approved timing reached;
- verified payment instructions;
- valid currency/payment method;
- required service/technical evidence where applicable.

The normal payment lifecycle is:

`Proposed -> Reviewed -> Approved -> Released -> Submitted -> Bank Confirmed -> Settled`

with exception states for rejection, failure, cancellation and recalled/returned payments.

Creating a payment proposal never means that cash has moved.

---

## Systems

Key system roles are:

- `ESYS-001 Core ERP` — Supplier Finance Account, supplier invoice, matching status, AP open item, payment proposal, payment instruction and AP settlement system of record;
- `ESYS-003 Quality Management System` — technical supplier-quality evidence and restrictions;
- `ESYS-007 Microsoft 365` — controlled supporting commercial/agreement documents where applicable;
- `ESYS-013 Online Banking Portal` — authoritative external bank movement;
- `ESYS-009 Power BI` — reporting/analytics copy only.

A reporting copy does not become authoritative.

---

## Workbook sheets

The workbook contains the following architecture areas:

1. `Supplier_Finance_Accounts`
2. `Supplier_Payment_Terms`
3. `Supplier_Term_Assignments`
4. `AP_Profiles`
5. `Supplier_AP_Assignments`
6. `Invoice_Matching_Profiles`
7. `Supplier_Matching_Assignments`
8. `Matching_Elements`
9. `Matching_Tolerance_Rules`
10. `Invoice_Validation_Rules`
11. `AP_Hold_Types`
12. `AP_Hold_Routing`
13. `Invoice_Accounting_Rules`
14. `AP_Accounting_Mappings`
15. `AP_Adjustment_Rules`
16. `AP_Open_Item_Statuses`
17. `AP_Aging_Buckets`
18. `Payment_Profiles`
19. `Supplier_Payment_Assignments`
20. `Payment_Methods`
21. `Payment_Eligibility_Rules`
22. `Payment_Proposal_Rules`
23. `Payment_Status_Model`
24. `AP_Settlement_Rules`
25. `Payment_Difference_Rules`
26. `Supplier_Prepayment_Rules`
27. `Duplicate_Check_Rules`
28. `Responsibility_Mappings`
29. `System_Data_Ownership`
30. `Source_Mappings`
31. `Relationship_Catalog`
32. `Architecture_Notes`
33. `Control_Parameters`
34. `Data_Dictionary`

---

## Source precedence

The principal sources are:

- `hav_seafood_finance_accounting_foundation_dimensions_v1.xlsx` — GL accounts and posting classes;
- `hav_seafood_finance_tax_currency_document_framework_v1.xlsx` — document types, currency/tax framework and correction relationships;
- `hav_seafood_procurement_supplier_sourcing_architecture_v1.xlsx` — supplier and Supplier + Item sourcing structure;
- `hav_seafood_procurement_supplier_governance_commercial_framework_v1.xlsx` — supplier governance and commercial assumptions;
- `hav_seafood_supply_chain_inbound_logistics_receiving_v1.xlsx` — receiving evidence architecture;
- `hav_seafood_procurement_process_control_framework_v1.xlsx` — Procurement process, authority and control boundaries;
- `hav_seafood_hr_positions_workforce_establishment_v1.xlsx` — position identity;
- `hav_seafood_hr_process_approval_authority_v1.xlsx` — enterprise authority backbone.

If this workbook conflicts with the authoritative source for an upstream entity, the upstream source wins. Finance remains authoritative only for the Finance/AP structures created here.

---

## Phase 1 exclusions

This architecture deliberately contains no:

- purchase orders;
- goods receipts;
- supplier invoices or invoice lines;
- invoice attachments/PDFs;
- matching results;
- invoice discrepancies;
- actual AP holds;
- duplicate-invoice cases;
- AP balances;
- AP aging balances;
- payment proposals;
- payment runs;
- bank files;
- supplier payments;
- bank confirmations;
- supplier credit notes/refunds;
- supplier prepayment transactions;
- AP settlements;
- foreign-exchange settlement results;
- supplier disputes;
- statement reconciliations;
- approval events;
- workflow/audit logs.

Those belong to Phase 3 after Phase 2 stories are deliberately selected.

---

## Story neutrality

The workbook does not deliberately seed:

- duplicate or fraudulent invoices;
- price/quantity mismatches;
- payment delays;
- supplier disputes;
- control bypasses;
- missing POs;
- unapproved non-PO invoices;
- suspicious bank-detail changes;
- chronic AP holds;
- failed payments;
- liquidity problems;
- supplier complaints about payment;
- segregation-of-duties failures.

Those should be introduced only through Phase 2 story design and later operational dataset generation.

---

## Recommended AI navigation

- supplier Finance setup -> `Supplier_Finance_Accounts`
- Finance payment term -> `Supplier_Term_Assignments`
- supplier AP processing profile -> `Supplier_AP_Assignments`
- invoice match model -> `Supplier_Matching_Assignments`
- what is compared during matching? -> `Matching_Elements`
- allowed differences -> `Matching_Tolerance_Rules`
- supplier-invoice validation -> `Invoice_Validation_Rules`
- why can an invoice be held? -> `AP_Hold_Types`
- who owns the discrepancy? -> `AP_Hold_Routing`
- accounting treatment -> `Invoice_Accounting_Rules` + `AP_Accounting_Mappings`
- when may a payable be paid? -> `Payment_Eligibility_Rules`
- how is a proposal constructed? -> `Payment_Proposal_Rules`
- payment lifecycle -> `Payment_Status_Model`
- settlement logic -> `AP_Settlement_Rules`
- supplier prepayment -> `Supplier_Prepayment_Rules`
- duplicate checks -> `Duplicate_Check_Rules`
- system/domain ownership -> `System_Data_Ownership`
- authoritative sources -> `Source_Mappings`
- entity joins -> `Relationship_Catalog`

---

## Overall role

Together, the workbook and this Markdown reference form HAV Seafood's static **Supplier Payables & Payments master-data, invoice-control, payment-process and settlement architecture**.

They connect Procurement supplier and purchasing evidence to Finance supplier accounts, invoice validation, AP liabilities, payment eligibility, payment processing and later bank settlement without collapsing upstream Procurement/Logistics/Quality objects into Finance records or introducing Phase 3 operational history.
