api extrase + ordine de plata

Citesti extrase.
Generezi plati.

Incarci un extras MT940, MT942, CAMT.053 sau CSV de la patru banci si primesti tranzactii JSON normalizate, cu sold reconciliat. Sau trimiti un lot de plati si primesti inapoi fisierul .xlsx de import in Internet Banking.

Creeaza cont gratuit Vezi ce primesti

4 banci Revolut, BT, ING, Raiffeisen

0.01 RON toleranta reconciliere sold

10 / luna extrase gratuit, fara card

~/integrare

$ curl -X POST https://bank-statement-parser.test/api/v1/parse \
    -H "Authorization: Bearer $BSP_TOKEN" \
    -F file=@extras-martie.sta \
    -F bank=banca_transilvania \
    -F format=mt940

HTTP/2 200 OK
{
  "data": {
    "statements": [ /* ... */ ],
    "transactionCount": 34
  },
  "meta": {
    "request_id": "9b2c7e1a-...",
    "version": "1.0.0-beta"
  }
}

# sincron: tranzactiile reconciliate vin in acelasi raspuns

schema raspuns

Un singur obiect. Toate campurile de care ai nevoie.

Raspunsul pe `/parse` contine `statements`, fiecare cu tranzactiile sale normalizate. Cheile sunt camelCase, sumele sunt string pentru precizie exacta, iar fiecare tranzactie pastreaza payload-ul brut al bancii in `raw`, ca sa poti audita orice decizie de parsare.

Cum arata o tranzactie bancara normalizata — acelasi format indiferent de banca sau format sursa (MT940, MT942, CAMT.053, CSV).

bookingDate Data la care banca a inregistrat operatiunea
amount Signed decimal, string pentru precizie exacta
type credit / debit / fee / interest
counterpartyName / counterpartyIban Numele si IBAN-ul partii, cand sunt prezente in sursa
raw Obiect JSON cu tot ce a extras parser-ul din fisierul original

transaction.json

{
  "bookingDate": "2026-03-15",
  "valueDate": "2026-03-15",
  "amount": "1250.00",
  "currency": "RON",
  "type": "credit",
  "description": "Transfer primit - factura PDAF 16",
  "counterpartyName": "ACME SRL",
  "counterpartyIban": "RO49AAAA1B31007593840000",
  "reference": "PDAF-16",
  "category": null,
  "balanceAfter": "8420.00",
  "raw": {
    // payload original MT940, pastrat ca sa poti
    // audita orice decizie de parsare
    "61": ":61:2603150315C1250,00NTRF",
    "86": ":86:Transfer primit factura PDAF 16"
  }
}

cum functioneaza

Un apel. Sincron. Nimic magic.

Fara webhooks, fara polling. Trimiti fisierul si primesti tranzactiile reconciliate in acelasi raspuns HTTP.

Trimiti fisierul

POST multipart cu extrasul, codul bancii si formatul (mt940, mt942, camt053, csv).

POST /api/v1/parse

Parsam si reconciliem

Parser-ul potrivit din registry extrage tranzactiile si verifica sold initial + suma = sold final. Daca nu iese cu toleranta de 0.01, primesti parse_failed.

opening + Σ = closing

Primesti raspunsul

In acelasi request: statements normalizate cu transactionCount, gata de integrare. Fiecare request e auditat cu un request_id.

200 OK · data.statements

banci suportate

Onest despre ce suportam acum.

Am inceput cu Revolut Business si am adaugat MT940/MT942 pentru bancile traditionale romanesti. Patru banci sunt in productie, fiecare cu reconciliere de sold verificata pe fixture reale. Restul vin pe masura ce validam formatele cu utilizatori reali.

Banca	Format	Extensie	Status
Revolut Business	CAMT.053	.xml	in productie
Revolut Business	CSV	.csv	in productie
Banca Transilvania	MT940	.sta	in productie
ING	MT940	.sta	in productie
Raiffeisen Bank	MT940	.sta	in productie
Raiffeisen Bank	MT942 (intraday)	.sta	in productie
BCR, Unicredit	MT940 / CSV	.sta / .csv	in evaluare
Intesa, FirstBank, CEC	PDF	.pdf	v2 (OCR)

