Bank- och betalningsimport

Alla importer landar som banktransaktioner på ett bankkonto (bank/accounts/create). Transaktioner bär på ett externalId; det är säkert att importera samma fil igen eftersom rader vars (bankAccountId, externalId) redan finns hoppas över och rapporteras i räknaren skipped. Importerade transaktioner startar med status new och bokförs i huvudboken endast när de matchas (bank/transactions/match, med bank/transactions/suggest-matches för kandidater).

Webbapplikationen exponerar samma importer under Bank → Importera fil (filuppladdning, mallväljare).

En felaktig matchning ångras med bank/transactions/unmatch (Ta bort matchning under Bank → Transaktioner). Bokförda poster redigeras eller raderas aldrig: en betalning som matchats mot en faktura, eller en rad som en importmall har bokfört på ett konto, får en reverseringstransaktion (journal transaction) där varje post har omvänt tecken, daterad med date (standard: idag, och aldrig före den ursprungliga bokföringen). Fakturans betalda belopp och betalningsstatus minskas med beloppet för den bankraden. En rad som är kopplad till en utbetalning från en betaltjänstleverantör (PSP) kopplas endast bort, eftersom utbetalningsbokföringen tillhör batchen. Raden återgår till status new och kan matchas igen. Reverseringsdatumet måste infalla i en öppen redovisningsperiod.

Importmallar

