---
title: "Dokumenty"
description: "Przesyłanie, parsowanie i zarządzanie dokumentami przychodzącymi — faktury od dostawców, paragony, inne dowody księgowe. AI wyodrębnia dane, człowiek weryfikuje, a Numify zamienia to w transakcję do zaksięgowania."
url: https://numifyai.com/docs/korzystanie-z-numify/dokumenty
review_status: internal
updated: 2026-04-16
---


> **Nie mylić z [Faktury](/docs/korzystanie-z-numify/faktury).** Ta strona
> opisuje **dokumenty przychodzące** — faktury od dostawców, paragony,
> które AI parsuje i zamienia w transakcje. Jeśli chcesz **wystawić**
> fakturę sprzedażową, zobacz [Faktury](/docs/korzystanie-z-numify/faktury).

**Dokumenty** to punkt wejścia do księgowości — miejsce, gdzie spółka
przesyła dowody księgowe (faktury zakupu, paragony, inne), a Numify
automatycznie wyodrębnia z nich dane do dalszej obróbki.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /documents — upload zone + tabela z kolumnami Nazwa/Status/Kwota/Data/Typ */}

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

<LegalRef act="UoR" art="20" paragraph="1" /> wymaga, aby **każde zdarzenie**
gospodarcze zostało wprowadzone do ksiąg w postaci zapisu. Podstawą tego
zapisu musi być **dowód księgowy** (art. 20 ust. 2) — w praktyce dla sp. z o.o.
najczęściej faktura zakupu otrzymana od kontrahenta.

Numify:

