Nordlet

← Документация / Руководства

Импорт выписок банков и платежных систем

Выписки в формате camt.053, CSV-файлы Stripe, сверка расчетов с платежными провайдерами (PSP) и пользовательские фиды JSON.

Все импортируемые данные поступают в виде банковских транзакций на банковский счет (bank/accounts/create). Транзакции имеют поле externalId; повторный импорт того же файла безопасен, поскольку строки, у которых пара (bankAccountId, externalId) уже существует, пропускаются, а их количество фиксируется в счетчике skipped. Импортированные транзакции получают статус new и проводятся в Главную книгу (ledger) только после сопоставления (bank/transactions/match, а для подбора кандидатов используется bank/transactions/suggest-matches).

Веб-приложение отображает те же импорты в разделе Банк → Импорт файла (загрузка файла, выбор шаблона).

Ошибочное сопоставление можно отменить с помощью запроса bank/transactions/unmatch (пункт Отменить сопоставление в разделе Банк → Транзакции). Проведенные проводки никогда не редактируются и не удаляются: платеж, сопоставленный со счетом, или строка, проведенная шаблоном импорта на счет учета, получают сторнирующую бухгалтерскую проводку (реверс) со всеми записями на противоположных сторонах, датированную параметром date (по умолчанию: сегодня, но не раньше даты исходной проводки). Оплаченная сумма счета и статус оплаты уменьшаются на сумму этой банковской строки. Строка, связанная с расчетами платежного провайдера, только отвязывается, так как проводка по расчету принадлежит всему пакету. Строка возвращается в статус 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.
  • Поле Customer Email в Stripe может содержать параметр "createPartner": true. В этом случае при импорте для каждого адреса электронной почты из файла, для которого еще нет контрагента в системе, создается новый клиент (контрагент типа «физическое лицо», помеченный как клиент), используя Customer Description в качестве имени (или email, если описание пустое) и колонки Card Address … в качестве адреса, если они присутствуют в файле. Существующие контрагенты сопоставляются по email без учета регистра. В отклике возвращается количество созданных клиентов в поле 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; группы, которые не удалось обработать (отсутствует email клиента, смешанные валюты, связанный счет все еще находится в статусе черновика или уже полностью оплачен), перечисляются в поле 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 не применяются, так как формат 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 и др.) позволяют скачивать выписки по счетам в формате XML camt.053 через интернет-банкинг (обычно в разделе экспорта/скачивания выписок, формат "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 = id балансовой транзакции).
  • Ненулевая комиссия (fee) становится второй транзакцией с противоположным знаком (externalId = <id>:fee, контрагент "Stripe"), что позволяет сопоставлять и проводить комиссии как расходы отдельно от выручки. Комиссии, возвращенные при рефандах, поступают как положительные суммы.
  • Строки выплат (payout) импортируются как единые отрицательные транзакции; сопоставляйте их с соответствующими входящими транзакциями в выписке по вашему реальному банковскому счету.
  • Строки с нулевой суммой пропускаются; дата берется из поля created_utc (UTC).
  • Строки экспорта платежей, не повлекшие движения средств, пропускаются: Captured = false (авторизации / отложенные списания) и Status равный Failed/Canceled.
  • Ненулевая сумма возврата (Amount Refunded) становится третьей, отрицательной транзакцией (externalId = <id>:refund) с датой Refunded date (UTC), благодаря чему частичные и полные возвраты, включенные в строки платежей, не теряются.

Сверка расчетов с PSP (отчеты о выплатах Stripe)

Для детализации единовременной выплаты по исходным заказам, возвратам, комиссиям и чарджбекам используйте эндпоинты расчетов вместо обычного импорта выписок. Поддерживаются два формата экспорта Stripe (определяются автоматически):

  • Reports → Payouts → Payout reconciliation, itemized (типы отчетов payout_reconciliation.itemized.* или payout_reconciliation.by_id.itemized.*) — точный отчет, по одной строке на каждую балансовую транзакцию; рекомендуется для «живых» аккаунтов.
  • Payments → Export (unified payments) — экспорт на уровне платежей; работает в тестовом режиме / песочнице, где сверка выплат недоступна. Успешные списания группируются по id выплаты в колонке Transfer; незавершенные/неудачные строки пропускаются (skippedNotSettled); ненулевое значение Amount Refunded превращается в синтетическую строку возврата в пакете выплаты данного платежа (это приближение, поскольку фактический возврат мог войти в более позднюю выплату). Ссылки для сопоставления берутся из id платежа, 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 в пакеты расчетов — по одному пакету на выплату, с итоговыми значениями gross/fee/net (сумма колонок 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):

  • Дебетуется счет учета банка в Главной книге на сумму чистой выплаты (net); дебетуются комиссии PSP (settlements.fees, по умолчанию 6800) на сумму удержанных комиссий и строк сборов.
  • Кредитуется дебиторская задолженность по сопоставленным платежам; возвраты и чарджбеки сторнируют ее. Сумма применения ограничена остатком по каждому счету — любой излишек попадает на транзитный счет с предупреждением.
  • Несопоставленные платежи: при заданном параметре 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 для каждой транзакции, чтобы обеспечить идемпотентность повторных импортов.