LoanLink — Issue Triage Dashboard

Notion item: box 3 leningdelen: consumptief bedrag ontbreekt in aanvraag

Status: READY TO BUILD

Prioriteit: Hoog (raakt 30/31 providers, 347 validatiefouten)

Geschatte effort: 1-2 uur

Wie: Arnold (mapping) + Max (review)

---

Probleem

Bij Box 3 leningdelen wordt het ConsumptiefBedrag niet meegestuurd in de HDN aanvraag. Geldverstrekkers vereisen dit veld wanneer BelastingBox = "03 Box 3".

Testresultaat: "Indien er sprake is van een (gedeeltelijk) Box 3 leningdeel moet het ConsumptiefBedrag zijn meegegeven" — komt voor bij vrijwel alle providers.

Code-analyse

Bestand: packages/model-mapping/src/hdn25_0/mappers/leningdeel-mapper.ts

Regel 85: // ConsumptiefBedrag: — het veld staat als comment, niet geïmplementeerd.

De NietFiscaalAftrekbaarBedrag mapping (regel 94-97) is wél correct:

NietFiscaalAftrekbaarBedrag:
    internalLeningdeel.interestDeductionLaw === "none"
        ? fuzzyStringToHdnNum(internalLeningdeel.amount)
        : undefined,

Oplossing

ConsumptiefBedrag is voor Box 3 leningdelen gelijk aan het leningdeelbedrag. Dezelfde logica als NietFiscaalAftrekbaarBedrag:

// leningdeel-mapper.ts, regel 85 — vervang de comment:
ConsumptiefBedrag:
    internalLeningdeel.interestDeductionLaw === "none"
        ? fuzzyStringToHdnNum(internalLeningdeel.amount)
        : undefined,

Geen model-app wijziging nodig — het bedrag komt uit internalLeningdeel.amount dat al beschikbaar is.

Verificatie

• Unit test toevoegen in `leningdeel-mapper.test.ts`: Box 3 leningdeel moet `ConsumptiefBedrag` bevatten
• `pnpm test` in model-mapping package
• Mapping-validatie draaien: verwacht ~347 minder fouten over alle providers

Notion item: rentevorm altijd 'rentevast' ook bij variabele rente

Status: READY TO BUILD

Prioriteit: Hoog (raakt 17/31 providers, ~61 validatiefouten)

Geschatte effort: 3-4 uur

Wie: Arnold (mapping + model) + Max (review)

---

Probleem

De RenteAfspraak in de HDN aanvraag is hardcoded op "01 rentevast" (leningdeel-mapper.ts:101). Bij variabele rente of rentedaling wordt dus de verkeerde code meegestuurd. Geldverstrekkers klagen: "Code van de rentevorm is verplicht" wanneer de meegegeven waarde niet past bij het gekozen product.

Code-analyse

Bestand: packages/model-mapping/src/hdn25_0/mappers/leningdeel-mapper.ts

Regel 101: RenteAfspraak: "01 rentevast",

HDN kent deze RenteAfspraak codes:

• `01 rentevast` — Vaste rente voor bepaalde periode
• `02 variabele rente` — Rente kan wijzigen
• `03 rentedaling` — Rente kan alleen dalen
• `04 basisrente` — Basisrente met opslagen

Oplossing

1. Model-app uitbreiden (`packages/model-app/src/0.2.0.ts`)

Voeg interestRateType toe aan MortgagePart:

export interface MortgagePart {
    // ... bestaande velden ...
    interestRateType?: "fixed" | "variable" | "declining" | "base";
}

2. Mapping toevoegen (`leningdeel-mapper.ts`)

const interestRateTypeMap: Record<string, string> = {
    "fixed": "01 rentevast",
    "variable": "02 variabele rente",
    "declining": "03 rentedaling",
    "base": "04 basisrente",
};

// Regel 101 — vervang hardcoded waarde:
RenteAfspraak: internalLeningdeel.interestRateType
    ? interestRateTypeMap[internalLeningdeel.interestRateType]
    : "01 rentevast", // fallback voor bestaande data

3. Frontend: veld toevoegen in leningdeel formulier

In de hypotheek-opzet pagina een loanlinkOption veld toevoegen voor rentevorm (fixed/variable/declining/base). Default: "fixed".

4. Zero schema update

interestRateType toevoegen aan het Zero sync schema zodat het real-time beschikbaar is.

Impact

• Fix voor ~61 validatiefouten
• Backwards compatible door fallback naar "01 rentevast"
• Raakt: model-app, model-mapping, frontend (formulier), zero schema

Verificatie

• Unit test: variabele rente → `"02 variabele rente"`
• Unit test: geen waarde → fallback `"01 rentevast"`
• E2E: product met variabele rente selecteren → correct in XML
• Mapping-validatie draaien

Notion item: terugbetaalstrategie niet selecteerbaar bij aflossingsvrij

Status: READY TO BUILD

Prioriteit: Hoog (raakt 24/31 providers, ~42 validatiefouten)

