Nordlet

← Dokumentation / Guides

Bank- og betalingsimport

camt.053-kontoudtog, Stripe-CSV, afstemning af PSP-afregninger og tilpassede JSON-feeds.

Alle importer lander som bankposteringer på en bankkonto (bank/accounts/create). Posteringer har et externalId, og det er sikkert at genimportere den samme fil - rækker, hvor (bankAccountId, externalId) allerede findes, springes over og registreres i tælleren skipped. Importerede posteringer starter i status new og bogføres først på hovedbogen, når de afstemmes (bank/transactions/match, med bank/transactions/suggest-matches til kandidatforslag).

Webapplikationen viser de samme importer under Bank → Importér fil (filupload, skabelonvælger).

En forkert afstemning fortrydes med bank/transactions/unmatch (Fjern afstemning under Bank → Posteringer). Bogførte poster redigeres eller slettes aldrig: en betaling afstemt mod en faktura eller en linje, som en importskabelon har bogført på en konto, modtager en modposterende journalpost med alle poster på den modsatte side, dateret med date (standard: i dag, og aldrig før den oprindelige bogføring). Fakturaens betalte beløb og betalingsstatus rykkes tilbage med beløbet for den pågældende banklinje. En linje, der er knyttet til en afregning fra en betalingsudbyder (PSP-afregning), fjernes blot fra tilknytningen, da afregningsposteringen tilhører samleposten (batch). Linjen vender tilbage til status new og kan afstemmes igen. Modponeringsdatoen skal ligge i en åben regnskabsperiode.

Importskabeloner

