💰 Finance & Accounting — Solution Response

Dynamics 365 Finance & Operations supports flexible, multi-level charts of accounts natively. For NordHav, we deploy the Norwegian Standard chart of accounts (NS 4102) as the foundation, implemented through the MainAccountEntity data entity.

The chart is configured as a shared chart of accounts named NS4102, loaded via DMF template 020 — GL Shared.json. It includes the full 4-digit account structure covering:

• Balance sheet accounts (1000–2999), including NordHav-specific extensions for biological assets (1200–1299)
• Revenue accounts (3000–3999) segmented by product type (fresh salmon, frozen, VAP)
• Cost accounts (4000–7999) covering COGS, personnel, operating costs, and extraordinary items
• Financial income/expense accounts (8000–8999)

NordHav has full flexibility to add, rename, and restructure accounts through the General Ledger → Chart of Accounts → Main Accounts form. Account categories ensure correct positioning on statutory financial statements. Approximately 600 main accounts are loaded in the baseline configuration, including custom extensions for aquaculture-specific accounts (WIP live fish, biological asset fair value adjustment, processing by-product revenue, etc.).

D365 Finance supports an unlimited number of financial dimensions attached to every GL transaction. For NordHav, we configure exactly 5 custom dimensions plus the main account, meeting and exceeding the requirement:

1. CostCenter — operational cost centers (e.g., Austevoll Processing, Smolt Facility Nord, HQ Admin)
2. Department — organizational departments (e.g., Finance, Sales, Production, Biology)
3. Project — project tracking for CAPEX, R&D, and special initiatives
4. FishGeneration — year-class / generation dimension tracking biological production costs across the lifecycle
5. Region — geographic regions (Vestland, Nordland, Trøndelag)

Dimensions are deployed via the DimensionAttributeEntity and DimensionAttributeActivationEntity in DMF template 020 — GL Shared. Dimension values are loaded via FinancialDimensionValueEntity with Norwegian and English translations. All dimensions are available on every journal line, purchase order, sales order, and production order for full cost traceability.

Dimension sets are configured for financial reporting (FRD), enabling reports by any combination of dimensions. The Financial Dimension Set configuration includes sets for: "All Dimensions", "Region + Department", "CostCenter + FishGeneration", and "Project Only".

The FishGeneration dimension is configured as a standard D365 financial dimension of type "Custom dimension". Each dimension value represents a distinct year class / generation batch — for example GEN-2024A (2024 spring release), GEN-2024B (2024 autumn release), GEN-2025A, etc.

This dimension is mandatory on all cost transactions related to biological production, enforced via account structure rules. When costs are posted — whether feed purchases, labor allocations, treatment costs, or overhead — the FishGeneration dimension must be supplied, creating a complete cost trail from smolt input through sea grow-out, harvest, processing, and final product sale.

The dimension integrates with D365's cost accounting and financial reporting modules. Generation P&L reports are produced by filtering the standard P&L report on the FishGeneration dimension. The AquaMonitor MDA (Model-Driven App) integration pushes generation identifiers to D365 via the OData API, ensuring consistency between the biological tracking system and financial accounting.

Dimension values are created at the start of each production cycle and are maintained through the General Ledger → Financial Dimensions → Financial Dimension Values form or via automated Power Automate flows from the AquaMonitor system.

D365 Finance provides native fiscal calendar functionality supporting any number of periods per year. For NordHav, the fiscal calendar is configured with:

• 12 regular periods (January through December) matching the calendar year
• 1 closing/adjustment period (Period 13) for year-end adjustments, audit entries, and statutory close entries
• Fiscal years pre-configured from 2024 through 2030 using the FiscalYearEntity and FiscalPeriodEntity data entities

Period status management is fully supported: each period can be independently set to Open, On Hold, or Permanently Closed. Module-level period control allows, for example, the GL to be closed while AP remains open for late invoices. The closing period (Period 13) is used exclusively for year-end adjustments, ensuring the regular periods remain clean for comparative reporting.

The fiscal calendar is deployed via DMF template 020 — GL Shared.json (Sequence 10) and linked to the NHA legal entity in template 025 — General Ledger.json (Sequence 10–20). Period management is handled through the General Ledger → Ledger Calendar workspace.

D365 Finance supports a comprehensive range of journal types out of the box. For NordHav, 8 journal names are configured in the LedgerJournalNameEntity, deployed via DMF template 025 — General Ledger.json:

1. NHA-GEN — General journal (manual entries, miscellaneous postings)
2. NHA-REC — Recurring journals (template-based entries that repeat monthly/quarterly)
3. NHA-REV — Reversing journals (auto-reverse on a specified date)
4. NHA-ACC — Accrual journals (linked to accrual schemes for automated deferral/recognition)
5. NHA-ALL — Allocation journals (cost distribution entries from allocation rules)
6. NHA-SYS — System-generated journals (automated postings from subledgers)
7. NHA-IMP — Import journals (entries imported from external systems: payroll, farming)
8. NHA-ADJ — Adjustment journals (year-end and period-close adjustments, requires approval workflow)

Each journal name is configured with: default offset account, voucher number sequence, approval workflow assignment, posting restrictions, and financial dimension default rules. The NHA-ADJ journal requires workflow approval before posting, ensuring audit control over adjustments.

D365 Finance includes native Ledger Allocation Rules that distribute costs across financial dimensions based on configurable allocation bases. For NordHav, three baseline allocation rules are configured:

1. HQ Overhead Allocation — distributes head office costs (account range 6000–6999, CostCenter = HQ) to farming regions based on harvest volume (tonnes). The allocation basis is updated quarterly from production data.
2. Admin Cost Allocation — allocates administrative department costs to operational cost centers based on headcount ratios.
3. Processing Overhead Allocation — distributes processing plant overhead across product lines based on production kg output.

Allocation rules are deployed via the LedgerAllocationRuleEntity, LedgerAllocationBasisRuleEntity, and related entities in DMF template 025 — General Ledger.json (Sequence 50–58). Each rule defines source accounts/dimensions, allocation basis (fixed percentage, proportional, or formula-based), and destination accounts/dimensions.

Allocations can be run manually or scheduled as batch jobs during period-end processing. Results are posted to the NHA-ALL journal with full audit trail linking each allocation entry to its source rule and basis calculation.

D365 Finance provides built-in ledger accrual schemes that support automated accrual and deferral processing. When a journal line is posted with an accrual scheme attached, the system automatically generates the deferral/recognition schedule and posts reversing entries on the configured dates.

For NordHav, accrual schemes are configured for:

• Prepaid insurance — annual insurance premiums deferred monthly over the policy period
• License fees — aquaculture license fees (konsesjonsavgift) recognized evenly across 12 months
• Maintenance contracts — annual service agreements spread across the contract period
• Subscription costs — software and service subscriptions recognized monthly

Each scheme defines: recognition period (monthly, quarterly), number of periods, and reversal posting behavior. Accrual entries are posted via the NHA-ACC journal with cross-references to the original transaction. The Ledger Accruals workspace provides a consolidated view of all open accrual positions and upcoming recognition entries, enabling the finance team to monitor and adjust schedules as needed.

D365 Finance includes a powerful Foreign Currency Revaluation process that automatically revalues open balances in foreign currencies and posts unrealized gains/losses. NordHav operates with NOK as the base (accounting) currency and maintains transactions in 6 additional currencies:

• EUR (Euro) — primary export currency
• USD (US Dollar) — international fish sales
• GBP (British Pound) — UK market
• JPY (Japanese Yen) — Japan market
• SEK (Swedish Krona) — Nordic transactions
• DKK (Danish Krone) — Nordic transactions

The revaluation process is run monthly (or as needed) from General Ledger → Periodic Tasks → Foreign Currency Revaluation. It processes: bank account balances, customer receivables (AR), vendor payables (AP), and any other GL accounts with foreign currency balances. Exchange rates are pulled from the European Central Bank (ECB) via D365's built-in exchange rate provider, loaded daily via automated import.

Realized and unrealized FX gains/losses are posted to dedicated GL accounts (8070 — Unrealized FX Gain, 8071 — Unrealized FX Loss, 8080 — Realized FX Gain, 8081 — Realized FX Loss), configured via Accounts for Automatic Transactions.

Although NordHav operates as a single legal entity, D365 Finance's financial reporting capabilities fully support consolidation-style reporting with elimination of internal transactions. This is achieved through:

1. Financial dimension-based reporting — the Region and CostCenter dimensions enable P&L and balance sheet views per region, division, or cost center. Financial Report Designer (FRD) reports are configured with dimension filters and sub-totals.
2. Elimination journals — internal transactions between cost centers/regions (e.g., fish transferred from farming to processing) can be identified and eliminated using journal entries tagged with specific financial reason codes.
3. Consolidation workspace — D365's consolidation feature can be used even within a single entity to produce "as-if" consolidated views that net out inter-regional balances.

For future corporate restructuring (e.g., if NordHav splits into separate legal entities for farming and processing), D365's multi-entity consolidation module is fully available. Intercompany accounting rules, elimination rules, and consolidation currencies can be configured at that time without re-implementation. This provides a clear upgrade path from the current single-entity structure.

