Nordlet

← Grunnleggende / SDK-er

Bank- og betalingsimport

camt.053-kontoutskrifter, Stripe CSV, avstemming av PSP-utbetalinger og egendefinerte JSON-strømmer.

Alle importer lander som banktransaksjoner på en bankkonto (bank/accounts/create). Transaksjoner har en externalId. Det er trygt å importere den samme filen på nytt, siden rader der (bankAccountId, externalId) allerede finnes, blir hoppet over og rapportert i skipped-telleren. Importerte transaksjoner starter med statusen new og blir bare bokført i hovedbokføringen når de avstemmes (bank/transactions/match, med bank/transactions/suggest-matches for kandidater).

Nettoppløsningen viser de samme importene under Bank → Importer fil (filopplasting, malvelger).

En feilaktig avstemming angres med bank/transactions/unmatch (Fjern avstemming under Bank → Transaksjoner). Bokførte posteringer blir aldri redigert eller slettet: en betaling som er avstemt mot en faktura, eller en linje som en importmal har bokført på en konto, får en reverserende bilagstransaksjon med alle oppføringer på motsatt side, datert med date (standard: i dag, og aldri før den opprinnelige posteringer). Fakturaens betalte beløp og betalingsstatus går tilbake med beløpet på den banklinjen. En linje som er knyttet til en betalingsleverandørutbetaling (PSP-utbetaling), blir bare fjernet fra tilknytningen, fordi posteringen for utbetalingen tilhører bunken. Linjen går tilbake til statusen new og kan avstemmes på nytt. Reverseringsdatoen må falle innenfor en åpen regnskapsperiode.

Importmaler

En importmal navngir en datakilde, lister opp feltene som kilden leverer, og tilknytter feltene som inneholder penger, til hovedbokskontoer. Maler administreres under Bank → Importmaler og via bank/import-templates/create|update|delete|get|list.