Geschatte effort: 4-5 uur

Wie: Arnold (mapping + model) + Max (frontend + review)

---

Probleem

Bij aflossingsvrije leningdelen (AflossingsVorm = "05 Aflossingsvrij") is het HDN-veld WijzeVanTerugbetaling verplicht. Dit veld ontbreekt volledig in het LoanLink model en de mapping. Geldverstrekkers melden: "Bij elk aflossingsvrij leningdeel is het verplicht de terugbetaal strategie vast te leggen."

Code-analyse

• **leningdeel-mapper.ts:** Geen `WijzeVanTerugbetaling` property in het output object
• **model-app MortgagePart:** Geen `repaymentStrategy` veld
• **mapping.json (XSD):** Veld `WijzeVanTerugbetaling` bestaat wel in het HDN schema (regel 1834-1835)

HDN specificatie

WijzeVanTerugbetaling is verplicht bij AflossingsVorm 05. Mogelijke waarden:

• `01 Verkoop woning`
• `02 Spaarverzekering / beleggingsverzekering`
• `03 Spaarrekening / beleggingsrekening`
• `04 Overig`
• `05 Erfenis / schenking`
• `06 Pensioenvoorziening`

Oplossing

1. Model-app uitbreiden

export type RepaymentStrategy =
    | "sale-of-property"
    | "savings-insurance"
    | "savings-account"
    | "other"
    | "inheritance"
    | "pension";

export interface MortgagePart {
    // ... bestaande velden ...
    repaymentStrategy?: RepaymentStrategy;
}

2. Mapping toevoegen (`leningdeel-mapper.ts`)

const repaymentStrategyMap: Record<RepaymentStrategy, string> = {
    "sale-of-property": "01 Verkoop woning",
    "savings-insurance": "02 Spaarverzekering / beleggingsverzekering",
    "savings-account": "03 Spaarrekening / beleggingsrekening",
    "other": "04 Overig",
    "inheritance": "05 Erfenis / schenking",
    "pension": "06 Pensioenvoorziening",
};

// Toevoegen aan leningdeel object:
WijzeVanTerugbetaling:
    internalLeningdeel.repaymentForm === "interest-only" && internalLeningdeel.repaymentStrategy
        ? repaymentStrategyMap[internalLeningdeel.repaymentStrategy]
        : undefined,

3. Frontend: conditioneel veld

In het leningdeel formulier: toon repaymentStrategy dropdown alleen wanneer repaymentForm === "interest-only". Default: "01 Verkoop woning" (meest voorkomend).

4. Zero schema + database migratie

Nieuw veld repayment_strategy in de mortgage_part tabel + Zero schema.

Verificatie

• Unit test: aflossingsvrij met strategie → correct HDN veld
• Unit test: annuïtair → geen WijzeVanTerugbetaling
• Frontend: veld verschijnt/verdwijnt bij wisselen aflossingsvrij
• Mapping-validatie: ~42 minder fouten verwacht

Notion item: rentebedenktijd wordt niet meegestuurd naar geldverstrekker

Status: READY TO BUILD

Prioriteit: Middel (raakt 10/31 providers, ~33 validatiefouten)

Geschatte effort: 2-3 uur

Wie: Arnold (mapping + model) + Max (review)

---

Probleem

Het HDN-veld RenteBedenkTijd wordt niet meegestuurd. Sommige geldverstrekkers vereisen dit veld bij de offerteaanvraag — het geeft aan hoeveel dagen/maanden bedenktijd de klant wil voor de renteofferte.

Code-analyse

• **mapping.json (XSD):** `RenteBedenkTijd` (regel 1849) en `RenteBedenkTijdInMnd` (regel 1853) bestaan in het HDN schema
• **leningdeel-mapper.ts:** Geen van beide velden gemapped
• **model-app MortgagePart:** Geen `reflectionPeriod` veld

HDN specificatie

• `RenteBedenkTijd` — "J Ja" / "N Nee" (wil klant bedenktijd?)
• `RenteBedenkTijdInMnd` — Aantal maanden bedenktijd (numeriek)

Typische waarden: 1-3 maanden. Default bij veel adviseurs: "N Nee" of 1 maand.

Oplossing

1. Model-app uitbreiden

export interface MortgagePart {
    // ... bestaande velden ...
    interestReflectionPeriodMonths?: number; // 0 = geen, 1-6 = maanden
}

2. Mapping toevoegen (`leningdeel-mapper.ts`)

RenteBedenkTijd: internalLeningdeel.interestReflectionPeriodMonths
    && internalLeningdeel.interestReflectionPeriodMonths > 0
        ? "J Ja"
        : "N Nee",
RenteBedenkTijdInMnd: internalLeningdeel.interestReflectionPeriodMonths
    && internalLeningdeel.interestReflectionPeriodMonths > 0
        ? fuzzyStringToHdnNumWhole(internalLeningdeel.interestReflectionPeriodMonths)
        : undefined,

