Nordlet

← Documentatie / Ghiduri

Importuri de extrase bancare și plăți

Extrase camt.053, fișiere CSV Stripe, reconciliere de decontări PSP și fluxuri JSON personalizate.

Toate importurile sunt înregistrate ca tranzacții bancare într-un cont bancar (bank/accounts/create). Tranzacțiile conțin un identificator extern (externalId); reimportarea aceluiași fișier este sigură - rândurile ale căror perechi (bankAccountId, externalId) există deja sunt sărite și raportate în contorul skipped. Tranzacțiile importate încep cu starea new și sunt înregistrate în registrul-jurnal (ledger) doar atunci când sunt reconciliate (bank/transactions/match, având bank/transactions/suggest-matches pentru candidați).

Aplicația web expune aceleași importuri în secțiunea Bancă → Importă fișier (încărcare de fișiere, selector de șabloane).

O reconciliere greșită este anulată cu ajutorul bank/transactions/unmatch (Anulare reconciliere din Bancă → Tranzacții). Înregistrările contabilizate nu sunt niciodată editate sau șterse: o plată reconciliată cu o factură sau o linie pe care un șablon de import a contabilizat-o într-un cont primește o tranzacție jurnal de storno cu fiecare înregistrare pe partea opusă, datată la data date (implicit: astăzi, dar niciodată înainte de data contabilizării originale). Valoarea achitată și starea de plată a facturii scad cu valoarea acelei linii bancare. O linie legată de o decontare a unui furnizor de servicii de plată (PSP) este doar delogată, deoarece înregistrarea contabilă a decontării aparține lotului. Linia revine la starea new și poate fi reconciliată din nou. Data stornării trebuie să se încadreze într-o perioadă contabilă deschisă.

Șabloane de import