POST /v1/bank/import-templates/create
{
  "name": "Stripe payments export",
  "type": "stripe",
  "fields": [
    { "name": "id" },
    { "name": "Created date (UTC)" },
    { "name": "Amount" },
    { "name": "Fee", "accountCode": "6800" },
    { "name": "Amount Refunded" }
  ],
  "metaFields": ["order_id"]
}
  • type er en av stripe, iso20022, bank_connection eller revolut.
  • Hvert felt har et name (navn) og en valgfri accountCode (kontokode). Bare feltene som inneholder penger, godtar en konto: Stripe Amount, Fee og Amount Refunded; camt.053 Ntry/Amt; bankstrøm transaction_amount.amount. Kontoen må finnes i kontoplanen (opprett den med ledger/accounts/create).
  • fields kan utelates. Da brukes standard feltliste for typen: kolonnenavnene i filen for Stripe Payments → Export (uten de 19 Card …-kolonnene, som skjemaet også lar stå avhuket som standard), camt.053-elementene som enhver kontoutskrift inneholder (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), eller attributtene som en PSD2-bankstrøm returnerer per transaksjon. Legg til eller fjern oppføringer for å tilpasse filen din: importøren leser også de valgfrie camt.053-elementene Ntry/ValDt, Ntry/NtryRef, Ntry/AcctSvcrRef, Ntry/AddtlNtryInf, TxDtls/Refs/EndToEndId, TxDtls/Refs/TxId, TxDtls/RltdPties/Dbtr/Nm, TxDtls/RltdPties/DbtrAcct/Id/IBAN, TxDtls/RltdPties/Cdtr/Nm, TxDtls/RltdPties/CdtrAcct/Id/IBAN, TxDtls/RmtInf/Ustrd og TxDtls/AddtlTxInf.
  • Et Stripe-felt for Customer Email kan ha "createPartner": true. Importen oppretter deretter en kunde (partner av typen person, merket som kunde) for hver e-postadresse i filen som ikke finnes hos en eksisterende partner. Den bruker Customer Description som navn (eller e-postadressen hvis den er tom) og kolonnene Card Address … som adresse hvis filen inneholder dem. Eksisterende partnere gjenkjennes på e-postadresse, uavhengig av store og små bokstaver. Svaret rapporterer antallet i customersCreated.
  • metaFields (gjelder kun Stripe) lister opp metadatakøkene som belastningene dine inneholder. Stripe eksporterer hver nøkkel som en <key> (metadata)-kolonne; listen er fritekstbasert og kan være lang.
  • invoiceItemId (gjelder kun Stripe, valgfri) er en katalogartikkel. Når den er satt, refererer hver faktura- og kreditnotalinje som importen oppretter, til den artikkelen (dens postering og, når invoiceVatRatePercent er tom, dens mva-sats). Linjeteksten kommer fremdeles fra belastningen.
  • companyMetaField (gjelder kun Stripe) angir en av disse nøklene som bedriftsflagg. Når en belastning har true, 1, yes, company, business eller b2b i den kolonnen, blir kunden som opprettes for den, en partner av typen bedrift i stedet for person.
  • invoiceMetaField (gjelder kun Stripe) angir en av disse nøklene, for eksempel et ordrenummer, og invoiceVatRatePercent angir mva-satsen for fakturaer som opprettes fra den. Ved import blir hver belastnings- og refusjonsrad gruppert etter verdien til den nøkkelen:
    • en verdi som samsvarer med en eksisterende salgsfaktura (en salgsordre der externalRef er den verdien (ecommerce/orders/create, alle kanaler) eller en faktura der fullNumber er den verdien), knytter gruppen til den fakturaen
    • en verdi uten en faktura oppretter en ny: partner fra Customer Email (opprettes hvis den mangler, som for createPartner), én linje per belastning (Checkout Line Item Summary eller Description som tekst, beløpet på belastningen som en mva-inkluderende pris med invoiceVatRatePercent), utstedelsesdato = datoen for den første belastningen, mva-behandling fra bedriften og kortets land. Fakturaen utstedes og bokføres med en gang, og en salgsordre med kanalen stripe og den verdien som externalRef registreres slik at senere importer knytter i stedet for å opprette.
    • hver belastning i gruppen avstemmes deretter mot fakturaen som en betaling (bokføring av innbetalingen), og hver refusjon oppretter en utstedt kreditnota mot fakturaen for det refunderte beløpet og avstemmer refusjonen mot den. Antallene returneres som invoicesCreated, invoicesLinked, creditNotesCreated og paymentsMatched. Grupper som ikke kunne behandles (mangler e-postadresse for kunde, blandede valutaer, en tilknyttet faktura som fremdeles er et utkast eller allerede er fullt betalt), listes opp i warnings og blir stående som new-banktransaksjoner. Ikke koble Amount til en hovedbokskonto i den samme malen samtidig: en belastning som er avstemt mot en faktura, blir ikke bokført en gang til, men en som ikke er avstemt, ville blitt det.
  • Malnavnene er unike per bedrift.
  • camt.053- og banktilkoblingsmaler har de samme alternativene, men leser fra kontoutskriften i stedet for Stripe-kolonner:
    • Opprett manglende partnere: createPartner på raden for debitors navn (TxDtls/RltdPties/Dbtr/Nm, strøm debtor.name) oppretter en kunde for hver ukjente betaler av innkommende penger, og på raden for kreditors navn (TxDtls/RltdPties/Cdtr/Nm, strøm creditor.name) en leverandør for hver ukjente mottaker av utgående penger. Partnere gjenkjennes etter IBAN (lagret i partner_bank_accounts) og deretter på nøyaktig navn. En ny partner er en bedrift hvis navnet inneholder en selskapsform (UAB, MB, SIA, GmbH, Ltd, …), og ellers en person. Antallet returneres som customersCreated (filimport) eller partnersCreated (strømsynkronisering).
    • Knytt fakturaer etter referanse: invoiceMetaField satt til en betalingsinformasjons- eller referanserad (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; strøm remittance_information, reference_number) avstemmer hver nye banklinje der referansen, betalingsinformasjonen eller beskrivelsen inneholder nummeret til en åpen utstedt salgsfaktura (penger inn) eller registrert kjøpsfaktura (penger ut), og bokfører betalingen. Når betalerens IBAN er lagret på en partner, eller betalerens navn samsvarer med en partners navn eller kode, må fakturaen tilhøre den partneren. En betaling fra en ukjent betaler knyttes bare til hvis den tilsvarer fakturaens gjenstående saldo og fakturanummeret inneholder seriemefikset sitt, slik at et rent tall som for eksempel et beløp, aldri blir oppfattet som en referanse. En betaling som er større enn den gjenstående saldoen, knyttes aldri til. Linjer som ikke består disse kontrollene, forblir nye for manuell avstemming og listes opp i advarslene (warnings). Med advanceInvoices: true vil en ikke-avstemt innkommende betaling fra en kjent partner opprette en utstedt forskuddsfaktura (type advance) for beløpet med invoiceVatRatePercent eller mva-satsen til invoiceItemId, og avstemme betalingen mot den. Partneren må være kjent, så huk også av for debitorraden.
    • Bokføringsregler etter transaksjonskode: I tillegg til Ntry/Amt / transaction_amount.amount har feltlisten regnrader som Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (strøm: bank_transaction_code=…, credit_debit_indicator=…). En linje bokføres på kontoen for den første regelen den oppfyller: først banktransaksjonskundefamilien, deretter retningen, og til slutt den vanlige beløpsraden. Regnrader sjekkes ikke opp mot filen.
    • Bankomkostningspartner: createPartner på regnraden …=CHRG oppretter en leverandør oppkalt etter banken (utskriftens Stmt/Acct/Svcr/FinInstnId/Nm, eller banken til tilkoblingen, eller navnet på bankkontokontoen i hovedboken) og bokfører hver omkostning med den partneren.
    • Banktilkoblingsmaler velges per strømkonto med bank/feeds/accounts/configure (Bank → Tilkoblinger i appen), som også setter syncSchedule (manual, daily, weekly, monthly). API-et synkroniserer kontoer med en tidsplan automatisk når perioden deres har utløpt. Maler anvendes ved hver bank/feeds/sync. Synkroniseringsresponsen rapporterer deretter også posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched og warnings.

