Nordlet

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

Банкови и платежни импорти

Извлечения camt.053, Stripe CSV, реконсиляция на разплащания от PSP и потребителски JSON потоци.

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

Уеб приложението предоставя същите импорти в секцията Банка → Импортиране на файл (качване на файл, избор на шаблон).

Неправилното съпоставяне се отменя с bank/transactions/unmatch (Отмяна на съпоставянето в Банка → Транзакции). Осчетоводените записи никога не се редактират или изтриват: плащане, съпоставено с фактура, или ред, който шаблонът за импорт е осчетоводил по сметка, получава сторнираща счетоводна операция с всяка позиция в обратната страна, с дата date (по подразбиране: днес, и никога преди оригиналното осчетоводяване). Платената сума и статусът на плащане на фактурата се връщат назад със сумата на този банков ред. Ред, обвързан с разплащане от доставчик на платежни услуги (PSP), се само развързва, тъй като осчетоводяването на разплащането принадлежи към партидата. Редът се връща в статус 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 може да бъде пропуснато; в този случай се взема стандартният списък с полета за съответния тип: имената на колоните във файла Payments → Export на Stripe (без 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 за име (имейла, когато то е празно) и колоните 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:
    • Създаване на липсващи контрагенти: createPartner в реда с името на длъжника (TxDtls/RltdPties/Dbtr/Nm, канал debtor.name) създава клиент за всеки непознат платец на входящи парични средства; в реда с името на кредитора (TxDtls/RltdPties/Cdtr/Nm, канал creditor.name) – доставчик за всеки непознат получател на изходящи парични средства. Контрагентите се разпознават по IBAN (записан в partner_bank_accounts), след това по точно име; новият контрагент е юридическо лице, когато името съдържа правно организационна форма (УАБ, МБ, СИЯ, GmbH, Ltd, …), а в противен случай – физическо лице. Броят се връща като customersCreated (импорт на файл) или partnersCreated (синхронизация на канал).
    • Свързване на фактури по референция: invoiceMetaField, зададено за ред с основание за плащане или референция (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; канал remittance_information, reference_number), съпоставя всеки нов банков ред, чиято референция, основание или описание съдържа номера на отворена издадена фактура за продажба (входящи пари) или регистрирана фактура за покупка (изходящи пари), и осчетоводява плащането. Когато IBAN на платеца е запазен към контрагент, или името на платеца е равно на името или кода на контрагент, фактурата трябва да принадлежи на този контрагент. Плащане от непознат платец се свързва само когато то е равно на остатъчното салдо по фактурата и номерът на фактурата съдържа нейния префикс на серия, така че гол номер като сума никога да не се приема за референция. Плащане, по-голямо от остатъчното салдо, никога не се свързва. Лентите, които не издържат тези проверки, остават нови за ръчно съпоставяне и са изброени в предупрежденията (warnings). При зададено advanceInvoices: true несъпоставено входящо плащане от познат контрагент създава издадена авансова фактура (тип advance) за сумата при invoiceVatRatePercent или ставката invoiceItemId и съпоставя плащането с нея; контрагентът трябва да е познат, затова маркирайте и реда на длъжника.
    • Правила за осчетоводяване по код на транзакция: освен Ntry/Amt / transaction_amount.amount, списъкът с полета съдържа редове с правила Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (канал: bank_transaction_code=…, credit_debit_indicator=…). Редът се осчетоводява по сметката на първото правило, което съвпада: семейството на кодовете на банковите транзакции, след това посоката му, и накрая обикновеният ред за сума. Редовете с правила не се проверяват срещу файла.
    • Контрагент за банкови такси: 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 с currency, различен от този на сметката.

Всяко движение, произведено от поле, което има 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 по ISO 20022 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 се държи като банкова сметка: плащанията постъпват, таксите се приспадат, а изплащанията прехвърлят баланса към вашата истинска банкова сметка.

Поведение при импорт:

  • Всяка балансова транзакция се превръща в една банкова транзакция за брутната сума (externalId = идентификатор на балансовата транзакция).
  • Ненулевата такса се превръща във втора транзакция с обратен знак (externalId = <id>:fee, контрагент "Stripe") – така таксите могат да бъдат съпоставени/осчетоводени като разходи отделно от приходите. Таксите, възставени при отменени плащания, постъпват като положителни суми.
  • Редовете за изплащане (Payout) се импортират като единични отрицателни транзакции; съпоставете ги със съответната входяща
  • транзакция по извлечението на вашата реална банкова сметка.
  • Редовете с нулеви суми се пропускат; датата се взема от created_utc (UTC).
  • Редовете от експорта на плащания, които не са преместили парични средства, се пропускат: Captured = false (оторизации/забавени улавяния) и Status с грешка/отменени (Failed/Canceled).
  • Ненулевата сума за Amount Refunded се превръща в трета, отрицателна транзакция (externalId = <id>:refund) с дата Refunded date (UTC) – така частичните и пълните възстановявания на суми, вградени в редовете на плащанията, не се губят.

Реконсиляция на разплащания от PSP (отчети за изплащания от Stripe)

За разпределение на групово плащане (lump-sum) към неговите същински поръчки, възстановявания, такси и откази от плащане (chargebacks), използвайте крайните точки за реконсиляция на разплащания вместо обикновения импорт на извлечения. Приемат се два вида експорт от Stripe (откриват се автоматично):

  • Reports → Payouts → Payout reconciliation, itemized (типове отчети payout_reconciliation.itemized.* или payout_reconciliation.by_id.itemized.*) – точен, по един ред за всяка балансова транзакция; предпочита се при активни сметки.
  • Payments → Export (унифицирани плащания) – експортът на ниво транзакция; работи в тестов режим / режим sandbox, където реконсиляцията на изплащанията не е достъпна. Уловените плащания се групират по идентификатор на изплащане в колоната 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 в партиди за изплащане – по една партида за всяко изплащане, с брутни/таксови/нетни общи суми (сумата от 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):

  • Дебитирайте сметката от главната книга на банковата сметка за нетното изплащане; дебитирайте таксите на PSP (settlements.fees, по подразбиране 6800) за задържаните такси и редовете с такси.
  • Кредитирайте вземанията от клиенти за всяка съпоставена транзакция; възстановяванията на суми и отказите от плащане ги сторнират. Прилагането е ограничено до остатъчната сума на всяка фактура – всяко превишение попада в сметката за изчакващи плащания (suspense) с предупреждение.
  • Несъпоставени транзакции: при зададено commissionPercent те се разделят на приходи от комисионни (settlements.commissionRevenue, по подразбиране 5001) и задължение към продавач (settlements.sellerPayable, по подразбиране 4499) – моделът на електронна търговия (marketplace), където събраните пари до голяма степен принадлежат на продавачите. Без това те се разполагат в сметката 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 за всяка транзакция, за да поддържате повторните импорти идеопотентни.