Nordlet

← Alapok / SDK-k

Banki és fizetési importok

camt.053 kivonatok, Stripe CSV, PSP elszámolások egyeztetése és egyedi JSON-hírek.

Minden import banki tranzakcióként érkezik egy bankszámlára (bank/accounts/create). A tranzakciók rendelkeznek externalId azonosítóval, így ugyanannak a fájlnak az újraimportálása biztonságos - azok a sorok, amelyek (bankAccountId, externalId) párja már létezik, átugrásra kerülnek, és a rendszer a skipped számlálóban jelzi ezt. Az importált tranzakciók new státusszal indulnak, és csak párosításkor kerülnek könyvelésre (bank/transactions/match, jelöltekhez a bank/transactions/suggest-matches végpont használható).

A webes alkalmazás ugyanezeket az importokat a Bank → Fájl importálása menüpont alatt teszi elérhetővé (fájlfeltöltés, sablonválasztó).

A hibás párosítás a bank/transactions/unmatch végponttal vonható vissza (a Bank → Tranzakciók menüben ez a Párosítás visszavonása). A már könyvelt tételeket a rendszer soha nem szerkeszti vagy törli: egy számlához párosított fizetés, vagy egy olyan tétel, amelyet egy importzáradék könyvelt egy számlára, egy sztornó bizonylatot kap, amely minden tételt fordított előjellel tartalmaz, a date dátummal ellátva (alapértelmezés szerint a mai nap, de soha nem korábban, mint az eredeti könyvelés dátuma). A számla kiegyenlített összege és fizetési státusza a banki sor összegével csökken. A fizetési szolgáltató (PSP) elszámolásához kapcsolt sor csak leválasztásra kerül, mivel az elszámolási könyvelés a köteg része. A sor visszatér a new státuszba, és újra párosítható. A sztornó dátumának nyitott könyvelési időszakra kell esnie.

Import sablonok