Send templateId til bank/statements/import i stedet for format. Malens type velger parseren, og filen må inneholde hvert felt som er oppført i malen. En fil der et felt mangler, avvises med HTTP 422 og navnene på de manglende kolonnene eller elementene. Metadafeltene er ikke påkrevd å være til stede. Banktilkoblingsmaler beskriver en live PSD2-strøm og kan ikke brukes til filimport.

En ISO 20022-mal leser også MT940-filer: en fil som starter med {1: eller :20: (eller sendes med "format": "mt940"), blir tolket som MT940, og malens referanseavstemming og bokføringsregler anvendes på linjene i den. Elementkontrollen hoppes over for MT940, og regler med Ntry/BkTxCd=… gjelder aldri for MT940-linjer, siden MT940 ikke inneholder noen ISO 20022-banktransaksjonskode. Bruk Ntry/CdtDbtInd=…-reglene i stedet.

En bankkonto har én valuta. En kontoutskrift i en annen valuta avvises med HTTP 422 (i en camt.053-fil med kontoutskrifter i flere valutaer for samme IBAN blir bare kontoutskriften i kontoens valuta importert), og det samme gjelder for en linje som sendes til bank/transactions/import med en annen valuta enn kontoens.

Enhver bevegelse som produseres fra et felt som har en accountCode, bokføres ved importtidspunktet som én enkelt bilagstransaksjon: penger inn debiterer bankkontoens hovedbokskonto og krediterer den tilknyttede kontoen, mens penger ut debiterer den tilknyttede kontoen og krediterer bankkontoens hovedbokskonto. Beløp omregnes til the basisvalutaen på bevegelsesdatoen. Banktransaksjonen blir deretter matched mot denne bilagstransaksjonen (matchedDocumentType = journal_transaction) og tilbys ikke lenger til fakturaavstemming. Svaret rapporterer antallet i posted. Bevegelser fra felter som ikke er knyttet til en konto, forblir new og avstemmes mot fakturaer som før. Du kan for eksempel knytte Fee til gebyrkostnadskontoen for PSP og la Amount være uknyttet slik at belastninger fremdeles avstemmes mot salgsfakturaer.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "…",
  "content": "id,Created date (UTC),Amount,…"
}

ISO 20022 camt.053 (åpen bank-XML)

Litauiske banker (Swedbank, SEB, Luminor, Šiaulių bankas, …) lar deg laste ned kontoutskrifter som ISO 20022 camt.053 XML fra nettbanken din, vanligvis under eksport eller nedlasting av kontoutskrift med formatet "ISO XML" eller "camt.053". Det samme formatet returneres av PSD2-kontoinformasjons-API-ene.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • En fil kan inneholde flere kontoutskrifter. IBAN-en til hver kontoutskrift må samsvare med bankkontoens IBAN (kontoutskrifter uten IBAN eller kontoer uten IBAN godtas som de er).
  • Oppføringsreferanser (AcctSvcrRef/NtryRef, med fallbacks til en innholdshash) blir til externalId.
  • Svaret gjenspeiler metadata per kontoutskrift: kontoutskrifts-ID, periode, inngående og utgående saldo, samt transaksjonsantall.
  • Motpartens navn, IBAN og betalingsformål hentes ut per oppføring for avstemming.

