Importere bankutdrag¶

Før du kan avstemme en bankkonto må banktransaksjonene være tilgjengelige i ePortal. Du henter dem enten fra regnskapssystemet (Visma Business / NXT) eller laster opp en CAMT.053-fil eksportert fra nettbanken. Samme rutine kjøres normalt månedlig i forkant av avstemming.

For NXT-import henter ePortal banktransaksjoner og hovedbokslinjer i samme operasjon (to separate kall mot integrasjonen). For CAMT-import lastes kun banktransaksjonene inn — hovedbokslinjer må hentes separat via ERP-importen i arbeidsbenken for den enkelte konto.

Tilgang¶

Hvem	Hva trengs
Modul	Bankavstemming (`moduleId: 42`) — verifisert i bank-reconciliation-routing.module.ts:20
Rutevakter	`ActivateService` + `ModuleGuard` på alle ruter under `/bank-reconciliation/*`
Tilleggsrettighet	`wv_BankAccountAccess` styrer hvilke bankkontoer en bruker ser i listen
Integrasjon	Aktiv NXT-/Visma-integrasjon, eller CAMT-fil fra nettbank

Mangler du modulrettighet vises ikke /bank-reconciliation/*-rutene i menyen. Mangler du kontorettighet ser du modulen, men kontoen er ikke synlig i oversikten.

Forutsetninger¶

Bankkontoen er opprettet i ePortal (se kontoadministrasjonen i Bankavstemming-modulen) med riktig kontonummer og koblet hovedbokskonto
Åpningssaldo er satt via Initialiser konto — ellers vil første periode mangle utgangspunkt for saldo
For NXT-import: integrasjonen mot regnskapssystemet er aktivert (se Konti Connect)
For CAMT-import: du har lastet ned filen fra nettbanken (formatet som støttes er CAMT.053, ISO 20022 XML)
I konsernoppsett står du på riktig regnskapsklient (AccountingClient) — bankkontoer er knyttet til én klient

Surfacer for import¶

ePortal har to inngangspunkter for import. Hvilken du bruker avhenger av om du vil hente data for én konto eller mange samtidig.

A) Dashboardet — bulkimport for alle kontoer¶

Dashboardet (/bank-reconciliation/dashboard, menyetikett Dashboard) har én importknapp i header — en delt knapp der hovedflaten kjører bulkimporten og pila åpner de øvrige importvalgene — bank-reconciliation-dashboard.component.html:24-46:

Valg	i18n-nøkkel	Effekt
Importer bank/regnskap (hovedflaten)	`BankReconciliation.importAllAccounts`	Kjører ERP-import (banktransaksjoner + hovedbokslinjer) for alle aktive kontoer i listen, sekvensielt
Import fra fil (under pila)	`BankReconciliation.camtImportButton`	Åpner CAMT-modalen for opplasting av CAMT.053-fil(er)

I tillegg kan du importere én konto direkte fra tabellraden: en konto uten import viser tilstanden Ikke importert i statuskolonnen, med en Importer nå-lenke i samme kolonne, som kjører samme sekvens for bare den kontoen — bank-reconciliation-dashboard.component.ts:1369 importAccountNow. (Fram til BRQ-39 satt denne lenken i sist-importert-kolonnen sammen med datoen; den flyttet til statuskolonnen da de tre separate statussignalene ble samlet til én kolonne — se Bankavstemming-modulen.)

Bulkimporten itererer over filteredOverviewItems.filter(a => a.isActive) og kaller importBankTransactions etterfulgt av importLedgerEntries for hver konto — bank-reconciliation-dashboard.component.ts:1323 importAllAccounts. Datofiltrene er låst til dateFrom = undefined og dateTo = dashboard-dateTo (datovelgeren oppe i header, "forrige måned" som standard). Backenden klemmer da effectiveDateFrom til kontoens ReconciliationStartDate + 1 dag — kontoen er avstemt til og med selve cutoff-datoen, så det ordinære vinduet begynner dagen etter den; samme regel gjelder for både banktransaksjoner og hovedbokslinjer — BankReconciliationService.cs:241-256 / :362-377.

BRQ-13: hvis banktransaksjons-importen for en konto feiler (success: false, f.eks. fordi rader ikke lot seg lagre), kjøres ikke hovedboks-importen for akkurat den kontoen — bulkimporten går videre til neste konto, og den feilede telles i feilsummen som gjør at avsluttende toast vises som advarsel i stedet for suksess. Regelen ligger i én delt metode (importAccountTransactions, bank-reconciliation-dashboard.component.ts:1279 importAccountTransactions) som både bulkimporten og rad-importen bruker, så begge veier stopper likt.

B) Arbeidsbenken — én konto, full kontroll¶

Fra dashboardet klikker du på en rad eller pila under Åpne avstemming for å gå til /bank-reconciliation/reconcile/:id. Der finner du knappen Importer (bank-reconciliation-workspace.component.html:41) som åpner en modal med to faner (bank-reconciliation-workspace.component.html:924-988):

Fra regnskapssystem (importFromErpTab) — separat fra-/til-dato, kjør import
Fra fil (CAMT) (importFromFileTab) — embedder samme <app-camt-file-import> som dashboardet bruker

Her kan du velge eksakt datointervall (fra/til), og resultatet vises som meldingsbobler under skjemaet før modalen lukkes.

BRQ-13: feiler banktransaksjons-importen (success: false), kjøres hovedboks-importen ikke — sekvensen stopper, boblen for banktransaksjoner vises rød med en forklarende melding, og du får en feiltoast med den konkrete årsaken (eller en generisk melding hvis serveren ikke ga en). Lykkes banksiden men hovedbokssiden feiler, vises hovedboks-boblen rød og en egen feiltoast, mens de radene som faktisk kom inn på banksiden fortsatt vises — se bank-reconciliation-workspace.component.ts:1091-1145.

CAMT-importflyten¶

Komponenten <app-camt-file-import> styrer hele filimporten — samme komponent brukes i både dashboard-modalen og workspace-tabben.

Filvalidering¶

Filen kontrolleres mot tre regler — camt-file-import.component.ts:538-585:

Regel	Detalj
Filendelse	`.xml` eller `.bck` aksepteres (camt-file-import.component.html:16)
XML-innhold	Filen må starte med `<?xml` (sjekkes ved å lese første 512 byte) — camt-file-import.component.ts:527-536
Total størrelse	Maks 50 MB samlet for alle valgte filer — camt-file-import.component.ts:28

Feiler første eller andre regel, vises toast BankReconciliation.camtInvalidFileType. Feiler tredje regel, vises BankReconciliation.camtFileTooLarge. Serveren gjør full XML-validering + schema-sjekk senere.

Forhåndsvisning¶

Når du klikker Forhåndsvis import lastes filene opp via POST /api/BankReconciliation/PreviewCamtImport. Resultatet viser:

Antall kontoutdrag i fil(ene)
Antall transaksjoner totalt
Manglende kontoer (kontonumre i filen som ikke finnes som wv_BankAccount i ePortal)
Per-kontoutdrag tabell med periode, antall transaksjoner, sluttsaldo og status «Konfigurert» / «Ikke konfigurert»

Manglende kontoer¶

Er det manglende kontoer i fila vises de som en avhukingsliste — alle er forhåndsvalgt. Du har tre valg:

Opprett valgte kontoer (camtCreateSelectedAccounts) — åpner en wizard som lar deg sette type (Bank/CreditCard/Loan/Other/Intercompany), kontonavn, regnskapsklient, hovedbokskonto og valuta per konto, deretter initialisere åpningssaldo
Importer valgte (camtImportSelected) — kjører import og hopper over rader for ikke-opprettede kontoer
Tilbake til filopplasting (camtBackToUpload) — annullerer og lar deg starte på nytt

Kjør import¶

Klikk Importer nå (camtImportNow) for å laste data inn. Endepunktet er POST /api/BankReconciliation/ExecuteCamtImport. Resultatkortet viser «nye poster», «duplikater hoppet over» og «importerte kontoutdrag / totalt» — samt en rad per konto med antall, en «Feil»-kolonne og en statusmerkelapp (Importert / Delvis feilet / Feilet).

BRQ-13: endepunktet regner ut suksess ut fra faktisk lagrede rader, ikke bare at kallet ikke kastet unntak. Hvis én eller flere rader feiler å lagre, vises resultatet fortsatt (du ser nøyaktig hvor mange nye poster som kom inn), men toasten blir gul («delvis fullført») i stedet for grønn, og kontoraden(e) med feil får status «Delvis feilet» (noen rader kom inn) eller «Feilet» (ingen rader kom inn) — se BankReconciliationController.cs — ExecuteCamtImport og ExecuteCamtImportAsync.

ERP-importens datofilter¶

Når du henter fra NXT, brukes ulike GraphQL-felter på de to sidene — verifisert i VismaBusinessNXTBankDataProvider.cs:

Alle tre henter på valuteringsdato, med bilags-/bokføringsdato som reserve når raden ikke har valuteringsdato:

Datatype	Valuteringsdato	Reserve	Referanse
Banktransaksjoner	`interestDate`	`bookingDate`	BuildBankTransactionsQueryByInterestDate / ByBookingDate
Hovedboksposter (GL)	`valueDate`	`voucherDate`	BuildLedgerTransactionQueryByValueDate / ByVoucherDate
Subreskontro (kunde/leverandør)	`valueDate`	`voucherDate` (BRQ-34 S1)	BuildSubledgerTransactionQueryByValueDate / ByVoucherDate

accountStatementTransaction har ikke noe valueDate-felt i NXT — interestDate er valuteringsdatoen der (samme felt som IntDt on-prem).

Reserveaksen er nødvendig fordi rene GL-posteringer (f.eks. konsernintern reskontro) mangler valuteringsdato, så et filter på valuteringsdato alene ville returnert tomt sett for dem. En manglende dato kan komme fra NXT som enten 0 eller null — begge feltene er nullbare Int i introspeksjonen — og begge behandles likt: datoen regnes som satt bare når den er større enn 0. Tidligere ble hele hovedboksspørringen filtrert på bilagsdato; nå hentes hver akse for seg og slås sammen, slik at det bare er radene som faktisk mangler valuteringsdato som blir liggende igjen på bilagsaksen.

Grunnen til at valuteringsdato er riktig akse: det er datoen resten av modulen bruker når den avgjør hvilke rader som hører til perioden. Hentet vi på bokføringsdato, ville en rad bokført på avstemt-til-og-med-datoen men valutert etter den aldri blitt hentet — og dermed aldri kunne matches (eierbeslutning 2026-08-05, BRQ-32). Samme regel gjelder on-prem Visma Business, der prosedyrene filtrerer COALESCE(NULLIF(valuteringsdato, 0), bilagsdato).

Konsekvenser:

Hvis du venter på sene banktransaksjoner, utvid dateTo noen dager — duplikater blokkeres uansett av ExternalID-deduplikering
Hvis bilag er postert i forrige periode men selve banktransaksjonen kommer først nå, kan periodene se ut til å avvike — utvid datointervallet til å dekke etterslepet

Lagring og deduplikering¶

Når importen kjøres, gjør service- og repository-laget følgende — banktransaksjonene i BankReconciliationRepository.ImportBankTransactionsAsync (BankReconciliationRepository.cs:1336-1554):

Henter alle eksisterende ExternalID for kontoen i én batch (ikke per rad)
Skipper innkommende rader der ExternalID allerede finnes
Gjør en sekundær kryss-kilde sjekk for å fange tilfeller der samme transaksjon er importert via Visma (VB_*/NXT_*-prefiks) og senere via CAMT (CAMT_*-prefiks) med ulik ExternalID
Skriver banktransaksjoner til wv_BankTransaction
CAMT-detaljrader (AcStmtDe) lagres til wv_BankTransactionDetail for sporbarhet — egen metode, BankReconciliationRepository.ImportBankTransactionDetailsAsync (BankReconciliationRepository.cs:1708)
Hovedbokslinjer skrives til wv_LedgerEntry (kun ved ERP-import) — egen metode, BankReconciliationRepository.ImportLedgerEntriesAsync (BankReconciliationRepository.cs)
Banktransaksjoner hvis effektive dato (valuteringsdato, ellers bokføringsdato) er på eller før ReconciliationStartDate droppes før lagring (steg 1-4 over) — kontoen er avstemt til og med den datoen (vinduet er strengt "etter", ikke "fra og med") — BankReconciliationService.cs:277-294. Hovedbokslinjer droppes bare når de har en valuteringsdato som ligger på eller før grensen; en linje uten valuteringsdato beholdes bevisst her — den plasseres i stedet på sin bilagsdato andre steder i modulen og ekskluderes fra automatisk matching på grunn av manglende valuteringsdato. Dette er et kjent, bevisst avvik fra effektiv-dato-regelen ellers i modulen (eies av BRQ-32, ikke endret av BRQ-36) — BankReconciliationService.cs:397
En revisjonsrad skrives via LogBankRecAuditAsync ved hver vellykket import — kalles fra service-laget, ikke repository (LogBankRecAuditAsyncs egen definisjon i BankReconciliationRepository.cs)