En importmall namnger en datakälla, listar de fält som källan tillhandahåller och mappar de fält som hanterar pengar till huvudbokskonton. Mallar hanteras under Bank → Importmallar och 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 är antingen stripe, iso20022, bank_connection eller revalut.
Varje fält har ett name och en valfri accountCode. Endast fält som hanterar pengar tillåter ett konto: Stripes Amount, Fee och Amount Refunded; camt.053 Ntry/Amt; bankflödets transaction_amount.amount. Kontot måste finnas i kontoplanen (skapa det med ledger/accounts/create).
fields kan utelämnas; det återgår då till typens standardlista över fält: kolumnnamnen i Stripes Payments → Export-fil (utan de 19 Card …-kolumnerna, vilka formuläret också lämnar oikryssade som standard), de camt.053-element som varje kontoutdrag innehåller (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), eller de attribut som ett PSD2-bankflöde returnerar per transaktion. Lägg till eller ta bort poster för att matcha din fil: importören läser även de valfria camt.053-elementen 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 och TxDtls/AddtlTxInf.
Ett Stripe-fält för Customer Email kan innehålla "createPartner": true. Importen skapar därefter en kund (motpart av typ privatperson, markerad som kund) för varje e-postadress i filen som saknas bland befintliga motparter, med Customer Description som namn (e-postadressen om detta fält är tomt) och Card Address …-kolumnerna som adress om filen innehåller dem. Befintliga motparter matchas på e-postadress, skiftlägesokänsligt. Svaret rapporterar antalet i customersCreated.
metaFields (endast Stripe) listar de metadataknycklar som dina transaktioner har. Stripe exporterar varje nyckel som en kolumn med namnet <key> (metadata); listan är fri och kan vara lång.
invoiceItemId (endast Stripe, valfritt) är en artikel. När detta är angett refererar varje faktura- och kreditnotarad som importen skapar till den artikeln (dess bokföring och, när invoiceVatRatePercent är tomt, dess momssats); radtexten kommer fortfarande från transaktionen.
companyMetaField (endast Stripe) namnger en av dessa nycklar som företagsflagga. När en transaktion har true, 1, yes, company, business eller b2b i den kolumnen, blir kunden som skapas för den en motpart av typen företag istället för privatperson.
invoiceMetaField (endast Stripe) namnger en av dessa nycklar, till exempel ett ordernummer, och invoiceVatRatePercent anger momssatsen för fakturor som skapas utifrån den. Vid import grupperas varje transaktions- och återbetalningsrad utifrån värdet på den nyckeln:
- ett värde som matchar en befintlig utgående faktura - en kundorder vars externalRef är det värdet (ecommerce/orders/create, valfri kanal) eller en faktura vars fullNumber är det värdet - kopplar gruppen till den fakturan;
- ett värde som saknar faktura skapar en ny: motpart hämtas från Customer Email (skapas om den saknas, på samma sätt som för createPartner), en rad per transaktion (Checkout Line Item Summary eller Description som text, transaktionsbeloppet som ett pris inklusive moms med invoiceVatRatePercent), utfärdandedatum = datum för den första transaktionen, momshantering baserat på företaget och kortets land. Fakturan utfärdas och bokförs omedelbart, och en kundorder med kanalen stripe och det värdet som externalRef registreras så att senare importer länkar istället för att skapa nya;
- varje transaktion i gruppen matchas sedan mot fakturan som en betalning (bokföring av inbetalningen); varje återbetalning skapar en utfärdad kreditnota mot fakturan för det återbetalda beloppet och matchar återbetalningen mot den. Antal returneras som invoicesCreated, invoicesLinked, creditNotesCreated och paymentsMatched; grupper som inte kunde behandlas (saknad e-postadress för kund, blandade valutor, en länkad faktura som fortfarande är ett utkast eller redan är helt betald) listas i warnings och lämnas som nya banktransaktioner (new). Mappa inte dessutom Amount till ett huvudbokskonto i samma mall: en transaktion som matchas mot en faktura bokförs inte en andra gång, men en omatchad transaktion skulle göra det.
Mallnamn är unika per företag.
camt.053- och bankanslutningsmallar har samma alternativ, som läses från kontoutdraget istället för från Stripe-kolumner:
- Skapa saknade motparter: createPartner på raden för betalarens namn (TxDtls/RltdPties/Dbtr/Nm, flöde debtor.name) skapar en kund för varje okänd betalare av inkommande pengar; på raden för mottagarens namn (TxDtls/RltdPties/Cdtr/Nm, flöde creditor.name) skapas en leverantör för varje okänd mottagare av utgående pengar. Motparter identifieras via IBAN (lagras i partner_bank_accounts), därefter på exakt namn; en ny motpart blir ett företag om namnet innehåller en företagsform (AB, MB, SIA, GmbH, Ltd, …), annars en privatperson. Antalet returneras som customersCreated (filimport) eller partnersCreated (flödessynkronisering).
- Koppla fakturor via referens: invoiceMetaField satt till en betalningsmeddelande- eller referensrad (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; flöde remittance_information, reference_number) matchar varje ny bankrad vars referens, betalningsmeddelande eller beskrivning innehåller numret på en öppen utfärdad kundfaktura (pengar in) eller registrerad leverantörsfaktura (pengar ut), och bokför betalningen. När betalarens IBAN är sparat på en motpart, eller betalarens namn matchar en motparts namn eller kod, måste fakturan tillhöra den motparten. En betalning från en okänd betalare kopplas endast när den motsvarar fakturans återstående saldo och fakturanumret innehåller dess serieprefix, vilket gör att ett rent nummer som till exempel ett belopp aldrig tolkas som en referens. En betalning som är större än det återstående saldot kopplas aldrig. Rader som inte klarar dessa kontroller förblir nya för manuell matchning och listas i varningarna. Med advanceInvoices: true skapar en omatchad inkommande betalning från en känd motpart en utfärdad förskottsfaktura (typ advance) för beloppet med invoiceVatRatePercent eller den momssats som anges för invoiceItemId och matchar betalningen mot den; motparten måste vara känd, så markera även debiteringsraden.
- Bokföringsregler per transaktionskod: utöver Ntry/Amt / transaction_amount.amount har fältlistan reglerader Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (flöde: bank_transaction_code=…, credit_debit_indicator=…). En rad bokförs på det konto som tillhör den första regel den matchar: dess banktransaktionskodsfamilj, sedan dess riktning, och slutligen den enkla beloppsraden. Reglerader kontrolleras inte mot filen.
- Bankavgifter motpart: createPartner på regleraden …=CHRG skapar en leverantör uppkallad efter banken (kontoutdragets Stmt/Acct/Svcr/FinInstnId/Nm, eller anslutningens bank, eller huvudbokens bankkontonamn) och bokför varje avgift på den motparten.
- Bankanslutningsmallar väljs per flödeskonto med bank/feeds/accounts/configure (Bank → Anslutningar i applikationen), vilket även ställer in syncSchedule (manual, daily, weekly, monthly): API:et synkroniserar konton med ett schema automatiskt när deras period har passerat. Mallar tillämpas vid varje bank/feeds/sync; synkroniseringssvaret rapporterar därefter även posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched och warnings.

