Nordlet

← Documentatie / Handleidingen

Bank- en betalingsimport

camt.053-afschriften, Stripe CSV, PSP-uitbetalingsverwerking en aangepaste JSON-feeds.

Alle imports komen binnen als banktransacties op een bankrekening (bank/accounts/create). Transacties zijn voorzien van een externalId; het opnieuw importeren van hetzelfde bestand is veilig - rijen waarvan de combinatie (bankAccountId, externalId) al bestaat, worden overgeslagen en gerapporteerd in de skipped-teller. Geïmporteerde transacties beginnen met de status new en worden pas naar het grootboek geboekt wanneer ze zijn gekoppeld (bank/transactions/match, met bank/transactions/suggest-matches voor kandidaat-koppelingen).

De webapplicatie toont dezelfde imports onder Bank → Bestand importeren (bestandsupload, sjabloonselectie).

Een onjuiste koppeling kan ongedaan worden gemaakt met bank/transactions/unmatch (Ontkoppelen onder Bank → Transacties). Reeds geboekte boekingen worden nooit bewerkt of verwijderd: een betaling die aan een factuur is gekoppeld, of een regel die door een importsjabloon naar een grootboekrekening is geboekt, krijgt een correctieboeking waarbij elke regel op de tegenovergestelde kant staat, gedateerd op date (standaard: vandaag, en nooit vóór de oorspronkelijke boeking). Het betaalde bedrag en de betalingsstatus van de factuur worden verlaagd met het bedrag van die bankregel. Een regel die is gekoppeld aan een betalingsprovider-afrekening (PSP settlement) wordt enkel losgekoppeld, omdat de afrekeningsboeking bij de batch hoort. De regel keert terug naar de status new en kan opnieuw worden gekoppeld. De correctiedatum moet binnen een open boekhoudperiode vallen.

Importsjablonen