Betalinger i den andre retningen eksporteres som pain.001 via bank/payments/export.

Revolut Business CSV

Last ned transaksjonskontoutskriften for en Revolut Business-konto som CSV, og importer den ved hjelp av den innebygde malen Revolut Business (templateId: "builtin-revolut"). Alle bedrifter har denne malen uten å måtte opprette den: bank/import-templates/list-builtin lister den opp, bank/import-templates/get returnerer den, og bank/import-templates/update og bank/import-templates/delete avviser den med HTTP 400. I appen er den oppført først under Bank → Importmaler. Åpning av malen viser innstillingene dens, og lagring oppretter en egen bedriftsmal som du kan endre.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}
  • Bare rader der State = COMPLETED blir importert. Andre rader (for eksempel PENDING) utelates og telles i warnings. De blir importert ved en senere import av en fil der de er fullført.
  • Hver rad blir til en banktransaksjon med datoen fra Date completed (UTC), beløpet fra Total amount, valutaen fra Payment currency, ID som externalId og Description som beskrivelse.
  • Motparten for utgående penger er Beneficiary name og Beneficiary IBAN. For en kortbetaling uten mottaker brukes anmelderen eller forhandleren i Description. Motparten for innkommende penger er Sender name og Sender account.
  • Rader grupperes etter konto og valuta. International account number må samsvare med bankkontoens IBAN, og bare rader i bankkontoens valuta blir importert.
  • For hver rad sjekker importøren at saldoen til forrige rad pluss Total amount tilsvarer Balance, og lister opp hver rad der den ikke gjør det, i warnings.
  • Filen må inneholde kolonnene Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name og Beneficiary name.

Ved hver import vil den innebygde malen:

  • opprette en kunde for hver ukjente avsender av innkommende penger, og en leverandør for hver ukjente mottaker eller kortforhandler for utgående penger, som beskrevet under Opprett manglende partnere ovenfor

  • avstemme hver rad der Reference eller Description inneholder nummeret til en åpen salgs- eller kjøpsfaktura, og bokføre betalingen i henhold til kontrollene under Knytt fakturaer etter referanse ovenfor

  • bokføre rader som ingen faktura matchet basert på Type, på kontoen for en bokføringsregel:

    Type Bokføringsregel Standardkonto Rumensk kontoplan Bokføring
    FEE bank.fees 6800 627 debiter regelens konto, krediter bankkontoens hovedbokskonto; partner: en leverandør oppkalt etter bankkontoen
    CARD_PAYMENT bank.cardPayments 6209 628 debiter regelens konto, krediter bankkontoens hovedbokskonto, uten mva
    TOPUP bank.topUps 3010 1012 debiter bankkontoens hovedbokskonto, krediter regelens konto

    Rader av andre typer, slik som TRANSFER, forblir new for manuell avstemming.

Endre kontoene med ledger/posting-rules/update. Den innebygde malen bruker de nye kontoene fra og med neste import. En bokføringsregel kan ikke slås av: Hvis du vil importere kortbetalinger eller påfyllinger uten å bokføre dem, kan du opprette en bedriftsmal av typen revolut uten radene Type=CARD_PAYMENT eller Type=TOPUP og importere med den. En kortbetaling som bokføres på denne måten, avstemmes ikke mot leverandørens faktura når den fakturaen registreres senere. Bokfør enten den ene eller den andre, ikke begge.

En bedriftsmal av typen revolut bruker de samme kolonnene og kan bokføre rader etter type ved hjelp av regnradene Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER og Type=TOPUP. Import med "format": "revolut-csv" og uten mal importerer radene uten noen av disse trinnene.

Stripe CSV

Eksporter fra Stripe-dashbordet (begge rapportene fungerer):

  • Reports → Balance → Itemized balance change from activity (anbefalt): kolonnene balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description.
  • Payments → Export: kolonnene id, Created (UTC), Amount, Fee, Currency, Description, Customer Description.
POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "stripe-csv",
  "content": "balance_transaction_id,created_utc,currency,gross,fee,net,…"
}

Opprett en dedikert bankkonto for Stripe (f.eks. med navnet "Stripe", hovedbokskonto 2710 eller en egen underkonto). Saldoen i Stripe fungerer som en bankkonto: belastninger flyter inn, gebyrer trekkes fra, og utbetalinger overfører saldoen til din reelle bankkonto.