En importskabelon navngiver en datakilde, lister de felter, kilden leverer, og knytter de felter, der indeholder pengebeløb, til hovedbogskonti. Skabeloner administreres under Bank → Importskabeloner 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 enten stripe, iso20022, bank_connection eller revolut.
  • Hvert felt har et name og en valgfri accountCode. Kun felter, der håndterer penge, kan knyttes til en konto: Stripe Amount, Fee og Amount Refunded; camt.053 Ntry/Amt; bank-feed transaction_amount.amount. Kontiene skal findes i kontoplanen (opret dem med ledger/accounts/create).
  • fields kan udelades, hvorefter standardfeltlisten for typen anvendes: kolonnenavnene fra filen Stripe Payments → Export (uden de 19 Card …-kolonner, som formularen også fravælger som standard), de camt.053-elementer, ethvert kontoudtog indeholder (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), eller de attributter, et PSD2-bank-feed returnerer pr. postering. Tilføj eller fjern poster, så de passer til din fil: importøren læser også de valgfrie camt.053-elementer 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 af typen Customer Email kan indeholde "createPartner": true. Importen opretter derefter en kunde (partner af typen person, markeret som kunde) for hver e-mailadresse i filen, som ikke findes i forvejen, ved at bruge Customer Description som navn (eller e-mailadressen, hvis denne er tom) og kolonnerne Card Address … som adresse, hvis filen indeholder dem. Eksisterende partnere matches på e-mail uafhængigt af store og små bogstaver. Svaret rapporterer antallet i customersCreated.
  • metaFields (kun for Stripe) lister de metadatanøgler, dine betalinger indeholder. Stripe eksporterer hver nøgle som en <key> (metadata)-kolonne; listen er frit definerbar og kan være lang.
  • invoiceItemId (kun for Stripe, valgfri) er en vare i kataloget. Når denne er angivet, refererer hver faktura- og kreditnotalinje, som importen opretter, til den pågældende vare (dens bogføring og, hvis invoiceVatRatePercent er tom, dens momssats); linjeteksten stammer dog stadig fra betalingen.
  • companyMetaField (kun for Stripe) udpeger en af disse nøgler som virksomhedsflag. Når en betaling har true, 1, yes, company, business eller b2b i den pågældende kolonne, oprettes kunden som en partner af typen virksomhed i stedet for person.
  • invoiceMetaField (kun for Stripe) udpeger en af disse nøgler, f.eks. et ordrenummer, og invoiceVatRatePercent angiver momssatsen for fakturaer oprettet på baggrund heraf. Ved import grupperes alle betalings- og refusionsrækker efter værdien af denne nøgle:
    • en værdi, der matcher en eksisterende salgsfaktura – en salgsordre, hvis externalRef er den pågældende værdi (ecommerce/orders/create, alle kanaler), eller en faktura, hvis fullNumber er den pågældende værdi – knytter gruppen til den pågældende faktura;
    • en værdi uden en matchende faktura opretter en ny: partner ud fra Customer Email (oprettes hvis den mangler, som ved createPartner), én linje pr. betaling (Checkout Line Item Summary eller Description som tekst, betalingsbeløbet som en pris inkl. moms med invoiceVatRatePercent), udstedelsesdato = den første betalingsdato, momsbehandling baseret på virksomheden og kortets land. Fakturaen udstedes og bogføres med det samme, og der oprettes en salgsordre med kanalen stripe og denne værdi som externalRef, så efterfølgende importer linker i stedet for at oprette nye;
    • hver betaling i gruppen afstemmes derefter mod fakturaen som en betaling (hvor indbetalingen bogføres); hver refundering opretter en udstedt kreditnota mod fakturaen for det refunderede beløb og afstemmer refunderingen herimod. Antallene returneres som invoicesCreated, invoicesLinked, creditNotesCreated og paymentsMatched; grupper, der ikke kunne behandles (mangler kunde-e-mail, blandede valutaer, en tilknyttet faktura der stadig er en kladde eller allerede er fuldt betalt), angives under warnings og efterlades som new-bankposteringer. Map ikke også Amount til en hovedbogskonto i samme skabelon: en betaling, der afstemmes mod en faktura, bogføres ikke en gang til, men en uafstemt betaling ville gøre det.
  • Skabelonnavne er unike pr. virksomhed.
  • camt.053- og bankforbindelsesskabeloner har de samme indstillinger, der læses fra kontoudtoget i stedet for fra Stripe-kolonner:
    • Opret manglende partnere: createPartner på debitornavnerækken (TxDtls/RltdPties/Dbtr/Nm, feed debtor.name) opretter en kunde for hver ukendt betaler af indgående midler; på kreditornavnerækken (TxDtls/RltdPties/Cdtr/Nm, feed creditor.name) oprettes en leverandør for hver ukendt modtager af udgående midler. Partnere genkendes via IBAN (gemt i partner_bank_accounts) og derefter på nøjagtigt navn; en ny partner klassificeres som virksomhed, hvis navnet indeholder en selskabsform (UAB, MB, SIA, GmbH, Ltd, …), og ellers som person. Antallet returneres som customersCreated (ved filimport) eller partnersCreated (ved feed-synkronisering).
    • Knyt fakturaer sammen via reference: invoiceMetaField sat til en meddelelses- eller referencerække (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; feed remittance_information, reference_number) matcher hver ny banklinje, hvis reference, meddelelse eller beskrivelse indeholder nummeret på en åben udstedt salgsfaktura (indgående midler) eller registreret købsfaktura (udgående midler), og bogfører betalingen. Hvis betalerens IBAN er gemt på en partner, eller betalerens navn svarer til en partners navn eller kode, skal fakturaen tilhøre den pågældende partner. En betaling fra en ukendt betaler knyttes kun til, hvis beløbet svarer nøjagtigt til fakturaens udestående saldo, og fakturanummeret indeholder sit seriepræfiks, så et råt nummer som f.eks. et beløb aldrig opfattes som en reference. En betaling, der overstiger det udestående beløb, knyttes aldrig automatisk. Linjer, der ikke består disse kontroller, forbliver i status new med henblik på manuel afstemning og angives i advarslerne (warnings). Med advanceInvoices: true opretter en uafstemt indgående betaling fra en kendt partner en udstedt acontofaktura (type advance) for beløbet baseret på invoiceVatRatePercent eller invoiceItemId-satsen og afstemmer betalingen herimod; partneren skal være kendt, så debitorrækken skal også være afkrydset.
    • Bogføringsregler efter transaktionskode: Ud over Ntry/Amt / transaction_amount.amount indeholder feltlisten reglerækker som Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (feed: bank_transaction_code=…, credit_debit_indicator=…). En linje bogføres på kontoen for den første regel, den matcher: først banktransaktionskodens familie, dernæst retningen og til sidst standardbeløbsrækken. Reglerækker tjekkes ikke mod filen.
    • Bankgebyrer for partner: createPartner på regelsættet …=CHRG opretter en leverandør opkaldt efter banken (kontoudtogets Stmt/Acct/Svcr/FinInstnId/Nm, forbindelsens bank eller hovedbankkontoens navn) og bogfører alle gebyrer på denne partner.
    • Bankforbindelsesskabeloner vælges pr. feed-konto med bank/feeds/accounts/configure (Bank → Forbindelser i appen), som også fastsætter syncSchedule (manual, daily, weekly, monthly): API'et synkroniserer automatisk konti med en tidsplan, når deres periode er udløbet. Skabeloner anvendes ved hver bank/feeds/sync; synkroniseringssvaret rapporterer derefter også posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched og warnings.