3. Frontend

Optioneel veld per leningdeel: "Rentebedenktijd (maanden)" — number input, default 0.

Openstaande vragen

• **Vraag aan team:** Moet dit per leningdeel of per aanvraag? Sommige geldverstrekkers verwachten het op aanvraagniveau.
• **Default waarde:** Willen we een kantoor-instelling hiervoor (bijv. altijd 1 maand)?

Verificatie

• Unit test: 0 maanden → `"N Nee"`, geen RenteBedenkTijdInMnd
• Unit test: 2 maanden → `"J Ja"`, `RenteBedenkTijdInMnd: 2`
• Mapping-validatie: ~33 minder fouten verwacht

Notion item: woonsituatie velden niet compleet in HDN aanvraag

Status: IN PROGRESS (Arnold + Gustaaf — zie TASKS.md)

Prioriteit: Hoog (raakt 16/31 providers)

Geschatte effort: 8-12 uur (meerdere componenten)

Wie: Arnold (actief), Gustaaf (review spec)

---

Probleem

getHuidigeWoonsituatie() in personal-mapper.ts retourneert alleen "03 Koopwoning" (als hasOwnedProperty true is) of undefined. Ontbreken: huurwoning, inwonend, geen eigen woning.

Huidige status (TASKS.md)

Dit item is actief in ontwikkeling:

• Spec review door Max (PDF: `docs/specs/woonsituatie-hdn-mapping-spec.pdf`)
• Model uitbreiden: `inventarisation-living-situation.ts`
• Frontend ownership form updaten (AppCard, 7 blokken)
• Living situation mapper implementeren
• `toHdn25_0.ts` aanpassen — HuidigObject mapping
• Unit tests + E2E test

Er zijn ook bekende bugs:

• Bevestigingsdialoog bug: omgekeerde logica in `InventarisationLivingSituationPage.vue:46-57`
• `getSeparateSituationDetailsProps` geeft "together" ipv "separate"

Feature flag: VITE_FEATURE_INVENTARISATION_LIVING_SITUATION

Code-analyse

personal-mapper.ts:87-97:

export function getHuidigeWoonsituatie(
    currentObjects?: CurrentObjects,
): WoonsituatieType | undefined {
    if (!currentObjects) return undefined;
    if (currentObjects.hasOwnedProperty && currentObjects.objects.length > 0) {
        return "03 Koopwoning";
    }
    return undefined; // <-- hier mist huur/inwonend/geen
}

Benodigde HDN waarden

• `01 Huurwoning`
• `02 Inwonend bij ouders`
• `03 Koopwoning` (al geïmplementeerd)
• `04 Geen eigen woning`

Aanbeveling

Geen actie nodig vanuit dit spec-traject — Arnold is ermee bezig. Wel:

• **Bugs eerst fixen** (dialoog + getSeparateSituationDetailsProps)
• **Spec review** door Max versnellen zodat implementatie door kan

Notion item: doornemen bkr meldingen, studie fin en erfpacht invloed lti

Status: NEEDS RESEARCH

Prioriteit: Middel

Geschatte effort: Onderzoek 4-8 uur, implementatie onbekend

Wie: Gustaaf (functioneel), Arnold/Max (technisch)

Aangemaakt: 15 januari 2026

---

Context

Dit item combineert drie gerelateerde onderwerpen die de hypotheekberekening beïnvloeden:

1. BKR meldingen

Huidige staat in code: Niet geïmplementeerd. Geen BKR API-integratie gevonden in de codebase. Waarschijnlijk wordt BKR nu door de geldverstrekker zelf gecheckt na ontvangst van de aanvraag.

Vraag: Willen we BKR-data actief ophalen (voor pre-screening) of alleen de impact op LTI documenteren zodat adviseurs het handmatig kunnen meenemen?

Opties:

• A) **Informatief:** Adviseur vult BKR-registraties handmatig in → invloed op LTI tonen
• B) **Geïntegreerd:** BKR API aansluiten → automatisch ophalen → meenemen in berekening

2. Studiefinanciering

Huidige staat: Deels geïmplementeerd. getStudieleningInventarisatie() in personal-mapper.ts detecteert of er studieschuld is (SF15/SF35 secties in liabilities). De HDN mapping stuurt "03 Ja, er is sprake van een studielening" of "02 Ja, maar geen sprake".

Wat ontbreekt: De *weging* van studieschuld in de LTI-berekening. DUO-schulden worden anders gewogen dan reguliere schulden (0,45% van oorspronkelijk bedrag per maand i.p.v. werkelijke maandlast).

3. Erfpacht invloed op LTI

Huidige staat: Erfpacht wordt waarschijnlijk al meegenomen via de woning-objecten, maar de specifieke invloed op LTI (canonlast telt mee als vaste last) moet geverifieerd worden.

Vervolgstappen

1. Functioneel onderzoek (Gustaaf):

- Welke BKR-registraties zijn relevant voor hypotheekadvies?