Un șablon de import denumește o sursă de date, listează câmpurile pe care sursa le furnizează și mapează câmpurile care conțin sume monetare către conturile contabile. Șabloanele sunt gestionate în Bancă → Șabloane de import și prin intermediul 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 poate fi stripe, iso20022, bank_connection sau revolut.
  • Fiecare câmp are un name și un accountCode opțional. Doar câmpurile care transportă sume monetare acceptă un cont: Amount, Fee și Amount Refunded pentru Stripe; Ntry/Amt pentru camt.053; transaction_amount.amount pentru fluxul bancar. Contul trebuie să existe în planul de conturi (creați-l cu ledger/accounts/create).
  • Câmpul fields poate fi omis; în acest caz, revine la lista standard de câmpuri pentru tipul respectiv: denumirile coloanelor din fișierul Payments → Export furnizat de Stripe (fără cele 19 coloane Card …, pe care formularul le lasă, de asemenea, bifați implicit), elementele camt.053 pe care le conține fiecare extras (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt) sau atributele pe care un flux bancar PSD2 le returnează per tranzacție. Adăugați sau eliminați intrări pentru a se potrivi cu fișierul dumneavoastră: importatorul citește, de asemenea, elementele camt.053 opționale 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 și TxDtls/AddtlTxInf.
  • Un câmp Customer Email din Stripe poate conține "createPartner": true. În acest caz, importul creează un client (partener de tip persoană fizică, marcat ca și client) pentru fiecare adresă de e-mail din fișier care nu se regăsește la niciun partener existent, utilizând Customer Description ca nume (sau adresa de e-mail dacă aceasta este goală) și coloanele Card Address … ca adresă, atunci când fișierul le conține. Partenerii existenți sunt identificați după adresă de e-mail, fără a se ține cont de majuscule și minuscule. Răspunsul raportează numărul acestora în customersCreated.
  • metaFields (doar pentru Stripe) listează cheile de metadate pe care le conțin tranzacțiile dumneavoastră. Stripe exportă fiecare cheie ca o coloană <key> (metadata); lista are format liber și poate fi lungă.
  • invoiceItemId (doar pentru Stripe, opțional) reprezintă un articol din catalog. Când este setat, fiecare linie de factură și notă de credit pe care o creează importul face referire la articolul respectiv (inregistrarea sa contabilă și, atunci când invoiceVatRatePercent este gol, cota sa de TVA); textul liniei provine în continuare din tranzacție.
  • companyMetaField (doar pentru Stripe) desemnează una dintre aceste chei drept indicator pentru companii. Atunci când o tranzacție are valoarea true, 1, yes, company, business sau b2b în acea coloană, clientul creat pentru aceasta este un partener de tip companie în loc de persoană fizică.
  • invoiceMetaField (doar pentru Stripe) desemnează una dintre aceste chei, de exemplu un număr de comandă, iar invoiceVatRatePercent reprezintă cota de TVA pentru facturile create pe baza acesteia. La import, fiecare rând de încasare și rambursare este grupat după valoarea acelei chei:
    • o valoare care se potrivește cu o factură de vânzare existentă - o comandă de vânzare a cărei externalRef este acea valoare (ecommerce/orders/create, pentru orice canal) sau o factură a cărei fullNumber este acea valoare - leagă grupul de factura respectivă;
    • o valoare fără o factură existentă generează una nouă: partenerul este preluat din Customer Email (creat dacă lipsește, la fel ca pentru createPartner), o linie per tranzacție (utilizând Checkout Line Item Summary sau Description drept text, valoarea tranzacției ca preț cu TVA inclus la cota invoiceVatRatePercent), data emiterii fiind prima dată a tranzacției, iar regimul de TVA este determinat pe baza companiei și a țării cardului. Factura este emisă și contabilizată imediat, iar o comandă de vânzare cu canalul stripe și acea valoare ca externalRef este înregistrată, astfel încât importurile ulterioare să realizeze o legătură în loc să creeze înregistrări noi;
    • fiecare tranzacție din grup este apoi reconciliată cu factura ca plată (contabilizând încasarea); fiecare rambursare creează o notă de credit emisă pe factura respectivă pentru suma returnată și reconciliază rambursarea cu aceasta. Rezultatele sunt returnate ca numărătoari în invoicesCreated, invoicesLinked, creditNotesCreated și paymentsMatched; grupurile care nu au putut fi procesate (fără e-mail de client, valute mixte, o factură legată care este încă ciornă sau deja achitată integral) sunt listate în warnings și rămân ca tranzacții bancare cu starea new. Nu mapați simultan câmpul Amount la un cont contabil în același șablon: o tranzacție reconciliată cu o factură nu este înregistrată a doua oară, însă una nereconciliată ar fi.
  • Numele șabloanelor sunt unice per companie.
  • Șabloanele camt.053 și cele pentru conexiuni bancare conțin aceleași opțiuni, citite din extras în loc de coloanele Stripe:
    • Creare parteneri lipsă: opțiunea createPartner pe rândul cu numele debitorului (TxDtls/RltdPties/Dbtr/Nm, fluxul debtor.name) creează un client pentru fiecare plătitor necunoscut de sume în incasso; pe rândul cu numele creditorului (TxDtls/RltdPties/Cdtr/Nm, fluxul creditor.name), creează un furnizor pentru fiecare beneficiar necunoscut de plăți efectuate. Partenerii sunt recunoscuți după IBAN (stocat în partner_bank_accounts), apoi după numele exact; un partener nou este considerat companie dacă numele conține o formă juridică (UAB, MB, SIA, GmbH, Ltd, …), altfel este considerat persoană fizică. Numărătoarea este returnată ca customersCreated (import de fișier) sau partnersCreated (sincronizarea fluxului).
    • Legare facturi după referință: invoiceMetaField setat pe un rând de detalii de plată sau referință (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; fluxurile remittance_information, reference_number) asociază fiecare linie bancară nouă a cărei referință, detalii de plată sau descriere conține numărul unei facturi de vânzare emise deschise (încasări) sau al unei facturi de achiziție înregistrate (plăți) și contabilizează plata. Atunci când IBAN-ul plătitorului este salvat la un partener sau numele plătitorului este identic cu numele ori codul unui partener, factura trebuie să aparțină acelui partener. O plată de la un plătitor necunoscut este asociată doar atunci când este egală cu soldul rămas al facturii, iar numărul facturii conține prefixul seriei sale, astfel încât un număr izolat, cum ar fi o valoare monetară, să nu fie niciodată luat drept referință. O plată mai mare decât soldul rămas nu este asociată niciodată. Liniile care nu trec aceste verificări rămân în starea new pentru reconciliere manuală și sunt listate în avertismente. Cu opțiunea advanceInvoices: true, o plată în incasso nereconciliată provenită de la un partener cunoscut creează o factură de avans emisă (de tip advance) pentru valoarea respectivă la cota de TVA invoiceVatRatePercent sau la cota din invoiceItemId și reconciliază plata cu aceasta; partenerul trebuie să fie cunoscut, așa că bifați și rândul debitorului.
    • Reguli contabile după codul tranzacției: pe lângă Ntry/Amt / transaction_amount.amount, lista de câmpuri include rândurile de reguli Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (flux: bank_transaction_code=…, credit_debit_indicator=…). O linie este contabilizată în contul primei reguli cu care se potrivește: familia de coduri de tranzacție bancară, apoi direcția sa, urmată de rândul cu suma simplă. Rândurile de reguli nu sunt verificate în raport cu fișierul.
    • Partener pentru comisioane bancare: createPartner pe rândul regulii …=CHRG creează un furnizor denumit după bancă (extrasul Stmt/Acct/Svcr/FinInstnId/Nm, banca conexiunii sau numele contului bancar din registrul-jurnal) și înregistrează fiecare comision pe acel partener.
    • Șabloanele de conexiune bancară sunt alese per cont de flux cu bank/feeds/accounts/configure (Bancă → Conexiuni în aplicație), care setează și opțiunea syncSchedule (manual, daily, weekly, monthly): API-ul sincronizează automat conturile care au un program stabilit odată ce perioada acestora a expirat. Șabloanele sunt aplicate la fiecare apel bank/feeds/sync; răspunsul de sincronizare raportează apoi și posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched și warnings.