Angiv templateId til bank/statements/import i stedet for format: skabelonens type bestemmer parseren, og filen skal indeholde alle de felter, der er opført i skabelonen – en fil, hvor et felt mangler, afvises med HTTP 422 og angivelse af de manglende kolonne- eller elementnavne. Metadatafelter behøver ikke at være til stede. Bankforbindelsesskabeloner beskriver et live PSD2-feed og kan ikke bruges til filimport.

En ISO 20022-skabelon kan også læse MT940-filer: en fil, der starter med {1: eller :20: (eller sendes med "format": "mt940"), fortolkes som MT940, og skabelonens referencematchnings- og bogføringsregler anvendes på dens linjer. Kontrollen af elementer springes over for MT940, og regler af typen Ntry/BkTxCd=… gælder aldrig for MT940-linjer, da MT940 ikke indeholder ISO 20022-banktransaktionskoder; brug i stedet reglerne Ntry/CdtDbtInd=….

En bankkonto indeholder én valuta. Et kontoudtog i en anden valuta afvises med HTTP 422 (i en camt.053-fil med kontoudtog i flere valutaer for den samme IBAN importeres kun kontoudtoget i kontoens valuta), og det samme gælder en linje sendt til bank/transactions/import med en anden currency end kontoens.

Enhver bevægelse genereret fra et felt med en accountCode bogføres ved importtidspunktet som én journalpost: indgående midler debiterer bankkontoens hovedbogskonto og krediterer den tilknyttede konto; udgående midler debiterer den tilknyttede konto og krediterer bankkontoens hovedbogskonto. Beløb omregnes til basisvalutaen på bevægelsens dato. Bankposteringen bliver derefter afstemt (matched) med denne journalpost (matchedDocumentType = journal_transaction) og tilbydes ikke længere til fakturaafstemning. Svaret rapporterer antallet i posted. Bevægelser fra ikke-tilknyttede felter forbliver i status new og afstemnes mod fakturaer som hidtil – man kan f.eks. knytte Fee til PSP-gebyromkostningskontoen og lade Amount forblive utilknyttet, så betalinger stadig afstemmes mod salgsfakturaer.

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

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

Litauiske banker (Swedbank, SEB, Luminor, Šiaulių bankas, …) giver dig mulighed for at downloade kontoudtog som ISO 20022 camt.053 XML fra deres netbank – typisk under eksport/download af kontoudtog med formatet "ISO XML" eller "camt.053". Det samme format returneres af PSD2-kontooplysnings-API'er.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • En fil kan indeholde flere kontoudtog; hvert kontoudtogs IBAN skal matche bankkontoens IBAN (kontoudtog uden IBAN eller konti uden IBAN accepteres som de er).
  • Posteringंच्या referencer (AcctSvcrRef/NtryRef, med faldt-tilbage til et indholdshash) bliver til externalId.
  • Svaret returnerer metadata pr. kontoudtog: kontoudtogets id, periode, primo-/ultimosaldo og posteringsantal.
  • Modpartens navn, IBAN og betalingsformål udtrækkes pr. postering til brug for afstemning.

Betalinger i den modsatte retning eksporteres som pain.001 via bank/payments/export.

Revolut Business CSV

Download transaktionskontoudtoget for en Revolut Business-konto som CSV, og importér det ved hjælp af den indbyggede skabelon Revolut Business (templateId: "builtin-revolut"). Alle virksomheder har denne skabelon uden at skulle oprette den: bank/import-templates/list-builtin lister den, bank/import-templates/get henter den, og bank/import-templates/update samt bank/import-templates/delete afviser den med HTTP 400. I appen vises den øverst under Bank → Importskabeloner; åbner man den, vises dens indstillinger, og ved gemning oprettes der en egen virksomhedsskabelon, som du kan ændre.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}
  • Kun rækker hvor State = COMPLETED importeres. Andre rækker (f.eks. PENDING) udelades og tælles med i warnings; de importeres ved en senere import af en fil, hvor de er blevet fuldført.
  • Hver række bliver til en bankpostering med datoen fra Date completed (UTC), beløbet fra Total amount, valutaen fra Payment currency, ID som externalId og Description som beskrivelse.
  • Modparten ved udbetalinger er Beneficiary name og Beneficiary IBAN; ved kortbetalinger uden modpart angives forretningen i Description. Modparten ved indbetalinger er Sender name og Sender account.
  • Rækker grupperes efter konto og valuta. International account number skal matche bankkontoens IBAN, og kun rækker i bankkontoens valuta importeres.
  • For hver række kontrollerer importøren, at saldoen fra den foregående række plus Total amount svarer til Balance, og opfører alle rækker, hvor dette ikke er tilfældet, under warnings.
  • Filen skal indeholde kolonnerne Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name og Beneficiary name.