Skicka templateId till bank/statements/import istället för format: mallens typ väljer tolken (parser), och filen måste innehålla varje fält som listas i mallen - en fil som saknar något av dem avvisas med HTTP 422 tillsammans med de saknade kolumn- eller elementnamnen. Metadatafält krävs inte finnas med. Bankanslutningsmallar beskriver ett live-PSD2-flöde och kan inte användas för filimport.

En ISO 20022-mall läser även MT940-filer: en fil som börjar med {1: eller :20: (eller skickas med "format": "mt940") tolkas som MT940 och mallens referensmatchnings- och bokföringsregler tillämpas på dess rader. Elementkontrollen hoppas över för MT940, och regler för Ntry/BkTxCd=… tillämpas aldrig på MT940-rader eftersom MT940 saknar ISO 20022-banktransaktionskoder; använd reglerna Ntry/CdtDbtInd=… istället.

Ett bankkonto har en valuta. Ett kontoutdrag i en annan valuta avvisas med HTTP 422 (i en camt.053-fil med kontoutdrag i flera olika valutor för samma IBAN importeras endast det kontoutdrag som har kontots valuta), och detsamma gäller en rad som skickas till bank/transactions/import med en annan currency än kontots.

Varje rörelse som genereras från ett fält med en accountCode bokförs vid importtillfället som en verifikation (journal transaction): pengar in debiterar bankkontots huvudbokskonto och krediterar det mappade kontot; pengar ut debiterar det mappade kontot och krediterar bankkontots huvudbokskonto. Belopp konverteras till basvalutan per rörelsens datum. Banktransaktionen matchas sedan mot den verifikationen (matchedDocumentType = journal_transaction) och erbjuds inte längre för fakturatchning. Svaret rapporterar antalet i posted. Rörelser från omappade fält förblir nya (new) och matchas mot fakturor som tidigare - mappa till exempel Fee till PSP-avgiftens kostnadskonto och lämna Amount omappat så att transaktioner fortfarande matchas mot kundfakturor.

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

ISO 20022 camt.053 (open banking XML)

Litauiska banker (Swedbank, SEB, Luminor, Šiaulių bankas, …) gör det möjligt att ladda ner kontoutdrag som ISO 20022 camt.053 XML från deras internetbank - vanligen under export/nedladdning av kontoutdrag, med formatet "ISO XML" eller "camt.053". Samma format returneras av PSD2-kontoinformations-API:er.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}

En fil kan innehålla flera kontoutdrag; varje kontoutdrags IBAN måste matcha bankkontots IBAN (kontoutdrag utan IBAN, eller konton som saknar ett sådant, accepteras i befintligt skick).
Postreferenser (AcctSvcrRef/NtryRef, med återfall till en innehållshash) blir externalId.
Svaret återspeglar metadata per kontoutdrag: kontoutdrags-ID, period, ingående/utgående saldon, antal transaktioner.
Motpartens namn, IBAN och betalningsändamål extraheras per post för matchning.

Betalningar i den andra riktningen exporteras som pain.001 via bank/payments/export.

Revolut Business CSV