Een importsjabloon definieert een gegevensbron, somt de velden op die de bron aanlevert en koppelt de geldbedragdragende velden aan grootboekrekeningen. Sjablonen worden beheerd via Bank → Importsjablonen en 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 is een van stripe, iso20022, bank_connection of revolut.
  • Elk veld heeft een name en een optionele accountCode. Alleen velden die geldbedragen bevatten accepteren een grootboekrekening: Stripe Amount, Fee en Amount Refunded; camt.053 Ntry/Amt; bankfeed transaction_amount.amount. De rekening moet bestaan in het grootboekrekenchema (aanmaken kan via ledger/accounts/create).
  • fields mag worden weggelaten; het systeem valt dan terug op de standaard veldlijst van het type: de kolomnamen van het Stripe-bestand Payments → Export (zonder de 19 Card …-kolommen, die het formulier standaard ook ongeselecteerd laat), de camt.053-elementen die elk afschrift bevat (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), of de attributen die een PSD2-bankfeed per transactie retourneert. Voeg regels toe of verwijder ze om aan te sluiten op uw bestand: de importfunctie leest ook de optionele 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 en TxDtls/AddtlTxInf.
  • Een Stripe-veld Customer Email kan zijn voorzien van "createPartner": true. De importfunctie maakt dan voor elk e-mailadres in het bestand waarvoor nog geen relatie bestaat een klant aan (relatie van het type persoon, gemarkeerd als klant), waarbij Customer Description wordt gebruikt als naam (of het e-mailadres als dat leeg is) en de kolommen Card Address … als adres indien het bestand deze bevat. Bestaande relaties worden gematcht op e-mailadres, niet-hoofdlettergevoelig. Het antwoord vermeldt het aantal in customersCreated.
  • metaFields (alleen Stripe) somt de metagegevenssleutels op die uw transacties (charges) bevatten. Stripe exporteert elke sleutel als een <key> (metadata)-kolom; de lijst is vrij te definiëren en kan lang zijn.
  • invoiceItemId (alleen Stripe, optioneel) is een catalogusartikel. Indien ingesteld, verwijst elke factuur- en creditnotaregel die de import aanmaakt naar dat artikel (de bijbehorende boeking en, wanneer invoiceVatRatePercent leeg is, het btw-tarief); de regelomschrijving is nog steeds afkomstig van de transactie.
  • companyMetaField (Stripe online) wijst een van deze sleutels aan als bedrijfsmarkering. Wanneer een transactie true, 1, yes, company, business of b2b in die kolom heeft, is de daarvoor aangemaakt klant een relatie van het type bedrijf in plaats van persoon.
  • invoiceMetaField (alleen Stripe) wijst een van deze sleutels aan, bijvoorbeeld een bestelnummer, en invoiceVatRatePercent definieert het btw-tarief voor facturen die daarvan worden aangemaakt. Bij het importeren wordt elke transactie- en teruggavenrij gegroepeerd op de waarde van die sleutel:
    • een waarde die overeenkomt met een bestaande verkoopfactuur - een verkooporder waarvan externalRef die waarde is (ecommerce/orders/create, elk verkoopkanaal) of een factuur waarvan fullNumber die waarde is - koppelt de groep aan die factuur;
    • een waarde zonder bestaande factuur maakt er een aan: relatie op basis van Customer Email (wordt aangemaakt indien ontbrekend, net als bij createPartner), één regel per transactie (Checkout Line Item Summary of Description als omschrijving, het transactiebedrag als een prijs inclusief btw tegen invoiceVatRatePercent), factuurdatum = de datum van de eerste transactie, btw-behandeling op basis van het bedrijf en het land van de betaalkaart. De factuur wordt direct uitgeven en geboekt, en er wordt een verkooporder met kanaal stripe en die waarde als externalRef geregistreerd zodat latere imports koppelen in plaats van aanmaken;
    • elke transactie in de groep wordt vervolgens als betaling aan de factuur gekoppeld (waarbij de ontvangst wordt geboekt); elke teruggave maakt een uitgaande creditnote aan tegen de factuur voor het teruggestorte bedrag en koppelt de teruggave daaraan. De aantallen worden geretourneerd als invoicesCreated, invoicesLinked, creditNotesCreated en paymentsMatched; groepen die niet verwerkt konden worden (geen e-mailadres van de klant, gemengde valuta's, een gekoppelde factuur die nog een concept is of reeds volledig is voldaan) worden vermeld in warnings en blijven achter als new banktransacties. Koppel in hetzelfde sjabloon niet tegelijkertijd Amount aan een grootboekrekening: een transactie die aan een factuur is gekoppeld wordt niet dubbel geboekt, maar een ongekoppelde transactie zou dat wel worden.
  • Sjablonennamen zijn uniek per bedrijf.
  • camt.053- en bankkoppeling-sjablonen (bank-connection) bevatten dezelfde opties, gelezen uit het afschrift in plaats van Stripe-kolommen:
    • Ontbrekende relaties aanmaken (Create missing partners): createPartner op de naamregel van de debiteur (TxDtls/RltdPties/Dbtr/Nm, feed debtor.name) maakt een klant aan voor elke onbekende betaler van binnenkomend geld; op de naamregel van de crediteur (TxDtls/RltdPties/Cdtr/Nm, feed creditor.name) een leverancier voor elke onbekende ontvanger van uitgaand geld. Relaties worden herkend op IBAN (opgeslagen in partner_bank_accounts), vervolgens op exacte naam; een nieuwe relatie is een bedrijf wanneer de naam een rechtsvorm bevat (B.V., N.V., V.O.F., C.V., GmbH, Ltd, …), anders een persoon. Het aantal wordt geretourneerd als customersCreated (bestandsimport) of partnersCreated (feed-synchronisatie).
    • Facturen koppelen op kenmerk (Link invoices by reference): invoiceMetaField ingesteld op een omschrijvings- of referentieregel (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; feed remittance_information, reference_number) koppelt elke nieuwe bankregel waarvan de referentie, omschrijving of betalingskenmerk het nummer bevat van een openstaande verkoopfactuur (geld binnen) of geregistreerde inkoopfactuur (geld weg), en boekt de betaling. Wanneer het IBAN van de betaler is opgeslagen bij een relatie, of de naam van de betaler gelijk is aan de naam of code van een relatie, moet de factuur bij die relatie horen. Een betaling van een onbekende betaler wordt alleen gekoppeld wanneer deze exact gelijk is aan het resterende saldo van de factuur en het factuurnummer het serieuze voorvoegsel bevat, zodat een kaal getal zoals een bedrag nooit als referentie wordt beschouwd. Een betaling die groter is dan het openstaande saldo wordt nooit gekoppeld. Regels die niet door deze controles komen, blijven de status new behouden voor handmatige matching en worden vermeld in de waarschuwingen (warnings). Met advanceInvoices: true maakt een ongekoppelde inkomende betaling van een bekende relatie een uitgaande aanbetalingsfactuur (type advance) aan voor het bedrag tegen het tarief van invoiceVatRatePercent of invoiceItemId en koppelt de betaling daaraan; de relatie moet bekend zijn, vink dus ook de debiteurregel aan.
    • Boekingsregels op transactiecode: naast Ntry/Amt / transaction_amount.amount heeft de veldenlijst regelopties zoals Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (feed: bank_transaction_code=…, credit_debit_indicator=…). Een regel wordt geboekt op de grootboekrekening van de eerste regel waaraan deze voldoet: eerst de banktransactiecode-familie, dan de richting, en ten slotte de standaard bedragregel. Regelopties worden niet gecontroleerd tegen het bestand.
    • Bankkosten relatie (Bank charges partner): createPartner op de regel …=CHRG maakt een leverancier aan vernoemd naar de bank (afschrift Stmt/Acct/Svcr/FinInstnId/Nm, of de bank van de verbinding, of de naam van de grootboekrekening van de bank) en boekt alle kosten op die relatie.
    • Sjablonen voor bankverbindingen worden per feedrekening gekozen met bank/feeds/accounts/configure (Bank → Verbindingen in de applicatie), waarmee tevens syncSchedule wordt ingesteld (manual, daily, weekly, monthly): de API synchroniseert rekeningen met een schema automatisch zodra de periode is verstreken. Sjablonen worden toegepast bij elke bank/feeds/sync; het synchronisatieresultaat rapporteert dan tevens posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched en warnings.

Geef templateId mee aan bank/statements/import in plaats van format: het type van het sjabloon bepaalt de parser, en het bestand moet elk veld bevatten dat in het sjabloon is vermeld. Een bestand waarin een veld ontbreekt, wordt geweigerd met HTTP 422 inclusief de ontbrekende kolom- of elementnamen. Metagegevensvelden zijn niet verplicht om aanwezig te zijn. Sjablonen voor bankverbindingen beschrijven een live PSD2-feed en kunnen niet worden gebruikt voor bestandsimport.

Een ISO 20022-sjabloon leest tevens MT940-bestanden: een bestand dat begint met {1: of :20: (of wordt verzonden met "format": "mt940") wordt geparseerd als MT940 en de referentiematching- en boekingsregels van het sjabloon worden op de regels toegepast. De elementcontrole wordt overgeslagen voor MT940, en Ntry/BkTxCd=…-regels zijn nooit van toepassing op MT940-regels omdat MT940 geen ISO 20022-banktransactiecodes bevat; gebruik in plaats daarvan de Ntry/CdtDbtInd=…-regels.

Een bankrekening heeft één valuta. Een afschrift in een andere valuta wordt geweigerd met HTTP 422 (in een camt.053-bestand met afschriften in verschillende valuta's voor dezelfde IBAN wordt alleen het afschrift in de valuta van de rekening geïmporteerd), en dat geldt eveneens voor een regel die naar bank/transactions/import wordt gestuurd met een andere currency dan die van de rekening.

Elke mutatie voortkomend uit een veld dat is voorzien van een accountCode wordt op het moment van import geboekt als één memoriaalboeking: geld binnen debiteert de grootboekrekening van de bank en crediteert de gekoppelde rekening; geld weg debiteert de gekoppelde rekening en crediteert de grootboekrekening van de bank. Bedragen worden omgerekend naar de basisvaluta tegen de wisselkoers op de mutatiedatum. De banktransactie wordt vervolgens gekoppeld (matched) aan die memoriaalboeking (matchedDocumentType = journal_transaction) en wordt niet langer aangeboden voor factuurmatching. Het antwoord vermeldt het aantal in posted. Mutaties van niet-gekoppelde velden blijven de status new behouden en worden zoals voorheen aan facturen gekoppeld; koppel bijvoorbeeld Fee aan de kostenrekening voor PSP-kosten en laat Amount ongekoppeld zodat betalingen alsnog aan verkoopfacturen kunnen worden gekoppeld.

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

ISO 20022 camt.053 (open banking XML)

Litouwse banken (Swedbank, SEB, Luminor, Šiaulių bankas, …) stellen u in staat rekeningafschriften te downloaden als ISO 20022 camt.053 XML via hun internetbankieren, doorgaans onder afschrift export/download, met formaat "ISO XML" of "camt.053". Hetzelfde formaat wordt geretourneerd door PSD2 account-information API's.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • Een bestand kan meerdere afschriften bevatten; de IBAN van elk afschrift moet overeenkomen met de IBAN van de bankrekening (afschriften zonder IBAN, of rekeningen zonder IBAN, worden ongewijzigd geaccepteerd).
  • Transactiereferenties (AcctSvcrRef/NtryRef, met terugval op een inhouds-hash) worden gebruikt als externalId.
  • Het antwoord retourneert metagegevens per afschrift: afschrift-ID, periode, begin- en eindsaldo, transactieaantal.
  • Naam van de tegenpartij, IBAN en betalingskenmerk worden per regel geëxtraheerd ten behoeve van de matching.

Betalingen in de omgekeerde richting worden geëxporteerd als pain.001 via bank/payments/export.

Revolut Business CSV

Download het transactieoverzicht van een Revolut Business-rekening als CSV en importeer dit met het ingebouwde sjabloon Revolut Business (templateId: "builtin-revolut"). Elk bedrijf beschikt over dit sjabloon zonder dat dit hoeft te worden aangemaakt: bank/import-templates/list-builtin toont het, bank/import-templates/get retourneert het, en bank/import-templates/update en bank/import-templates/delete weigeren dit met HTTP 400. In de applicatie wordt dit als eerste vermeld onder Bank → Importsjablonen; bij het openen worden de instellingen getoond, en bij opslaan wordt een eigen bedrijfsssjabloon aangemaakt dat u kunt wijzigen.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}
  • Alleen regels met State = COMPLETED worden geïmporteerd. Overige regels (bijvoorbeeld PENDING) worden overgeslagen en geteld in warnings; deze worden geïmporteerd bij een latere import van een bestand waarin ze wel zijn voltooid.
  • Elke regel wordt een banktransactie met de datum uit Date completed (UTC), het bedrag uit Total amount, de valuta uit Payment currency, ID als externalId en Description als omschrijving.
  • De tegenpartij bij uitgaand geld is Beneficiary name en Beneficiary IBAN; bij een kaartbetaling zonder begunstigde is dit de handelaar in Description. De tegenpartij bij inkomend geld is Sender name en Sender account.
  • Regels worden gegroepeerd op rekening en valuta. International account number moet overeenkomen met de IBAN van de bankrekening, en alleen regels in de valuta van de bankrekening worden geïmporteerd.
  • Voor elke regel controleert de importfunctie of het saldo van de voorgaande regel plus Total amount gelijk is aan Balance, en vermeldt elke regel waarbij dit niet klopt in warnings.
  • Het bestand moet de volgende kolommen bevatten: Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name en Beneficiary name.

Bij elke import voert het ingebouwde sjabloon de volgende acties uit:

  • het maakt een klant aan voor elke onbekende afzender van inkomend geld, en een leverancier voor elke onbekende begunstigde of kaartmerchant van uitgaand geld, zoals hierboven beschreven bij Ontbrekende relaties aanmaken (Create missing partners);

  • het koppelt elke regel waarvan Reference of Description het nummer bevat van een openstaande verkoop- of inkoopfactuur, en boekt de betaling met inachtneming van de controles zoals beschreven bij Facturen koppelen op kenmerk (Link invoices by reference) hierboven;

  • het boekt de regels die niet aan een factuur konden worden gekoppeld op basis van hun Type naar de rekening van een boekingsregel:

    Type Boekingsregel Standaardrekening Roemeens schema Boeking
    FEE bank.fees 6800 627 debiteer de rekening van de regel, crediteer de grootboekrekening van de bank; relatie: een leverancier vernoemd naar de bankrekening
    CARD_PAYMENT bank.cardPayments 6209 628 debiteer de rekening van de regel, crediteer de grootboekrekening van de bank, zonder btw
    TOPUP bank.topUps 3010 1012 debiteer de grootboekrekening van de bank, crediteer de rekening van de regel

    Regels van andere typen, zoals TRANSFER, behouden de status new voor handmatige matching.

Wijzig rekeningen via ledger/posting-rules/update; het ingebouwde sjabloon gebruikt de nieuwe rekeningen vanaf de volgende import. Een boekingsregel kan niet worden uitgeschakeld: om kaartbetalingen of opwaarderingen (top-ups) te importeren zonder deze te boeken, dient u een bedrijfsssjabloon van het type revolut aan te maken zonder de rijen Type=CARD_PAYMENT of Type=TOPUP en daarmee te importeren. Een op deze manier geboekte kaartbetaling wordt niet gekoppeld aan de factuur van de leverancier wanneer die factuur later wordt geregistreerd; boek er slechts één van beide, niet allebei.

Een bedrijfsssjabloon van het type revolut gebruikt dezelfde kolommen en kan regels per type boeken via de regelopties Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER en Type=TOPUP. Importeren met "format": "revolut-csv" en zonder sjabloon importeert de regels zonder al deze stappen.

Stripe CSV

Exporteer vanuit het Stripe-dashboard - elk van beide rapporten is bruikbaar:

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

Maak een speciale bankrekening aan voor Stripe (bijvoorbeeld met naam "Stripe", grootboekrekening 2710 of een eigen subrekening) - het Stripe-saldo gedraagt zich als een bankrekening: betalingen komen binnen, kosten worden ingehouden, en uitbetalingen boeken het saldo over naar uw echte bankrekening.

Importgedrag:

  • Elke balanstransactie wordt één banktransactie voor het bruto bedrag (externalId = balanstransactie-ID).
  • Niet-zero kosten (fee) worden een tweede transactie met het omgekeerde teken (externalId = <id>:fee, tegenpartij "Stripe") - zodat kosten afzonderlijk van de omzet als kosten kunnen worden gematcht en geboekt. Kosten die bij terugbetalingen worden gerestitueerd, komen binnen als positieve bedragen.
  • Uitbetalingsrijen (payout) worden geïmporteerd als enkelvoudige negatieve transacties; match deze tegen de bijbehorende inkomende transactie op het afschrift van uw echte bankrekening.
  • Rijen met een bedrag van nul worden overgeslagen; de datum wordt overgenomen van created_utc (UTC).
  • Betalingsexport-rijen waarbij geen geld is overgeboekt, worden overgeslagen: Captured = false (autorisaties/uitgestelde vastleggingen) en Status Failed/Canceled.
  • Een niet-zero Amount Refunded (teruggestort bedrag) wordt een derde, negatieve transactie (externalId = <id>:refund) gedateerd op Refunded date (UTC) - zodat gedeeltelijke en volledige terugbetalingen verwerkt in betalingsrijen niet verloren gaan.

PSP-uitbetalingsverwerking (Stripe payout-rapporten)

Voor het uitsplitsen van een verzameluitbetaling in de onderliggende orders, teruggaven, kosten en chargebacks kunt u beter de afrekeningseindpunten gebruiken in plaats van de standaard afschriftimport. Twee Stripe-exportformaten worden geaccepteerd (automatisch gedetecteerd):

  • Reports → Payouts → Payout reconciliation, itemized (rapporttypen payout_reconciliation.itemized.* of payout_reconciliation.by_id.itemized.*) - exact, één rij per balanstransactie; heeft de voorkeur op live rekeningen.
  • Payments → Export (unified payments) - de export op transactieniveau; werkt in test-/sandboxmodus waar payout reconciliation niet beschikbaar is. Vastgelegde transacties (captured) worden gegroepeerd op de uitbetalings-ID in de kolom Transfer; niet-vastgelegde/mislukte rijen worden overgeslagen (skippedNotSettled); een niet-zero Amount Refunded wordt een synthetische teruggaberegel in de uitbetalingsbatch van de transactie - een benadering, aangezien de teruggave in werkelijkheid in een latere uitbetaling verrekend kan zijn. Matching-referenties zijn afkomstig van de transactie-ID, PaymentIntent ID, Invoice Number, Client Reference ID en elke … (metadata)-kolom (bijvoorbeeld een bestelnummer in de metagegevens).

Eén CSV-bestand kan meerdere uitbetalingen omvatten. Stripe downloadt het gespecificeerde rapport één bestand per sectie (…_charge_…, …_refund_…, …_fee_…); importeer ze allemaal - rijen voor een reeds geïmporteerde uitbetaling worden samengevoegd met de bestaande batch (gerapporteerd in de updated-teller) zolang deze nog niet is geboekt, en batchtotalen worden hererekend.

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

Importgedrag:

  • Rijen worden gegroepeerd op automatic_payout_id in afrekeningsbatches - één batch per uitbetaling, met bruto-/kosten-/nettototalen (som van rij net = het bedrag dat op uw bankrekening binnenkomt). Het opnieuw importeren van een uitbetaling wordt overgeslagen (skipped-teller). Rijen die nog niet aan een uitbetaling zijn toegewezen en de payout-rijen zelf worden overgeslagen en apart geteld.
  • Elke transactie-, teruggave- en betwistingsrij (dispute) wordt automatisch gekoppeld aan een verkoopfactuur op basis van, in deze volgorde: de externalRef van een e-commerce order (elke waarde uit order_id, payment_intent_id, source_id, charge_id of een *_metadata[...]-kolom), een factuur fullNumber voorkomend in die kolommen, en - voor teruggaven en chargebacks - de charge_id van een eerder gekoppelde transactie (zelfde bestand of eerdere imports).
  • Controleer via bank/settlements/list / bank/settlements/get; los overblijvende regels op met bank/settlements/match { lineId, invoiceId } (of invoiceId: null om te ontkoppelen).

POST /v1/bank/settlements/post { id, date?, commissionPercent? } boekt de gehele batch als één in evenwicht zijnde memoriaalboeking en wikkelt de gekoppelde facturen af (paidAmount/paymentStatus, sale_invoice.paid-webhooks):

  • Debiteer de grootboekrekening van de bank voor het netto uitbetalingsbedrag; debiteer PSP-kosten (settlements.fees, standaard 6800) voor ingehouden kosten en kostenregels.
  • Crediteer debiteuren per gekoppelde transactie; teruggaven en chargebacks keren dit om. Toewijzing is gemaximeerd op het resterende bedrag van elke factuur - elk overschot komt op de tussenrekening (suspense) terecht met een waarschuwing.
  • Ongekoppelde transacties: indien commissionPercent is ingesteld, worden deze gesplitst in provisie-omzet (settlements.commissionRevenue, standaard 5001) en een verkopersverplichting (settlements.sellerPayable, standaard 4499) - het marktplaatsmodel waarbij ingevorderd geld grotendeels toebehoort aan verkopers. Zonder dit percentage worden ze geparkeerd op settlements.suspense (standaard 4440, ontvangen vooruitbetalingen).
  • platform_earning-rijen (applicatiekosten van Stripe Connect) worden geboekt op provisie-omzet; transfer-rijen (uitbetalingen aan gekoppelde verkopers) verlagen de verkopersverplichting.
  • Alle vier de rekeningen kunnen per bedrijf worden overschreven via boekingsregels (ledger/posting-rules).
  • Een regel waarvan de transactie, kosten of teruggave reeds was geïmporteerd op een andere bankrekening vanuit de Stripe-betalingsexport (bank/statements/import) wordt niet geboekt op kosten, debiteuren of tussenrekening. Het netto bedrag (net) wordt in plaats daarvan gecrediteerd op de grootboekrekening van die bankrekening, zodat de Stripe-bankrekening uitbetaling per uitbetaling wordt vereffend. summary.clearedAmount is het totale bedrag dat op deze manier is verplaatst; een regel waarvan het bedrag afwijkt van wat die rekening bevat, wordt vermeld in warnings. Als er niets overblijft om te boeken, wordt de batch geboekt met journalTransactionId null.

bank/settlements/list en /get retourneren per batch clearedNet, clearingDifference (uitbetalingsregels minus de bedragen die de andere bankrekening daarvoor aanhoudt; nul wanneer ze overeenkomen) en clearingOpenCount (regels met een verschil of een ongeboekte mutatie); /get retourneert hetzelfde per regel als clearingBankAccountId, clearingBooked, clearingDifference en clearingUnposted. Teruggaberegels van één transactie worden gezamenlijk vergeleken, omdat de betalingsexport enkel het totaalbedrag aan teruggaven bevat. Een Stripe-betalingsexport die wordt geïmporteerd nadat de bijbehorende uitbetaling al is geboekt, slaat de mutaties van die uitbetaling over en vermeldt dit in warnings.

Btw over de provisie zelf wordt afzonderlijk gefactureerd (reik een provisiefactuur uit aan de verkoper); de splitsing wijst enkel de geïnde contanten toe.

Uitbetalingen in een andere valuta

Het journaal wordt altijd geschreven in de basisvaluta van het bedrijf, maar een uitbetaling in een andere valuta wordt automatisch geboekt - handmatige invoer is niet nodig:

  • De batch rekent om tegen de wisselkoers voor de boekingsdatum (date, met terugval op de uitbetalingsdatum, en anders vandaag). De koers is de eigen koers van het bedrijf voor die valuta (reference/exchange-rates/set) wanneer deze ten minste zo recent is als de officiële koers, en anders de laatste officiële koers op of vóór die datum. Als er geen koers is op of vóór de datum, mislukt de aanroep met 422 en wordt reference/exchange-rates/sync vermeld.
  • Elke rekening rekent om tegen die batchkoers behalve debiteuren, welke worden afgelost tegen de fxRate waartegen elke factuur oorspronkelijk is uitgegeven. Het koersverschil tussen beide koersen wordt geboekt op bank.fxGain (standaard 5803) of bank.fxLoss (standaard 6803) als gerealiseerd koersverschil, zodat de boeking in evenwicht blijft.
  • Het antwoord summary retourneert de gebruikte fxRate en het resulterende exchangeDifference, en de batch behoudt de koers waartegen deze is geboekt. Een gekoppelde factuur waarvan de eigen valuta afwijkt van de batchvaluta wordt niet afgeletterd: het bedrag hiervan gaat naar de tussenrekening met een waarschuwing.
  • Één importbeperking blijft bestaan: een enkele uitbetaling waarvan de regels meerdere valuta's mengen wordt geweigerd met 422, evenals een herimport waarvan de valuta afwijkt van de batch die al voor die uitbetaling is opgeslagen.

Handmatige / aangepaste feeds

Elke andere gegevensbron kan worden aangeleverd als platte JSON:

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

Geef een stabiele externalId op per transactie om herhaalde imports idempotent te houden.

FAQ

Q: Kan ik een reeds geboekte betaling of afschriftregel bewerken? A: Nee. Om fouten te corrigeren gebruikt u de ontkoppelingsfunctie (bank/transactions/unmatch) of wordt er automatisch een correctieboeking aangemaakt wanneer u een transactie opnieuw verwerkt.

Q: Hoe weet het systeem of een betaling bij een bepaalde factuur hoort? A: Het systeem zoekt naar factuurnummers en betalingskenmerken in de omschrijving, referentie of metagegevens van de bankregel, en controleert desgewenst ook op het IBAN en de naam van de relatie.