Returnerte tellinger på UI:

newRecords — rader som faktisk ble lagt til
skippedDuplicates — TotalFromSource - NewRecords (inkluderer både ExternalID-treff og pre-start-drop)
errors — antall feilrader. BRQ-13: errors > 0 gjør at hele svaret rapporteres som success: false (både for ERP-import og CAMT-import) — en kjøring med feilede rader er ikke lenger en stille suksess.

Slik gjør du — månedsimport¶

Antar at åpningssaldo og bankkonto allerede er på plass.

Gå til Bankavstemming → Dashboard (URL /bank-reconciliation/dashboard).
I konsernoppsett: velg selskap i selskaps-filteret (Alle selskaper eller én klient).
Sjekk datovelgeren oppe i header — denne styrer dateTo for bulkimport og periodeoversikten. Bruk pil-knappene (prevMonth/nextMonth) for å gå én måned bakover/forover.
Klikk Importer bank/regnskap (btn-action-outline, ikon bi-cloud-download) for å hente alt ERP-data. Progress-teksten viser «Importerer X av Y: kontonavn …» under kjøringen.
Vent på avsluttende toast — BankReconciliation.importAllDone med antall nye poster og duplikater.
Vil du i tillegg laste opp CAMT-fil(er): klikk Import fra fil, dra og slipp filene (eller bruk Velg filer), klikk Forhåndsvis import, opprett evt. manglende kontoer, og klikk Importer nå.
Bekreft at saldoene i kontoraden ser fornuftige ut: kolonnene Bank-saldo, Hovedboks-saldo og Differanse skal stemme mot dine kilder.
Klikk på en rad for å åpne arbeidsbenken og fortsette med matche transaksjoner.