Ladda ner transaktionshistoriken för ett Revolut Business-konto som CSV och importera den med den inbyggda mallen Revolut Business (templateId: "builtin-revolut"). Alla företag har denna mall utan att behöva skapa den: bank/import-templates/list-builtin listar den, bank/import-templates/get returnerar den, och bank/import-templates/update samt bank/import-templates/delete avvisar den med HTTP 400. I applikationen listas den först under Bank → Importmallar; genom att öppna den visas dess inställningar, och om du sparar skapas en egen företagsmall som du kan ändra.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}

Endast rader med State = COMPLETED importeras. Andra rader (till exempel PENDING) utelämnas och räknas i warnings; de importeras vid en senare import av en fil där de har slutförts.
Varje rad blir till en banktransaktion med datum från Date completed (UTC), belopp från Total amount, valuta från Payment currency, ID som externalId och Description som beskrivning.
Motparten för utgående pengar är Beneficiary name och Beneficiary IBAN; för en kortbetalning utan mottagare används handlaren i Description. Motparten för inkommande pengar är Sender name och Sender account.
Rader grupperas per konto och valuta. International account number måste matcha bankkontots IBAN, och endast rader i bankkontots valuta importeras.
För varje rad kontrollerar importören att saldot för den föregående raden plus Total amount motsvarar Balance, och listar varje rad där så inte är fallet under warnings.
Filen måste innehålla kolumnerna Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name och Beneficiary name.

Vid varje import utför den inbyggda mallen följande:

skapar en kund för varje okänd avsändare av inkommande pengar, och en leverantör för varje okänd mottagare eller korthandlare för utgående pengar, enligt beskrivningen under Skapa saknade motparter ovan;
matchar varje rad vars Reference eller Description innehåller numret på en öppen kund- eller leverantörsfaktura, och bokför betalningen med de kontroller som beskrivs under Koppla fakturor via referens ovan;

bokför de rader som ingen faktura matchade, baserat på deras Type, mot kontot för en bokföringsregel:

`Type`	Bokföringsregel	Standardkonto	Rumänsk kontoplan	Bokföring
`FEE`	`bank.fees`	6800	627	debitera regelns konto, kreditera bankkontots huvudbokskonto; motpart: en leverantör uppkallad efter bankkontot
`CARD_PAYMENT`	`bank.cardPayments`	6209	628	debitera regelns konto, kreditera bankkontots huvudbokskonto, utan moms
`TOPUP`	`bank.topUps`	3010	1012	debitera bankkontots huvudbokskonto, kreditera regelns konto

Rader av andra typer, såsom TRANSFER, förblir nya (new) för matchning.

Ändra kontona med ledger/posting-rules/update; den inbyggda mallen använder de nya kontona vid nästa import. En bokföringsregel kan inte stängas av: om du vill importera kortbetalningar eller påfyllningar (top-ups) utan att bokföra dem, skapa en företagsmall av typen revolut utan raden Type=CARD_PAYMENT eller Type=TOPUP och importera med den. En kortbetalning som bokförs på detta sätt matchas inte mot leverantörens faktura när den fakturan registreras senare; bokför endast en av de två, inte båda.

En företagsmall av typen revolut använder samma kolumner och kan bokföra rader efter typ med regleraderna Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER och Type=TOPUP. Import med "format": "revolut-csv" och utan någon mall importerar raderna utan att utföra några av dessa steg.

Stripe-CSV

Exportera från Stripe-instrumentpanelen - vilken rapport som helst fungerar:

Reports → Balance → Itemized balance change from activity (rekommenderas): kolumnerna balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description.
Payments → Export: kolumnerna 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,…"
}

Skapa ett dedikerat bankkonto för Stripe (t.ex. med namnet "Stripe", huvudbokskonto 2710 eller ett eget underkonto) - Stripes saldo fungerar som ett bankkonto: betalningar flyter in, avgifter dras av, och utbetalningar överför saldot till ditt verkliga bankkonto.

Importbeteende:

