Nordlet

← Документація / Посібники

Банківські та платіжні імпорти

Виписки camt.053, CSV-файли Stripe, звірка розрахунків з ПСП та кастомні JSON-потоки.

Усі імпорти надходять як банківські транзакції на банківський рахунок (bank/accounts/create). Транзакції мають поле externalId; повторний імпорт того самого файлу є безпечним: рядки, чия пара (bankAccountId, externalId) вже існує, пропускаються, а їхня кількість фіксується у лічильнику skipped. Імпортовані транзакції розпочинають роботу зі статусом new і проводяться в головну книгу (ledger) лише після зіставлення (bank/transactions/match, при цьому для кандидатів використовується bank/transactions/suggest-matches).

Вебдодаток надає доступ до таких самих імпортів у розділі Банк → Імпорт файлу (завантаження файлу, вибір шаблону).

Помилкове зіставлення скасовується за допомогою bank/transactions/unmatch (кнопка Скасувати зіставлення у розділі Банк → Транзакції). Проведені записи ніколи не редагуються та не видаляються: платіж, зіставлений із рахунком-фактурою (invoice), або рядок, який шаблон імпорту провів за рахунком, отримує сторнуючу журнальну транзакцію з кожним записом на протилежному боці. Дата такої транзакції встановлюється у полі date (за замовчуванням сьогодні, але ніколи не раніше за дату початкового проведення). Оплачена сума та статус оплати рахунка-фактури зменшуються на суму цього банківського рядка. Рядок, пов'язаний зі звіркою постачальника платіжних послуг (PSP settlement), лише розриває зв'язок, оскільки проведення розрахунку належить до пакета. Рядок повертається у статус new, і його можна зіставити знову. Дата сторно має припадати на відкритий обліковий період.

Шаблони імпорту