Re-import fyller inn manglende felter¶

En ny import overskriver ikke rader som allerede finnes, men den fyller inn felter som manglet:

Felt	Fylles inn når	Hvorfor det står tomt
Valuteringsdato	Feltet er tomt fra før	Rader importert før feltet fantes
Valutanummer	Feltet er tomt fra før	Rader importert før feltet fantes

En kjent verdi overskrives aldri. Så lenge valutanummeret mangler, skiller systemet kontovaluta fra andre valutaer på valutakoden alene, og saldoen er foreløpig — antallet slike rader vises per konto på kontooversikten.

Vanlige problemer¶

«CAMT-filen blir avvist ved opplasting»¶

Toast med teksten fra BankReconciliation.camtInvalidFileType eller BankReconciliation.camtFileTooLarge.

Årsak: Filen har ikke .xml/.bck som filendelse, starter ikke med en XML-deklarasjon, eller den totale størrelsen overstiger 50 MB.

Løsning: Be banken om en ny eksport i CAMT.053-format. Hvis filen er for stor, del opp eksporten per konto eller per uke i nettbanken.

«Manglende kontoer» i forhåndsvisningen¶

Forhåndsvisningen viser kontonumre fra fila som ikke finnes i wv_BankAccount.

Årsak: Bankkontoen er ikke opprettet i ePortal, eller den ligger på en annen regnskapsklient enn den du står på.