- Hoe weegt studieschuld mee in de nieuwste leennormen?

- Hoe verhoudt erfpachtcanon zich tot de woonquote?

2. Technisch haalbaarheid (Max):

- Is BKR API beschikbaar voor hypotheekadviseurs? (Mogelijk via Datakeeper?)

- Wat is de impact op de incomeCalculations.ts logica?

3. Na onderzoek: Aparte specs per deelonderwerp

Notion item: koppeling maken met orv en inkomensverstrekkers, hoe; as do ff bespreken

Status: NEEDS DISCUSSION

Prioriteit: Middel-Hoog

Geschatte effort: Onderzoek 2-4 uur, implementatie 2-6 weken afhankelijk van scope

Wie: Max + Gustaaf (architectuur), Arnold (implementatie)

Aangemaakt: 6 januari 2026

---

Context

ORV (Overlijdensrisicoverzekering) is verplicht bij de meeste hypotheken. Momenteel heeft LoanLink alleen percentage-parameters (0%, 2%, 8%, 10.4% in parameters.ts). Er is geen:

• Offerte-aanvraag bij ORV-verzekeraars
• Premieberekening op basis van risicoprofiel
• Koppeling met inkomensverstrekkers (pensioenuitvoerders, UWV)

Huidige implementatie

apps/frontend/src/parameters/parameters.ts → ovbPercentages:

2023: [0%, 2%, 8%, 10.4%]
2026: [0%, 2%, 8%, 10.4%]

Adviseur selecteert handmatig een percentage. Geen koppeling met externe partijen.

Scope-opties

Optie A: Basis — ORV premie-indicatie

• Leeftijd + gezondheid → indicatieve premie berekenen
• Geen externe API, alleen lokale berekening met standaard tarieftabellen
• **Effort:** 1-2 weken

Optie B: Gevorderd — ORV offerte via API

• Aansluiten op 1-2 ORV-verzekeraars (bijv. Aegon, NN, ASR)
• Offerte opvragen, vergelijken, selecteren
• **Effort:** 4-8 weken (per verzekeraar)
• **Vereist:** API-contracten met verzekeraars

Optie C: Inkomensverstrekkers koppeling

• Datakeeper al geïmplementeerd voor inkomensverificatie
• Uitbreiden naar pensioenuitvoerders en UWV?
• **Effort:** Onderzoek nodig — Datakeeper dekt mogelijk al voldoende

Beslispunten

1. Scope: A, B, of C? Of combinatie?

2. Prioriteit: Dit raakt geen HDN-validatie maar wel klantwaarde

3. Business case: Hoeveel aanvragen per maand? Rechtvaardigt dat een API-integratie?

4. Datakeeper: Dekt de bestaande Datakeeper-integratie al delen van de inkomensverstrekkers-koppeling?

Aanbeveling

Start met Optie A (premie-indicatie) — lage effort, directe klantwaarde. Parkeer B en C tot er concrete vraag is van adviseurs.

Notion item: functionaliteit om e-mails met bestanden naar de app te sturen, soort 'bak'

Status: DESIGN READY

Prioriteit: Middel

Geschatte effort: 2-3 weken

Wie: Max (backend), Arnold (frontend)

Aangemaakt: 8 december 2025

---

Probleem

Adviseurs willen documenten per e-mail naar een dossier sturen — vergelijkbaar met boekhoudpakketten die een uniek email-adres per klant/dossier hebben. Nu moeten documenten handmatig geüpload worden via de UI.

Bestaande infrastructuur

LoanLink heeft al een complete Postmark email pipeline:

• `POST /webhooks/postmark` — Inbound webhook receiver (met token-validatie)
• `emailHandleInbound.ts` — Worker die emails verwerkt
• `interestSheetManager.ts` — Bijlagen extracten → Azure Blob Storage
• Bestaande flow: email → parse → extract attachments → store in blob → link to interest sheets

De infrastructuur voor document-opslag is ook compleet:

• `documentManager.ts` + `DocumentService` — Upload naar Azure Blob
• SAS-token generatie voor upload/download
• `dossierDocument` tabel voor metadata
• AI classificatie tabel (nog niet actief)

Oplossing

1. Uniek email-adres per dossier

Formaat: dossier-{dossierId}@inbound.loanlink.nl (of docs-{shortId}@)

Postmark ondersteunt inbound domains — alle emails naar *@inbound.loanlink.nl komen binnen op de bestaande webhook.

2. Webhook routing uitbreiden

In emailHandleInbound.ts:

// Huidige flow: alle inbound → interest sheets
// Nieuwe flow: route op basis van To-adres

const toAddress = email.ToFull[0]?.Email;
if (toAddress?.startsWith("dossier-")) {
    const dossierId = extractDossierIdFromEmail(toAddress);
    await handleDossierDocumentEmail(email, dossierId);
} else {
    // Bestaande interest sheet flow
    await handleInterestSheetEmail(email);
}

3. Document opslag per dossier