Transmiteți templateId către bank/statements/import în loc de format: tipul șablonului selectează analizatorul (parserul), iar fișierul trebuie să conțină fiecare câmp enumerat în șablon - un fișier căruia îi lipsește oricare dintre acestea este respins cu codul HTTP 422, fiind menționate numele coloanelor sau elementelor lipsă. Câmpurile de metadate nu sunt obligatorii să fie prezente. Șabloanele pentru conexiuni bancare descriu un flux PSD2 live și nu pot fiutilizate pentru importul de fișiere.

Un șablon ISO 20022 citește, de asemenea, fișiere MT940: un fișier care începe cu {1: sau :20: (sau este trimis cu "format": "mt940") este analizat ca fișier MT940, iar regulile de potrivire a referințelor și de contabilizare din șablon sunt aplicate liniilor sale. Verificarea elementelor este omisă pentru fișierele MT940, iar regulile Ntry/BkTxCd=… nu se aplică niciodată liniilor MT940 deoarece acest format nu conține un cod de tranzacție bancară ISO 20022; utilizați în schimb regulile Ntry/CdtDbtInd=….

Un cont bancar deține o singură valută. Un extras într-o altă valută este respins cu HTTP 422 (într-un fișier camt.053 care conține extrase în mai multe valute pentru același IBAN, doar extrasul în valuta contului este importat), la fel ca și o linie trimisă către bank/transactions/import cu o altă valută (currency) decât cea a contului.

Fiecare mișcare generată dintr-un câmp care are un accountCode este contabilizată la momentul importului ca o singură tranzacție jurnal: sumele încasate debitează contul contabil al băncii și creditează contul mapat; sumele plătite debitează contul mapat și creditează contul contabil al băncii. Sumele sunt convertite în valuta de bază la cursul valutar de la data mișcării. Tranzacția bancară este apoi reconciliată (matched) cu acea tranzacție jurnal (matchedDocumentType = journal_transaction) și nu mai este propusă pentru reconcilierea cu facturile. Răspunsul raportează numărul acestora în posted. Mișcările din câmpurile nemapate rămân în starea new și sunt reconciliate cu facturile ca înainte - de exemplu, mapați Fee la contul de cheltuieli cu comisioanele PSP și lăsați Amount nemapat, astfel încât încasările să fie în continuare reconciliate cu facturile de vânzare.

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

ISO 20022 camt.053 (XML pentru Open Banking)

Băncile din Lituania (Swedbank, SEB, Luminor, Šiaulių bankas, …) permit descărcarea extraselor de cont în format XML ISO 20022 camt.053 din sistemul de internet banking - de obicei în secțiunea de export/descărcare extrase, folosind formatul "ISO XML" sau "camt.053". Același format este returnat de API-urile de informații despre conturi PSD2.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • Un fișier poate conține mai multe extrase; IBAN-ul fiecărui extras trebuie să corespundă IBAN-ului contului bancar (extrasele fără IBAN sau conturile fără IBAN sunt acceptate ca atare).
  • Referințele înregistrărilor (AcctSvcrRef/NtryRef, având ca fallback un hash al conținutului) devin externalId.
  • Răspunsul returnează metadate per extras: ID-ul extrasului, perioada, soldurile de deschidere/închidere, numărul de tranzacții.
  • Numele contrapartidei, IBAN-ul și scopul plății sunt extrase pentru fiecare înregistrare în vederea reconcilierii.

Plățile în sens invers sunt exportate ca pain.001 prin intermediul bank/payments/export.

Revolut Business CSV

Descărcați extrasul de tranzacții al unui cont Revolut Business în format CSV și importați-l utilizând șablonul încorporat Revolut Business (templateId: "builtin-revolut"). Orice companie dispune de acest șablon fără a fi nevoie să îl creeze: bank/import-templates/list-builtin îl listează, bank/import-templates/get îl returnează, iar bank/import-templates/update și bank/import-templates/delete îl refuză returnând codul HTTP 400. În aplicație, acesta este listat primul sub Bancă → Șabloane de import; deschiderea lui afișează setările sale, iar salvarea creează un șablon propriu al companiei pe care îl puteți modifica.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}
  • Doar rândurile cu State = COMPLETED sunt importate. Celelalte rânduri (de exemplu PENDING) sunt omise și contorizate în warnings; ele vor fi importate printr-un import ulterior al unui fișier în care acestea apar ca finalizate.
  • Fiecare rând devine o tranzacție bancară cu data preluată din Date completed (UTC), suma din Total amount, valuta din Payment currency, ID ca externalId și Description ca descriere.
  • Contrapartea pentru plățile efectuate este reprezentată de Beneficiary name și Beneficiary IBAN; pentru o plată cu cardul fără beneficiar, contrapartea este comerciantul din Description. Contrapartea pentru încasări este Sender name și Sender account.
  • Rândurile sunt grupate după cont și valută. Câmpul International account number trebuie să corespundă IBAN-ului contului bancar și doar rândurile în valuta contului bancar sunt importate.
  • Pentru fiecare rând, importatorul verifică dacă soldul rândului anterior plus Total amount este egal cu Balance și listează în warnings fiecare rând unde această condiție nu este îndeplinită.
  • Fișierul trebuie să conțină coloanele Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name și Beneficiary name.