1. **Przechowuje oryginał** dokumentu (PDF, obraz) w Cloudflare R2 — elektronicznie, zgodnie z <LegalRef act="UoR" art="73" paragraph="2" />.
2. **Parsuje dane** modelem AI i podsuwa je do weryfikacji.
3. **Tworzy <FeatureRef slug="transakcje">transakcję</FeatureRef>** po zatwierdzeniu — to z niej zostanie utworzony zapis w dzienniku (<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik">UoR art. 14</FeatureRef>).

## Co można przesłać [#co-można-przesłać]

| Format    | Obsługa                            | Uwagi               |
| --------- | ---------------------------------- | ------------------- |
| PDF       | Pełna — tekstowa + skany z OCR     | Preferowany format  |
| PNG / JPG | Pełna — OCR w ramach modelu        | Jakość ma znaczenie |
| HEIC      | Automatycznie konwertowane do JPEG | iPhone scans        |
| XML FA(3) | Tak — bezpośredni parsing (bez AI) | Faktury z KSeF      |

**Limit wielkości:** domyślnie 10 MB na plik. Wiele plików można wgrać
jednocześnie (drag-and-drop) — każdy jest przetwarzany asynchronicznie
w tle (BullMQ).

## Pipeline parsowania [#pipeline-parsowania]

```
Upload → R2 (oryginał) → ekstrakcja tekstu (PDF/OCR)
       → model Gemini 2.5 Flash → schema Zod → draft transakcji
       → (ludzki przegląd) → zaakceptowanie → dziennik
```

<ServiceRef path="src/lib/services/document-parser.ts">
  document-parser.ts
</ServiceRef>

### Co AI wyciąga z dokumentu [#co-ai-wyciąga-z-dokumentu]

Schemat (`invoiceSchema`) obejmuje m.in.:

* typ dokumentu (`invoice` / `receipt` / `credit_note` / `other`),
* numer dokumentu, data wystawienia, termin płatności,
* sprzedawcę (nazwa, NIP, adres, kraj),
* nabywcę (nazwa, NIP, adres),
* pozycje (opis, ilość, cena jednostkowa, netto, stawka VAT, brutto),
* sumy (netto, VAT, brutto, waluta),
* kategorię kosztu (dopasowaną do <LegalRef act="UoR" art="21" paragraph="1" /> pkt 6 — „dekretacja").

Przed zaakceptowaniem jako transakcja **zawsze** trafia to do weryfikacji
ludzkiej — AI może się mylić, zwłaszcza przy paragonach o niskiej jakości.

## Statusy dokumentu [#statusy-dokumentu]

| Status       | Znaczenie                                                            |
| ------------ | -------------------------------------------------------------------- |
| `pending`    | Wrzucony, w kolejce BullMQ.                                          |
| `processing` | AI parsuje w tej chwili (UI odpytuje co 5 s).                        |
| `completed`  | Sparsowany; czeka na akceptację lub edytę.                           |
| `failed`     | Parsing zawiódł (np. dokument nieczytelny) — możliwa obsługa ręczna. |

Po zaakceptowaniu transakcji dokument zostaje **na stałe** powiązany z tą
transakcją (i z wpisem w dzienniku) — to materializuje wymóg
<LegalRef act="UoR" art="21" paragraph="1" /> pkt 1–2 (rodzaj i numer dowodu, strony).

## Wymogi art. 21 — 6 elementów dowodu [#wymogi-art-21--6-elementów-dowodu]

Zgodnie z <LegalRef act="UoR" art="21" paragraph="1" /> dowód księgowy **powinien
zawierać co najmniej** sześć elementów:

| # | Element                                    | Skąd w Numify                                                                                                   |
| - | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------- |
| 1 | Rodzaj i numer dowodu                      | Z faktury (`invoiceNumber`) + klasyfikacja Numify (`invoice` / `receipt` …).                                    |
| 2 | Strony operacji (nazwy, adresy)            | Z faktury (`seller`, `buyer`).                                                                                  |
| 3 | Opis operacji + wartość                    | Pozycje + sumy (linie dokumentu).                                                                               |
| 4 | Data operacji                              | `invoiceDate` (+ `saleDate` jeśli różne).                                                                       |
| 5 | Podpis wystawcy                            | Typowo brak na e-fakturach — zastępuje go cyfrowa autentyczność wystawienia. W KSeF — numer KSeF pełni tę rolę. |
| 6 | Dekretacja (konta, miesiąc, sposób ujęcia) | Nadawana przy akceptacji transakcji (propozycja AI + korekta użytkownika).                                      |

## Bezpieczne przechowywanie [#bezpieczne-przechowywanie]

Zgodnie z <LegalRef act="UoR" art="73" paragraph="2" /> dowody elektroniczne są
akceptowalne, jeśli zapewniona jest **niezmienność przez wymagany okres
przechowywania** (5 lat dla większości dowodów — szczegóły →
<FeatureRef slug="/docs/zgodnosc-z-prawem/przechowywanie-dokumentow">przechowywanie dokumentów</FeatureRef>).

Numify realizuje to tak:

* Oryginał w R2 jest **write-once** (kluczowany hashem zawartości — nadpisanie nie jest możliwe bez świadomej akcji).
* Powiązanie dokument ↔ transakcja ↔ zapis księgowy jest twarde (klucze obce) — nie da się „osierocić" zapisu.
* Usunięcie dokumentu jest zablokowane, gdy istnieje powiązana transakcja (ślad rewizyjny → <LegalRef act="UoR" art="25" />).

## Ograniczenia [#ograniczenia]

1. **AI czasem się myli** na paragonach niskiej jakości (wyblakły druk, odręczne notatki). Wymaga ręcznej poprawki.
2. **Dokumenty wielopozycyjne** o nietypowym układzie (skany książek przychodów z XIX w., faktury rękopisy) mogą wymagać pełnej edycji ręcznej.
3. **Brak rozpoznawania języków innych niż PL / EN** — faktury w DE / FR / IT są obsługiwane, ale jakość klasyfikacji jest gorsza.
4. **Dokumenty obraz + tekst w jednym PDF** — model zazwyczaj radzi sobie z obydwoma, ale przy bardzo dużych plikach (200+ stron) zalecane jest dzielenie.
5. **Brak zbiorczego uploadu faktur z KSeF** w pełnej automatyzacji — odbiór z KSeF działa, ale wymaga skonfigurowanej sesji (→ <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/odbieranie">KSeF — odbieranie</FeatureRef>).

## Rekomendowany workflow [#rekomendowany-workflow]

1. **Prześlij PDF / obraz** — przeciągnij do strefy lub kliknij Upload.
2. **Poczekaj kilka sekund** — status zmienia się z `pending` → `processing` → `completed`.
3. **Otwórz dokument**, sprawdź wyciągnięte dane (kontrahent, kwoty, stawki VAT).
4. **Popraw błędy**, jeśli występują — jeden klik → edycja pola.
5. **Utwórz transakcję** — dokument zostaje trwale powiązany.
6. **Nie usuwaj dokumentu** po zaksięgowaniu — zamiast tego użyj korekty w <FeatureRef slug="transakcje">transakcjach</FeatureRef>.

{/* SCREENSHOT: pojedynczy dokument — panel boczny z danymi wyodrębnionymi przez AI */}

## Powiązane [#powiązane]

* <FeatureRef slug="transakcje">transakcje</FeatureRef> — powstają z zaakceptowanych dokumentów.
* <FeatureRef slug="faktury">faktury</FeatureRef> — faktury wystawiane (nie mylić z przychodzącymi).
* <FeatureRef slug="kontrahenci">kontrahenci</FeatureRef> — parser tworzy kontrahentów z NIP-u wystawcy.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik">UoR — dziennik</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/przechowywanie-dokumentow">Przechowywanie dokumentów</FeatureRef>.