async function handleDossierDocumentEmail(email, dossierId) {
    // 1. Verifieer dat dossier bestaat en afzender geautoriseerd is
    // 2. Voor elke bijlage:
    //    - Upload naar Azure Blob (pad: files/agency/{id}/dossiers/{dossierId}/documents/{docId})
    //    - Maak dossierDocument record aan (type: "email_upload")
    //    - Optioneel: AI classificatie triggeren
    // 3. Log inbound email in bestaande inbound_email tabel
    // 4. Stuur bevestiging naar afzender (optioneel)
}

4. Frontend: inbox weergave

Nieuw tabblad "Inbox" in dossier-view:

• Toont ontvangen emails met bijlagen
• Status: "nieuw", "geclassificeerd", "gekoppeld aan sectie"
• Drag & drop naar juiste dossier-sectie

5. Later: automatische verwerking

Fase 2: AI-classificatie activeert automatisch:

• Loonstrook → inkomen sectie
• ID bewijs → klantgegevens
• Taxatierapport → woning sectie

Beveiliging

• Email-adres per dossier is niet gevoelig (geen PII in het adres zelf)
• Afzender-verificatie: check of email komt van bekende adviseur of klant
• Rate limiting op de webhook
• Virus scan op bijlagen (Azure Blob heeft dit ingebouwd)

Verificatie

• Postmark inbound domain configureren
• Unit test: email routing op basis van To-adres
• Integration test: bijlage → Azure Blob → dossierDocument
• E2E: email versturen → verschijnt in dossier inbox

Notion item: kan 'transcriptor' worden verrijkt met berekeningen uit tools?

Status: NEEDS RESEARCH

Prioriteit: Laag-Middel

Geschatte effort: Onderzoek 2-4 uur, implementatie 1-2 weken

Wie: Max (AI/backend), Gustaaf (functioneel)

Aangemaakt: 3 december 2025

---

Context

De transcriptor (Speechmatics) zet gesprekken om naar tekst. De gespreksamenvatting wordt gemaakt door Claude Sonnet via OpenRouter. De vraag is of deze samenvatting verrijkt kan worden met berekeningen — bijv. als de adviseur zegt "de klant verdient 65.000 bruto" dan direct de maximale hypotheek berekenen.

Huidige implementatie

Transcriptie pipeline:

1. useSpeechmaticsTranscriber.ts — Real-time WebSocket transcriptie

2. conversationTranscribe.ts — Batch transcriptie (backend worker)

3. OpenRouter → Claude Sonnet — Samenvatting genereren

Berekeningen:

• `incomeCalculations.ts` — Inkomen aggregatie
• `parameters.ts` — NHG grenzen, woonquote, toetsrente etc.
• Alle berekeningen draaien in de frontend

Opties

Optie A: Post-processing enrichment

Na de samenvatting: zoek naar bedragen/feiten → koppel aan berekeningen → voeg toe als "inzichten":

Samenvatting: "Klant verdient €65.000 bruto per jaar..."
→ Inzicht: Maximale hypotheek ca. €340.000 (op basis van huidige toetsrente 5%)
→ Inzicht: NHG mogelijk (grens €470.000 in 2026)

Optie B: Tool-calling in samenvatting prompt

Claude Sonnet krijgt tools mee (berekening-functies) en kan deze aanroepen tijdens samenvatting. Vereist backend-side function calling.

Optie C: Interactieve verrijking

Na transcriptie toont de UI een "Analyseer" knop die de tekst door Claude haalt met toegang tot alle dossierggevens + berekeningen.

Aanbeveling

Optie A is het snelst te implementeren en geeft directe waarde. Optie B is eleganter maar complexer. Optie C geeft de meeste controle aan de adviseur.

Openstaande vragen

• Hoe accuraat moeten de berekeningen zijn? Indicatief of bindend?
• Mag Claude zelfstandig berekeningen maken of alleen verwijzen naar de tool?
• Privacy: worden gesprekstranscripties naar OpenRouter gestuurd? (Ja, dat gebeurt al)

Notion item: Meer invulvelden HDN inbouwen

Status: IN PROGRESS (Arnold)

Prioriteit: Hoog — doorlopend

Geschatte effort: Doorlopend, ~2-4 uur per veld

Wie: Arnold (primair), Max (review)

Aangemaakt: 15 september 2025

---

Context

Dit is een overkoepelend item voor het uitbreiden van de HDN mapping. De huidige mapping score is 97.7% (koop-alleenstaand) maar er zijn nog ~352 validatiefouten over 32 providers. De meeste fouten vallen in specifieke categorieën die elk een eigen spec hebben:

Relatie met andere specs

| Spec | HDN veld(en) | Geschatte impact |

|------|-------------|-----------------|

| SPEC-001 | ConsumptiefBedrag | -347 fouten |

| SPEC-002 | RenteAfspraak | -61 fouten |

| SPEC-003 | WijzeVanTerugbetaling | -42 fouten |

| SPEC-004 | RenteBedenktijd | -33 fouten |