Løsning: Bruk Opprett valgte kontoer direkte i CAMT-flyten — wizarden hjelper deg med å registrere konto, hovedbokstilknytning, valuta og initialisere åpningssaldo. Alternativt: bytt regnskapsklient og kjør forhåndsvisning på nytt.

«NXT-importen returnerer 0 nye rader»¶

Du forventet transaksjoner, men newRecords = 0 og alt går til skippedDuplicates.

Årsak: Vanligste:

Alle rader var allerede importert (forrige kjøring fanget dem)
Postert bilag og bankuttrekk har flere dagers gap, og datointervallet du valgte får bare med den ene siden — begge sider hentes på valuteringsdato, men bank og regnskap kan likevel ha ulik valuteringsdato på samme transaksjon
Bankkontoens LedgerAccountNo peker mot feil hovedbokskonto i NXT
NXT-integrasjonen returnerer feil mandant (sjekk AccountingClient på kontoen)

Løsning: Utvid datointervallet med noen dager i hver retning (duplikater blokkeres automatisk), verifiser hovedbokskontonummeret mot NXT, og se etter feilmeldinger i loggen under Konti Connect.

«Importen feiler med besked om reconciliation start date»¶

Du ser effectiveDateFrom klempes til en senere dato enn du valgte, eller du får advarsel om at fra-dato er låst.