Importoppførsel:

  • Hver saldotransaksjon blir til én banktransaksjon for det brutto beløpet (externalId = saldotransaksjons-ID).
  • Et ikke-null gebyr blir til en andre transaksjon med motsatt fortegn (externalId = <id>:fee, motpart "Stripe"), slik at gebyrer kan avstemmes/bokføres som kostnader atskilt fra omsetning. Gebyrer som returneres ved refusjoner, kommer inn som positive beløp.
  • Utbetalingsrader (Payout) importeres som enkeltstående negative transaksjoner. Avstem dem mot den tilsvarende innkommende transaksjonen på kontoutskriften til din reelle bankkonto.
  • Rader med null beløp hoppes over. Datoen hentes fra created_utc (UTC).
  • Betalingseksporterte rader som ikke flyttet noen penger, hoppes over: Captured = false (autorisasjoner / forsinkede fangster) og Status lik Failed/Canceled.
  • Et ikke-null Amount Refunded blir til en tredje, negativ transaksjon (externalId = <id>:refund) datert med Refunded date (UTC), slik at delvis og full refusjon som er inkludert i betalingsrader, ikke går tapt.

Avstemming av PSP-utbetalinger (Stripe-utbetalingsrapporter)

For å dele opp en samleutbetaling i de underliggende ordrene, refusjonene, gebyrene og tilbakeføringene, kan du bruke avstemmingsendepunktene i stedet for den vanlige kontoutskriftsimporten. To ulike Stripe-eksportformater godtas (detekteres automatisk):

  • Reports → Payouts → Payout reconciliation, itemized (rapporttyper payout_reconciliation.itemized.* eller payout_reconciliation.by_id.itemized.*): nøyaktig, én rad per saldotransaksjon. Foretrukket på live-kontoer.
  • Payments → Export (unified payments): eksporten på belastningsnivå. Fungerer i test-/sandkassemodus der utbetalingsavstemming ikke er tilgjengelig. Fullførte belastninger grupperes etter utbetalings-ID-en i Transfer-kolonnen. Ikke-fullførte / mislykkede rader hoppes over (skippedNotSettled). Et ikke-null Amount Refunded blir til en syntetisk refusjonslinje i belastningens utbetalingsbunke (en tilnærming, siden refusjonen kan ha blitt utbetalt i en senere utbetaling). Avstemmingsreferanser kommer fra belastnings-ID-en, PaymentIntent ID, Invoice Number, Client Reference ID og alle … (metadata)-kolonnene (f.eks. et ordrenummer i metadata).

Én CSV-fil kan omspenne mange utbetalinger. Stripe laster ned den spesifiserte rapporten én fil per seksjon (…_charge_…, …_refund_…, …_fee_…). Importer alle sammen: rader for en utbetaling som allerede er importert, flettes inn i den eksisterende bunken (rapportert i updated-telleren) så lenge den ikke er bokført enda, og bunkens totalsummer beregnes på nytt.

POST /v1/bank/settlements/import
{
  "bankAccountId": "…",
  "provider": "stripe",
  "content": "balance_transaction_id,created_utc,…,reporting_category,…,automatic_payout_id,…"
}

Importoppførsel:

  • Rader grupperes etter automatic_payout_id i utbetalingsbuker (én bunke per utbetaling, med bruttosum, gebyrer og nettosum; summen av radenes net er beløpet som treffer banken din). Ny import av en utbetaling hoppes over (skipped-telleren). Rader som ennå ikke er tilordnet en utbetaling, og selve payout-radene, hoppes over og teltes separat.
  • Hver belastnings-, refusjons- og tvisterad automatisk avstemmes mot en salgsfaktura ved hjelp av følgende i rekkefølge: en e-handelstransaksjons externalRef (enhver verdi fra order_id, payment_intent_id, source_id, charge_id eller en hvilken som helst *_metadata[...]-kolonne), et faktura-fullNumber som vises i disse kolonnene, og for refusjoner og tilbakeføringer, charge_id til en tidligere avstemt belastning (fra samme fil eller tidligere importer).
  • Gjennomgå med bank/settlements/list / bank/settlements/get; fiks gjenværende poster med bank/settlements/match { lineId, invoiceId } (eller invoiceId: null for å fjerne avstemmingen).