Ved hver import udfører den indbyggede skabelon følgende:

  • opretter en kunde for hver ukendt afsender af indgående midler og en leverandør for hver ukendt modtager eller kortforretning ved udgående midler, som beskrevet under Opret manglende partnere ovenfor;

  • matcher hver række, hvis Reference eller Description indeholder nummeret på en åben salgs- eller købsfaktura, og bogfører betalingen under overholdelse af kontrollerne under Knyt fakturaer sammen via reference ovenfor;

  • bogfører de rækker, som ingen faktura matchede, baseret på deres Type til kontoen i en bogføringsregel:

    Type Bogføringsregel Standardkonto Rumænsk kontoplan Bogføring
    FEE bank.fees 6800 627 debitér regelens konto, kreditér bankkontoens hovedbogskonto; partner: en leverandør opkaldt efter bankkontoen
    CARD_PAYMENT bank.cardPayments 6209 628 debitér regelens konto, kreditér bankkontoens hovedbogskonto, uden moms
    TOPUP bank.topUps 3010 1012 debitér bankkontoens hovedbogskonto, kreditér regelens konto

    Rækker af andre typer, f.eks. TRANSFER, forbliver i status new med henblik på manuel afstemning.

Ændr kontiene med ledger/posting-rules/update; den indbyggede skabelon anvender de nye konti fra næste import. En bogføringsregel kan ikke slås fra: Hvis du vil importere kortbetalinger eller optankninger uden at bogføre dem, skal du oprette en virksomhedsskabelon af typen revolut uden rækkerne Type=CARD_PAYMENT eller Type=TOPUP og importere med den. En kortbetaling, der bogføres på denne måde, afstemmes ikke mod leverandøren faktura, når denne registreres senere; bogført enten den ene eller den anden, ikke begge.

En virksomhedsskabelon af typen revolut bruger de samme kolonner og kan bogføre rækker efter type ved hjælp af reglerækkerne Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER og Type=TOPUP. Import med "format": "revolut-csv" uden en skabelon importerer rækkerne uden nogen af disse trin.

Stripe-CSV

Eksport fra Stripe-kontrolpanelet – begge rapporter kan anvendes:

  • Rapporter → Saldo → Specificeret saldoændring fra aktivitet (anbefalet): kolonnerne balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description.
  • Betalinger → Eksport: kolonnerne 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,…"
}

Opret en dedikeret bankkonto til Stripe (f.eks. med navnet "Stripe", hovedbogskonto 2710 eller sin egen underkonto) – Stripe-saldoen fungerer som en bankkonto: betalinger flyder ind, gebyrer trækkes fra, og udbetalinger overfører saldoen til din rigtige bankkonto.