Az import sablon megnevez egy adatforrást, felsorolja a forrás által biztosított mezőket, és a pénzmozgást hordozó mezőket összerendeli (hozzárendeli) a főkönyvi számlákhoz. A sablonok a Bank → Import sablonok menüben, valamint a bank/import-templates/create|update|delete|get|list végpontokon keresztül kezelhetők.

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"]
}
  • A type értéke stripe, iso20022, bank_connection vagy revolut lehet.
  • Minden mező rendelkezik egy name névvel és egy opcionális accountCode kóddal. Csak a pénzmozgást hordozó mezők fogadnak el számlát: a Stripe esetében az Amount, a Fee és az Amount Refunded; a camt.053 esetében az Ntry/Amt; a banki hírforrásnál a transaction_amount.amount. A számlának léteznie kell a számlatükörben (létrehozásához használja a ledger/accounts/create végpontot).
  • A fields megadása elhagyható; ilyenkor a rendszer az adott típus alapértelmezett mezőlistáját használja: a Stripe Payments → Export fájl oszlopait (a 19 Card … oszlop kivételével, amelyeket az űrlap alapértelmezés szerint szintén bejelöletlenül hagy), a camt.053 elemeket, amelyeket minden kivonat tartalmaz (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), vagy a PSD2 banki hírforrás által tranzakciónként visszaadott attribútumokat. Adjon hozzá vagy távolítson el elemeket a fájlnak megfelelően: az importáló beolvassa az opcionális camt.053 elemeket is, mint például a 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 és TxDtls/AddtlTxInf.
  • A Stripe Customer Email mezője tartalmazhatja a "createPartner": true beállítást. Az importálás ekkor létrehoz egy vevőt (természetes személy partner, vevőként megjelölve) a fájlban szereplő minden olyan e-mail címhez, amelyhez még nem tartozik meglévő partner, a Customer Description értéket használva névként (üres mező esetén az e-mail címet), és a Card Address … oszlopokat címként, ha a fájl tartalmazza azokat. A meglévő partnereket a rendszer e-mail cím alapján, kis- és nagybetűkre nem érzékenyen azonosítja. A válasz a customersCreated mezőben adja vissza a darabszámot.
  • A metaFields (csak Stripe esetén) felsorolja a terhelésekhez tartozó metaadat-kulcsokat. A Stripe minden kulcsot <key> (metadata) oszlopként exportál; a lista tetszőleges összetételű és hosszú lehet.
  • Az invoiceItemId (csak Stripe esetén, opcionális) egy katalóguselem. Beállítása esetén az import által létrehozott minden számla és helyesbítő számla sora erre az elemre hivatkozik (annak könyvelésére, és ha az invoiceVatRatePercent üres, az ÁFA-kulcsára); a sor szövege továbbra is a terhelésből származik.
  • A companyMetaField (csak Stripe esetén) ezen kulcsok egyikét jelöli meg cégjelölőként. Ha egy terhelés oszlopában a true, 1, yes, company, business vagy b2b érték szerepel, az abból létrehozott vevő természetes személy helyett cég típusú partner lesz.
  • Az invoiceMetaField (csak Stripe esetén) ezen kulcsok egyikét adja meg (például egy rendelési számot), az invoiceVatRatePercent pedig az abból létrehozott számlák ÁFA-kulcsát. Importáláskor minden terhelés- és visszatérítési sor az adott kulcs értéke szerint csoportosul:
    • az olyan érték, amely megegyezik egy meglévő kimenő számlával - egy olyan vevői rendeléssel, amelynek externalRef azonosítója megegyezik ezzel az értékkel (ecommerce/orders/create, bármilyen csatorna), vagy egy olyan számlával, amelynek fullNumber száma megegyezik ezzel az értékkel -, az adott számlához kapcsolja a csoportot;
    • az olyan érték, amelyhez nem tartozik számla, újat hoz létre: a partner a Customer Email alapján (hiányzéka létrehozva, mint a createPartner esetében), soronként egy terhelés (Checkout Line Item Summary vagy Description szövegként, a terhelési összeg bruttó árként az invoiceVatRatePercent kulcs szerinti ÁFA-kulccsal), kiállítás dátuma = az első terhelés dátuma, ÁFA-kezelés a cég és a kártya országa alapján. A számla azonnal kiállításra és könyvelésre kerül, és a rendszer rögzít egy stripe csatornájú, az adott értéket externalRef azonosítóként viselő vevői rendelést, így a későbbi importok már hivatkoznak rá ahelyett, hogy újat hoznának létre;
    • a csoport egyes terhelései ezután fizetésként (a bevétel könyvelésével) párosulnak a számlához; minden visszatérítés egy kiállított helyesbítő számlát hoz létre a számlához a visszatérített összegre, és párosítja a visszatérítést azzal. A darabszámok az invoicesCreated, invoicesLinked, creditNotesCreated és paymentsMatched mezőkben érkeznek vissza; a feldolgozhatatlan csoportok (nincs vevői e-mail, vegyes devizanemek, még vázlat státuszú vagy már teljesen kifizetett kapcsolt számla) a warnings (figyelmeztetések) listában szerepelnek, és new státuszú banki tranzakcióként maradnak. Ügyeljen arra, hogy ugyanebben a sablonban ne rendelje hozzá az Amount mezőt is egy főkönyvi számlához: a számlához párosított terhelés nem kerül kétszer könyvelésre, de egy párosítatlan igen.
  • A sablonnevek cégenként egyediak.
  • A camt.053 és bankkapcsolati sablonok ugyanezeket a beállításokat tartalmazzák, amelyeket a Stripe oszlopok helyett a kivonatból olvasnak be:
    • Hiányzó partnerek létrehozása: a createPartner a adós nevét tartalmazó sorban (TxDtls/RltdPties/Dbtr/Nm, hírforrásban debtor.name) minden bejövő pénzmozgás ismeretlen fizetőjéhez létrehoz egy vevőt; a hitelező nevét tartalmazó sorban (TxDtls/RltdPties/Cdtr/Nm, hírforrásban creditor.name) minden kimenő pénzmozgás ismeretlen kedvezményezettjéhez egy szállítót. A partnerek azonosítása IBAN alapján (partner_bank_accounts táblában tárolva), majd pontos név alapján történik; az új partner cég lesz, ha a név jogi formát tartalmaz (UAB, MB, SIA, GmbH, Ltd, …), egyébként természetes személy. A darabszám a customersCreated (fájlimport) vagy partnersCreated (hírforrás szinkronizálás) mezőben érkezik vissza.
    • Számlák összekapcsolása hivatkozás alapján: az invoiceMetaField egy közlemény- vagy hivatkozási sorra (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; hírforrásban remittance_information, reference_number) beállítva minden olyan új banki sort párosít, amelynek hivatkozása, közleménye vagy leírása tartalmazza egy nyitott kimenő számla (be jövő pénz) vagy rögzített bejövő számla (kimenő pénz) számát, és könyveli a fizetést. Ha a fizető IBAN-ja rögzítve van egy partnernél, vagy a fizető neve megegyezik egy partner nevével vagy kódjával, a számlának az adott partnerhez kell tartoznia. Ismeretlen fizetőtől származó fizetés csak akkor kerül összekapcsolásra, ha az megegyezik a számla hátralévő egyenlegével, és a számlaszám tartalmazza a sorozat előtagját, így a csupasz számok (például egy összeg) soha nem minősülnek hivatkozásnak. A hátralévő egyenleget meghaladó fizetés soha nem kerül összekapcsolásra. Az ezen ellenőrzéseken elbukó sorok kézi párosításhoz új státuszban maradnak, és a figyelmeztetések között szerepelnek. Az advanceInvoices: true beállítással egy ismert partnertől származó, párosítatlan bejövő fizetés egy kiállított előlegszámlát (advance típusú) hoz létre az összegre az invoiceVatRatePercent vagy az invoiceItemId ÁFA-kulcsa alapján, és a fizetést ehhez párosítja; a partnernek ismertnek kell lennie, ezért jelölje be a adós sorát is.
    • Könyvelési szabályok tranzakciókód alapján: az Ntry/Amt / transaction_amount.amount mellett a mezőlista tartalmazza a szabálysorokat: Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (hírforrásban: bank_transaction_code=…, credit_debit_indicator=…). Egy sor annak az első szabálynak a számlájára kerül könyvelésre, amelyre illeszkedik: először a banki tranzakciókód családja, majd az iránya, végül az egyszerű összegre vonatkozó sor. A szabálysorokat a rendszer nem ellenőrzi a fájlban.
    • Bankköltség partner: a createPartner a …=CHRG szabálysoron létrehoz egy szállítót a bank elnevezésével (kivonatból: Stmt/Acct/Svcr/FinInstnId/Nm, vagy a kapcsolat bankja, vagy a főkönyvi bankszámla neve), és minden költséget ehhez a partnerhez könyvel.
    • A bankkapcsolati sablonokat hírforrásszámlánként a bank/feeds/accounts/configure végponttal lehet kiválasztani (az alkalmazásban a Bank → Kapcsolatok menüben), amely a syncSchedule beállítást (manual, daily, weekly, monthly) is rögzíti: az API az ütemezéssel rendelkező számlákat az időszak letelte után önmagától szinkronizálja. A sablonok minden bank/feeds/sync híváskor érvényesülnek; a szinkronizálási válasz ekkor a posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched és warnings értékeket is visszaadja.