D365 Finance & Operations provides a comprehensive, immutable audit trail for all transactions through multiple layered mechanisms:

1. Voucher trail — every GL posting creates a voucher with: posting date, user ID, source journal, transaction text, and complete debit/credit detail. Vouchers are sequentially numbered and cannot be deleted or modified after posting.
2. Database logging — enabled for all sensitive tables (GL transactions, journal headers/lines, ledger parameters). Captures: table name, field changed, old value, new value, user, timestamp, and session ID. Accessible via System Administration → Database Log.
3. User activity logging — D365 logs all form opens, record modifications, and report generations with user identity and timestamp.
4. Subledger journal drill-down — from any GL voucher, users can drill through to the originating subledger transaction (AP invoice, AR payment, inventory movement, etc.).

Audit logs are retained for the configured retention period (minimum 7 years for financial data per Norwegian Bokføringsloven). Logs are immutable — even system administrators cannot modify or delete audit records. This fully satisfies Norwegian auditing requirements and provides auditors with direct access to the trail through read-only inquiry forms.

D365 Finance includes the Financial Period Close workspace — a purpose-built tool for managing structured period-end and year-end closing processes. For NordHav, the workspace is configured with:

• Close schedule templates — monthly and annual close schedules defined with all required tasks in sequence
• Task checklists — each close task is defined with: description, responsible person/role, due date (relative to period end), dependent tasks, and required sign-off
• Status tracking — tasks progress through: Not Started → In Progress → Completed → Signed Off. The workspace dashboard shows overall close progress and overdue items.
• Sign-off capability — designated reviewers must approve completed tasks before the period can be formally closed. Electronic sign-off with timestamp and user identity.

Standard monthly close tasks include: subledger reconciliation, bank reconciliation, foreign currency revaluation, accrual processing, allocation processing, and trial balance review. Year-end tasks additionally include: depreciation verification, inventory valuation review, tax provision calculation, and statutory report generation. The workspace integrates with D365's notification framework to send email reminders for upcoming and overdue tasks.

D365 Finance provides extensive financial reporting through Financial Report Designer (FRD), also known as Management Reporter. For NordHav, the following standard report templates are pre-configured:

• Trial Balance — summary and detailed views, filterable by period, dimension, and posting layer
• Balance Sheet — statutory format per Norwegian standards, with comparative periods
• Profit & Loss Statement — by natural account and by function, with budget comparison columns
• Dimension analysis reports — P&L and balance by CostCenter, Department, Region, and FishGeneration
• Cash Flow Statement — indirect method, auto-populated from GL transactions

All FRD reports support full drill-down: click any amount to see underlying transactions, then drill further to the source document (invoice, payment, journal). Reports are generated in the Financial Reporting workspace and can be exported to Excel, PDF, or displayed in web format. Report trees enable hierarchical roll-up views (e.g., company → region → cost center). Scheduled generation delivers reports to email recipients automatically after period close.

For NordHav's current single-entity structure, intercompany-like postings between regions and cost centers are handled through financial dimension tagging on journal entries. When goods, services, or costs transfer between regions (e.g., fish from Region Nordland to Austevoll Processing), balanced entries are posted with both the sending and receiving Region/CostCenter dimensions.

D365's due-to/due-from accounting pattern is used: an internal receivable is posted on the sending region's dimension set, and an internal payable on the receiving region. These entries net to zero at the company level but provide complete regional P&L visibility. Elimination reports in FRD can automatically remove these internal transactions for consolidated reporting.

If NordHav restructures into separate legal entities in the future, D365's full intercompany module is available: intercompany trading agreements, automatic balancing entries across entities, and centralized elimination rules. No re-implementation would be required — the migration path from dimension-based tracking to full intercompany is well-defined.

D365 Finance provides multiple standard mechanisms for importing journal entries from external systems:

1. Data Management Framework (DMF) — the GeneralJournalEntity supports batch import of journal entries from CSV, XML, or Excel files. Files can be uploaded manually or loaded from Azure Blob Storage on a schedule.
2. OData/REST API — the LedgerJournalHeaders and LedgerJournalLines data entities expose full CRUD operations via REST API, enabling real-time integration from external systems.
3. Recurring integrations — D365's data management recurring integration feature can poll a designated Azure Blob container or SFTP location for new journal files and import them automatically.

For NordHav, the primary use cases are: (a) Payroll journal import from the Norwegian payroll ISV via automated SFTP → DMF pipeline; (b) Farming cost journals from AquaMonitor via Power Automate → OData API; and (c) Bank fee journals from the banking integration. The NHA-IMP journal name is designated for imported entries, with separate voucher number sequence for traceability. Import validation rules ensure dimensional completeness and account validity before posting.

D365 Finance & Operations includes a built-in Document Attachment framework available on virtually every transactional and master data record. For NordHav:

• Attachment capability on all GL journal entries, vouchers, AP invoices, AR invoices, purchase orders, and sales orders
• Supported file types: PDF, Word, Excel, images (JPEG, PNG), and any custom file type
• Storage: Documents are stored in Azure Blob Storage (integrated with D365's cloud infrastructure), ensuring high availability and no impact on database performance
• Access control: Attachments inherit the security permissions of their parent record — only users who can access the transaction can view its attachments

The attachment button is available directly on journal lines and voucher inquiries. Users can drag-and-drop files, capture images via the mobile app, or upload from their device. For OCR-processed AP invoices, the original PDF is automatically attached to the vendor invoice record. Attachments are fully searchable and included in the audit trail. This meets Norwegian requirements for supporting documentation (bilag) per Bokføringsloven §10.

D365 Finance's Vendor Master (VendVendorV2Entity) provides a comprehensive vendor record supporting all NordHav requirements:

• Identity: Name, short name, vendor group classification (8 groups configured: Feed Suppliers, Equipment, Services, Transport, Packaging, Pharmaceuticals, Government, Other)
• Addresses: Multiple addresses with purpose codes (business, invoice, delivery, remit-to)
• Bank details: Multiple bank accounts per vendor with IBAN, SWIFT/BIC, and Norwegian account number format
• Payment terms: Default payment terms and method of payment per vendor
• Currency: Default transaction currency (NOK, EUR, USD, etc.)
• Tax information: Organisasjonsnummer (org.nr), MVA registration number, withholding tax group where applicable
• Classification: Vendor group, procurement category, and default financial dimensions

Approximately 150 vendors are pre-loaded via DMF template 120 — Accounts Payable.json. The vendor master integrates with D365's global address book providing centralized party management. Norwegian-specific fields (org.nr, MVA nr) are stored in the tax registration framework.

D365 Finance supports EHF (Elektronisk Handelsformat) electronic invoicing through the Electronic Invoicing add-in (part of the D365 Globalization features). Configuration includes:

• PEPPOL BIS Billing 3.0 format configuration for both sending and receiving invoices
• Access Point integration via certified Norwegian PEPPOL Access Point provider (e.g., Basware, Pagero, or Nets/Nexi)
• Automated processing pipeline: incoming EHF invoices are parsed, validated against vendor master and PO data, and routed to the appropriate approval workflow
• Electronic Reporting (ER) format configurations for Norwegian EHF invoice/credit note generation

The solution uses D365's Electronic Reporting framework with pre-built Norwegian localization formats. Inbound EHF invoices are automatically matched to open purchase orders (three-way matching). The EHF payload includes all required Norwegian elements: KID number (payment reference), MVA details, and PEPPOL participant identifiers. This eliminates manual data entry for electronic invoices and ensures compliance with Norway's mandatory e-invoicing requirements for B2G and increasingly B2B transactions.

D365 Finance's Invoice Capture solution (powered by AI Builder) provides OCR and AI-based processing for PDF and paper invoices:

• Automated data extraction: vendor name, invoice number, invoice date, amount, currency, MVA, bank account, and line items are extracted using trained AI models
• Confidence scoring: each extracted field displays a confidence score; low-confidence fields are highlighted for manual review
• Vendor matching: the system automatically matches extracted vendor information to the D365 vendor master
• PO matching: extracted PO references are used to automatically link the invoice to purchase orders for three-way matching

Invoices can be submitted via: email inbox monitoring (dedicated AP email address), manual upload, or mobile capture via the D365 mobile app. The AI model continuously improves as users correct extraction errors. Processed invoices flow into the standard vendor invoice journal for approval workflow. For NordHav, this is particularly valuable for feed supplier invoices (often PDF-based) and service invoices from smaller local vendors who may not support EHF.

D365 Finance provides native three-way matching between Purchase Order, Product Receipt (Goods Receipt), and Vendor Invoice. The matching engine compares:

• Price matching: unit price on invoice vs. PO price, with configurable tolerance (e.g., ±2%)
• Quantity matching: invoiced quantity vs. received quantity, with tolerance threshold
• Total amount matching: invoice line total vs. PO line total

Matching policies are configured per vendor group and can be set to: No matching (trust vendor), Two-way (PO → Invoice), or Three-way (PO → Receipt → Invoice). For NordHav, the default policy is three-way matching with:

• Price tolerance: 2% for standard purchases, 5% for catch-weight/variable items (feed, packaging)
• Quantity tolerance: 5% to accommodate delivery variances in bulk materials
• Match discrepancy handling: invoices with out-of-tolerance discrepancies are routed to a dedicated approval workflow requiring operations manager sign-off

The matching results are visible on the Invoice Matching Details form, showing green/yellow/red status for each matching check. Discrepancy reports are available for procurement analytics.

D365 Finance includes a powerful workflow engine that supports configurable multi-level invoice approval. For NordHav, the vendor invoice approval workflow is configured with:

• Amount thresholds: invoices < 10,000 NOK auto-approved for budget holders; 10,000–100,000 NOK requires department manager; > 100,000 NOK requires finance controller; > 500,000 NOK requires CFO
• Cost center routing: invoices are automatically routed to the cost center owner based on the coding on the invoice line
• Category rules: specific procurement categories (e.g., CAPEX, consulting) always require additional approval regardless of amount
• Mobile approval: approvers can review and approve invoices via the D365 mobile app or Power Automate notifications with approve/reject links

The workflow supports delegation (out-of-office reassignment), escalation (automatic escalation after configurable SLA), parallel approvals, and conditional branching. All approval actions are logged with user, timestamp, and comments, creating a complete approval audit trail. Email notifications with invoice summary and attached PDF are sent at each workflow step.

D365 Finance supports recurring vendor invoices through invoice templates that automatically generate periodic entries. For NordHav, recurring invoice templates are configured for:

• Monthly office rent (all locations)
• Software license subscriptions (monthly/annual)
• Service contracts (maintenance, cleaning, security)
• Insurance premium installments

Each template defines: vendor, amounts, GL account coding (with full dimension string), frequency (monthly/quarterly/annually), and start/end dates. Templates are processed via the Accounts Payable → Periodic → Recurring Invoices batch job, which generates draft invoices for review before posting. Amounts can be fixed or variable (with manual adjustment before posting). The recurring invoice feature integrates with the approval workflow — generated invoices follow the same approval path as manually entered invoices.

D365 Finance natively supports vendor prepayments through the prepayment journal and prepayment invoice features:

• Prepayment creation: post advance payments to vendors using prepayment journal vouchers or prepayment purchase orders
• Balance tracking: open prepayment balances are tracked per vendor on the prepayment clearing account (separate from standard AP)
• Application: when the final vendor invoice is received, prepayments are automatically applied (or manually applied via settlement) to reduce the payable amount
• Aging: prepayment balances appear in vendor aging reports in a dedicated "Prepayment" aging bucket

For NordHav, prepayments are common for: equipment purchases with milestone payments (e.g., new processing line equipment), well-boat charters requiring upfront deposits, and annual license fee renewals. The prepayment process maintains full subledger to GL reconciliation, with the clearing account providing transparent tracking of unapplied advances.

D365 Finance's Vendor Payment Proposal generates payment batches based on configurable criteria:

• Due date selection: pay all invoices due by a specified date, with options for early payment to capture cash discounts
• Payment terms: filter by payment terms group to separate domestic and international payments
• Cash discount optimization: automatically selects invoices where cash discount savings exceed the cost of early payment
• Priority-based: critical vendors (e.g., feed suppliers) can be prioritized for payment runs
• Currency grouping: separate payment runs by currency (NOK domestic, EUR/USD international)

After generation, the payment proposal is presented as an editable list where the AP team can: add/remove invoices, adjust payment amounts, change payment dates, or split payments. The approved proposal then generates the payment journal lines ready for bank file creation. Payment journals support multiple methods of payment (bank transfer, check) per vendor. The payment proposal workspace provides a consolidated dashboard view of upcoming payment obligations.

D365 Finance supports Norwegian and international payment formats through the Electronic Reporting (ER) framework:

• ISO 20022 pain.001.001.03 (Norwegian profile) — the primary domestic payment format for Norwegian bank transfers, configured with Norwegian-specific rules for KID (customer identification) and payment type codes
• SEPA Credit Transfer — for EUR-denominated payments within the European Economic Area
• SWIFT MT101/103 — for international payments outside SEPA (USD, GBP, JPY)

Payment format configurations are maintained as ER format definitions in D365's Globalization Studio. Norwegian payment-specific fields (KID number, payment type code, bank registration number) are populated from the vendor master and invoice records. The formats are regularly updated by Microsoft as part of the D365 localization package for Norway. Each payment method of payment in D365 is linked to the appropriate export format, ensuring the correct file type is generated based on the payment currency and destination.

D365 Finance generates payment files for direct upload to NordHav's banking partners:

• DNB: ISO 20022 pain.001 format (DNB accepts the Norwegian ISO 20022 profile). Files are uploaded to DNB's corporate banking portal (DNB Regnskap / DNB Online Banking) or transmitted via host-to-host connection.
• Nordea: ISO 20022 pain.001 format. Files uploaded to Nordea Corporate Netbank or Nordea Connect.
• AutoPay/AvtaleGiro: D365's ER framework can be configured to generate the standard Norwegian AutoPay format for recurring payment collections (used primarily for AR, but available for AP standing orders).

The bank file generation process is: Payment Proposal → Payment Journal → Generate Payment File. Files are validated against the bank's format requirements before generation. A payment status tracker updates the journal when payments are confirmed by the bank (via return file processing). The Bank Payment File Validation feature checks for: duplicate payments, IBAN validity, amount limits, and currency consistency before generating the file.

D365 Finance automatically generates and sends remittance advice documents to vendors when payments are processed. Configuration includes:

• Email distribution: remittance advice sent as PDF attachment to the vendor's designated email address (from vendor master)
• Content: payment amount, payment date, bank reference, and detailed list of invoices settled by the payment
• Format: D365 SSRS report configured with NordHav branding and Norwegian/English bilingual text
• Trigger: automatically generated when the payment journal is posted, or sent as a batch after the payment file is generated

The remittance advice print management is configured per vendor or vendor group — high-volume vendors receive consolidated remittance advice, while smaller vendors receive individual notices per payment. EDI-based remittance (EDIFACT REMADV) can also be configured for vendors who support electronic remittance processing.

D365 Finance provides a standard Vendor Aging Report accessible from Accounts Payable → Inquiries and Reports → Vendor Aging. For NordHav, the report is configured with:

• Aging period definitions: Current, 1–30 days, 31–60 days, 61–90 days, 90+ days overdue
• Aging basis: by due date (default), transaction date, or document date
• Drill-down: click any aging bucket amount to see individual invoices, then drill to the invoice document
• Filtering: by vendor group, currency, payment terms, and financial dimensions

The report can be generated as at any date (not just current date), enabling retrospective aging for period-end close. Export to Excel is supported for further analysis. A snapshot aging report can be saved for audit documentation. The vendor aging data is also exposed via OData for Power BI dashboards showing trend analysis of payables aging over time.

D365 Finance supports vendor statement reconciliation through several standard features:

• Vendor Transaction Inquiry: view all posted transactions for a vendor with filtering, sorting, and balance calculation — provides the internal view to compare against the vendor's statement
• Open Transactions: dedicated view of unsettled (open) vendor invoices and payments, enabling identification of discrepancies
• Settlement reversal: if a payment was incorrectly settled, the settlement can be reversed to correct the matching
• Reconciliation report: Vendor Balance List report shows opening balance, period transactions, and closing balance per vendor — format matches typical vendor statement layout

For systematic reconciliation, the AP team uses the vendor transaction list filtered by the statement period. Any differences between the vendor's statement and D365 records are investigated and corrected (missing invoices, duplicate payments, timing differences). The process is typically performed monthly for major vendors (top 20 by spend) and quarterly for others.

D365 Finance supports withholding tax calculation and reporting. For NordHav, this is configured for payments to foreign vendors where Norwegian kildeskatt applies:

• Withholding tax groups configured per vendor based on tax treaty status and payment type
• Automatic calculation: withholding tax is deducted from the payment amount and posted to a withholding tax payable account
• Reporting: withholding tax transaction report provides the data needed for annual reporting to Skatteetaten
• Tax treaty rates: configurable rates per country, reflecting Norway's double taxation agreements

As NordHav's primary vendors are Norwegian domestic suppliers, withholding tax applies only to a limited set of foreign service providers (consulting, international logistics, potentially some equipment vendors). The feature is configured but activated only for vendors flagged with the appropriate withholding tax group.

A full-featured vendor self-service portal is identified as Gap G-11 and is scheduled for post go-live implementation (Q3 2028). The solution approach uses:

• D365 Vendor Collaboration — D365's built-in vendor collaboration workspace provides external vendor access to: view PO status, confirm/reject POs, respond to RFQs, and submit invoices. This is available as standard functionality and can be enabled immediately.
• Microsoft Power Pages — for an enhanced, branded self-service portal experience with: order tracking dashboards, payment status inquiries, document downloads, and bank detail update forms. Integrated via Dataverse virtual entities connecting to D365 data.
• Microsoft Entra External ID (B2C) — secure external user authentication for vendor portal users

For Phase 1 go-live, vendors can use the D365 Vendor Collaboration workspace (accessed via browser with Entra B2C authentication). The full Power Pages portal with enhanced UX and self-service bank detail management is planned for post go-live. This is a Desirable (D) priority requirement and does not impact critical operations.

D365 Finance's Customer Master (CustomersV3Entity) provides a comprehensive customer record. For NordHav, ~350 customers are pre-loaded via DMF with:

• Identity: Name, customer group (7 groups: Retail Domestic, Retail Export, Foodservice, Industrial, Direct Consumer, Intercompany, Other)
• Addresses: Multiple delivery addresses per customer (headquarters, distribution centers, stores) with Incoterms default per delivery address
• Invoicing: Separate invoice address, payment terms, method of payment, and currency defaults
• Contact persons: Multiple contacts per customer (buyer, logistics, finance, quality)
• Credit management: Credit limit, credit rating, payment history score, and credit hold status
• Sales region: Mapped to NordHav's market regions (Domestic NO, Nordics, EU, UK, Asia, Americas)

Customer records integrate with D365's global address book. The customer master feeds sales order processing, invoicing, credit management, and reporting. Customer-specific pricing and Incoterms defaults are inherited automatically on new sales orders.

D365 Finance supports multi-currency invoicing natively. Customer invoices are generated in the customer's default currency (or overridden per order). For NordHav:

• 7 transaction currencies: NOK, EUR, USD, GBP, JPY, SEK, DKK
• Exchange rates: loaded daily from the European Central Bank (ECB) via D365's built-in exchange rate provider
• Invoice generation: invoices display amounts in the transaction (customer) currency with the exchange rate shown. GL posting occurs in both transaction currency and accounting currency (NOK)
• Dual currency display: optionally show both the customer's currency and NOK equivalent on invoice documents

Exchange rate types are configured for: spot rate (daily transactions), monthly average (reporting), and budget rate (planning). Invoices, credit notes, and payments all support multi-currency. Any exchange differences at payment settlement are automatically posted to the configured FX gain/loss accounts. Customers can pay in any currency — the system handles cross-currency settlement and exchange difference calculations.

D365 Finance supports EDI invoice transmission through the Electronic Reporting (ER) framework:

• PEPPOL BIS Billing 3.0 — for customers on the PEPPOL network (increasingly standard across European retail)
• EDIFACT INVOIC D.96A — for major retail customers using traditional EDI (e.g., Nordic retail chains)
• Customer-specific formats — ER format configurations can be customized per customer where needed

EDI integration is handled via a certified PEPPOL Access Point provider and/or EDI Value-Added Network (VAN). D365 generates the invoice message in the correct format, digitally signs it if required, and transmits via the configured channel. Customer-specific article numbers, GLN codes, and delivery note references are mapped from the sales order data. The EDI process is fully automated: when a sales invoice is posted in D365, the electronic version is generated and transmitted without manual intervention.

D365 Finance provides comprehensive credit note (credit memo) management:

• Reason codes: configurable credit note reason codes (quality issue, pricing error, delivery shortage, return, commercial goodwill)
• Original invoice link: credit notes reference the original sales invoice, creating a clear audit trail
• Automatic reversals: revenue, COGS, and inventory transactions are automatically reversed based on the original invoice posting
• Approval workflow: D365 workflow routes credit notes for approval based on amount and reason code before posting
• Return order integration: for physical product returns, the credit note is linked to a return order with item receipt processing

For NordHav's seafood operations, credit notes commonly arise from: weight discrepancies (delivered weight vs. invoiced weight), quality downgrades identified by the customer, and temperature excursion claims. The reason code provides data for claims trend analysis and supplier/production quality feedback. Credit notes follow the same journal posting and dimension coding as the original invoice.

D365 Supply Chain Management's catch-weight functionality is a core feature designed specifically for industries where product weight varies per unit — exactly NordHav's situation with fresh fish:

• Dual unit of measure: products are tracked in both a nominal unit (cases, pallets) and an actual weight unit (kg). Inventory, pricing, and invoicing can use either or both.
• Weight capture: actual weights are captured at packing/dispatch from in-line scales and recorded per case/pallet via barcode scanning
• Weight-based pricing: invoices calculate amounts based on actual delivered weight (not nominal/estimated weight)
• Weight tolerance: configurable tolerance between ordered weight and delivered weight, with workflow alerts for out-of-tolerance deliveries

For NordHav, this handles the core fresh fish business model: a customer orders 5,000 kg of HOG salmon, the order is packed as ~250 cases at ~20 kg each, but actual total weight may be 5,023.7 kg. The invoice is generated for 5,023.7 kg at the agreed price per kg. The catch-weight framework ensures accurate revenue recognition, inventory valuation, and COGS calculation. This is D365's standard functionality, not a customization — it's used extensively across food manufacturing and seafood industries.

D365 Finance includes a dedicated Credit and Collections module with automated credit management:

• Credit limits: defined per customer in the customer master, with optional insurance-backed limits
• Automatic checking: at sales order confirmation, D365 checks the customer's total outstanding balance (posted + unposted orders) against their credit limit
• Order hold: if the credit limit is exceeded, the sales order is automatically placed on credit hold with a blocking code
• Release authorization: designated users (Credit Manager role) can review held orders and: increase the credit limit, apply a temporary override, or reject the order
• Credit scoring: automated credit risk scoring based on payment behavior history (average days to pay, dispute frequency)

The Credit and Collections workspace provides a real-time dashboard showing: customers over credit limit, aged balances, recent payment activity, and orders on credit hold. The credit check integrates seamlessly with the sales order workflow — sales representatives are notified immediately if their customer is on hold, and can escalate to the credit team for review. For export customers paying via letter of credit or prepayment, the credit limit rules are configured differently (higher limits or exemptions).

D365 Finance provides both customer aging reports and automated dunning (collection letter) management:

Aging Reports:

• Standard aging report with configurable buckets (Current, 1–30, 31–60, 61–90, 90+ days)
• Drill-down from aging amounts to individual invoices and source documents
• Filtering by customer group, salesperson, region, and currency
• Export to Excel and Power BI for trend analysis

Dunning/Collection Letters:

• Collection letter sequences configured with escalating severity: Reminder (friendly), 1st Collection Letter (formal), 2nd Collection Letter (urgent), Final Notice (legal warning)
• Automated generation: batch process identifies overdue invoices and generates appropriate collection letters based on aging
• Distribution: letters are emailed automatically (with PDF attachment) or printed for mailing
• Interest calculation: optional interest notes for overdue balances per agreed terms
• Activity tracking: all collection activities logged in the customer record for history and follow-up

Non-recourse factoring (receivables sale) integration is identified as Gap G-12, scheduled for post go-live (Q2 2028). The solution approach:

• Architecture: Azure Logic Apps integration between D365 and the factoring company's API. When invoices are assigned to the factor, a Logic App creates: (a) a payment-like settlement on the original invoice, (b) a factoring receivable posting, and (c) records the factoring fee as a financial expense.
• Tracking: factored invoices are tagged with a custom financial dimension or document reference for identification in reports
• Reporting: Power BI dashboard showing: factored volume, outstanding factored receivables, factoring fees, and effective cost of factoring vs. carrying the receivable

For Phase 1, factoring transactions are managed via manual journal entries in D365 (low volume — estimated 10–20 invoices/month factored). The automated integration is scoped for post go-live once the factoring partner's API specifications are confirmed.

D365 Supply Chain Management's Rebate Management module provides comprehensive rebate processing:

• Rebate programs: defined per customer or customer group with: target metrics (kg, NOK revenue), tier thresholds, rebate percentages or fixed amounts per tier, and program period (quarterly, annual)
• Automatic accrual: as sales orders are invoiced, D365 calculates the rebate obligation in real-time and posts accruals to the rebate provision account
• Multiple criteria: rebates can be based on volume (kg), revenue, product mix, or combinations thereof
• Settlement: at the end of each rebate period, the system generates a settlement calculation, creates credit notes for the rebate amount, and reverses accruals
• Reporting: real-time visibility of estimated rebate obligations by customer, program, and remaining volume to next tier

For NordHav, rebate programs are primarily used for: large retail customer annual volume incentives, loyalty rebates for long-term contract customers, and product-mix bonuses encouraging VAP product purchases. The rebate management workspace provides the sales and finance teams with current accrual positions and forecasted rebate payouts.

Customer claims management is implemented through a combination of D365 features:

• Case Management — D365's built-in case management module handles claim registration with: case type (quality, delivery, commercial), severity, linked customer and product, description, and supporting evidence (photos, lab reports attached via document management)
• Quality Order NCR — claims related to product quality are linked to Non-Conformance Reports (NCR) in D365 Quality Management, triggering investigation workflows
• Investigation workflow — each claim follows a structured workflow: Registration → Investigation (root cause analysis) → Resolution (corrective action) → Credit note issuance (if applicable) → Closure
• Trend reporting — claims data is exposed to Power BI for trend analysis by: claim type, product, customer, production batch, cause category, and period

The claims process feeds back into production quality control: recurring claims for a specific product or batch trigger quality investigations. Claim costs (credit notes, logistics cost of returns, investigation time) are tracked for total cost of quality analysis. Claims data is also linked to vendor quality scoring when the root cause is traced to incoming material quality.

Revenue per kg analysis is implemented primarily through Power BI analytics connected to D365 Finance data:

• Data source: D365 sales invoice lines provide: revenue amount, invoiced weight (kg), product, customer, market region, quality grade, and financial dimensions. This data flows to Power BI via the D365 data lake (Azure Synapse Link) or OData feeds.
• Analysis dimensions: Revenue per kg is calculated and reported by: product type (HOG, fillet, VAP), customer, market/region, species, quality grade (Superior/Ordinary/Production), and sales channel (contract vs. spot)
• Benchmarking: actual revenue per kg is compared against: Fish Pool index price, budget price, and historical trend
• Period analysis: daily, weekly, monthly, and rolling 12-month views

Additionally, D365's standard Sales Statistics reports and FRD reports can display revenue per kg where invoiced weight is captured via the catch-weight framework. The Power BI reports provide the richer interactive experience with drill-down, filtering, and trend visualization that NordHav's commercial team requires for daily price realization analysis and market strategy decisions.

D365 Finance's Fixed Assets module provides complete asset lifecycle management. For NordHav, ~1,200 assets are configured across 13 asset groups covering all operational areas (aquaculture equipment, processing machinery, buildings, vehicles, IT equipment).

• Acquisition: assets acquired via purchase order (auto-capitalize), manual journal, or CAPEX project capitalization
• Transfer: change asset location, department, or responsible person with full audit trail
• Split/Merge: split one asset into multiple (e.g., upgrading a component) or merge assets
• Revaluation: upward/downward revaluation with posting to revaluation reserve
• Impairment: record impairment losses per IAS 36 with journal entries
• Write-off: partial or full write-off for damaged/obsolete assets
• Disposal: sale or scrap with automatic gain/loss calculation and posting

The Asset Maintenance workspace links each asset's financial record to its operational maintenance history (via D365 Asset Management), providing a complete picture of asset cost vs. uptime and performance.

D365 Fixed Assets supports Norwegian tax depreciation rules through declining-balance (saldo) depreciation methods. For NordHav, the tax depreciation book is configured with the following saldogrupper:

• Gruppe a (30%): Office equipment, IT hardware
• Gruppe b (20%): Acquired goodwill
• Gruppe c (20%): Trucks, vans, work vehicles
• Gruppe d (20%): Passenger vehicles, machinery, equipment
• Gruppe e (10%): Vessels, barges, processing line equipment
• Gruppe f (7%): Aircraft (not applicable for NordHav)
• Gruppe g (5%): Net pens, mooring systems (aquaculture-specific)
• Gruppe h (4%): Buildings and permanent structures
• Gruppe i (2%): Commercial buildings for rent (not applicable)
• Gruppe j (10%): Technical/industrial buildings

Each saldogruppe is configured as a D365 depreciation group with the declining-balance method at the prescribed rate. Assets are assigned to groups based on their classification. Annual tax depreciation calculations are run as a batch job, producing the schedules needed for the corporate tax return (Skattemelding). The difference between accounting and tax depreciation is tracked automatically for deferred tax calculation.

D365 Fixed Assets supports multiple depreciation books per asset, enabling parallel accounting and tax depreciation. For NordHav, 4 value models are configured:

1. Accounting (NGAAP) — straight-line depreciation for financial reporting, Norwegian GAAP compliant
2. Tax (SALDO) — Norwegian declining-balance depreciation per saldogrupper for tax reporting
3. IFRS — depreciation per IFRS requirements (for potential future IFRS adoption or comparative reporting)
4. Insurance — replacement values for insurance purposes (no depreciation, revalued annually)

Each book runs independently: the accounting book posts to the GL financial reporting layer, the tax book posts to the tax layer (or generates reports only), and the insurance book stores values without GL posting. Depreciation methods in the accounting book include: straight-line (default), declining balance, and units of production (used for vessel hours and processing line productive hours). The system automatically tracks and reports the difference between accounting and tax depreciation for deferred tax liability calculation.

D365 Fixed Assets provides multi-dimensional asset classification through:

• Fixed asset groups (13 configured): Processing Equipment, Aquaculture Equipment, Vessels & Barges, Net Pens & Moorings, Buildings, Vehicles, IT & Office Equipment, Smolt Facility Equipment, Feed Systems, Laboratory Equipment, Cold Storage Equipment, Safety & Environmental, Software & Licenses
• Location: physical location of the asset (mapped to D365 sites: Austevoll, Smolt Nord, Smolt Vest, etc.)
• Financial dimensions: each asset carries Department, CostCenter, and Region dimensions for cost allocation and reporting
• Operational area: custom classification field for: Farming, Processing, VAP, Administration, Support

These classifications enable asset reporting by any combination of group, location, department, and operational area. The fixed asset inquiry and reports support filtering on all classification fields, providing views such as "all processing equipment at Austevoll" or "total asset value for the Nordland region".

The Insurance value model (the 4th depreciation book) in D365 Fixed Assets maintains insurance replacement values:

• Replacement values stored per asset, separate from accounting and tax book values
• Annual update: insurance values are updated annually (typically as part of the insurance renewal process) via mass update tools or individual asset adjustment
• No depreciation: the insurance book does not calculate depreciation — it stores the estimated replacement cost of the asset
• Insurance reporting: reports showing total insured values by asset group, location, and building — used for insurance policy discussions and premium calculations

The insurance book enables NordHav to provide their insurance company with accurate, up-to-date replacement values for all assets. The report can be filtered to show: building insurance values, machinery insurance values, and marine equipment insurance values separately, matching typical insurance policy structures.

D365 Project Operations provides full capital project management:

• Project budgeting: define CAPEX budgets by cost category (materials, labor, services, contingency) with approval workflow
• Commitment tracking: purchase requisitions and POs against the project create committed costs, visible in the project budget vs. actual view
• Cost collection: all project costs (POs, time entries, expense claims, internal allocations) are collected against the project with WBS (Work Breakdown Structure) tracking
• Construction-in-Progress (CIP): costs accumulate on CIP accounts during the project execution phase
• Capitalization: upon project completion, accumulated CIP costs are transferred to a new fixed asset via the Fixed Asset Estimate → Elimination process, creating the asset with the correct total cost

For NordHav, CAPEX projects include: new net pen installations, processing line upgrades, smolt facility expansion, vessel acquisitions, and cold storage construction. Each project is tracked with full budget vs. actual visibility, providing the finance team and project owners with real-time cost forecasting. Project approval workflows ensure CAPEX spend stays within authorized limits.

D365 Asset Management is fully integrated with D365 Fixed Assets, providing the link between financial asset records and operational maintenance management:

• Asset linkage: every functional location and maintenance asset in Asset Management is linked to its corresponding Fixed Asset record in Finance
• Maintenance cost tracking: work order costs (labor, spare parts, external services) are posted to the GL with the asset's financial dimensions, enabling total cost of ownership reporting
• Maintenance history: accessible from both the Fixed Asset form and the Asset Management workspace — complete history of corrective and preventive maintenance actions
• Remaining useful life: maintenance insights (frequency of repairs, condition assessments) inform decisions about remaining useful life adjustments in the accounting depreciation book

This integration means the finance team can see maintenance costs alongside depreciation costs for any asset, and the maintenance team can see the asset's book value and depreciation schedule. Combined, this supports optimal asset replacement timing decisions based on total cost of ownership analysis.

D365 Finance includes the Asset Leasing module, which handles lease accounting per IFRS 16 and the Norwegian NRS 14 equivalent:

• Right-of-use (ROU) assets: automatically calculated upon lease commencement based on lease payments, discount rate, and lease term
• Lease liabilities: present value of future lease payments recognized as a financial liability
• Interest expense: monthly calculation of interest on the lease liability using the incremental borrowing rate
• ROU depreciation: straight-line depreciation of the right-of-use asset over the lease term
• Remeasurement: support for lease modifications (term extension, payment changes) with recalculation

For NordHav, Asset Leasing is configured for: office space leases (Austevoll HQ, Bergen sales office), vehicle fleet leases (service boats, company cars), and equipment operating leases. Each lease record contains: commencement date, lease payments, payment frequency, lease term, and discount rate. The module automates the monthly journal entries for depreciation and interest, and generates the IFRS 16 disclosure notes. Norwegian GAAP (NRS 14) treatment is available as an alternative posting layer.

D365 Fixed Assets supports asset tagging and physical verification:

• Asset ID / barcode: every fixed asset has a unique identifier that can be encoded as a barcode or QR code label. Labels are generated from D365 using standard label printing features.
• Physical counting: D365's Warehouse Management mobile app (or a custom Power Apps canvas app) can scan asset barcode labels to record physical presence and condition during asset inventories
• Verification workflow: physical count results are compared to the asset register, with discrepancies flagged for investigation (missing assets, unregistered assets, location mismatches)

For NordHav, asset verification is particularly important for dispersed marine assets (net pens, moorings, feed barges) and processing equipment. Annual physical asset inventories are supported with a scan-and-verify process that reconciles the physical count against the D365 asset register. QR code labels are recommended for marine environment durability. This is standard D365 functionality extended with the mobile app for field scanning.

D365 Finance's Cash and Bank Management module provides complete multi-currency bank account management. For NordHav, 5 bank accounts are configured:

1. DNB — NOK Operating Account (primary domestic account for AP/AR)
2. DNB — EUR Account (Euro-denominated for EU customer receipts and payments)
3. DNB — USD Account (US Dollar for international trade)
4. Nordea — NOK Payroll Account (dedicated for salary payments)
5. Nordea — GBP Account (British Pound for UK market transactions)

Each bank account is linked to: the bank's BIC/SWIFT code, IBAN, and method of payment configuration. Real-time balance visibility is achieved through bank statement import (camt.053/054) processed daily. The Cash Overview workspace provides a consolidated dashboard showing current balances across all accounts and currencies, with conversion to NOK at current exchange rates. Bank transaction types are configured to map imported statement lines to appropriate GL accounts automatically.

D365 Finance provides advanced bank reconciliation with automated matching:

• Statement import: bank statements are imported in ISO 20022 camt.053 (end-of-day statement) and camt.054 (intraday notification) format — the standard formats used by DNB and Nordea
• Automated matching: configurable matching rules automatically match bank statement lines to D365 transactions based on: amount, date, payment reference (KID), and transaction text
• Manual matching: unmatched items are presented in a reconciliation worksheet for manual matching or journal entry creation
• One-to-many / many-to-one: the matching engine supports complex scenarios (one bank entry matching multiple D365 transactions, or vice versa)

For NordHav, bank reconciliation is run daily for the NOK operating account and weekly for foreign currency accounts. The matching rules achieve ~85-90% automated match rates. Remaining items (bank fees, FX differences, unidentified receipts) are resolved in the reconciliation worksheet by the treasury team. The reconciled statement provides a clear audit trail for period-end bank balance verification.

D365 Finance includes Cash Flow Forecasting that aggregates data from multiple sources to project future cash positions:

• Accounts Payable: scheduled vendor payments based on open invoices and payment terms
• Accounts Receivable: expected customer receipts based on open invoices and historical payment behavior
• Recurring transactions: recurring journals (rent, subscriptions, insurance) projected forward
• Payroll: monthly payroll obligation estimates based on current headcount and total compensation
• CAPEX: project-committed spend and planned capital expenditure from budgets
• Budget entries: revenue and expense budgets for items not yet in the transaction pipeline

The cash flow forecast is displayed in the Cash Overview workspace with a graphical timeline showing projected balances by day/week over a configurable horizon (13-week rolling is the NordHav standard). The forecast highlights projected cash shortfalls (below minimum balance threshold) and surplus periods. Data is also exported to Power BI for more detailed analysis, scenario modeling, and executive reporting. Currency-specific forecasts show NOK, EUR, and USD positions separately.

Currency exposure reporting is delivered through a combination of D365 standard reports and Power BI:

• D365 reports: the Foreign Currency Revaluation report shows open balances by currency for: customer receivables, vendor payables, and bank accounts. This provides the point-in-time exposure snapshot.
• Power BI dashboard: a dedicated currency exposure dashboard combines: open AR by currency, open AP by currency, bank balances by currency, and committed (unposted) transactions by currency to show the net exposure position per currency pair (EUR/NOK, USD/NOK, GBP/NOK, JPY/NOK)
• Trend analysis: historical exposure trends showing how NordHav's net currency position changes over time, correlated with exchange rate movements

The exposure report supports the treasury team's hedging decisions by showing: which currencies have the largest net exposure, the direction of the exposure (net receivable or net payable), and the time horizon of the exposure (when receivables will be collected and payables will be paid). This feeds into FX hedging strategy decisions (see FIN-055).

FX hedge management is identified as Gap G-13. The solution is delivered through two phases:

• Phase 1 (go-live): FX forward contracts are recorded as manual journal entries in D365 using a dedicated journal type (NHA-FX). The forward contract terms (notional amount, strike rate, maturity date) are tracked in the D365 foreign currency revaluation framework.
• Phase 2 (Q2 2028): The NordHav Finance App — FX Hedge module (model-driven Power App on Dataverse, shared platform with SalmonHedge, NRV, Grunnrenteskatt, and IAS 41 modules) provides a full FX forward register with: contract capture (counterparty, notional, rate, maturity), automatic mark-to-market revaluation against live EUR/NOK spot rates, IFRS 9 hedge effectiveness testing (80–125% offset band), and automated settlement and MTM journal generation posted to D365 via OData API.
• Hedge accounting: for hedges designated under IFRS 9 cash flow hedge accounting, the Finance App supports: documentation of the hedging relationship, prospective and retrospective effectiveness testing, and appropriate P&L vs. OCI (Other Comprehensive Income) posting of hedge gains/losses

NordHav's FX exposure is primarily EUR (≈ 60% of export revenue) against NOK costs. The Finance App's FX Hedge module tracks an estimated 20–30 forward contracts per year, provides period-end MTM journals, hedge effectiveness reports, and a treasury dashboard — all within the unified Finance App platform, eliminating spreadsheet dependency.

Salmon price hedge tracking (Fish Pool) is identified as Gap G-14, delivered via the NordHav Finance App — SalmonHedge module:

• Solution: The SalmonHedge module within the NordHav Finance App (model-driven Power App on Dataverse, shared platform with FX Hedge, NRV, Grunnrenteskatt, and IAS 41 modules) provides a complete Fish Pool contract register with: contract type (forward/call/put), volume (tonnes), strike price (NOK/kg), maturity date, counterparty, and real-time mark-to-market valuation.
• Fish Pool API integration: An Azure Logic App retrieves Fish Pool NOSA index and forward prices weekly, storing them in a Dataverse price table shared across all Finance App modules. The SalmonHedge module uses these prices for portfolio MTM calculation, exposure analysis, and hedge effectiveness testing (IFRS 9 / NRS).
• GL integration: settlement journals (realised P&L) and MTM revaluation journals (unrealised P&L) are auto-generated and posted to D365 via OData API (journal name FISHHEDGE). All journal entries carry the FIN-TREASURY cost centre dimension.
• Reporting: The module includes 8 screens — Dashboard (portfolio KPIs, 12-month price chart, monthly position strip), Contract Register, Price Monitor (spot/forward curves), Exposure Analysis (hedge ratio vs. policy bands), Settlement History, GL Journals, Hedge Effectiveness (IFRS 9 offset testing), and Configuration (hedging policy, API settings, D365 OData mapping).

For Phase 1 (go-live), Fish Pool contracts are tracked in the Finance App with settlement journals posted to D365. The full automated API integration is enabled once Fish Pool API access is confirmed (Action A-04). This is a configuration solution using the Microsoft Power Platform — no custom code development required.

Biological asset management is addressed through Gap G-02, using a custom D365 X++ extension that creates a biological asset register:

• Asset register: custom tables in D365 maintain live fish inventory classified by: site/pen location (linked to D365 Sites/Warehouses), generation (FishGeneration dimension), species (Atlantic Salmon, Rainbow Trout), and life stage (smolt, post-smolt, sea grow-out)
• Integration with inventory: biological assets are represented as D365 inventory items with batch tracking (generation), catch-weight attributes (kg biomass), and site/warehouse dimensions mapping to physical farm locations
• Financial dimension flow: all transactions carry the FishGeneration, Region, and CostCenter dimensions, ensuring the GL reflects biological asset positions accurately

The biological asset register receives data from the AquaMonitor MDA (biomass estimates, fish counts, mortality) via Power Automate integration. This bridges the gap between operational biological data and financial asset accounting. The register is the source of truth for biomass valuation reports and cost accumulation per generation.

Cost accumulation to biological assets is implemented through a combination of standard D365 inventory costing and the custom biological asset extension:

• Cost categories: smolt cost (purchase of smolt batch), feed cost (allocated from feed consumption per pen), direct labor (allocated from time registration), well-boat/transport costs, treatment costs (pharmaceutical, mechanical delousing), mortality write-off, and site overhead allocation
• Accumulation mechanism: costs are tracked via D365's production costing framework, adapted for biological production. Each generation (batch) accumulates costs through its lifecycle stages.
• Feed cost allocation: the largest single cost component — feed consumption data from AquaMonitor is converted to cost using purchase prices and posted to the generation's cost via automated journals
• Overhead allocation: site-level overhead (moorings, equipment, staff) is allocated to generations based on biomass share using D365's allocation rules

The result is a complete cost build-up per fish generation from egg input to harvest, enabling generation P&L analysis and cost per kg calculations at any point during the production cycle.

Norwegian GAAP (NRS 8) valuation of biological assets at accumulated cost is the primary valuation method for NordHav:

• Cost basis: biological assets are carried at accumulated production cost (per FIN-058) in the D365 inventory system
• NRV ceiling test: at each reporting date, the accumulated cost is compared to net realizable value (estimated selling price less costs to complete and sell). If NRV is lower than cost, a write-down is recognized.
• NRV calculation: uses Fish Pool forward price (for the expected harvest period), less estimated remaining production costs, less estimated processing and transport costs, less estimated selling costs
• Write-down posting: inventory write-downs are posted to the appropriate expense accounts with the FishGeneration dimension

The NRV test is performed monthly as part of period-end close. The calculation is managed via the NordHav Finance App — a model-driven Power App on Dataverse (similar in architecture to the AquaMonitor operational app). The Finance App pulls: (a) current cost per kg from D365 via OData, (b) Fish Pool forward prices from the Dataverse price table (populated by the existing Azure Logic App integration), and (c) configurable remaining-cost estimates maintained per generation. A Power Automate flow runs the NRV comparison, flags any generation where NRV < cost, and auto-generates the write-down journal entry in D365 via OData API. All calculations and historical results are stored in Dataverse, providing a full audit trail and eliminating spreadsheet dependency. This approach fully complies with NRS 8 and Norsk RegnskapsStiftelse guidance on biological asset valuation.

IAS 41 (Biological Assets) fair value valuation is implemented as a supplementary reporting layer alongside the NRS 8 cost basis, delivered through the NordHav Finance App — IAS 41 module:

• Fair value model: the IAS 41 module (model-driven Power App on Dataverse, shared platform with SalmonHedge, FX Hedge, NRV, and Grunnrenteskatt modules) calculates fair value less costs to sell using: (a) Fish Pool forward prices from the shared Dataverse price table, (b) estimated biomass (kg) from AquaMonitor via Dataverse, (c) quality grade assumptions (% Superior, Ordinary, Production), and (d) configurable cost-to-sell deductions (processing, transport, selling commission)
• Periodic journal: fair value adjustments are auto-generated and posted to D365 via OData as a separate journal entry (NHA-ADJ) to a parallel posting layer, adjusting the biological asset carrying amount from cost to fair value without affecting statutory accounts
• Fish Pool integration: the Finance App shares the Dataverse price table populated by the Azure Logic App (same data feed as SalmonHedge module), ensuring consistent valuation across all modules
• Unrealised gain/loss: the difference between cost and fair value is posted to accounts 8090 (Unrealised Biological Asset Gain) and 8091 (Unrealised Biological Asset Loss) in the NHA-ADJ posting layer

This dual-valuation approach (NRS 8 primary, IAS 41 supplementary) allows NordHav to comply with Norwegian GAAP for statutory reporting while having IFRS-compliant figures available for bank covenants, investor reporting, or future IFRS transition. The IAS 41 module shares the NordHav Finance App platform, Dataverse tables, and Fish Pool price feed — no additional custom development is required beyond configuration of the model-driven app views, business rules, and Power Automate journal-posting flows.

Biomass integration between AquaMonitor (operational biological data) and D365 (financial records) is automated via the Microsoft platform:

• Data flow: AquaMonitor stores daily biomass estimates per pen/site in Dataverse. A scheduled Power Automate flow runs nightly, calculating the biomass change (growth, mortality, harvest, transfer) since the last sync.
• D365 update: the flow updates D365 inventory quantities via OData API, adjusting the biological asset register to reflect current biomass. Growth adjustments add inventory, mortality adjustments remove inventory with write-off posting.
• Reconciliation: monthly reconciliation compares the AquaMonitor biomass estimate to the D365 biological asset register, with any discrepancies investigated and resolved.

This automated integration ensures the financial records always reflect current biomass positions without manual journal entry, providing the finance team with up-to-date data for valuation reports, management reporting, and regulatory filing. The integration respects the financial dimension structure (FishGeneration, Region, CostCenter) on all transactions.

Mortality write-off is automated through the AquaMonitor → D365 integration:

• Mortality data: daily mortality counts per pen (from AquaMonitor) are valued at the current accumulated cost per fish (total generation cost ÷ current fish count)
• Journal generation: Power Automate creates monthly summary journal entries in D365: debit account 4900 (Mortality Loss) and credit account 1220/1230 (Biological Asset / Accumulated Mortality Write-off)
• Dimension coding: each mortality journal line carries the FishGeneration, Region, and CostCenter dimensions for the affected pen/site
• Mortality analysis: the journal detail feeds into mortality cost analysis by: cause of death, generation, site, and time period — available in Power BI

The mortality write-off calculation is critical for accurate generation P&L. A generation that experiences high mortality will show higher cost per surviving kg, accurately reflecting the true production economics. The automated calculation elimates manual journal preparation and ensures timely recognition of mortality losses.

When fish are harvested and transported to the processing plant, the accumulated cost is transferred from biological assets to processing inventory:

• Trigger: when a harvest event is recorded in AquaMonitor (fish count, live weight from counters), the cost transfer is initiated
• Calculation: the cost transferred = (harvested kg ÷ total generation kg) × total accumulated generation cost. This allocates cost proportionally based on harvest weight.
• Posting: debit account 1400 (WIP — Processing Inventory) and credit account 1220 (Biological Assets — Sea Phase). Posted via automated journal with the harvest batch number as reference.
• Downstream flow: the harvested fish inventory enters D365's production costing system as raw material input to the processing production order, carrying the accumulated farming cost

This transfer is the critical handover point between the biological (farming) cost pool and the manufacturing (processing) cost pool. The generation P&L continues to accumulate processing costs and ultimately revenue when the finished products are sold and invoiced.

Generation P&L is a core management reporting requirement, delivered through Power BI combined with D365 Financial Reporting:

• FRD report: a D365 Financial Report Designer report configured with the FishGeneration dimension as the primary axis, showing full P&L per generation. This provides the basic generation P&L directly within D365.
• Power BI report: an enhanced, interactive generation P&L dashboard showing:
  • Revenue: total sales revenue from products traced to this generation
  • Farming costs: smolt, feed, labor, treatments, mortality, overhead — accumulated during the sea phase
  • Processing costs: slaughter, processing, packing, cold storage, QC — incurred at harvest and processing
  • Distribution costs: transport, customs, sales commissions
  • Gross margin per kg by generation
• Lifecycle timeline: shows the cost build-up over time from egg input to final sale, with margin evolution as product moves through the value chain
• Generation comparison: side-by-side comparison of multiple generations showing which performed best on cost per kg and margin

The monthly biomass valuation report is delivered through Power BI combining multiple data sources:

• Standing biomass: current biomass (tonnes) by site, pen, and generation — sourced from AquaMonitor (Dataverse)
• Accumulated cost: cost at cost basis (NRS 8) per generation — sourced from D365 GL filtered by FishGeneration dimension
• Fair value estimate: fair value per IAS 41 calculation using Fish Pool forward prices, estimated harvest timing, and quality assumptions
• Unrealized gain/loss: the difference between accumulated cost and fair value, showing the embedded profit/loss in the biological asset portfolio
• Breakdown: by site, by license, by region, and company total — with MAB limit comparison per license

The report is generated monthly as part of period-end close and distributed to: CFO, finance team, farming director, and external auditors (upon request). The report provides the data required for both NRS 8 note disclosure and IFRS 41 (if applicable) fair value disclosure in the financial statements. Historical trend views show how the biological asset portfolio value evolves over time.

D365's Cost Accounting and Production Costing modules provide detailed cost per kg tracking through the value chain:

• Smolt stage: cost per fish calculated from accumulated smolt facility costs ÷ number of smolt produced
• Sea farming: cost per kg live weight = total generation costs (feed + labor + treatments + overhead + mortality) ÷ total live biomass (kg)
• Primary processing: cost per kg HOG = raw material cost (live fish at harvested cost) + processing costs (labor, energy, packaging, depreciation) ÷ HOG output kg
• VAP products: cost per kg/unit = raw material (fillet cost) + ingredients + processing labor + packaging + overhead ÷ output kg

D365's production order costing captures all cost elements per production batch, enabling precise cost per kg calculation. Costs are tracked using D365's cost groups (material, labor, overhead, direct, indirect) and cost categories. All cost data flows to Power BI for interactive cost analysis dashboards comparing: cost per kg by period, by site, by product, and against budget/standard. The ability to track cost per kg at each stage is essential for NordHav's margin management and pricing decisions.

D365 Supply Chain Management's Standard Cost methodology is configured for the processing and VAP operations:

• Standard costs: defined per finished product/semi-finished product based on: standard raw material consumption (from BOM/formula), standard labor hours (from route), and standard overhead rates
• Variance analysis: when production orders are completed and costs are calculated, D365 automatically generates variances:
  • Price variance: difference between standard and actual material prices
  • Usage/quantity variance: difference between standard and actual material consumption
  • Yield variance: difference between standard and actual output quantity (particularly important for fish processing where yield varies)
  • Labor efficiency variance: actual labor hours vs. standard hours
  • Overhead variance: actual overhead vs. applied overhead
• Variance posting: variances are posted to dedicated GL accounts by variance category for financial analysis

Standard costs are reviewed and updated quarterly. The variance reports are critical for identifying production efficiency improvements and cost management opportunities.

D365 Manufacturing supports co-product and by-product costing through the formula/BOM and production order framework:

• Joint cost allocation: when a single production process produces multiple outputs (e.g., HOG salmon + heads + frames + viscera), joint costs are allocated using configurable methods:
  • Net Realizable Value: costs allocated proportionally based on each product's estimated selling price (total value method)
  • Physical quantity: costs allocated based on kg output per product
  • Fixed percentage: user-defined allocation percentages per co-product
• By-product treatment: low-value by-products (viscera for ensilage, blood water) can be treated as scrap with: no cost allocation (offset reduces primary product cost), or a minimal fixed value deducted from joint cost
• Co-product cost calculation: D365's production order cost calculation distributes costs to co-products based on the selected allocation method

For NordHav, the primary processing BOM defines: HOG salmon as the primary product, with heads, frames, belly trimmings, and skins as co-products, and viscera/blood water as by-products. Revenue from co-product sales (e.g., heads exported to Asia) is properly matched against their allocated cost for accurate margin analysis.

Processing yield analysis is delivered through D365 standard reports and Power BI:

• D365 reports: production order reports show: input quantity (kg), output quantity per product (kg), calculated yield percentage, and variance from standard yield
• Power BI dashboard: interactive yield analysis showing:
  • Yield % by product type, production line, shift, and period
  • Yield trend over time with statistical process control limits
  • Financial impact: the NOK cost of yield loss (below standard) per period
  • Correlation analysis: yield vs. raw material attributes (fish size, quality grade, season)
• Drill-down: from yield dashboard → production batch → individual processing parameters → root cause

Yield is one of the most critical operational KPIs for NordHav's processing operations. A 1% improvement in processing yield represents significant revenue and margin improvement. The reporting enables production management to identify the best-performing lines/shifts and replicate practices.

Feed cost per kg of biomass produced is calculated by combining two data sources:

• Feed consumption: AquaMonitor tracks kg of feed consumed per pen per day (from feed barge systems integration). This provides the physical feed usage data by generation/site.
• Feed pricing: D365 Procurement maintains feed purchase prices per product per supplier. The actual purchase cost per kg of feed is calculated from vendor invoices.
• Calculation: Feed Cost per kg Biomass = (Total feed consumed in kg × Average feed cost per kg) ÷ Net biomass gain (kg) for the period/generation

The calculation is performed in Power BI, combining the feed consumption data (from Dataverse/AquaMonitor) with the feed purchase cost data (from D365 AP/Inventory). Results are reported by: pen, site, generation, region, and period. This metric is compared against: biological FCR × feed price (the theoretical minimum), enabling identification of overfeeding or underperformance. Feed cost typically represents 50-60% of total production cost, making this the most financially significant operational metric.

D365 Finance's Tax module is configured with the complete Norwegian MVA (merverdiavgift) structure:

• 8 sales tax codes configured: 25% standard, 15% food (used for salmon products sold domestically), 12% transport/hospitality, 0% export (used for all international sales), 0% exempt, reverse charge (for certain service purchases), 0% B2B EU, and a special code for government/public sector transactions
• Sales tax groups and Item sales tax groups determine the correct rate based on customer type, product category, and transaction type
• Automated MVA return: D365's Electronic Reporting generates the Norwegian MVA return (Skattemelding for merverdiavgift) in the format required by Skatteetaten, pulling data directly from posted sales tax transactions. The return can be filed electronically via Altinn.
• Periodic settlement: bi-monthly MVA settlement (Norwegian standard) creating the VAT payable/receivable posting

Tax configuration is deployed via DMF template 035 — Tax.json. The tax module handles: domestic sales (15% food rate for fish), export sales (0%), domestic purchases (various rates with input VAT deduction), and import purchases with reverse charge mechanism.

D365 Finance provides a standard SAF-T export through the Electronic Reporting (ER) framework:

• SAF-T Norway v1.10: the current Norwegian standard format, pre-built as an ER configuration in D365's Globalization Studio
• Data scope: the export includes: master data (chart of accounts, customer/vendor master, tax codes), general ledger entries, accounts receivable and payable subledgers, and inventory transactions
• Generation: accessible via General Ledger → Periodic Tasks → SAF-T Export. Generates an XML file for the selected period(s) suitable for upload to Skatteetaten.
• Validation: the ER framework validates data completeness and format compliance before generating the file

SAF-T is legally required for all Norwegian businesses subject to accounting obligations. The export is typically generated annually for tax audits or on-demand when requested by Skatteetaten. NordHav runs the SAF-T export as part of the annual close process. D365's SAF-T format is maintained and updated by Microsoft as part of the Norwegian localization package, ensuring ongoing compliance with any format version changes.

Norway's aquaculture resource rent tax (grunnrenteskatt, 25% since 2024) is identified as Gap G-04:

• Calculation engine: the NordHav Finance App (model-driven Power App on Dataverse, shared with NRV valuation per FIN-059) hosts the grunnrenteskatt calculation module. The app pulls all required data from D365 via OData: production volume, norm prices (from Skatteetaten published rates stored in a Dataverse reference table), deductible operating costs by category, and fixed asset values for the investment allowance (from D365 FA register).
• Scenario analysis: the Finance App supports multiple calculation scenarios (budget, forecast, actual) with side-by-side comparison, enabling the finance team to model the tax impact of production and investment decisions before year-end.
• Audit trail: all calculation inputs, intermediate results, and final tax positions are stored in Dataverse with full version history — replacing the spreadsheet-based approach with a governed, auditable platform.
• RF-1151 filing: a custom D365 Electronic Reporting (ER) format generates the RF-1151 tax return form with automated data population from the Finance App's calculated figures, ready for Altinn submission.
• Power Automate: scheduled flows update the calculation when period-end close completes, and notify the tax team of any material changes in the estimated resource rent tax position.

The first annual resource rent tax return is due March 2027 (for FY2026). The NordHav Finance App will be operational from go-live, enabling the tax team to track the grunnrenteskatt position throughout the year rather than only at filing time.

A-melding (the combined monthly report of income, employment, and tax deduction information submitted to Skatteetaten, NAV, and SSB) is generated by the Norwegian payroll ISV selected under Gap G-03:

• Integration flow: D365 Human Resources provides employee master data (employment dates, position, working hours, personal details) to the payroll ISV via Azure API Management integration. The ISV calculates payroll and generates the A-melding in the required XML format for submission to Altinn.
• Data exchange: the payroll ISV reads: employee registry, employment changes, leave data, and time & attendance data from D365 HR. It returns: payroll cost journals (posted to D365 GL), payslip data, and A-melding filing confirmation.
• Reconciliation: monthly reconciliation between: D365 GL payroll expense accounts, payroll ISV net pay calculations, and A-melding submitted figures ensures completeness and consistency

The A-melding is filed monthly, typically by the 5th of the following month. The payroll ISV handles all Norwegian-specific payroll calculations, tax table lookups, and regulatory format generation that D365 HR does not natively support.

D365 Fixed Assets' tax depreciation book (configured with Norwegian saldogruppe rates per FIN-043) generates the required tax depreciation reporting:

• Depreciation schedule: annual declining-balance depreciation calculated per saldogruppe for all fixed assets
• Tax vs. accounting difference: the system automatically tracks the difference between the accounting (straight-line) and tax (declining-balance) depreciation, providing the data for deferred tax liability calculation
• Reporting: tax depreciation schedules by saldogruppe, showing: opening tax balance, additions, disposals, depreciation, and closing tax balance — matching the format required for the tax return (Skattemelding RF-1217)
• Export: data exportable to Excel for use by external tax advisors in preparing the annual tax return

The depreciation schedules are generated as part of the year-end close process. Any adjustments (e.g., asset reclassification between saldogrupper, disposal adjustments) are made in the tax book before the final schedule is produced.

D365 Finance provides the data foundation for preparing the annual corporate tax return (Skattemelding for aksjeselskap):

• Financial statements: FRD-generated balance sheet and P&L form the starting point for the tax return
• Tax depreciation schedules: from the Fixed Assets tax book (RF-1217 format)
• Receivables/payables aging: for tax provision calculations on doubtful receivables
• Inventory valuation: for tax-basis inventory reporting
• FX gains/losses: realized and unrealized, for tax treatment analysis
• SAF-T export: provides the transactional detail required by Skatteetaten

The actual tax return preparation and filing is typically done in collaboration with external tax advisors using data exported from D365. D365 provides all the source data in structured formats (Excel exports, standard reports, SAF-T) that feed into the tax calculation and return filing via Altinn. For larger companies like NordHav, this is standard practice — the ERP provides the data, the tax team/advisors prepare the return.

Transfer pricing documentation for fish transferred from farming to processing is implemented through D365's financial dimension framework:

• Internal pricing: when harvested fish enters the processing facility, the cost transfer (FIN-063) uses a configurable transfer price methodology — either accumulated cost (NRS 8 basis) or a norm/market price (for resource rent tax calculations)
• Dual valuation: the system can record both cost-basis transfers (for GAAP) and norm-price transfers (for grunnrenteskatt) using separate posting layers or dimension tags
• Documentation: the transfer pricing methodology, pricing basis, and calculations are documented and accessible for audit purposes
• Margin analysis: internal margin between farming and processing is visible through the FishGeneration dimension P&L — enabling the finance team to see profitability at each value chain stage

This is particularly important for the resource rent tax (grunnrenteskatt), which requires arm's-length pricing for the fish as it leaves the production phase. The D365 configuration ensures the required pricing documentation and calculations are embedded in the transaction flow rather than created retrospectively.