La fiecare import, șablonul încorporat:

  • creează un client pentru fiecare expeditor necunoscut de încasări și un furnizor pentru fiecare beneficiar necunoscut sau comerciant de card pentru plățile efectuate, conform descrierii din secțiunea Creare parteneri lipsă de mai sus;

  • reconciliază fiecare rând a cărui referință (Reference) sau descriere (Description) conține numărul unei facturi de vânzare sau achiziție deschise și înregistrează plata, aplicând verificările menționate în secțiunea Legare facturi după referință de mai sus;

  • contabilizează rândurile pe care nicio factură nu le-a potrivit în funcție de Type-ul lor, în contul unei reguli de înregistrare contabilă:

    Type Regulă contabilă Cont implicit Plan de conturi românesc Contabilizare
    FEE bank.fees 6800 627 debitează contul regulii, creditează contul contabil al băncii; partener: un furnizor numit după contul bancar
    CARD_PAYMENT bank.cardPayments 6209 628 debitează contul regulii, creditează contul contabil al băncii, fără TVA
    TOPUP bank.topUps 3010 1012 debitează contul contabil al băncii, creditează contul regulii

    Rândurile de alte tipuri, cum ar fi TRANSFER, rămân în starea new pentru reconciliere.

Modificați conturile utilizând ledger/posting-rules/update; șablonul încorporat va folosi noile conturi începând cu următorul import. O regulă de contabilizare nu poate fi dezactivată: pentru a importa plăți cu cardul sau alimentări (top-ups) fără a le contabiliza, creați un șablon de companie de tip revolut fără rândul Type=CARD_PAYMENT sau Type=TOPUP și efectuați importul utilizându-l. O plată cu cardul contabilizată în acest mod nu este reconciliată cu factura furnizorului atunci când acea factură este înregistrată ulterior; contabilizați doar una dintre cele două operațiuni, nu pe ambele.