generare fisier op-uri

Nu doar citesti extrase. Generezi ordinele de plata.

Trimiti un lot de plati structurat ca JSON si primesti inapoi fisierul .xlsx, codat base64, gata de import in Internet Banking. Primul format livrat: Raiffeisen — import ordine de plata RON. Acelasi model ca parser-ele: contract + registry pe cheie `{banca}.{format}`.

Trimiti contul-sursa si lista de plati. Validam, generam fisierul si il returnam — fara sa stocam niciun IBAN sau nume de beneficiar.

debtor Contul-sursa: name + iban (IBAN platitor)
payments[] Per plata: payee_name, payee_iban, amount, reference
validare IBAN Fiecare IBAN e verificat inainte de scriere; numele beneficiarului e trunchiat la 40, descrierea la 70 — exact cum cere importul Raiffeisen
contentBase64 Fisierul .xlsx gata de import, plus paymentCount si totalAmount pentru reconciliere

payments/generate

$ curl -X POST .../api/v1/payments/generate \
    -H "Authorization: Bearer $BSP_TOKEN" \
    -H "Content-Type: application/json" \
    -d @lot-plati.json

# lot-plati.json
{
  "bank": "raiffeisen",
  "format": "raiffeisen_xlsx",
  "currency": "RON",
  "debtor": { "name": "PROJECTCITY SRL",
              "iban": "RO11RZBR0000060000000001" },
  "payments": [{
    "payee_name": "FURNIZOR SRL",
    "payee_iban": "RO81RZBR0000060000000099",
    "amount": "1234.56",
    "currency": "RON",
    "reference": "Factura 123456"
  }]
}

HTTP/2 200 OK
{ "data": {
    "filename": "raiffeisen_plati_202606031542.xlsx",
    "contentBase64": "UEsDBBQABgAIAA...",
    "paymentCount": 1,
    "totalAmount": "1234.56"
} }

de ce bsp

Trei motive pentru care nu iti scrii propriul parser.

Reconciliere de sold, nu doar parsare.

Fiecare statement este validat: opening + sum(signed amounts) = closing. Daca ecuatia nu iese cu toleranta de 0.01, statement-ul e marcat failed si tranzactiile NU sunt inserate.

Dupa luni de greseli tacute pe parser-e ad-hoc, asta e singurul semnal care conteaza.

Multi-tenant din prima linie de cod.

Fiecare parse request si fiecare lot de plati e legat de un account_id, cu permisiuni separate (parse-requests:create, payment-files:create). Un cont nu poate vedea niciodata datele altui cont.

Nu-ti trebuie workaround-uri cand scalezi de la un client la zece.

Zero retentie implicita.

Parsarea ruleaza pe un fisier temporar care e sters imediat. La generarea de plati, fisierul .xlsx e returnat in raspuns si nu e stocat — auditul pastreaza doar payment_count si total_amount, niciodata IBAN-uri sau nume de beneficiari.

Nimic nu paraseste workspace-ul tau in afara raspunsurilor API pe care le ceri explicit.

pricing

Gratis pentru integrare si validare. Dupa aceea, vorbim.

free plan

0^{RON / luna}

10 extrase incarcate / luna
Generare fisiere de plata (op-uri)
Acces complet la API v1
Toate formatele suportate
Panou Filament inclus
Suport pe email

Creeaza cont gratuit

Nu cerem card pentru free plan. Zece extrase pe luna sunt suficiente pentru integrare si o luna de testare reala, atat timp cat nu procesezi un portofoliu intreg de clienti deodata.

Pentru volume mai mari, planurile Starter (100 / luna), Pro (500 / luna) sau Enterprise (nelimitat) sunt disponibile manual — onboarded individual, fara Stripe deocamdata. Scrie-ne si punem la punct un plan.

Toate planurile primesc aceleasi parser-e, aceleasi SLA de reconciliere, aceleasi raspunsuri JSON. Singura diferenta e numarul de upload-uri lunare.