Varje balanstransaktion blir till en banktransaktion för det bruttobelopp som anges (externalId = balanstransaktionens ID).
En icke-noll avgift blir till en andra transaktion med omvänt tecken (externalId = <id>:fee, motpart "Stripe") - vilket gör att avgifter kan matchas/bokföras som kostnader separat från intäkter. Avgifter som återbetalas i samband med återbetalningar kommer in som positiva belopp.
Utbetalningsrader (Payout) importeras som enskilda negativa transaktioner; matcha dem mot motsvarande inkommande transaktion på ditt riktiga bankkontoutdrag.
Rader med nollbelopp hoppas över; datumet hämtas från created_utc (UTC).
Betalningsexportrader som inte innebar några pengar som flyttades hoppas över: Captured = false (auktoriseringar/fördröjda dragningar) samt Status Failed/Canceled.
Ett icke-nollbelopp för Amount Refunded blir till en tredje, negativ transaktion (externalId = <id>:refund) daterad med Refunded date (UTC) - vilket säkerställer att partiella och fullständiga återbetalningar inbäddade i betalningsrader inte går förlorade.

PSP-avstämning (Stripe-utbetalningsrapporter)

För att dela upp en klumpsummeutbetalning i dess underliggande order, återbetalningar, avgifter och återföringar (chargebacks), använd avstämningsendpoints istället för den vanliga kontoutdragsimporten. Två Stripe-exporter accepteras (detekteras automatiskt):

Reports → Payouts → Payout reconciliation, itemized (rapporttyper payout_reconciliation.itemized.* eller payout_reconciliation.by_id.itemized.*) - exakt, en rad per balanstransaktion; föredras på live-konton.
Payments → Export (unified payments) - exporten på transaktionsnivå; fungerar i test-/sandlådeläge där utbetalningsavstämning inte är tillgänglig. Genomförda (captured) betalningar grupperas efter utbetalnings-ID i kolumnen Transfer; icke genomförda/misslyckade rader hoppas över (skippedNotSettled); ett icke-nollbelopp för Amount Refunded blir till en syntetisk återbetalningsrad i betalningens utbetalningsbatch - en uppskattning, eftersom återbetalningen faktiskt kan ha avstämts i en senare utbetalning. Matchningsreferenser kommer från betalnings-ID (charge id), PaymentIntent ID, Invoice Number, Client Reference ID och varje kolumn av typen … (metadata) (t.ex. ett ordernummer i metadata).

En CSV-fil kan spänna över många utbetalningar. Stripe laddar ner den detaljerade rapporten en fil per sektion (…_charge_…, …_refund_…, …_fee_…); importera dem alla - rader för en utbetalning som redan har importerats slås samman med den befintliga batchen (rapporteras i räknaren updated) så länge den inte har bokförts ännu, och batchsummorna beräknas om.

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

Importbeteende:

Rader grupperas efter automatic_payout_id i avstämningsbatcher - en batch per utbetalning, med brutto-, avgifts- och nettosummor (summan av radernas net = det belopp som landar på ditt bankkonto). Omimport av en utbetalning hoppas över (räknaren skipped). Rader som ännu inte har tilldelats en utbetalning samt själva payout-raderna hoppas över och räknas separat.
Varje debiterings-, återbetalnings- och tvistrad matchas automatiskt mot en kundfaktura i följande ordning: en e-handelsorders externalRef (valfritt värde från order_id, payment_intent_id, source_id, charge_id eller valfri kolumn av typen *_metadata[...]), ett fakturanummer (fullNumber) som förekommer i dessa kolumner, och - för återbetalningar och tvister - charge_id för en tidigare matchad betalning (från samma fil eller tidigare importer).
Granska med bank/settlements/list / bank/settlements/get; åtgärda eventuella kvarvarande poster med bank/settlements/match { lineId, invoiceId } (eller invoiceId: null för att ta bort matchning).

POST /v1/bank/settlements/post { id, date?, commissionPercent? } bokför hela batchen som en balanserad verifikation och reglerar de matchade fakturorna (paidAmount/paymentStatus, webhooks för sale_invoice.paid):