Un șablon de companie de tip revolut utilizează aceleași coloane și poate contabiliza rândurile după tip utilizând rândurile de reguli Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER și Type=TOPUP. Un import realizat cu "format": "revolut-csv" și fără niciun șablon va importa rândurile fără a parcurge niciunul dintre aceste pași.

Stripe CSV

Exportați din panoul de control Stripe - oricare raport funcționează:

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

Creați un cont bancar dedicat pentru Stripe (de exemplu, cu numele "Stripe", cont contabil 2710 sau un subcont propriu) - soldul Stripe se comportă ca un cont bancar: încasările intră, comisioanele sunt deduse, iar transferurile (payouts) mută soldul în contul dumneavoastră bancar real.

Comportamentul la import:

  • Fiecare tranzacție de sold devine o tranzacție bancară pentru suma brută (externalId = ID-ul tranzacției de sold).
  • Un comision diferit de zero devine a doua tranzacție cu semn opus (externalId = <id>:fee, contraparte "Stripe") - astfel încât comisioanele să poată fi reconciliate/contabilizate ca cheltuieli separat de venituri. Comisioanele returnate la rambursări sunt înregistrate ca sume pozitive.
  • Rândurile de transfer (payout) sunt importate ca tranzacții unice negative; reconciliați-le cu tranzacția de încasare corespunzătoare din extrasul contului bancar real.
  • Rândurile cu sumă zero sunt omise; data este preluată din created_utc (UTC).
  • Rândurile din exportul de plăți care nu au implicat transfer de bani sunt omise: Captured = false (autorizări/capturi întârziate) și Status Failed/Canceled (Eșuat/Anulat).
  • O sumă rambursată (Amount Refunded) diferită de zero devine o a treia tranzacție negativă (externalId = <id>:refund) cu data Refunded date (UTC) - astfel încât rambursările parțiale și totale incluse în rândurile de plată să nu se piardă.

Reconcilierea de decontări PSP (rapoarte de transfer Stripe)