Adja át a templateId paramétert a bank/statements/import végpontnak a format helyett: a sablon típusa kiválasztja a feldolgozót, és a fájlnak tartalmaznia kell a sablonban felsorolt összes mezőt - a hiányzó oszlop- vagy elemaneveket tartalmazó fájlt a rendszer HTTP 422 hibával elutasítja. A metaadat-mezők megléte nem kötelező. A bankkapcsolati sablonok élő PSD2 hírforrást írnak le, ezért fájlimportáláshoz nem használhatók.

Az ISO 20022 sablon MT940 fájlokat is beolvas: a {1: vagy :20: karakterekkel kezdődő (vagy "format": "mt940" paraméterrel küldött) fájlt a rendszer MT940 formátumként dolgozza fel, és a sablon hivatkozáspárosítási, valamint könyvelési szabályait alkalmazza a soraira. MT940 esetén az elemellenőrzés kihagyásra kerül, és az Ntry/BkTxCd=… szabályok soha nem érvényesülnek az MT940 sorokra, mivel az MT940 nem tartalmaz ISO 20022 banki tranzakciókódot; használja helyette az Ntry/CdtDbtInd=… szabályokat.

Egy bankszámla egy devizát tart nyilván. Egy eltérő devizájú kivonatot a rendszer HTTP 422 hibával elutasít (egy olyan camt.053 fájl esetén, amely egy IBAN-hoz több devizájú kivonatot is tartalmaz, csak a számla devizájának megfelelő kivonat kerül importálásra), és ugyanez vonatkozik a bank/transactions/import végpontra küldött, a számlától eltérő currency devizájú sorokra is.

Minden olyan mezőből származó pénzmozgás, amely rendelkezik accountCode kóddal, az importálás pillanatában egyetlen vegyes bizonylatként kerül könyvelésre: a bejövő pénz terheli a bankszámla főkönyvi számláját és jóváírja a hozzárendelt számlát; a kimenő pénz terheli a hozzárendelt számlát és jóváírja a bankszámla főkönyvi számláját. Az összegek a pénzmozgás napján érvényes árfolyamon kerülnek átváltásra az alappénznemre. Ezt követően a banki tranzakció összekapcsolásra (matched) kerül az adott vegyes bizonylattal (matchedDocumentType = journal_transaction), és a továbbiakban nem ajánlott fel számlapárosításhoz. A válasz a posted mezőben adja vissza a darabszámot. A nem hozzárendelt mezőkből származó pénzmozgások new státuszban maradnak, és a korábbiakhoz hasonlóan számlákhoz párosíthatók - például a Fee mezőt a PSP költségek ráfordítás számlájához rendelheti, míg az Amount mezőt hozzárendelés nélkül hagyja, így a terhelések továbbra is párosíthatók a vevői számlákkal.

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

ISO 20022 camt.053 (nyílt banki XML)

A litván bankok (Swedbank, SEB, Luminor, Šiaulių bankas, …) lehetővé teszik a számlakivonatok letöltését ISO 20022 camt.053 XML formátumban az internetbankjukból - általában a kivonatok exportálása/letöltése menüpont alatt, "ISO XML" vagy "camt.053" formátumot választva. Ugyanezt a formátumot adják vissza a PSD2 számlainformációs API-k is.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • A fájl több kivonatot is tartalmazhat; az egyes kivonatok IBAN azonosítójának meg kell egyeznie a bankszámla IBAN azonosítójával (az IBAN-nel nem rendelkező kivonatok vagy az IBAN nélküli számlák változtatás nélkül elfogadásra kerülnek).
  • A tételre vonatkozó hivatkozások (AcctSvcrRef/NtryRef, tartalmi hash-re visszalépve) lesznek az externalId azonosítók.
  • A válasz kivonatonként visszatükrözi a metaadatokat: kivonat azonosítója, időszaka, nyitó/záró egyenlege, tranzakciók száma.
  • A partner neve, IBAN azonosítója és a közlemény a párosításhoz tételenként kinyerésre kerül.

Az ellenkező irányú fizetések exportálása pain.001 formátumban a bank/payments/export végponton keresztül történik.

Revolut Business CSV

Töltse le a Revolut Business számla tranzakciós kivonatát CSV formátumban, és importálja a beépített Revolut Business sablonnal (templateId: "builtin-revolut"). Minden cég rendelkezik ezzel a sablonal anélkül, hogy létre kellene hoznia: a bank/import-templates/list-builtin listázza, a bank/import-templates/get lekéri, míg a bank/import-templates/update és bank/import-templates/delete HTTP 400 hibával elutasítja. Az alkalmazásban ez jelenik meg elsőként a Bank → Import sablonok menüben; megnyitásakor láthatók a beállításai, mentésekor pedig egy saját céges sablon jön létre, amelyet módosíthat.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}
  • Csak a State = COMPLETED státuszú sorok kerülnek importálásra. A többi sort (például a PENDING státuszúakat) a rendszer kihagyja, és a warnings számlálóban összesíti; ezek egy későbbi, olyan fájl importálásakor kerülnek be, amelyben már teljesültek.
  • Minden sor banki tranzakcióvá alakul a Date completed (UTC) szerinti dátummal, a Total amount szerinti összeggel, a Payment currency szerinti devizával, az ID azonosítóval mint externalId, valamint a Description leírással.
  • A kimenő pénz partnere a Beneficiary name és a Beneficiary IBAN; kedvezményezett nélküli kártyás fizetés esetén a kereskedő a Description mezőből. A bejövő pénz partnere a Sender name és a Sender account.
  • A sorok számla és deviza szerint csoportosulnak. Az International account number oszlopnak meg kell egyeznie a bankszámla IBAN azonosítójával, és csak a bankszámla devizájában lévő sorok kerülnek importálásra.
  • Az importáló minden sor esetében ellenőrzi, hogy az előző sor egyenlege plusz a Total amount megegyezik-e a Balance értékkel, és a warnings mezőben felsorolja azokat a sorokat, amelyeknél ez nem teljesül.
  • A fájlnak tartalmaznia kell a következő oszlopokat: Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name és Beneficiary name.

