---
title: "Konta bankowe"
description: "Rejestr rachunków bankowych spółki, import wyciągów CSV (mBank, ING, PKO, Santander, Nest Bank + generyczny), dopasowywanie wpłat do faktur (auto-match + ręczne) oraz automatyczne księgowanie płatności z wyceną różnic kursowych."
url: https://numifyai.com/docs/korzystanie-z-numify/konta-bankowe
review_status: numify-source
updated: 2026-04-16
---


**Konta bankowe** to rejestr rachunków spółki z o.o., punkt importu wyciągów
bankowych oraz miejsce, gdzie wiersze wyciągu zostają **dopasowane** do
konkretnych faktur i — w efekcie — **zaksięgowane w dzienniku** jako zapłata.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /bank-accounts — kafelki rachunków, poniżej tabela wierszy wyciągu z badge'ami Matched/Unmatched */}

## Po co to w Numify [#po-co-to-w-numify]

Każda operacja na rachunku bankowym spółki to **operacja gospodarcza** w
rozumieniu <LegalRef act="UoR" art="14" paragraph="1" /> — musi zostać
chronologicznie ujęta w dzienniku. W praktyce oznacza to trzy kroki:

1. **Import** wyciągu (CSV z banku),
2. **Dopasowanie** wiersza wyciągu do faktury (automatyczne lub ręczne),
3. **Zaksięgowanie** zapłaty w dzienniku — z automatycznym rozliczeniem rozrachunku (<AccountRef code="201" /> / <AccountRef code="202" />) i ewentualnymi różnicami kursowymi (<AccountRef code="750" /> / <AccountRef code="751" />).

Numify realizuje krok 2 i 3 automatycznie, pod warunkiem że rachunek
bankowy jest zmapowany na odpowiednie &#x2A;*konto księgowe (GL)**.

## Model danych [#model-danych]

Rachunek bankowy ma pola:

| Pole                            | Przeznaczenie                                                                                                               |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Nazwa                           | Etykieta („Konto firmowe mBank").                                                                                           |
| IBAN                            | Numer rachunku (wymagany, unikalny w obrębie spółki).                                                                       |
| Bank                            | Dowolny opis, pomocny przy wielu rachunkach.                                                                                |
| Waluta                          | PLN / EUR / USD (musi zgadzać się z walutą CSV przy imporcie).                                                              |
| Konto księgi (`chartAccountId`) | Najczęściej <AccountRef code="130" /> (PLN) lub <AccountRef code="135" /> (waluta obca) — to na tym koncie powstają zapisy. |
| Stan początkowy                 | Kwota otwarcia (używana przy rozliczaniu rocznym).                                                                          |
| Rachunek podstawowy             | Flaga `isPrimary` — domyślny rachunek do sugestii.                                                                          |

Numify automatycznie proponuje GL: **PLN → 130, waluta obca → 135**, ale
użytkownik może wybrać subkonto (np. `135-EUR`, `135-USD`).

## Obsługiwane formaty CSV [#obsługiwane-formaty-csv]

Parser obsługuje sześć profilów: `generic` (auto-detekcja separatora),
`mbank`, `ing`, `pko`, `santander`, `nestbank`. Wszystkie kwoty są
normalizowane do **minor units** (grosze dla PLN, centy dla EUR/USD) —
bezpośrednio zgodne z repozytorium i plikami JPK.

<ServiceRef path="src/lib/services/bank-csv-parser.ts" tests="27">
  bank-csv-parser.ts
</ServiceRef>

### Co parser rozumie poza kwotą i datą [#co-parser-rozumie-poza-kwotą-i-datą]

* Format PL („1 234,56") i mieszany („1.234,56") — z groszami.
* Daty DD.MM.YYYY, DD-MM-YYYY, DD/MM/YYYY, YYYY-MM-DD.
* Waluta z kolumny CSV (tylko ISO-4217 — np. `EUR`, `USD`; wartości typu „EURO", „pln " są odrzucane, żeby zabezpieczyć walidację waluty rachunku).
* Nazwa kontrahenta, IBAN kontrahenta, referencja / tytuł przelewu.

### Zabezpieczenia importu [#zabezpieczenia-importu]

* **Walidacja waluty** — jeśli CSV deklaruje walutę inną niż waluta rachunku bankowego, import odrzuca plik z komunikatem (brak miksu EUR na rachunek PLN).
* **Deduplikacja** — wiersze powielone (ta sama kombinacja data + kwota + opis) są rozpoznawane jako duplikaty i pomijane (komunikat: `skipped N duplicates`).
* **Auto-match po imporcie** — wiersze pasujące 1:1 do istniejących faktur są automatycznie oznaczane jako dopasowane.

## Dopasowywanie (matching) [#dopasowywanie-matching]

### Auto-match [#auto-match]

Numify dopasowuje wiersz wyciągu do faktury na podstawie:

* kwoty (z pełną tolerancją groszową dla walut),
* numeru faktury w opisie / referencji,
* NIP-u / nazwy kontrahenta,
* dat (wpłata w rozsądnym oknie od terminu płatności).

W praktyce na standardowych wyciągach trafia to **większość** pozycji. Reszta
trafia do kolejki **niedopasowanych** — do obsługi ręcznej.

### Ręczne [#ręczne]

Użytkownik może ręcznie dopasować wiersz do faktury z listy otwartych
rozrachunków lub **cofnąć** (unmatch) wcześniejsze dopasowanie.

## Automatyczne księgowanie płatności [#automatyczne-księgowanie-płatności]

Przy każdym dopasowaniu (automatycznym lub ręcznym) Numify tworzy zapis w
dzienniku o standardowej strukturze:

| Operacja                              | Przychód (income)                                                 | Koszt (expense)                                                    |
| ------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------ |
| Wpływ na rachunek bankowy             | <AccountRef code="130" /> / <AccountRef code="135" /> — **Debet** | <AccountRef code="201" /> — **Debet**                              |
| Wyksięgowanie należności/zobowiązania | <AccountRef code="201" /> — **Kredyt**                            | <AccountRef code="135" /> / <AccountRef code="130" /> — **Kredyt** |

Dla rozrachunków z dostawcami używamy <AccountRef code="202" /> zamiast
<AccountRef code="201" />.

<ServiceRef path="src/lib/services/payment-journal.ts" tests="30">
  payment-journal.ts
</ServiceRef>

### Różnice kursowe [#różnice-kursowe]

Gdy faktura jest w walucie obcej, **kurs NBP w dniu zaksięgowania faktury**
i **kurs w dniu otrzymania zapłaty** różnią się. <LegalRef act="UoR" art="30" paragraph="4" />
wymaga ujęcia różnicy w wyniku okresu:

* **Zysk kursowy** → konto <AccountRef code="750" name="Przychody finansowe" /> (tu trafia dodatnia różnica kursowa).
* **Strata kursowa** → konto <AccountRef code="751" name="Koszty finansowe" />.

Dokładny zapis prawny — <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut">UoR — kursy walut</FeatureRef>.

Numify liczy różnicę jako:

```
|bankLinePaidPln - (proporcja faktury zaksięgowanej w PLN)|
```

...i dobiera konto 750 lub 751 w zależności od znaku. Płatności częściowe
są obsługiwane proporcjonalnie, z korektą finałową na ostatniej racie —
tak, żeby po zamknięciu całej faktury rozrachunek (<AccountRef code="201" /> / <AccountRef code="202" />)
wynosił **dokładnie zero** (bez ±1 gr resztek zaokrągleń).

### Płatności częściowe [#płatności-częściowe]

Jeśli wpłata \< kwota faktury, Numify:

1. Tworzy zapis księgowy tylko na proporcję faktury.
2. Oznacza fakturę jako **częściowo zapłaconą**.
3. Resztę rozlicza przy kolejnych wpłatach.

Suma wszystkich rat musi zamknąć fakturę co do grosza.

## Cofanie dopasowania (unmatch) [#cofanie-dopasowania-unmatch]

<LegalRef act="UoR" art="25" paragraph="1" /> zakazuje usuwania zapisów w księgach.
Gdy użytkownik cofa dopasowanie:

1. Numify tworzy **storno** — zapis odwrotny w dzienniku (debety ↔ kredyty, kwoty bez minusów, ale odwrócone strony).
2. Wiersz wyciągu wraca do puli niedopasowanych.
3. Oryginalny zapis pozostaje w dzienniku — audytor widzi pełną historię.

**Nie ma przycisku „Usuń zapis"** — to konsekwencja <LegalRef act="UoR" art="25" />.

## Ograniczenia [#ograniczenia]

1. **Brak bezpośredniego podpięcia do banku** (Open Banking / PSD2) — zawsze importujemy z CSV. Roadmapa przewiduje PSD2 w drugiej połowie 2026 r.
2. **Auto-match bywa zachowawczy** — przy niejednoznacznych opisach wiersz zostaje oznaczony jako niedopasowany, zamiast zgadywać. Lepsze to niż błędne dopasowanie i błędne księgowanie.
3. **Korekty faktur nie są jeszcze wspierane w auto-match** — zobacz [issue #5](https://github.com/kacperkwapisz/numify/issues/5).
4. **Waluta wiersza musi zgadzać się z walutą rachunku.** Mieszane waluty na jednym rachunku nie są wspierane — prowadzić je jako osobne rachunki księgowe (typowa praktyka dla 135).

## Rekomendowany workflow [#rekomendowany-workflow]

1. **Dodaj rachunek** — domyślny GL 130 (PLN) lub 135 (waluta obca).
2. **Importuj wyciąg CSV** z panelu banku (wybierz profil banku z listy).
3. **Pozwól Numify zrobić auto-match** — najczęściej większość wierszy zostanie dopasowana.
4. **Obsłuż niedopasowane wiersze** — ręcznie dopasuj lub utwórz brakującą transakcję.
5. **Cofnij dopasowanie** (jeśli trzeba) — Numify zrobi storno; nie dotykaj dziennika ręcznie.

{/* SCREENSHOT: dialog „Import Bank Statement" z listą banków + polem pliku */}

## Powiązane [#powiązane]

* <FeatureRef slug="transakcje">transakcje</FeatureRef> — każda dopasowana wpłata wskazuje transakcję, do której należy.
* <FeatureRef slug="faktury">faktury</FeatureRef> — status „Opłacona" wynika z dopasowania wiersza bankowego.
* <FeatureRef slug="kontrahenci">kontrahenci</FeatureRef> — rachunek kontrahenta ułatwia matching po IBAN.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik">UoR — dziennik</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut">UoR — kursy walut</FeatureRef>.