Debitera bankkontots huvudbokskonto för nettoutbetalningen; debitera PSP-avgifter (settlements.fees, standard 6800) för innehållna avgifter och avgiftsrader.
Kreditera kundfordringar per matchad betalning; återbetalningar och tvister reverserar detta. Tillämpningen begränsas till varje fakturas återstående belopp - eventuellt överskott landar på interimskontot med en varning.
Omatchade betalningar: om commissionPercent är angett delas de upp i provisionsintäkter (settlements.commissionRevenue, standard 5001) och en säljarens skuld (settlements.sellerPayable, standard 4499) - marknadsplatsflödet där insamlade pengar till största delen tillhör säljarna. Utan detta parkeras de på settlements.suspense (standard 4440, erhållna förskott).
platform_earning-rader (Stripe Connect-applikationsavgifter) bokförs som provisionsintäkter; transfer-rader (utbetalningar till anslutna säljare) minskar säljarens skuld.
Alla fyra konton kan åsidosättas per företag via bokföringsregler (ledger/posting-rules).
En rad vars betalning, avgift eller återbetalning redan har importerats till ett annat bankkonto via Stripe-betalningsexporten (bank/statements/import) bokförs inte på avgifter, kundfordringar eller interimskonto. Dess netto krediteras istället det bankkontots huvudbokskonto, så att Stripe-bankkontot rensas utbetalning för utbetalning. summary.clearedAmount är det totala belopp som flyttats på detta sätt; en rad vars belopp skiljer sig från det som kontot innehar namnges i warnings. Om inget återstår att bokföra bokförs batchen med journalTransactionId satt till null.

bank/settlements/list och /get returnerar per batch clearedNet, clearingDifference (utbetalningsrader minus de belopp som det andra bankkontot innehar för dem; noll när de stämmer överens) och clearingOpenCount (rader med en differens eller en obokförd rörelse); /get returnerar samma uppgifter per rad som clearingBankAccountId, clearingBooked, clearingDifference och clearingUnposted. Återbetalningsrader för en och samma betalning jämförs tillsammans, eftersom betalningsexporten endast innehåller det återbetalda totalbeloppet. En Stripe-betalningsexport som importeras efter att dess utbetalning har bokförts hoppas över när det gäller den utbetalningens rörelser och namnges i varningslistan (warnings).

Moms på själva provisionen faktureras separat (utfärda en provisionsfaktura till säljaren); uppdelningen fördelar endast de insamlade kontanterna.

Utbetalningar i en annan valuta

Verifikationen skrivs alltid i företagets basvaluta, men en utbetalning i en annan valuta bokförs automatiskt - ingen manuell registrering krävs:

Batchen konverteras till den kurs som gäller för bokföringsdatumet (date, med återfall till utbetalningsdatumet och därefter idag). Kursen är företagets egen kurs för den valutan (reference/exchange-rates/set) när den är minst lika aktuell som den officiella, annars den senaste officiella kursen på eller före det datumet. Om det saknas en kurs på eller före datumet misslyckas anropet med 422 och anger reference/exchange-rates/sync.
Varje konto konverteras med den batchkursen förutom kundfordringar, vilka regleras till den fxRate som gällde när respektive faktura utfärdades. Differensen mellan de två kurserna bokförs på bank.fxGain (standard 5803) eller bank.fxLoss (standard 6803) som en realiserad valutakursdifferens, så att verifikationen ändå balanserar.
Svarets summary returnerar den fxRate som användes och den resulterande exchangeDifference, och batchen behåller den kurs som den bokfördes med. En matchad faktura vars egen valuta skiljer sig från batchvalutan regleras inte: dess belopp går till interimskontot med en varning.
En importbegränsning kvarstår: en enskild utbetalning vars rader blandar flera valutor avvisas med 422, och detsamma gäller en omimport vars valuta skiljer sig från den batch som redan är lagrad för den utbetalningen.

Manuella / anpassade flöden

Allt annat kan skickas som vanlig JSON:

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

Ange ett stabilt externalId per transaktion för att säkerställa att omimporter förblir idempotenta.