Pentru a împărți o plată agregată (payout în sumă globală) în comenzile, rambursările, comisioanele și refuzurile de plată (chargebacks) aferente, utilizați endpointurile de decontare în locul importului simplu de extrase. Sunt acceptate două tipuri de exporturi Stripe (detectate automat):

  • Reports → Payouts → Payout reconciliation, itemized (tipurile de raport payout_reconciliation.itemized.* sau payout_reconciliation.by_id.itemized.*) - exact, un rând per tranzacție de sold; este varianta recomandată pentru conturile live.
  • Payments → Export (unified payments) - exportul la nivel de plată; funcționează în modul test/sandbox unde reconcilierea de decontări nu este disponibilă. Plățile capturate sunt grupate după ID-ul de transfer din coloana Transfer; rândurile necapturate/eșuate sunt omise (skippedNotSettled); un Amount Refunded diferit de zero devine o linie de rambursare sintetică în lotul de transfer al plății - o aproximație, deoarece rambursarea s-ar putea să se fi decontat efectiv într-un transfer ulterior. Referințele de reconciliere provin din ID-ul plății, PaymentIntent ID, numărul facturii (Invoice Number), Client Reference ID și fiecare coloană … (metadata) (de exemplu, un număr de comandă din metadate).

Un singur fișier CSV poate acoperi mai multe transferuri. Stripe descarcă raportul detaliat câte un fișier pe secțiune (…_charge_…, …_refund_…, …_fee_…); importați-le pe toate - rândurile pentru un transfer deja importat se contopesc în lotul existent (raportat în contorul updated) atât timp cât lotul nu a fost încă contabilizat, iar totalurile lotului sunt recalibrate.

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

Comportamentul la import:

  • Rândurile sunt grupate după automatic_payout_id în loturi de decontare - un lot per transfer, cu totaluri brute/comisioane/nete (suma coloanei net reprezintă valoarea care intră în bancă). Reimportarea unui transfer este ignorată (contorul skipped). Rândurile neatribuite încă unui transfer și rândurile de tip payout în sine sunt omise și contorizate separat.
  • Fiecare rând de plată/rambursare/dispută este reconciliat automat cu o factură de vânzare utilizând, în ordine: externalRef al unei comenzi de comerț electronic (orice valoare din order_id, payment_intent_id, source_id, charge_id sau orice coloană *_metadata[...]), un fullNumber de factură care apare în acele coloane și - pentru rambursări și refuzuri de plată - charge_id-ul unei plăți anterior reconciliate (din același fișier sau din importuri anterioare).
  • Verificați cu bank/settlements/list / bank/settlements/get; corectați neconcordanțele cu bank/settlements/match { lineId, invoiceId } (sau invoiceId: null pentru anula reconcilierea).

Apelul POST /v1/bank/settlements/post { id, date?, commissionPercent? } contabilizează întregul lot ca o singură tranzacție jurnal echilibrată și decontează facturile reconciliate (webhook-urile paidAmount/paymentStatus, sale_invoice.paid):

  • Debitează contul general al băncii pentru suma netă a transferului; debitează comisioanele PSP (settlements.fees, valoarea implicită 6800) pentru comisioanele reținute și rândurile de comisioane.
  • Creditează clienții (conturi de creanțe) pentru fiecare plată reconciliată; rambursările și refuzurile de plată inversează această înregistrare. Aplicarea este plafonată la soldul rămas al fiecărei facturi - orice sumă excedentară ajunge în contul de decontări pendinte (suspans) însoțită de un avertisment.
  • Plăți nereconciliate: cu opțiunea commissionPercent setată, acestea sunt împărțite între veniturile din comisioane (settlements.commissionRevenue, valoarea implicită 5001) și o datorie față de vânzător (settlements.sellerPayable, valoarea implicită 4499) - fluxul de tip marketplace în care banii colectați aparțin în mare parte vânzătorilor. Fără acest parametru, sumele sunt alocate în contul de suspans (settlements.suspense, valoarea implicită 4440, avansuri primite).
  • Rândurile platform_earning (comisioanele de aplicație Stripe Connect) sunt înregistrate în veniturile din comisioane; rândurile transfer (plățile către vânzătorii conectați) diminuează datoria față de vânzător.
  • Toate cele patru conturi pot fi suprascrise per companie prin intermediul regulilor de contabilizare (ledger/posting-rules).
  • O linie a cărei plată, comision sau rambursare a fost deja importată într-un alt cont bancar din exportul de plăți Stripe (bank/statements/import) nu este înregistrată la comisioane, creanțe sau contul de suspans. Suma sa netă net este creditată în schimb în contul contabil al acelui cont bancar, astfel încât contul bancar Stripe să se deconteze transfer cu transfer. Câmpul summary.clearedAmount reprezintă totalul mutat în acest mod; o linie a cărei sumă diferă de ceea ce conține acel cont este menționată în warnings. Dacă nu mai rămâne nimic de înregistrat, lotul este contabilizat cu journalTransactionId având valoarea null.