Шаблон імпорту визначає джерело даних, перераховує поля, які надає джерело, та зіставляє поля з грошовими сумами з рахунками головної книги. Шаблони керуються в розділі Банк → Шаблони імпорту та за допомогою 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 набуває одного із значень: stripe, iso20022, bank_connection або revolut.
  • Кожне поле має name та необ'язковий accountCode. Рахунок приймають лише поля з грошовими сумами: Stripe Amount, Fee та Amount Refunded; camt.053 Ntry/Amt; банківський потік transaction_amount.amount. Рахунок має існувати в План рахунків (створіть його за допомогою ledger/accounts/create).
  • Масив fields можна пропустити; у такому разі за замовчуванням використовується стандартний список полів для цього типу: назви стовпців файлу експорту Stripe Payments → Export (без 19 стовпців Card …, які у формі також за замовчуванням залишаються не позначеними), елементи camt.053, які містить кожна виписка (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), або атрибути, які повертає банківський потік PSD2 для кожної транзакції. Додайте або видаліть записи відповідно до вашого файлу: імпортер також зчитує необ'язкові елементи camt.053 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 та TxDtls/AddtlTxInf.
  • Поле Stripe Customer Email може містити параметр "createPartner": true. У такому разі імпорт створює клієнта (контрагента типу „фізична особа“, позначеного як клієнт) для кожної електронної адреси у файлі, якої немає в жодного наявного контрагента. Як ім'я використовується Customer Description (або сама електронна адреса, якщо воно порожнє), а як адреса – стовпці Card Address …, якщо файл їх містить. Наявні контрагенти визначаються за електронною адресою без урахування регістру. У відповіді повертається кількість у полі customersCreated.
  • metaFields (тільки для Stripe) перераховує ключі метаданих, які містять ваші платежі. Stripe експортує кожен ключ як стовпчик <key> (metadata). Цей список є довільним і може бути довгим.
  • invoiceItemId (тільки для Stripe, необ'язково) є елементом каталогу. Якщо цей параметр встановлено, кожен рядок рахунка-фактури та кредитної ноти, створюваний імпортом, посилається на цей елемент (його проведення та, якщо invoiceVatRatePercent не заповнено, його ставку ПДВ); текст рядка все одно береться з платежу.
  • companyMetaField (тільки для Stripe) визначає один із цих ключів як ознаку компанії. Якщо платіж містить у цьому стовпчику значення true, 1, yes, company, business або b2b, створений для нього клієнт стає контрагентом типу „компанія“ замість „фізичної особи“.
  • invoiceMetaField (тільки для Stripe) визначає один із таких ключів (наприклад, номер замовлення), а invoiceVatRatePercent – ставку ПДВ для створених із нього рахунків-фактур. Під час імпорту кожен рядок платежу та повернення групується за значенням цього ключа:
    • значення, яке збігається з наявним рахунком-фактурою продажу (замовлення на продаж, чий externalRef дорівнює цьому значенню (ecommerce/orders/create, будь-який канал) або рахунок-фактура, чий fullNumber дорівнює цьому значенню), пов'язує групу з цим рахунком-фактурою;
    • значення без відповідного рахунка-фактури створює його: контрагент береться з поля Customer Email (створюється, якщо відсутній, як і для createPartner), по одному рядку на платіж (Checkout Line Item Summary або Description як текст, сума платежу як ціна з ПДВ за ставкою invoiceVatRatePercent), дата виставлення дорівнює даті першого платежу, обкладання ПДВ визначається за компанією та країною картки. Рахунок-фактура виставляється та проводиться одразу, а в системі реєструється замовлення на продаж із каналом stripe та цим значенням як externalRef, щоб наступні імпорти виконували зв'язування замість створення;
    • кожен платіж у групі потім зіставляється з рахунком-фактурою як оплатний документ (з проведенням надходження); кожне повернення створює виставлену кредитну ноту до рахунка-фактури на суму повернення та зіставляє повернення з нею. Кількість повертається у полях invoicesCreated, invoicesLinked, creditNotesCreated та paymentsMatched; групи, які не вдалося обробити (немає електронної адреси клієнта, змішані валюти, пов'язаний рахунок-фактура все ще перебуває в чорновиках або вже повністю оплачений), перераховуються у warnings і залишаються банківськими транзакціями зі статусом new. Не зіставляйте також поле Amount з рахунком головної книги в тому самому шаблоні: платіж, зіставлений із рахунком-фактурою, не проводиться вдруге, але незіставлений платіж було б проведено.
  • Назви шаблонів є унікальними в межах компанії.
  • Шаблони camt.053 та банківських підключень мають такі самі параметри, які зчитуються з виписки замість стовпців Stripe:
    • Створювати відсутніх контрагентів (Create missing partners): параметр createPartner у рядку імені боржника (TxDtls/RltdPties/Dbtr/Nm, для потоку – debtor.name) створює клієнта для кожного невідомого платника вхідних коштів; у рядку імені отримувача (TxDtls/RltdPties/Cdtr/Nm, для потоку – creditor.name) – постачальника для кожного невідомого одержувача вихідних коштів. Контрагенти розпізнаються за IBAN (зберігається в partner_bank_accounts), а потім за точним ім'ям. Новий контрагент вважається компанією, якщо його назва містить організаційно-правову форму (UAB, MB, SIA, GmbH, Ltd тощо), інакше – фізичною особою. Кількість повертається в customersCreated (імпорт файлу) або partnersCreated (синхронізація потоку).
    • Зв'язувати рахунки-фактури за референсом (Link invoices by reference): параметр invoiceMetaField, встановлений на рядок призначення платежу або референсу (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; для потоку – remittance_information, reference_number), зіставляє кожен новий банківський рядок, чий референс, призначення чи опис містить номер відкритого виставленого рахунка-фактури продажу (надходження коштів) або зареєстрованого рахунка-фактури купівлі (вибуття коштів), і проводить платіж. Якщо IBAN платника збережено в контрагента, або ім'я платника збігається з ім'ям чи кодом контрагента, рахунок-фактура має належати цьому контрагенту. Платіж від невідомого платника зв'язується лише тоді, коли він дорівнює залишком за рахунком-фактурою, а номер рахунка-фактури містить префікс серії, тому голий номер на кшталт суми ніколи не сприймається як референс. Платіж, більший за залишок заборгованості, ніколи не зв'язується. Рядки, що не пройшли ці перевірки, залишаються зі статусом new для ручного зіставлення та перераховуються у попередженнях. Якщо увімкнено параметр advanceInvoices: true, незіставлений вхідний платіж від відомого контрагента створює виставлений авансовий рахунок (тип advance) на суму за ставкою invoiceVatRatePercent або ставкою invoiceItemId та зіставляє платіж із ним; контрагент при цьому має бути відомим, тому позначте також рядок боржника.
    • Правила проведення за кодом транзакції (Posting rules by transaction code): окрім Ntry/Amt / transaction_amount.amount, список полів містить рядки правил Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (для потоку – bank_transaction_code=…, credit_debit_indicator=…). Рядок проводиться на рахунок першого правила, якому він відповідає: спочатку родина коду банківської транзакції, потім напрямок, і насамкінд рядок звичайної суми. Рядки правил не перевіряються на наявність у файлі.
    • Контрагент банківських комісій (Bank charges partner): параметр createPartner у рядку правила …=CHRG створює постачальника, назва якого збігається з назвою банку (виписка Stmt/Acct/Svcr/FinInstnId/Nm, або банк підключення, або назва банківського рахунка в головній книзі), і проводить кожну комісію на цього контрагента.
    • Шаблони банківських підключень вибираються для кожного рахунка потоку за допомогою bank/feeds/accounts/configure (у додатку Банк → Підключення), де також задається розклад синхронізації syncSchedule (manual, daily, weekly, monthly): API самостійно синхронізує рахунки за розкладом після настання їхнього періоду. Шаблони застосовуються під час кожного виклику bank/feeds/sync; відповідь синхронізації також містить кількість posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched та warnings.

Передайте templateId до методу bank/statements/import замість format: тип шаблону вибирає парсер, і файл повинен містити кожне поле, перелічене в шаблоні. Якщо у файлі бракує хоча б одного з них, він відхиляється з кодом помилки HTTP 422 із зазначенням назв відсутніх стовпців або елементів. Поля метаданих не обов'язково повинні бути присутніми. Шаблони банківських підключень описують реальний потік PSD2 і не можуть використовуватися для імпорту файлів.

Шаблон ISO 20022 також зчитує файли у форматі MT940: файл, який починається з {1: або :20: (або надсилається з параметром "format": "mt940"), аналізується як MT940, і до його рядків застосовуються правила зіставлення референсів та проведення шаблону. Перевірка елементів для MT940 пропускається, а правила Ntry/BkTxCd=… ніколи не застосовуються до рядків MT940, оскільки цей формат не містить коду банківської транзакції ISO 20022; натомість використовуйте правила Ntry/CdtDbtInd=….

Банківський рахунок має одну валюту. Виписка в іншій валюті відхиляється з кодом HTTP 422 (у файлі camt.053 із виписками в кількох валютах для одного IBAN імпортується лише виписка у валюті рахунка), так само як і рядок, надісланий до bank/transactions/import у валюті, що відрізняється від валюти рахунка.

Кожне переміщення, створене з поля, яке має accountCode, проводиться в момент імпорту як одна журнальна транзакція: надходження коштів дебетує рахунок головної книги банківського рахунка та кредитує зіставлений рахунок; вибуття коштів дебетує зіставлений рахунок і кредитує рахунок головної книги банківського рахунка. Суми конвертуються у базову валюту за курсом на дату переміщення. Банківська транзакція отримує статус matched із цією журнальною транзакцією (matchedDocumentType = journal_transaction) і більше не пропонується для зіставлення з рахунками-фактурами. У відповіді повертається кількість у полі posted. Переміщення з незіставлених полів залишаються зі статусом new і зіставляються з рахунками-фактурами, як і раніше (наприклад, зіставте Fee з рахунком витрат на комісію PSP і залиште Amount незіставленим, щоб платежі все одно зіставлялися з рахунками-фактурами продажу).

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

ISO 20022 camt.053 (XML відкритого банкінгу)

Литовські банки (Swedbank, SEB, Luminor, Šiaulių bankas тощо) дозволяють завантажувати виписки за рахунками у форматі ISO 20022 camt.053 XML через інтернет-банкінг – зазвичай у розділі експорту/завантаження виписок, формат "ISO XML" або "camt.053". Такий самий формат повертається API інформації про рахунки PSD2.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • Файл може містити кілька виписок; IBAN кожної виписки має збігатися з IBAN банківського рахунка (виписки без IBAN або рахунки без нього приймаються як є).
  • Референси записів (AcctSvcrRef/NtryRef, з резервним варіантом хешу вмісту) стають значеннями externalId.
  • У відповіді дублюються метадані по кожній виписці: ідентифікатор виписки, період, вхідне/закриваюче сальдо, кількість транзакцій.
  • Назва контрагента, IBAN та призначення платежу витягуються для кожного запису окремо для цілей зіставлення.

Платежі у зворотному напрямку експортуються як pain.001 за допомогою bank/payments/export.

Revolut Business CSV

Завантажте виписку транзакцій рахунка Revolut Business у форматі CSV та імпортуйте її за допомогою вбудованого шаблону Revolut Business (templateId: "builtin-revolut"). Цей шаблон є у кожної компанії без необхідності його створення: bank/import-templates/list-builtin виводить його у списку, bank/import-templates/get повертає його, а bank/import-templates/update та bank/import-templates/delete відхиляють запит із кодом HTTP 400. У додатку він відображається першим у розділі Банк → Шаблони імпорту; його відкриття показує налаштування, а збереження створює власний шаблон компанії, який ви можете змінювати.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}
  • Імпортуються лише рядки зі статусом State = COMPLETED. Інші рядки (наприклад, PENDING) пропускаються і враховуються у полі warnings; вони будуть імпортовані під час наступного імпорту файлу, у якому вони матимуть статус завершених.
  • Кожен рядок стає банківською транзакцією з датою з поля Date completed (UTC), сумою з Total amount, валютою з Payment currency, ідентифікатором ID як externalId та описом з Description.
  • Контрагентом для вибуття коштів є Beneficiary name та Beneficiary IBAN; для карткового платежу без бенефіціара контрагентом є мерчант із поля Description. Контрагентом для надходження коштів є Sender name та Sender account.
  • Рядки групуються за рахунком і валютою. International account number має збігатися з IBAN банківського рахунка, і імпортуються лише рядки у валюті банківського рахунка.
  • Для кожного рядка імпортер перевіряє, чи дорівнює сальдо попереднього рядка плюс Total amount значенню Balance, і фіксує у warnings усі рядки, де ця умова не виконується.
  • Файл повинен містити стовпці Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name та Beneficiary name.

Під час кожного імпорту вбудований шаблон виконує такі дії:

  • створює клієнта для кожного невідомого відправника вхідних коштів і постачальника для кожного невідомого бенефіціара чи карткового мерчанта вибуття коштів, як описано в розділі Створювати відсутніх контрагентів вище;

  • зіставляє кожен рядок, чий Reference або Description містить номер відкритого рахунка-фактури продажу чи купівлі, і проводить платіж із дотриманням перевірок з розділу Зв'язувати рахунки-фактури за референсом вище;

  • проводить рядки, які не збіглися з жодним рахунком-фактурою, за їхнім типом Type на рахунок правила проведення згідно з таблицею:

    Type Правило проведення Рахунок за замовчуванням Румунський план Проведення
    FEE bank.fees 6800 627 дебет рахунка правила, кредит рахунка головної книги банківського рахунка; контрагент – постачальник, названий на честь банківського рахунка
    CARD_PAYMENT bank.cardPayments 6209 628 дебет рахунка правила, кредит рахунка головної книги банківського рахунка, без ПДВ
    TOPUP bank.topUps 3010 1012 дебет рахунка головної книги банківського рахунка, кредит рахунка правила

    Рядки інших типів, наприклад TRANSFER, залишаються у статусі new для подальшого зіставлення.

Змінюйте рахунки за допомогою ledger/posting-rules/update; вбудований шаблон почне використовувати нові рахунки починаючи з наступного імпорту. Вимкнути правило проведення неможливо: щоб імпортувати карткові платежі або поповнення без їх проведення, створіть шаблон компанії типу revolut без рядків Type=CARD_PAYMENT або Type=TOPUP і виконуйте імпорт за його допомогою. Картковий платіж, проведений таким способом, не зіставляється з рахунком-фактурою постачальника, якщо цей рахунок реєструється пізніше; проводьте щось одне, а не обидва варіанти.

Шаблон компанії типу revolut використовує такі самі стовпці та може проводити рядки за типом за допомогою рядків правил Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER та Type=TOPUP. Імпорт із параметром "format": "revolut-csv" без зазначення шаблону імпортує рядки без жодного з цих кроків.

Stripe CSV

Експорт із панелі керування Stripe (підходить будь-який ізвіт):

  • Reports → Balance → Itemized balance change from activity (рекомендується): стовпці balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description.
  • Payments → Export: стовпці 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,…"
}

Створіть окремий банківський рахунок для Stripe (наприклад, з назвою "Stripe", рахунок головної книги 2710 або власний субрахунок) – баланс Stripe поводиться як банківський рахунок: надходять платежі, утримуються комісії, а виплати переказують кошти на ваш реальний банківський рахунок.

Поведінка під час імпорту:

  • Кожна балансова транзакція стає однією банківською транзакцією на валову (gross) суму (externalId = ідентифікатор балансової транзакції).
  • Нещирова комісія (fee) стає другою транзакцією з протилежним знаком (externalId = <id>:fee, контрагент "Stripe"), що дозволяє зіставляти/проводити комісії як витрати окремо від виручки. Комісії, повернуті за поповненнями/скасуваннями, надходять як додатні суми.
  • Рядки виплат (payout) імпортуються як окремі від'ємні транзакції; зіставляйте їх із відповідною вхідною транзакцією у виписці вашого реального банківського рахунка.
  • Рядки з нульовою сумою пропускаються; дата береться з поля created_utc (UTC).
  • Рядки експорту платежів, які не переміщували кошти, пропускаються: Captured = false (авторизації/відкладені списання) та зі статусом Status Failed/Canceled.
  • Нещирована сума Amount Refunded стає третьою від'ємною транзакцією (externalId = <id>:refund) із датою в полі Refunded date (UTC), щоб часткові та повні повернення, вбудовані в рядки платежів, не були втрачені.

Звірка розрахунків з ПСП (звіти про виплати Stripe)

Для розбиття паушальної виплати (lump-sum payout) на її складові замовлення, повернення, комісії та чарджбеки використовуйте кінцеві точки розрахунків замість звичайного імпорту виписок. Підтримуються два види експорту зі Stripe (визначаються автоматично):

  • Reports → payouts → Payout reconciliation, itemized (типи звітів payout_reconciliation.itemized.* або payout_reconciliation.by_id.itemized.*) – точний, один рядок на балансову транзакцію; є кращим для живих акаунтів.
  • Payments → Export (unified payments) – експорт на рівні платежів; працює в тестовому режимі / режимі пісочниці, де звірка виплат недоступна. Успішні платежі групуються за ідентифікатором виплати у стовпчику Transfer; незавершені/невдалі рядки пропускаються (skippedNotSettled); ненульова сума Amount Refunded стає синтетичним рядком повернення у пакеті виплати цього платежу (це наближення, оскільки повернення фактично могло розрахуватися в пізнішій виплаті). Референси для зіставлення беруться з ідентифікатора платежу, PaymentIntent ID, номера рахунка-фактури Invoice Number, ідентифікатора клієнта Client Reference ID та кожного стовпця … (metadata) (наприклад, номер замовлення в метаданих).

Один CSV-файл може охоплювати багато виплат. Stripe завантажує деталізований звіт по одному файлу на розділ (…_charge_…, …_refund_…, …_fee_…). Імпортуйте їх усі: рядки для вже імпортованої виплати об'єднуються з наявним пакетом (відображається у лічильнику updated), якщо він ще не був проведений, а підсумки пакета перераховуються.

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

Поведінка під час імпорту:

  • Рядки групуються за полем automatic_payout_id у пакети розрахунків (settlement batches) – один пакет на виплату, із підсумками валової суми, комісії та чистішої суми (сума net всіх рядків дорівнює сумі, що надходить на ваш банк). Повторний імпорт виплати пропускається (лічильник skipped). Рядки, які ще не призначені жодній виплаті, та самі рядки payout пропускаються і підраховуються окремо.
  • Кожен рядок платежу/повернення/спірної ситуації автоматично зіставляється з рахунком-фактурою продажу, використовуючи у такому порядку: externalRef замовлення електронної комерції (будь-яке значення з order_id, payment_intent_id, source_id, charge_id або будь-якого стовпця *_metadata[...]), fullNumber рахунка-фактури, що з'являється у цих стовпцях, а також – для повернень і чарджбеків – charge_id раніше зіставленого платежу (з того самого файлу або попередніх імпортів).
  • Перевіряйте результати за допомогою bank/settlements/list / bank/settlements/get; виправляйте залишки за допомогою bank/settlements/match { lineId, invoiceId } (або invoiceId: null для скасування зіставлення).

Виклик POST /v1/bank/settlements/post { id, date?, commissionPercent? } проводить увесь пакет як одну збалансовану журнальну транзакцію та закриває зіставлені рахунки-фактури (вебхуки paidAmount/paymentStatus, sale_invoice.paid):

  • Дебетується рахунок головної книги банківського рахунка на чисту суму виплати; дебетуються комісії ПСП (settlements.fees, за замовчуванням 6800) на суму утриманих комісій та рядків комісій.
  • Кредитується дебіторська заборгованість за кожним зіставленим платежем; повернення та чарджбеки сторнують її. Застосування обмежене залишком за кожним рахунком-фактурою – будь-який надлишок потрапляє на транзитний рахунок (suspense account) із попередженням.
  • Незіставлені платежі: якщо встановлено параметр commissionPercent, вони розбиваються на дохід від комісії (settlements.commissionRevenue, за замовчуванням 5001) та зобов'язання перед продавцем (settlements.sellerPayable, за замовчуванням 4499) – сценарій маркетплейсу, де зібрані гроші здебільшого належать продавцям. Без цього параметра вони розміщуються на транзитному рахунку settlements.suspense (за замовчуванням 4440, отримані аванси).
  • Рядки platform_earning (комісії платформи Stripe Connect) проводяться на дохід від комісії; рядки transfer (виплати підключеним продавцям) зменшують зобов'язання перед продавцем.
  • Усі чотири рахунки можна перевизначити для кожного окремого підприємства за допомогою правил проведення (ledger/posting-rules).
  • Рядок, чий платіж, комісія або повернення вже були імпортовані на інший банківський рахунок із експорту платежів Stripe (bank/statements/import), не проводиться на комісії, дебіторську заборгованість чи транзитний рахунок. Натомість його чиста сума (net) кредитується на рахунок головної книги цього банківського рахунка, завдяки чому банківський рахунок Stripe закриває розрахунки виплата за виплатою. У полі summary.clearedAmount відображається загальна сума, переміщена таким чином; рядок, сума якого відрізняється від суми на тому рахунку, зазначається у полі warnings. Якщо нічого проводити, пакет проводиться з нульовим journalTransactionId.

Методи bank/settlements/list та /get повертають для кожного пакета такі поля: clearedNet, clearingDifference (рядки виплат мінус суми, які інший банківський рахунок утримує для них; дорівнює нулю, коли вони збігаються) і clearingOpenCount (рядки з різницею або непроведеним рухом). Метод /get повертає такі самі поля для кожного рядка: clearingBankAccountId, clearingBooked, clearingDifference та clearingUnposted. Рядки повернень одного платежу порівнюються разом, оскільки експорт платежів містить лише загальну повернену суму. Експорт платежів Stripe, імпортований після проведення відповідної виплати, пропускає рухи цієї виплати та зазначає її у полі warnings.

ПДВ на саму комісію виставляється окремим рахунком (виставте рахунок на комісію продавцю); розбиття лише розподіляє зібрані кошти.

Виплати в іншій валюті

Журнал завжди створюється в базовій валюті компанії, але виплата в іншій валюті проводиться автоматично без необхідності ручного введення:

  • Пакет конвертується за курсом на дату проведення (date, з резервним варіантом на дату виплати, а потім на сьогодні). Курс береться власний для компанії для цієї валюти (reference/exchange-rates/set), якщо він є принаймні таким же свіжим, як офіційний, інакше використовується останній офіційний курс на дату або до неї. Якщо курс на дату або раніше відсутній, виклик завершується помилкою 422 із зазначенням необхідності викликати reference/exchange-rates/sync.
  • Кожен рахунок конвертується за цим курсом пакета, за винятком дебіторської заборгованості, яка закривається за тим курсом fxRate, за яким був виставлений кожен рахунок. Різниця між цими двома курсами зараховується на рахунок курсових різниць bank.fxGain (за замовчуванням 5803) або bank.fxLoss (за замовчуванням 6803) як реалізована курсова різниця, завдяки чому журнал залишається збалансованим.
  • У відповіді summary повертається використаний курс fxRate та отримана курсова різниця exchangeDifference, а пакет зберігає курс, за яким він був проведений. Зіставлений рахунок-фактура, валюта якого відрізняється від валюти пакета, не закривається: його сума спрямовується на транзитний рахунок із попередженням.
  • Зберігається одне обмеження імпорту: єдина виплата, рядки якої містять кілька валют, відхиляється з кодом 422, як і повторний імпорт, валюта якого відрізняється від пакета, вже збереженого для цієї виплати.

Ручні / кастомні потоки

Будь-які інші дані можна надсилати у форматі звичайного JSON:

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

Вказуйте стабільний externalId для кожної транзакції, щоб забезпечити ідемпотентність повторних імпортів.