| SPEC-005 | HuidigeWoonsituatie | -16 providers |

Overige ontbrekende velden (uit testresultaten)

• **HypotheekAkteKostenSpec** — Kosten hypotheekakte (5/31 providers)
• **DatumOntbindendeVoorwaarden** — Termijn ontbindende voorwaarden (5/31 providers)
• **CodeLeningdeel** — Auto-generatie logica (28/31 providers, deels TODO in code)

Recente voortgang (git log)

Recentelijk geïmplementeerd:

• LandWerkgever mapping
• VerbouwingsKosten mapping
• Telefoonnummer fix
• Object Adres fallback

Aanbeveling

Focus op SPEC-001 t/m SPEC-004 — samen goed voor ~483 minder fouten. Dat brengt de score naar ~99.5%+.

Notion item: Adviseur inkomen vullen in dossier?

Status: NEEDS CLARIFICATION

Prioriteit: Laag-Middel

Geschatte effort: 2-4 uur (als het simpel is)

Wie: Max (frontend)

Aangemaakt: 10 september 2025

---

Context

De vraag is of het inkomen ook handmatig door de adviseur ingevuld moet kunnen worden, naast de automatische import via Datakeeper. Nu wordt inkomen primair opgehaald via de Datakeeper → HDN BronAanvraag pipeline.

Huidige implementatie

Inkomensbronnen:

• Datakeeper (automatisch): loondienst, pensioen, uitkering via CX-bericht
• Handmatig: gedeeltelijk mogelijk via frontend formulieren

incomeCalculations.ts berekent totaal inkomen over: loondienst, uitkering, pensioen, onderneming, overig. Elk type heeft velden als grossSalary, vakantiegeld, bonussen etc.

Vraag ter verduidelijking

Wat wordt precies bedoeld?

1. Adviseur kan inkomen handmatig invoeren als Datakeeper niet beschikbaar is?

2. Adviseur kan Datakeeper-inkomen overschrijven/corrigeren?

3. Adviseur kan extra inkomensbronnen toevoegen die Datakeeper niet kent?

Optie 1 lijkt het meest waarschijnlijk en is grotendeels al mogelijk via de bestaande formulieren.

Aanbeveling

Navragen bij de indiener wat de exacte use case is. Mogelijk is dit al opgelost of is het een klein UI-probleem (velden niet vindbaar/zichtbaar).

Notion item: graag overzicht van welke velden wel/niet worden meegegeven per geldverstrekker

Status: PARTIALLY SOLVED

Prioriteit: Middel

Geschatte effort: 1-2 weken (als nieuwe feature), 0 (als rapport voldoet)

Wie: Gustaaf (functioneel), Arnold (data)

Aangemaakt: 20 augustus 2025

---

Context

De vraag is om transparantie over welke HDN-velden per geldverstrekker daadwerkelijk worden ingevuld/verstuurd. Dit is relevant voor:

• Adviseurs die willen weten waarom een aanvraag wordt afgewezen
• Quality control van de mapping
• Compliance (volledigheid van aanvragen)

Bestaande oplossing: testharnas

Het LoanLink testharnas genereert precies dit overzicht:

• `output/mapping-report.json` — Scores per provider (welke velden correct, welke ontbreken)
• Per-provider rapporten: `mapping-report-{XX}-{scenario}.json` — Exacte veldnamen + foutmeldingen
• Dashboard op `localhost:3456` — Visueel overzicht

Dit lost het intern (voor het team) al op.

Wat ontbreekt: adviseur-facing overzicht

Adviseurs hebben geen toegang tot het testharnas. Opties:

Optie A: Statisch overzicht in de app

Pagina per geldverstrekker met een tabel: "Deze velden worden meegestuurd" / "Deze niet". Onderhoud: handmatig bijwerken.

Optie B: Dynamisch na aanvraag

Na het indienen van een aanvraag: toon welke velden zijn meegestuurd en welke ontbraken. Dit is al deels mogelijk via de ValidatieMelding (VX) die terugkomt van de geldverstrekker.

Optie C: Pre-submit validatie

Vóór indienen: controleer tegen XSD/ControleXML en toon vooraf welke velden nog ontbreken. De backend doet dit al intern — het moet alleen naar de frontend doorgesluisd worden.

Aanbeveling

Optie C geeft de meeste waarde — adviseurs zien vóór indienen wat er nog mist. De infrastructuur bestaat al (validateXml in hdn-sdk), het is een frontend-integratie.

Optie B is een bonus: na indienen de validatiemelding van de geldverstrekker tonen.

Notion item: rente tool: kan er een vergelijking komen met meerdere aanbieders?

Status: DESIGN READY

Prioriteit: Middel

Geschatte effort: 1-2 weken

Wie: Max (backend + frontend)

Aangemaakt: 15 juli 2025

---

Context

De rente tool toont nu rentetarieven per individuele geldverstrekker. De vraag is om meerdere aanbieders naast elkaar te vergelijken — cruciaal voor het adviesgesprek.