POST /v1/bank/settlements/post { id, date?, commissionPercent? } bokfører hele bunken som én balansert bilagstransaksjon og gjør opp de avstemte fakturaene (paidAmount/paymentStatus, webhooks for sale_invoice.paid):

  • Debiter hovedbokskontoen for bankkontoen for nettoutbetalingen; debiter PSP-gebyrer (settlements.fees, standard 6800) for tilbakeholdte gebyrer og gebyrrader.
  • Krediter kundefordringer per avstemt belastning. Refusjoner og tilbakeføringer reverserer dette. Beløpet begrenses oppad til hver fakturas gjenstående beløp, og eventuelt overskudd havner på mellomværendekontoen med en advarsel.
  • Ikke-avstemte belastninger: Når commissionPercent er satt, deles de inn i provisjonssum (settlements.commissionRevenue, standard 5001) og en selgerforpliktelse (settlements.sellerPayable, standard 4499), som er markedsplassflyten der innkrevde penger stort sett tilhører selgerne. Uten denne settes de på mellomværende (settlements.suspense, standard 4440, mottatte forskudd).
  • platform_earning-rader (applikasjonsgebyrer for Stripe Connect) bokføres på provisjonssum. transfer-rader (utbetalinger til tilknyttede selgere) reduserer selgerforpliktelsen.
  • Alle de fire kontoene kan overstyres per bedrift via bokføringsregler (ledger/posting-rules).
  • En linje hvis belastning, gebyr eller refusjon allerede ble importert til en annen bankkonto fra Stripe-betalingseksporten (bank/statements/import), bokføres ikke på gebyrer, fordringer eller mellomværende. Dens net-beløp krediteres bankkontoens hovedbokskonto i stedet, slik at Stripe-bankkontoen gjøres opp utbetaling for utbetaling. summary.clearedAmount er det totale beløpet som er flyttet på denne måten. En linje der beløpet avviker fra det kontoen inneholder, nevnes i warnings. Hvis ingenting gjenstår å bokføre, bokføres bunken med journalTransactionId satt til null.

bank/settlements/list og /get returnerer per bunke clearedNet, clearingDifference (utbetalingslinjer minus beløpene den andre bankkontoen inneholder for dem; null når de stemmer overens) og clearingOpenCount (linjer med en avvikende differanse eller en ubokført bevegelse). /get returnerer det samme per linje som clearingBankAccountId, clearingBooked, clearingDifference og clearingUnposted. Refusjonslinjer for én belastning sammenlignes samlet, fordi betalingseksporten bare inneholder det refunderte totalbeløpet. En Stripe-betalingseksport som importeres etter at utbetalingen ble bokført, hopper over bevegelsene for den utbetalingen og nevner den i warnings.

Mva på selve provisjonen faktureres separat (utsted en provisjonsfaktura til selgeren); oppdelingen fordeler bare de innkrevde kontantene.

Utbetalinger i en annen valuta

Bilaget skrives alltid i bedriftens basisvaluta, men en utbetaling i en annen valuta bokføres automatisk uten at det kreves manuell registrering:

  • Bunken omregnes med kursen for bokføringsdatoen (date, med fallback til utbetalingsdatoen og deretter dags dato). Kursen er bedriftens egen kurs for den valutaen (reference/exchange-rates/set) når den er minst like ny som den offisielle kursen, og ellers den nyeste offisielle kursen på eller før den datoen. Hvis det ikke finnes noen kurs på eller før datoen, mislykkes kallet med 422 og henviser til reference/exchange-rates/sync.
  • Hver konto omregnes med denne bunkekursen, bortsett fra kundefordringer, som gjøres opp til den valutakursen (fxRate) hver faktura ble utstedt med. Differansen mellom de to kursene bokføres på bank.fxGain (standard 5803) eller bank.fxLoss (standard 6803) som en realisert valutakursdifferanse, slik at bilaget fremdeles balanserer.
  • Svarets summary returnerer fxRate-en som ble brukt, og den resulterende exchangeDifference. Bunken beholder kursen den ble bokført med. En avstemt faktura hvis egen valuta avviker fra bunkens valuta, gjøres opp: beløpet går til mellomværendekontoen med en advarsel.
  • Én importgrense gjelder fremdeles: en enkelt utbetaling der radene blander flere valutaer, avvises med 422, og det samme gjelder for en ny import der valutaen avviker fra bunken som allerede er lagret for den utbetalingen.

Manuelle / egendefinerte strømmer

Alt annet kan sendes inn som ren JSON:

POST /v1/bank/transactions/import
{
  "bankAccountId": "…",
  "transactions": [
    { "date": "2026-07-01", "amount": "-25.00", "currency": "EUR",
      "counterpartyName": "…", "description": "…", "externalId": "unique-ref-1" }
  ]
}

Oppgi en stabil externalId per transaksjon for å sikre at nyimport er idempotent.