Minden importálás során a beépített sablon:

  • létrehoz egy vevőt minden ismeretlen bejövő pénzküldőhöz, és egy szállítót minden ismeretlen kimenő kedvezményezetthez vagy kártyás kereskedőhöz, a fenti Hiányzó partnerek létrehozása részben leírtak szerint;

  • párosítja minden olyan sor, amelynek a Reference vagy Description mezője tartalmazza egy nyitott kimenő vagy bejövő számla számát, és könyveli a fizetést a fenti Számlák összekapcsolása hivatkozás alapján ellenőrzéseivel;

  • könyvelési szabály alapján könyveli azokat a sorokat, amelyekhez nem tartozott számla, a Type mezőjük alapján:

    Type Könyvelési szabály Alapértelmezett számla Román számlatükör Könyvelés
    FEE bank.fees 6800 627 a szabály számlájának terhelése, a bankszámla főkönyvi számlájának jóváírása; partner: a bankszámláról elnevezett szállító
    CARD_PAYMENT bank.cardPayments 6209 628 a szabály számlájának terhelése, a bankszámla főkönyvi számlájának jóváírása, ÁFA nélkül
    TOPUP bank.topUps 3010 1012 a bankszámla főkönyvi számlájának terhelése, a szabály számlájának jóváírása

    Az egyéb típusú sorok, például a TRANSFER, párosítatlan new státuszban maradnak.