Importadfærd:

  • Hver saldobevægelse bliver til én bankpostering for det bruttobeløb (externalId = saldobevægelsens id).
  • Et ikke-nul gebyr bliver til en anden postering med modsat fortegn (externalId = <id>:fee, modpart "Stripe"), så gebyrer kan afstemmes/bogføres som omkostninger uafhængigt af omsætningen. Gebyrer, der tilbagebetales ved refunderinger, kommer ind som positive beløb.
  • Udbetalingsrækker importeres som enkelte negative posteringer; afstem dem mod den tilsvarende indgående postering på kontoudtoget for din rigtige bankkonto.
  • Rækker med nulbeløb springes over; datoen hentes fra created_utc (UTC).
  • Betalingseksportrækker, der ikke har flyttet penge, springes over: Captured = false (autorisationer/forsinkede hævninger) og Status Failed/Canceled.
  • Et ikke-nul Amount Refunded (tilbagebetalt beløb) bliver til en tredje, negativ postering (externalId = <id>:refund) dateret med Refunded date (UTC), så delvise og fulde refunderinger indlejret i betalingsrækker ikke går tabt.

Afstemning af PSP-afregninger (Stripe-udbetalingsrapporter)

Til opdeling af en samlet udbetaling i de underliggende ordrer, refunderinger, gebyrer og indsigelser (chargebacks) skal du bruge afregningsendepunkterne i stedet for den almindelige kontoudtogsimport. To Stripe-eksporter accepteres (detekteres automatisk):

  • Rapporter → Udbetalinger → Udbetalingsafstemning, specificeret (rapporttyper payout_reconciliation.itemized.* eller payout_reconciliation.by_id.itemized.*) – nøjagtig, én række pr. saldobevægelse; foretrækkes på live-konti.
  • Betalinger → Eksport (samlede betalinger) – eksporten på betalingsniveau; fungerer i test-/sandkassetilstand, hvor udbetalingsafstemning ikke er tilgængelig. Gennemførte betalinger grupperes efter udbetalings-id'et i kolonnen Transfer; ikke-gennemførte/fejlede rækker springes over (skippedNotSettled); et ikke-nul Amount Refunded bliver til en syntetisk refusionslinje i betalingens udbetalingssamlepost – en tilnærmelse, da refunderingen i virkeligheden kan være afregnet i en senere udbetaling. Matchningsreferencer hentes fra betalings-id'et, PaymentIntent ID, Invoice Number, Client Reference ID og alle … (metadata)-kolonner (f.eks. et ordrenummer i metadata).

Én CSV-fil kan spænde over mange udbetalinger. Stripe downloader den specificerede rapport én fil pr. sektion (…_charge_…, …_refund_…, …_fee_…); importér dem alle – rækker for en allerede importeret udbetaling flettes ind i den eksisterende samlepost (rapporteres i tælleren updated), så længe den ikke er blevet bogført endnu, og samlepostens totaler genberegnes.

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

Importadfærd:

  • Rækker grupperes efter automatic_payout_id i afregningssamleposteringer (batches) – én batch pr. udbetaling med brutto-/gebyr-/nettototaler (summen af rækkernes net = det beløb, der rammer din bank). Genimport af en udbetaling springes over (tælleren skipped). Rækker, der endnu ikke er tildelt en udbetaling, samt selve payout-rækkerne springes over og tælles separat.
  • Hver betalings-, refusions- og tvisterække automatisk afstemmes mod en salgsfaktura ved i rækkefølge at anvende: en e-handelsordres externalRef (enhver værdi fra order_id, payment_intent_id, source_id, charge_id eller en vilkårlig *_metadata[...]-kolonne), et faktura-fullNumber, der optræder i disse kolonner, samt – for refunderinger og indsigelser – charge_id for en tidligere afstemt betaling (fra samme fil eller tidligere importer).
  • Gennemgå resultatet med bank/settlements/list / bank/settlements/get; ret resterende poster med bank/settlements/match { lineId, invoiceId } (eller invoiceId: null for at fjerne afstemningen).