Huidige implementatie

Interest sheets pipeline:

• Geldverstrekkers sturen rentetarieven per email naar Postmark
• `interestSheetManager.ts` verwerkt emails → extraheert PDFs
• Opgeslagen in `interest_sheet` tabel (met lender, date, attachment URL)
• Frontend: `InterestMails.vue` toont per geldverstrekker

Database schema:

inbound_email → interest_email → interest_sheet
                                  ├── lender
                                  ├── date
                                  └── attachment (Azure Blob)

Probleem

De rentetarieven zitten nu als PDF bijlagen opgeslagen — niet als gestructureerde data. Een vergelijking vereist dat de tarieven geëxtraheerd worden uit de PDFs.

Oplossing

Fase 1: Gestructureerde tarievenopslag

Nieuw database schema:

interestRate {
    id: uuid,
    lenderId: string,
    productName: string,
    nhgApplicable: boolean,
    fixedPeriodMonths: number,      // 1, 5, 10, 15, 20, 30
    ltv: number,                     // 0-100%
    rate: number,                    // bijv. 3.45
    effectiveDate: date,
    sourceSheetId: uuid,             // link naar interest_sheet
}

Fase 2: PDF → gestructureerde data

Opties:

• **AI extractie:** Claude Sonnet parse de PDF → JSON met tarieven
• **Handmatig:** Admin voert tarieven in via een formulier
• **Combinatie:** AI extraheert, admin valideert

Fase 3: Vergelijkingsweergave

Frontend component:

• Filters: NHG ja/nee, rentevaste periode, LTV range
• Tabel: geldverstrekkers als rijen, periodes als kolommen
• Sortering op rente (laagste eerst)
• Export naar PDF voor adviesgesprek

Openstaande vragen

• Hoe vaak worden tarieven bijgewerkt? (Wekelijks? Dagelijks?)
• Hoeveel geldverstrekkers sturen al tarieven via email? (Alle 32+ of een subset?)
• Mag de vergelijking naar de klant getoond worden of alleen intern?

Aanbeveling

Start met Fase 2 + 3 — AI extractie uit bestaande PDFs + vergelijkingstabel. De data is er al (emails komen binnen), het ontbreekt alleen aan parsing en weergave.

Notion item: toevoegen beheernorm tabellen

Status: NEEDS RESEARCH

Prioriteit: Laag (oud item, 2023)

Geschatte effort: Onderzoek 4 uur, implementatie 1-2 weken

Wie: Gustaaf (functioneel), Arnold (implementatie)

Aangemaakt: 1 november 2023

---

Context