A számlákat a ledger/posting-rules/update végponttal módosíthatja; a beépített sablon a következő importálástól kezdve az új számlákat használja. Egy könyvelési szabály nem kapcsolható ki: a kártyás fizetések vagy feltöltések könyvelés nélküli importálásához hozzon létre egy revolut típusú céges sablont a Type=CARD_PAYMENT vagy Type=TOPUP sorok nélkül, és azzal végezze az importálást. Az így könyvelt kártyás fizetés nem párosul a szállító számlájával, ha azt a számlát később rögzítik; a kettő közül csak az egyiket könyvelje, ne mindkettőt.

Egy revolut típusú céges sablon ugyanazokat az oszlopokat használja, és képes sorokat könyvelni típus szerint a Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER és Type=TOPUP szabálysorok használatával. A "format": "revolut-csv" paraméterrel és sablon nélkül végzett importálás ezen lépések nélkül importálja a sorokat.

Stripe CSV

Exportálás a Stripe vezérlőpultról (bármelyik jelentés megfelelő):

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

Hozzon létre egy külön bankszámlát a Stripe számára (pl. "Stripe" névvel, 2710-es főkönyvi számlával vagy saját alszámlával) - a Stripe egyenleg úgy viselkedik, mint egy bankszámla: a terhelések beáramlanak, a díjak levonásra kerülnek, a kifizetések pedig átutalják az egyenleget avalódi bankszámlájára.

Importálási viselkedés:

  • Minden egyenlegtranzakció egyetlen banki tranzakcióvá alakul a bruttó összeggel (externalId = egyenlegtranzakció azonosítója).
  • A nem nulla díj egy második, ellentétes előjelű tranzakciót hoz létre (externalId = <id>:fee, partner "Stripe") - így a díjak a bevételektől elkülönítve, ráfordításként párosíthatók/könyvelhetők. A visszatérítések során visszajáró díjak pozitív összegként érkeznek.
  • A payout (kifizetés) sorok egyetlen negatív tranzakcióként importálódnak; párosítsa ezeket a valódi bankszámlakivonat megfelelő bejövő tranzakciójával.
  • A nulla összegű sorok átugrásra kerülnek; a dátum a created_utc (UTC) mezőből származik.
  • A pénzmozgást nem generáló fizetési export sorok kihagyásra kerülnek: Captured = false (engedélyezések/késleltetett terhelések) és Status Failed/Canceled (Sikertelen/Törölt).
  • A nem nulla Amount Refunded (visszatérített összeg) egy harmadik, negatív tranzakcióvá alakul (externalId = <id>:refund), a Refunded date (UTC) dátummal ellátva - így a fizetési sorokba ágyazott részleges és teljes visszatérítések sem veszendők el.