POST /v1/bank/settlements/post { id, date?, commissionPercent? } bogfører hele samleposten som én afbalanceret journalpost og afregner de matchede fakturaer (paidAmount/paymentStatus, webhooks for sale_invoice.paid):

  • Debitér bankkontoens hovedbogskonto for nettopuljen; debitér PSP-gebyrer (settlements.fees, standard 6800) for indeholdte gebyrer og gebyrrækker.
  • Kreditér tilgodehavender fra salg pr. matchede betaling; refunderinger og indsigelser modposterer dette. Bogføringen er begrænset til hver enkelt fakturas udestående beløb – et eventuelt overskud lander på mellemværendekontoen (suspense) med en advarsel.
  • Uafstemte betalinger: Hvis commissionPercent er angivet, opdeles de i provisionsindtægt (settlements.commissionRevenue, standard 5001) og en leverandørgæld (settlements.sellerPayable, standard 4499) – markedspladsflowet, hvor indsamlede midler primært tilhører sælgerne. Uden denne parameter parkeres de på settlements.suspense (standard 4440, modtagne forudbetalinger).
  • platform_earning-rækker (applikationsgebyrer for Stripe Connect) bogføres på provisionsindtægt; transfer-rækker (udbetalinger til tilknyttede sælgere) nedskriver leverandørgælden.
  • Alle fire konti kan tilsidesættes pr. virksomhed via bogføringsregler (ledger/posting-rules).
  • En linje, hvis betaling, gebyr eller refundering allerede er blevet importeret på en anden bankkonto fra Stripe-betalingseksporten (bank/statements/import), bogføres ikke på gebyrer, tilgodehavender eller mellemværende. Dens net-beløb krediteres i stedet den pågældende bankkontos hovedbogskonto, så Stripe-bankkontoen udlignes udbetaling for udbetaling. summary.clearedAmount er det samlede beløb, der er flyttet på denne måde; en linje, hvis beløb afviger fra det, den pågældende konto indeholder, angives under warnings. Hvis der ikke er noget tilbage at bogføre, bogføres samleposten med journalTransactionId sat til null.

bank/settlements/list og /get returnerer pr. batch clearedNet, clearingDifference (udbetalingslinjer minus de beløb, den anden bankkonto indeholder for dem; nul når de stemmer overens) og clearingOpenCount (linjer med en differencen eller en udbogført bevægelse); /get returnerer det samme pr. linje som clearingBankAccountId, clearingBooked, clearingDifference og clearingUnposted. Refusionslinjer for en enkelt betaling sammenlignes samlet, da betalingseksporten kun indeholder det samlede refunderede beløb. En Stripe-betalingseksport, der importeres efter, at dens udbetaling er blevet bogført, springes over for så vidt angår bevægelserne for den pågældende udbetaling og nævnes i warnings.

Moms på selve provisionen faktureres separat (udsted en provisionsfaktura til sælgeren); opdelingen fordeler udelukkende de indsamlede kontanter.

Udbetalinger i en anden valuta

Journalen oprettes altid i virksomhedens basisvaluta, men en udbetaling i en anden valuta bogføres automatisk – der kræves ingen manuel indtastning:

  • Samleposten omregnes til kursen på bogføringsdatoen (date, med faldt-tilbage til udbetalingsdatoen og derefter dags dato). Kursen er virksomhedens egen kurs for den pågældende valuta (reference/exchange-rates/set), når denne er mindst lige så ny som den officielle kurs, og ellers den seneste officielle kurs på eller før den pågældende dato. Hvis der ikke findes nogen kurs på eller før datoen, fejler kaldet med 422 og angiver reference/exchange-rates/sync.
  • Hver enkelt konto omregnes til denne batch-kurs undtagen tilgodehavender fra salg, som udlignes til den fxRate, som hver enkelt faktura blev udstedt til. Differencen mellem de to kurser bogføres på bank.fxGain (standard 5803) eller bank.fxLoss (standard 6803) som en realiseret valutakursdifference, så journalen stadig balancerer.
  • Svarets summary returnerer den anvendte fxRate og den resulterende exchangeDifference, og samleposten beholder den kurs, den blev bogført til. En afstemt faktura, hvis egen valuta afviger fra batch-valutaen, afstemmes ikke: dens beløb går til mellemværendekontoen med en advarsel.
  • Én importbegrænsning gælder fortsat: en enkelt udbetaling, hvis rækker blander flere valutaer, afvises med 422, og det samme gælder en genimport, hvis valuta afviger fra den samlepost, der allerede er gemt for den pågældende udbetaling.

Manuelle / tilpassede feeds

Alt andet kan indsendes som almindelig JSON:

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

Angiv et stabilt externalId pr. postering for at sikre, at genimporter er idempotente.