Metodele bank/settlements/list și /get returnează, per lot, valorile clearedNet, clearingDifference (liniile de transfer minus sumele pe care celălalt cont bancar le deține pentru acestea; zero atunci când coincid) și clearingOpenCount (linii cu diferență sau cu o mișcare necontabilizată); /get returnează aceleași valori per linie sub formă de clearingBankAccountId, clearingBooked, clearingDifference și clearingUnposted. Liniile de rambursare ale unei plăți sunt comparate împreună, deoarece exportul de plăți conține doar totalul rambursat. Un export de plăți Stripe importat după ce transferul său a fost deja contabilizat omite mișcările acelui transfer și le menționează în warnings.

TVA-ul aferent comisionului în sine este facturat separat (emiteți o factură de comision către vânzător); divizarea alocă doar numerarul colectat.

Transferuri într-o altă valută

Registrul-jurnal este întocmit întotdeauna în valuta de bază a companiei, însă un transfer într-o valută diferită este contabilizat automat - nu este necesară introducerea manuală de date:

  • Lotul efectuează conversia la cursul valutar valabil pentru data contabilizării (date, având ca fallback data transferului, iar ulterior data de astăzi). Cursul utilizat este propriul curs al companiei pentru valuta respectivă (reference/exchange-rates/set) atunci când este cel puțin la fel de recent ca cel oficial, altfel cel mai recent curs oficial de la sau de dinaintea acelei date. Dacă nu există niciun curs disponibil la sau înainte de data respectivă, apelul eșuează cu codul 422 și indică reference/exchange-rates/sync.
  • Fiecare cont se convertește la cursul acelui lot, cu excepția conturilor de creanțe (clienți), care sunt descărcate la cursul valutar fxRate la care a fost emisă fiecare factură. Rezultatul dintre cele două cursuri este înregistrat în contul de diferențe favorabile de curs valutar bank.fxGain (valoarea implicită 5803) sau de diferențe nefavorabile bank.fxLoss (valoarea implicită 6803) ca diferență de curs valutar realizată, astfel încât registrul-jurnal să rămână în echilibru.
  • Răspunsul din summary returnează cursul de schimb fxRate utilizat și diferența de curs rezultat exchangeDifference, iar lotul reține cursul la care a fost contabilizat. O factură reconciliată a cărei valută difere de valuta lotului nu este decontată: valoarea sa este direcționată către contul de suspans însoțită de un avertisment.
  • Rămâne o singură limită de import: un singur transfer ale cărui rânduri combină mai multe valute este respins cu codul 422, la fel ca și un reimport a cărui valută diferă de cea a lotului deja stocat pentru transferul respectiv.

Fluxuri manuale / personalizate

Orice alt tip de date poate fi trimis sub formă de JSON simplu:

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

Furnizați un identificator extern stabil externalId per tranzacție pentru a asigura idempotența reimporturilor.