PSP elszámolások egyeztetése (Stripe kifizetési jelentések)

Az átalányösszegű kifizetések mögöttes rendelésekre, visszatérítésekre, díjakra és visszaterhelésekre történő felbontásához az egyszerű kivonatimport helyett használja az elszámolási végpontokat. Kétféle Stripe export fogadható el (a rendszer automatikusan felismeri):

  • Reports → Payouts → Payout reconciliation, itemized (payout_reconciliation.itemized.* vagy payout_reconciliation.by_id.itemized.* jelentéstípusok) - pontos, egyenlegtranzakciónként egy sor; éles fiókokban ez ajánlott.
  • Payments → Export (unified payments) - a terhelés szintű export; teszt/sandbox módban működik, ahol a kifizetés-egyeztetés nem érhető el. A lekönyvelt terhelések a Transfer oszlopban lévő kifizetési azonosító szerint csoportosulnak; a le nem könyvelt/sikertelen sorok átugrásra kerülnek (skippedNotSettled); a nem nulla Amount Refunded egy szintetikus visszatérítási sorrá alakul a terhelés kifizetési kötegében - ez egy becslés, mivel előfordulhat, hogy a visszatérítés valójában egy későbbi kifizetés során rendeződött. A párosítási hivatkozások a terhelési azonosítóból, a PaymentIntent ID, a Invoice Number, a Client Reference ID azonosítókból és az összes … (metadata) oszlopból származnak (pl. egy rendelési szám a metaadatokban).

Egyetlen CSV fájl több kifizetést is átölelhet. A Stripe a részletezett jelentést részenként egy fájlban tölti le (…_charge_…, …_refund_…, …_fee_…); importálja mindegyiket - a már importált kifizetés sorai egyesülnek a meglévő köteggel (a updated számláló jelzi), amíg az nem került könyvelésre, és a köteg összesítései újraszámolásra kerülnek.

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

Importálási viselkedés:

  • A sorok az automatic_payout_id alapján elszámolási kötegekké csoportosulnak - kifizetésenként egy köteg, bruttó/díj/nettó összesítéssel (a sorok net értékének összege = a bankszámlára érkező összeg). Egy kifizetés újraimportálása kihagyásra kerül (skipped számláló). A kifizetéshez még nem rendelt sorok és maguk a payout sorok kihagyásra kerülnek, és külön kerülnek összesítésre.
  • Minden terhelési/visszatérítési/vitatott sor automatikusan párosul egy vevői számlával az alábbi sorrendet használva: egy e-commerce rendelés externalRef azonosítója (order_id, payment_intent_id, source_id, charge_id vagy bármely *_metadata[...] oszlop értéke), az ezen oszlopokban szereplő számla fullNumber száma, valamint - visszatérítések és visszaterhelések esetén - a korábban párosított terhelés charge_id azonosítója (ugyanabból a fájlból vagy korábbi importokból).
  • Ellenőrzés a bank/settlements/list / bank/settlements/get végpontokkal; a fennmaradó tételek rendezése a bank/settlements/match { lineId, invoiceId } végponttal (vagy invoiceId: null paraméterrel a párosítás visszavonásához).