Årsak: Kontoen har en ReconciliationStartDate satt under initialiseringen ("avstemt til og med", se Initialisere bankkonto), og denne overstyrer brukervalgt dateFrom: ordinære rader kan tidligst dateres dagen ETTER denne datoen, siden cutoff-datoen selv allerede er dekket av åpningssaldoen — samme +1 dag-regel gjelder for både banktransaksjoner og hovedbokslinjer (BankReconciliationService.cs:241-256 / :362-377). Rader datert på eller før denne datoen droppes også på vei inn, men banksiden og hovedbokssiden bruker ulike regler: banktransaksjoner droppes alltid på sin effektive dato (valuteringsdato, ellers bokføringsdato) (BankReconciliationService.cs:277-294), mens hovedbokslinjer kun droppes når ValueDate er satt OG ligger på eller før startdatoen — en linje uten verdidato beholdes bevisst her, fordi den senere plasseres på sin bilagsdato andre steder i modulen (BankReconciliationService.cs:397).

Løsning: Hvis du faktisk trenger eldre data, må ReconciliationStartDate flyttes på kontoen via Initialiser-flyten. Dette er bevisst design — eldre rader ville ikke ha en gyldig åpningssaldo å regne mot. Har du utestående poster fra før cutoff som fortsatt skal kunne matches, legg dem inn som åpneposter i stedet — se Initialisere bankkonto.

«Import av hovedbokslinjer kjørte ikke etter banktransaksjons-import»¶

Du ser kun bank-boblen/-raden, ikke hovedboks-resultatet, og en rød feilmelding.

Årsak: Banktransaksjons-importen feilet (én eller flere rader kunne ikke lagres). ePortal stopper da bevisst sekvensen i stedet for å importere hovedbokslinjer mot et banktransaksjonssett som ikke ble fullstendig lagret (BRQ-13).

Løsning: Se feilmeldingen i toasten for konkret årsak, rett opp (f.eks. midlertidig NXT-feil, låst rad) og kjør Importer på nytt. Kjør deretter hovedboks-importen når banksiden er ren.

«Saldoen i ePortal stemmer ikke med banken etter importen»¶

Differansen blir ikke null selv etter ny import.

Årsak:

Åpningssaldo er ikke satt eller satt feil
Det er åpne transaksjoner fra forrige periode som ikke er importert
ERP-side mangler hovedbokslinjer for samme periode (CAMT importerer kun banksiden)

Løsning: Bekreft åpningssaldo via Initialiser-modalen, sjekk at forrige periode er korrekt avstemt, og kjør ERP-importen i arbeidsbenken slik at hovedbokslinjer også er på plass.

Konsekvenser for andre¶

Avstemming kan først starte når begge sider er importert — bank- og hovedboksrader på samme konto for samme periode
Konsernavstemming krever at importen er kjørt på alle datterselskap før konsernavstemming viser meningsfulle tall
Audit-spor — hver importert rad har ExternalID og SourceSystem lagret i wv_BankTransaction / wv_LedgerEntry, så man kan spore tilbake til kildesystemet
Matcher (wv_BankReconciliationMatch) berøres ikke direkte av import — kun nye rader på bank-/hovedboks-siden gjør avstemmingsoversikten større

Relaterte sider¶

Matche transaksjoner — neste steg etter import
Manuell matching — for transaksjoner som auto-match ikke fant par til
Konsernavstemming — bruker importerte data på tvers av selskap
Bankavstemming-modulen — modul-oversikt og kontoadministrasjon
Konti Connect — for å verifisere NXT-integrasjonen
Feilsøking — Bankavstemming