Beheernormen bepalen de maximale hypotheeklast op basis van inkomen. Dit is anders dan de woonquote — beheernormen zijn absoluut (in euro's per maand) terwijl de woonquote een percentage is.

Huidige staat

Niet gevonden in de codebase. De beheernorm-berekening ontbreekt volledig. Waarschijnlijk wordt dit nu door geldverstrekkers zelf getoetst.

De parameters.ts bevat wel gerelateerde parameters (woonquote, toetsrente, NHG grenzen) maar geen beheernormtabellen.

Vraag

Is dit item nog relevant? Beheernormen worden door de meeste geldverstrekkers zelf getoetst na ontvangst van de aanvraag. De toegevoegde waarde voor LoanLink zou zijn:

• Pre-screening: adviseur ziet vooraf of een aanvraag aan de beheernorm voldoet
• Vergelijking: welke geldverstrekker past bij dit inkomen?

Aanbeveling

Prioriteit herbeoordelen. Dit item is 2,5 jaar oud. Navragen bij het team of er concrete vraag is vanuit adviseurs, of dat dit achterhaald is door andere functionaliteit.

Notion item: graag mogelijkheid om verschillende berekeningen te kunnen maken in 1 dossier

Status: NEEDS DESIGN

Prioriteit: Middel

Geschatte effort: 2-4 weken

Wie: Max (architectuur), Arnold (implementatie)

Aangemaakt: 9 augustus 2023

---

Context

Adviseurs willen meerdere hypotheekscenario's naast elkaar berekenen binnen één klantdossier — bijv. "wat als we 10 jaar vast nemen" vs "wat als we 20 jaar vast nemen" of "met NHG" vs "zonder NHG".

Huidige architectuur

Elk dossier heeft één financing-opzet:

dossier → customers, property, financing (1:1)
financing → mortgageParts[]

Er is geen concept van "scenario" of "variant" in het datamodel.

Oplossing

Optie A: Scenario's als kopieën van financing

dossier → customers, property
       → scenarios[] (was: financing)
           → scenario[0] "Basis" → mortgageParts[]
           → scenario[1] "Alternatief NHG" → mortgageParts[]

Impact: groot — raakt het hele datamodel, Zero sync, HDN mapping, alle formulieren.

Optie B: Vergelijkingsweergave zonder datamodel-wijziging

"Kopieer financiering" → maakt een nieuw dossier aan met dezelfde klant/woning maar andere financiering. Vergelijkingsweergave toont beide dossiers naast elkaar.

Impact: klein — alleen UI, geen datamodel-wijziging.

Optie C: Snelle "what-if" calculator

Losse tool (geen dossier-wijziging) waar je snel bedragen/periodes/rentes kunt variëren en het verschil ziet. Zoals een spreadsheet-achtige interface.

Aanbeveling

Optie B als pragmatische oplossing — hergebruik bestaand datamodel, voeg alleen UI-vergelijking toe. Optie A is de juiste lange-termijn oplossing maar raakt te veel code voor nu.

Openstaande vragen

• Hoeveel scenario's typisch? 2-3 of meer?
• Moet de vergelijking ook naar de klant (bijv. als PDF)?
• Hoe verhoudt dit zich tot de rente-vergelijking (SPEC-013)?

Notion item: graag nhg berekening anders, werkt nu suboptimaal

Status: NEEDS CLARIFICATION

Prioriteit: Middel

Geschatte effort: Onbekend (afhankelijk van wat "suboptimaal" is)

Wie: Arnold (berekeningen)

Aangemaakt: 7 augustus 2023

---

Context

De NHG-berekening werkt "suboptimaal" maar het is onduidelijk wat precies het probleem is.

Huidige implementatie

parameters/nhgPremie.ts: Premiepercentages per jaar (0.4% in 2025)

parameters/nhgKostengrens.ts: Kostengrens per jaar (€470.000 in 2026)

De berekening lijkt beperkt tot:

• Eligible? → financieringsbedrag ≤ kostengrens
• Premie = financieringsbedrag × premiepercentage

Mogelijke problemen

1. Kostengrens berekening: NHG kostengrens is niet simpelweg de koopsom — het is koopsom + bijkomende kosten (overdrachtsbelasting, notaris, taxatie, etc.) minus eigen middelen. Is deze berekening correct?

2. Energiebesparende voorzieningen: NHG staat extra financiering toe voor energiebesparende maatregelen (max 6% bovenop kostengrens). Wordt dit meegenomen?

3. Toetsrente: NHG gebruikt soms een afwijkende toetsrente. Wordt dit correct berekend?

4. Voorwaarden check: Voldoet de klant aan alle NHG-voorwaarden (bijv. woonfunctie, geen belegging)?

Aanbeveling

Verduidelijking nodig. Dit item is bijna 3 jaar oud. Navragen:

1. Is het probleem nog actueel? (Parameters zijn sindsdien al meerdere keren bijgewerkt)

2. Wat is precies "suboptimaal" — de berekening, de weergave, of de NHG-voorwaarden?

3. Zijn er concrete aanvragen die fout gaan door de huidige NHG-logica?

Notion item: hoe gaan we wijzigingen zoals leennormen, (fiscale) wetgeving borgen in de tool?

Status: PARTIALLY ADDRESSED

Prioriteit: Middel (proces/governance)

Geschatte effort: Doorlopend proces

Wie: Gustaaf (eigenaar), team (uitvoering)

Aangemaakt: 2 februari 2023

---

Context

Hypotheekwetgeving en leennormen wijzigen jaarlijks. Hoe zorgen we dat LoanLink altijd actueel is?

Wat al geregeld is

parameters.ts — Versiebeheer per jaar:

• NHG premie: versied t/m 2025
• NHG kostengrens: versied t/m 2026
• Overdrachtsbelasting: versied t/m 2026 (incl. 10.4%)
• Maximale aftrek: versied t/m 2023
• Toetsrente/woonquote: versied

HDN schema's: Multi-versie support (24.0, 25.0, 26.0) met automatische schema-switching op basis van starting_date.

Leennormen 2024: Uitgewerkt en geïmplementeerd (TASKS.md: "uitzoeken nieuwe leennormen 2024" = Afgehandeld).

Wat ontbreekt

1. Proces: Geen formeel proces voor het detecteren van nieuwe wijzigingen

2. Alerting: Geen monitoring op wijzigingen in wet-/regelgeving

3. Testing: Geen automatische test dat parameters up-to-date zijn

4. Documentatie: Geen changelog van parameterwijzigingen

Aanbeveling

Jaarlijks proces (december/januari):

1. Check NHG website voor nieuwe kostengrens/premie

2. Check Nibud voor nieuwe leennormen

3. Check Belastingdienst voor fiscale wijzigingen

4. Update parameters.ts met nieuwe jaarcijfers

5. Update HDN schema's indien nieuwe versie

6. Run testharnas om impact te verifiëren

Automatisering (nice-to-have):

• Scheduled task die NHG/Nibud websites checkt op wijzigingen
• Alert naar team als er nieuwe publicaties zijn
• Parameter-validatie test: "zijn er parameters voor volgend jaar?"

Dit is grotendeels een organisatorisch vraagstuk, niet technisch. Het jaarlijks proces kan in een checklist worden vastgelegd.