A POST /v1/bank/settlements/post { id, date?, commissionPercent? } hívás az egész köteget egyetlen egyensúlyban lévő vegyes bizonylatként könyveli, és rendezni a párosított számlákat (paidAmount/paymentStatus, sale_invoice.paid webhookok):

  • Terheli a bankszámla főkönyvi számláját a nettó kifizetés összegével; terheli a PSP díjakat (settlements.fees, alapértelmezésben 6800) a visszatartott díjak és díjsorok összegével.
  • Jóváírja a vevőköveteléseket a párosított terhelések alapján; a visszatérítések és visszaterhelések ezt megfordítják. Az alkalmazás felső határa az egyes számlák hátralékos összege - minden felesleg figyelmeztetéssel a technikai (függő) számlára kerül.
  • Párosítatlan terhelések: megadott commissionPercent esetén a rendszer felosztja azokat jutalékbevételre (settlements.commissionRevenue, alapértelmezésben 5001) és eladói tartozásra (settlements.sellerPayable, alapértelmezésben 4499) - ez a marketplace (piaci) folyamat, ahol az összegyűjtött pénz túlnyomórészt az eladókat illeti meg. Ennek hiányában a tételek a settlements.suspense számlán (alapértelmezésben 4440, kapott előlegek) parkolnak.
  • A platform_earning sorok (Stripe Connect alkalmazási díjak) a jutalékbevételre könyvelődnek; a transfer sorok (kapcsolt eladók részére történő kifizetések) csökkentik az eladói tartozást.
  • Mind a négy számla felülírható cégenként a könyvelési szabályokon keresztül (ledger/posting-rules).
  • Az olyan sor, amelynek terhelését, díját vagy visszatérítését korábban már importálták egy másik bankszámlára a Stripe fizetési exportból (bank/statements/import), nem kerül könyvelésre a díjakra, követelésekre vagy függő számlára. Ehelyett a net összege az adott bankszámla főkönyvi számlájára kerül jóváírásra, így a Stripe bankszámla kifizetésről kifizetésre egyenlítődik ki. A summary.clearedAmount a így áthelyezett teljes összeg; az olyan sor, amelynek összege eltér az adott számlán lévő összegtől, a warnings mezőben szerepel. Ha nem maradt semmi könyvelni való, a köteg journalTransactionId null értékkel kerül könyvelésre.

A bank/settlements/list és /get végpontok kötegenként visszaadják a clearedNet, clearingDifference (a kifizetési sorok mínusz a többi bankszámla által ezekre tartott összegek; megegyezés esetén nulla) és clearingOpenCount (eltéréssel vagy nem könyvelt pénzmozgással rendelkező sorok) értékeket; a /get ugyanezeket tételenként is visszaadja mint clearingBankAccountId, clearingBooked, clearingDifference és clearingUnposted. Egy terhelés visszatérítési sorait a rendszer együtt vizsgálja, mivel a fizetési export csak a visszatérített végösszeget tartalmazza. A kifizetés könyvelése után importált Stripe fizetési export átugorja az adott kifizetés pénzmozgásait, és megjelöli azokat a warnings mezőben.

A jutalék ÁFA-ját a rendszer külön számlázza (állítson ki jutalékszámlát az eladónak); a felosztás csak a behajtott készpénzt allokálja.

Eltérő devizájú kifizetések

A vegyes bizonylat mindig a cég alappénznemében készül, de egy eltérő devizájú kifizetés automatikusan könyvelésre kerül - nincs szükség kézi rögzítésre:

  • A köteg átváltása a könyvelési nap (date, visszalépve a kifizetés dátumára, majd a mai napra) szerinti árfolyamon történik. Az árfolyam a cég saját árfolyama az adott devizára vonatkozóan (reference/exchange-rates/set), ha az legalább olyan friss, mint a hivatalos, egyébként az adott napon vagy azt megelőzően érvényes legfrissebb hivatalos árfolyam. Ha nincsen árfolyam az adott napon vagy azt megelőzően, a hívás 422 hibával meghiúsul, és megemlíti a reference/exchange-rates/sync végpontot.
  • Minden számla az adott kötegi árfolyamon váltódik át kivéve a vevőköveteléseket, amelyek kivezetése azzal az fxRate árfolyamon történik, amelyen az adott számla ki lett állítva. A két árfolyam közötti különbözet realizált árfolyamkülönbözetként a bank.fxGain (alapértelmezésben 5803) vagy bank.fxLoss (alapértelmezésben 6803) számlára könyvelődik, így a vegyes bizonylat egyensúlyban marad.
  • A válasz summary része visszatéríti a felhasznált fxRate árfolyamot és az abból adódó exchangeDifference különbözetet, és a köteg megőrzi azt az árfolyamot, amellyel könyvelve lett. Az olyan párosított számla, amelynek saját devizája eltér a köteg devizájától, nem kerül rendezésre: összege figyelmeztetéssel a függő számlára kerül.
  • Egy importálási korlátozás fennmarad: az olyan egyetlen kifizetés, amelynek sorai több devizát kevernek, 422 hibával elutasításra kerül, és ugyanez vonatkozik az olyan újraimportálásra is, amelynek devizája eltér az adott kifizetéshez már tárolt köteg devizájától.

Kézi / egyedi hírek

Bármilyen egyéb adat beküldhető sima JSON formátumban:

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

Tranzakciónként adjon meg egy stabil externalId azonosítót az újraimportálások idempotenciájának megőrzéséhez.