Biblioteka plików przykładowych
Gotowe pliki SEPA, camt.053, UBL, MT940 i Factur-X — prawidłowe na start, celowo zepsute do testów. Każdy plik jest sprawdzany przez właściwy dla niego walidator.
Pliki przykładowe SEPA i e-fakturowania
Gotowe pliki SEPA, camt.053, UBL, MT940 i Factur-X — prawidłowe na start, celowo zepsute do testów. Każdy plik jest sprawdzany przez właściwy dla niego walidator.
129
Pliki przykładowe
92
Prawidłowy
37
Nieprawidłowy
Przelew SEPA (pain.001) (12)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| pain.001.001.03 — valid credit transferPrawidłowy przelew SEPA w pain.001.001.03: trzy przelewy na łączną kwotę 1 580,00 EUR, zgodne sumy kontrolne, numery IBAN przechodzące test mod-97 i nazwy w podstawowym zestawie znaków SEPA. | Prawidłowy | |
| pain.001.001.09 — valid, hybrid addressPrawidłowy przelew pain.001.001.09 z BICFI i hybrydowym adresem pocztowym dopuszczonym przez EPC153-22 v2.1: TwnNm oraz Ctry, plus najwyżej dwa AdrLine po maksymalnie 70 znaków. | Prawidłowy | |
| pain.001.001.03 — CtrlSum mismatchPlik pain.001 z błędną sumą kontrolną: CtrlSum deklaruje 1 000,00 EUR, podczas gdy transakcje sumują się do 1 500,00 EUR. Rozbieżność jest zgłaszana dwukrotnie — dla partii płatności i dla nagłówka pliku. | Nieprawidłowy | |
| pain.001.001.03 — invalid IBANPlik pain.001 z numerem IBAN wierzyciela, którego dwie cyfry kontrolne nie przechodzą testu mod-97 (ISO 7064). Reszta pliku jest poprawna, więc walidator zgłasza dokładnie jeden błąd. | Nieprawidłowy | |
| pain.001.001.03 — NbOfTxs mismatchPlik pain.001, który źle się liczy: NbOfTxs deklaruje jedną transakcję, a plik zawiera dwie. Podobnie jak CtrlSum, liczba jest sprawdzana zarówno w partii płatności, jak i w nagłówku pliku. | Nieprawidłowy | |
| pain.001.001.03 — unstructured address after 2026-11-15Wzorcowy przypadek reguły EPC o adresie strukturalnym: adresy zawierają wyłącznie AdrLine, bez TwnNm. Błędem blokującym czyni go data wykonania zapisana w pliku (ReqdExctnDt = 2026-11-20, po progu 15.11.2026) — przy wcześniejszej dacie ten sam plik daje jedynie ostrzeżenie. | Nieprawidłowy | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15Wzorcowy plik „gotowy na 2026”: przelew pain.001.001.11, którego data wykonania (ReqdExctnDt = 2026-11-20) przypada po progu EPC dla adresu strukturalnego (15.11.2026). Każdy adres płatnika i odbiorcy jest w pełni strukturalny — StrtNm, BldgNb, PstCd, TwnNm, Ctry i ani jednego AdrLine. Trzy przelewy, 4 320,00 EUR, zero błędów i zero ostrzeżeń. | Prawidłowy | |
| pain.001.001.09 — valid, two payment batches with different execution datesJeden plik pain.001, dwa bloki PmtInf: partia A wykonywana 10.03.2026 z adresami hybrydowymi (TwnNm + Ctry + jedno AdrLine), partia B 20.11.2026 z adresami w pełni strukturalnymi. Pokazuje obie lekcje pliku wielopartyjnego: regułę adresową EPC ocenia się osobno dla każdej partii, na podstawie daty, którą ta partia niesie, a każdy PmtInf ma własne NbOfTxs / CtrlSum obok sum z GrpHdr (4 przelewy, 3 350,00 EUR). | Prawidłowy | |
| pain.001.001.03 — nine-character BICPlik pain.001, w którym BIC banku odbiorcy ma dziewięć znaków. Norma ISO 9362 dopuszcza 8 (instytucja + kraj + lokalizacja) albo 11 (plus trzyznakowy kod oddziału) — nigdy 9 ani 10. „BNPAFRPPX” to typowy obraz obciętego lub ręcznie uzupełnionego kodu oddziału i jedyna wada tego pliku, którą wychwytują obie warstwy: oficjalny XSD odrzuca go przez wzorzec BIC, a warstwa reguł przez długość. | Nieprawidłowy | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setPlik pain.001, w którym odbiorca nazywa się „Café Renard & Fils SARL” — litera z akcentem i ampersand, oba poza podstawowym łacińskim zestawem znaków zatwierdzonym przez EPC (a-z A-Z 0-9 oraz / - ? : ( ) . , ' + spacja). XML jest poprawnie zbudowany, a oficjalny XSD przyjmuje go bez zastrzeżeń: Max70Text akceptuje dowolny ciąg. Ta wada żyje wyłącznie w warstwie reguł — dlatego właśnie takie pliki docierają do banku, który je odrzuca albo po cichu transliteruje. | Nieprawidłowy | |
| pain.001.001.03 — 250 transfers, high-volume payroll runRealistyczna lista płac: 250 przelewów SEPA w jednym PmtInf, rozłożonych na pięć krajów (DE, NL, BE, ES, FR), łącznie 442 028,75 EUR. Każdy IBAN ma poprawne cyfry kontrolne mod-97 (ISO 7064), a obie sumy kontrolne odpowiadają dokładnej kwocie, co do grosza. Przydaje się, by zobaczyć, jak zachowa się własny parser, portal bankowy lub własne narzędzia na pliku, który nie jest ani zabawką, ani patologią — i by sprawdzić, że jeden błędny cent w partii tej wielkości nadal wychwyci sam CtrlSum. | Prawidłowy | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)Bliźniak blokującej próbki z adresem niestrukturalnym, różniący się jedną rzeczą: datą wykonania. Te same adresy złożone wyłącznie z AdrLine, ale ReqdExctnDt to 30.09.2026 — przed progiem EPC153-22 v2.1, więc ta sama wada wraca jako dwa ostrzeżenia zamiast dwóch błędów: dziś płatność nadal przechodzi. Plik pokazuje też, co naprawdę znaczy „strukturalny”: adres dłużnika nie ma ani TwnNm, ani Ctry, adres wierzyciela ma Ctry i wciąż nie ma TwnNm. Samo Ctry nie wystarczy — TwnNm jest tu rozstrzygający. | Prawidłowy |
Polecenie zapłaty SEPA (pain.008) (8)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitPrawidłowe polecenie zapłaty SEPA w schemacie CORE: dwa cykliczne pobrania na łączną kwotę 175,00 EUR, identyfikator wierzyciela (ICS) przechodzący kontrolę ISO 7064 MOD 97-10 oraz podpisany mandat przy każdym dłużniku. | Prawidłowy | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15Tak wygląda zgodne polecenie zapłaty SEPA po progu 15.11.2026: data pobrania to 20.11.2026, więc każdy adres wierzyciela i dłużnika jest strukturalny (TwnNm + Ctry). Schemat CORE, trzy pobrania na 228,80 EUR, zero ostrzeżeń. | Prawidłowy | |
| pain.008.001.02 — mandate signed after the collectionPobranie realizowane na podstawie mandatu, którego dłużnik jeszcze nie podpisał: DtOfSgntr to 10.04.2026, a data pobrania to 05.03.2026. Częsta i po cichu zabójcza wada — ICS, numery IBAN i sumy są poprawne. | Nieprawidłowy | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequencePrawidłowe polecenie zapłaty SEPA B2B w pain.008.001.08: LclInstrm/Cd = B2B, sekwencja RCUR, dwa cykliczne pobrania na łączną kwotę 4 650,00 EUR. Schemat B2B to wariant między firmami — dłużnik nie może być konsumentem i NIE ma prawa do zwrotu po rozliczeniu, dlatego jego bank sprawdza mandat przed obciążeniem, a pobrania B2B prezentuje się wcześniej niż CORE. | Prawidłowy | |
| pain.008.001.02 — valid CORE direct debit, FRST sequencePrawidłowe polecenie zapłaty SEPA CORE w sekwencji FRST: pierwsze pobranie w ramach świeżo podpisanego mandatu (DtOfSgntr sprzed kilku dni). Wszystko, co nastąpi później na tym samym mandacie, musi iść jako RCUR — pozostawienie partii na zawsze w FRST to jeden z najczęstszych błędów SDD i powód, dla którego banki zwracają pobrania z kodem błędnej sekwencji. | Prawidłowy | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequencePrawidłowe jednorazowe polecenie zapłaty SEPA: sekwencja OOFF, jedno pobranie na 349,00 EUR. Mandat upoważnia dokładnie do jednego obciążenia i zużywa się w chwili użycia — nie można go przedstawić ponownie, nawet jako RCUR. To sekwencja dla pojedynczego zakupu, zadatku lub jednorazowej opłaty; użycie zamiast niej FRST po cichu zostawia otwarty mandat, na który dłużnik nigdy się nie zgodził. | Prawidłowy | |
| pain.008.001.02 — mandate identifier (MndtId) missingPolecenie zapłaty bez identyfikatora mandatu: MndtRltdInf istnieje i niesie datę podpisu, ale brakuje elementu MndtId (AT-01 rulebooka). Oficjalny XSD ISO 20022 przyjmuje ten plik — MndtId jest w schemacie opcjonalny — więc czysto strukturalna kontrola go przepuszcza, a bank odrzuca: bez referencji mandatu bank dłużnika nie ma do czego dopiąć pobrania, a dłużnik nie ma czego zakwestionować. | Nieprawidłowy | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsPolecenie zapłaty SEPA, które źle się liczy i źle sumuje — na obu poziomach naraz: partia zawiera naprawdę 2 pobrania na 300,00 EUR, ale NbOfTxs deklaruje 3, a CtrlSum 250,00 — w PmtInf i ponownie w GrpHdr. To cztery błędy, nie dwa: sumy kontrolne sprawdza się na partii płatności ORAZ w nagłówku pliku, bo plik wielopartyjny może mieć poprawną sumę nagłówka opartą na dwóch błędnych sumach partii. XML jest poprawnie zbudowany, a oficjalny XSD go przyjmuje: dla schematu NbOfTxs i CtrlSum to po prostu liczby. | Nieprawidłowy |
Wyciąg bankowy (camt.052 / 053 / 054) (12)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| camt.053.001.02 — valid statementPrawidłowy wyciąg camt.053.001.02: cztery księgowania, salda otwarcia i zamknięcia, które się uzgadniają (OPBD ± obroty = CLBD), oraz daty w formacie Dt. | Prawidłowy | |
| camt.053.001.08 — valid statementPrawidłowy wyciąg camt.053.001.08: trzy księgowania, znaczniki czasu DtTm i BICFI zamiast BIC — różnice, na których potyka się każdy przechodzący z wersji 02 na 08. | Prawidłowy | |
| camt.053 — unsupported namespaceWyciąg deklarujący camt.053.001.99 — wersję, która nie istnieje w katalogu ISO 20022. Przydatny do sprawdzenia, czy własny parser odrzuca nieznane przestrzenie nazw, zamiast zgadywać. | Nieprawidłowy | |
| camt.053.001.06 — missing Stmt elementWyciąg z poprawną przestrzenią nazw camt.053.001.06, ale całkowicie bez elementu <Stmt>: koperta jest w porządku, brakuje treści. Tak wygląda ucięty eksport bankowy. | Nieprawidłowy | |
| camt.053.001.11 — valid statementPrawidłowy wyciąg camt.053.001.11 — bieżąca wersja komunikatu wyciągu ISO 20022. Cztery księgowania, OPBD 25 000,00 ± obroty = CLBD 34 659,05. Warto zauważyć, co wersja 11 czyni obowiązkowym w każdym księgowaniu: Sts i BkTxCd, które wcześniejsze wersje pozwalały pominąć. | Prawidłowy | |
| camt.053.001.08 — three accounts in one fileJeden komunikat camt.053, trzy bloki <Stmt>: rachunek bieżący, oszczędnościowy i walutowy w USD. Plik jest zgodny ze schematem; walidator wprost informuje, że analizuje wyłącznie pierwszy wyciąg. O to właśnie chodzi — parser, który bierze Stmt[0] i kończy, po cichu gubi dwa rachunki, a ten plik wielorachunkowy to obnaża. | Prawidłowy | |
| camt.053.001.10 — fully detailed entriesWszystko, co bank może podpiąć pod księgowanie camt.053, w jednym prawidłowym pliku: NtryDtls/TxDtls z EndToEndId, InstrId, TxId i MndtId; RltdPties i RltdAgts; ustrukturyzowana referencja wierzyciela ISO 11649 (RF) oraz powiązana faktura (CINV); księgowanie zbiorcze, w którym dwa TxDtls sumują się dokładnie do kwoty księgowania; a także BkTxCd ISO (PMNT/RCDT/ESCT) obok firmowego niemieckiego GVC. Przydatny, by sprawdzić, ile z księgowania naprawdę czyta wasza uzgadniarka. | Prawidłowy | |
| camt.053.001.08 — closing balance does not reconcileNajczęstsza wada produkcyjnych plików camt.053: saldo otwarcia 4 200,00 plus zaksięgowane pozycje daje 5 194,70, podczas gdy zadeklarowane CLBD mówi 5 194,07 — dwie cyfry przestawione. Plik bez zarzutu spełnia oficjalny XSD ISO 20022, bo schemat nie ma nic do powiedzenia o arytmetyce. Tylko uzgodnienie sald wykryje niezgodne saldo zamknięcia. | Prawidłowy | |
| camt.052.001.08 — valid intraday reportPrawidłowy raport śróddzienny camt.052 — i nie jest to mały camt.053: korzeniem jest BkToCstmrAcctRpt, kontenerem <Rpt>, a salda są PRZEJŚCIOWE (ITBD zaksięgowane, ITAV dostępne) zamiast pary OPBD/CLBD z wyciągu na koniec dnia. Zawiera też pozycję oczekującą (Sts=PDNG), celowo wyłączoną z salda przejściowego: pieniądz oczekujący to nie pieniądz zaksięgowany. | Prawidłowy | |
| camt.054.001.08 — valid debit/credit notificationPrawidłowe zawiadomienie o obciążeniu/uznaniu camt.054: jedno przychodzące uznanie SEPA i jedno wychodzące polecenie zapłaty, każde z pełnymi TxDtls i referencją end-to-end. Strukturalną niespodzianką jest to, czego NIE MA: camt.054 nie zawiera żadnego elementu <Bal> — schemat ISO 20022 go nie definiuje. Zawiadomienie ogłasza operacje, nigdy nie podaje salda: nie ma czego uzgadniać. | Prawidłowy | |
| camt.053.001.08 — entry with no CdtDbtIndDrugie księgowanie nosi kwotę 1 200,00 i żadnego <CdtDbtInd>. Kwoty w camt.053 są zawsze bez znaku: bez wskaźnika kierunku kwota nic nie znaczy. Psują się naraz dwie rzeczy — oficjalny XSD odrzuca plik (CdtDbtInd jest obowiązkowy 1..1 w księgowaniu), a parser po cichu przyjmujący CRDT księguje +1 200,00 zamiast −1 200,00 i myli się o 2 400,00, co natychmiast ujawnia kontrola sald. | Nieprawidłowy | |
| camt.053.001.08 — 220 entries, validFirmowy wyciąg na koniec miesiąca z 220 zaksięgowanymi pozycjami, w pełni uzgodniony: OPBD 125 000,00 ± obroty = CLBD 209 081,69. Każda pozycja niesie NtryDtls/TxDtls, EndToEndId i kontrahenta — pozwala sprawdzić czytnik camt.053 na realistycznej skali, a nie na trzywierszowym pliku-zabawce: przepustowość parsowania, renderowanie tabeli i uzgadnianie setek wierszy. | Prawidłowy |
Faktura UBL (Peppol BIS 3.0) (12)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0Prawidłowa faktura Peppol BIS Billing 3.0: trzy pozycje, 2 596,00 EUR brutto, zgodne sumy, francuski numer VAT i IBAN do zapłaty. | Prawidłowy | |
| UBL Credit Note — valid Peppol BIS 3.0Prawidłowa nota kredytowa Peppol BIS Billing 3.0: jedna pozycja, 1 770,00 EUR brutto, z odwołaniem do korygowanej faktury pierwotnej. Nota kredytowa to odrębny typ dokumentu UBL, a nie faktura z kwotami ujemnymi. | Prawidłowy | |
| UBL Invoice — BR-CO-10 violationFaktura naruszająca regułę EN 16931 BR-CO-10: suma kwot netto pozycji (1 000,00) nie równa się sumie dokumentu BT-106 (2 000,00). Jedno z najczęstszych odrzuceń w sieci Peppol. | Nieprawidłowy | |
| UBL Invoice — malformed seller VAT identifierFaktura, w której numer VAT sprzedawcy „FR1234” jest za krótki: numer francuski to FR, dwuznakowy klucz i dziewięć cyfr. Błędy formatu w BT-31 są wychwytywane na długo przed urzędem skarbowym. | Nieprawidłowy | |
| UBL Invoice — allowances and charges, line and document levelPrawidłowa faktura UBL w Peppol BIS 3.0 z rabatami i opłatami na OBU poziomach: rabat pozycji (BG-27), opłata pozycji (BG-28), rabat na poziomie dokumentu (BG-20) i koszt transportu (BG-21). Istotny jest łańcuch sum: BT-106 = 1 520,00 to suma NETTO kwot pozycji, a BT-109 = 1 530,00 = BT-106 - BT-107 + BT-108 (BR-CO-13), więc 19 % VAT liczy się od 1 530,00, a nie od 1 520,00. | Prawidłowy | |
| UBL Invoice — reverse charge (VAT category AE)Prawidłowa faktura z odwrotnym obciążeniem w UBL: francuski usługodawca fakturuje usługi niemieckiej firmie, VAT rozlicza nabywca, więc stawka wynosi 0 % i podatku nie naliczono. Kategoria AE niesie cztery reguły: oba numery VAT (BR-AE-02, BR-AE-03), stawkę 0 % (BR-AE-05), kwotę podatku 0,00 (BR-AE-09) oraz powód zwolnienia (BR-AE-10) — tutaj VATEX-EU-AE i tekst „Reverse charge”. | Prawidłowy | |
| UBL Invoice — VAT exempt (category E) with exemption reasonPrawidłowa faktura zwolniona z VAT (kategoria E): szkolenie zawodowe zwolnione na podstawie art. 132 ust. 1 lit. i) dyrektywy 2006/112/WE. Faktura zwolniona musi podać, DLACZEGO — reguła BR-E-10 wymaga kodu powodu zwolnienia (BT-121) albo tekstu (BT-120); ten plik zawiera oba: VATEX-EU-132 i brzmienie z oficjalnej listy kodów. | Prawidłowy | |
| UBL Invoice — intra-Community supply (VAT category K)Prawidłowa wewnątrzwspólnotowa dostawa towarów (kategoria VAT K): towary wysłane z Niemiec do zarejestrowanego na VAT nabywcy we Francji, stawka 0 % na podstawie art. 138 dyrektywy 2006/112/WE. Kategoria K wymaga dwóch łatwo pomijanych danych: BR-IC-11 — faktycznej daty dostawy (BT-72) albo okresu rozliczeniowego — oraz BR-IC-12 — kraju dostawy (BT-80). Bez nich faktura nie dowodzi, że towar opuścił kraj. | Prawidłowy | |
| UBL Invoice — two VAT rates, one breakdown per ratePrawidłowa faktura łącząca francuską stawkę podstawową (20 %) i obniżoną (5,5 %). Regułą, dla której ten plik powstał, jest BR-S-08: zestawienie VAT (BG-23) zawiera JEDEN TaxSubtotal na parę (kategoria, stawka), a każda podstawa opodatkowania równa się sumie pozycji z tej pary — 1 500,00 przy 20 % (VAT 300,00) i 400,00 przy 5,5 % (VAT 22,00). Połączenie dwóch stawek w jeden podsumowany wiersz przechodzi wszystkie kontrole BR-CO i nadal jest błędem. | Prawidłowy | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106Najczęstsze odrzucenie w produkcji, wyizolowane: dwie pozycje sumują się do 1 500,00, a BT-106 (LineExtensionAmount) deklaruje 1 400,00 — BR-CO-10. Cała reszta jest spójna z BŁĘDNĄ kwotą, więc BR-CO-13, BR-CO-14, BR-CO-15 i BR-CO-16 przechodzą i wraca dokładnie jeden błąd. Tak wygląda pozycja usunięta już po wyliczeniu sum. | Nieprawidłowy | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)Faktura zwolniona zepsuta na dwa sposoby. BR-E-10: zestawienie VAT dla kategorii E nie zawiera ani tekstu powodu zwolnienia (BT-120), ani kodu (BT-121) — faktura zwolniona musi podać, DLACZEGO. BR-E-08: podstawa zwolniona deklaruje 1 200,00, podczas gdy zwolnione pozycje sumują się do 1 500,00, bo druga pozycja nigdy nie trafiła do zestawienia. Cytowany błąd pochodzi z warstwy reguł biznesowych; oficjalny Schematron EN 16931 dokłada do tego BR-E-10. | Nieprawidłowy | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateZestawienie VAT, które się nie zgadza: podstawa 2 000,00 przy 19 % daje 380,00 podatku, a faktura deklaruje 395,00. Reguła BR-CO-17 sprawdza, że kwota podatku kategorii = podstawa × stawka / 100, z oficjalnym marginesem jednej jednostki waluty — prawdziwy grosz zaokrąglenia jest tolerowany, ta różnica 15,00 już nie. Wszystkie pozostałe sumy pasują do błędnej kwoty: tak właśnie błąd zaokrąglenia dociera na produkcję. | Nieprawidłowy |
Faktura CII (składnia XRechnung / Factur-X) (4)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validPrawidłowa faktura XRechnung 3.0 w składni CII (UN/CEFACT CrossIndustryInvoice) — niemiecka e-faktura dla sektora publicznego. Zawiera to, co reguły BR-DE instytucji KoSIT dokładają do EN 16931: Leitweg-ID jako referencję nabywcy (BR-DE-15), pełny kontakt sprzedawcy — nazwisko, telefon i e-mail (BR-DE-2 do BR-DE-6), adres elektroniczny sprzedawcy, ustrukturyzowane warunki płatności oraz przelew SEPA (sposób płatności 58). | Prawidłowy | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)Ładunek Factur-X / ZUGFeRD sam w sobie: XML w składni CII, który zwykle podróżuje osadzony w PDF/A-3, tutaj jako samodzielny plik do bezpośredniej walidacji. Profil BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) to CIUS zgodny z EN 16931 — pełne pozycje faktury, kompletne zestawienie VAT i sześć sum dokumentu. Przydatny do testowania ekstraktora na samym XML, bez PDF-a dookoła. | Prawidłowy | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 w składni CII: dwie pozycje sumują się do 2 000,00, a LineTotalAmount (BT-106, wewnątrz SpecifiedTradeSettlementHeaderMonetarySummation) deklaruje 1 900,00. Ta sama wada co w próbce UBL, tyle że w składni, w której najtrudniej ją dostrzec — sumy dokumentu leżą w innej gałęzi drzewa niż pozycje, które mają podsumowywać. | Nieprawidłowy | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisRabat na poziomie dokumentu, który istnieje tylko w połowie: faktura udziela 200,00 (BT-107), liczy VAT od podstawy po rabacie (1 800,00 × 19 % = 342,00 — poprawnie), ale BT-109 (TaxBasisTotalAmount) nadal deklaruje 2 000,00 bez rabatu. Reguła BR-CO-13 wymaga BT-109 = BT-106 - BT-107 + BT-108, więc nabywca płaci 200,00, które sprzedawca uważał za podarowane. | Nieprawidłowy |
Wyciąg SWIFT MT940 (10)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectWzorcowy przypadek MT940: jeden wyciąg, jedno uznanie i jedno obciążenie, z parą referencji klient/bank w linii :61:. Zacznij tutaj, aby poznać strukturę tagów przed dialektami. | Prawidłowy | |
| MT940 — ING Belgium, structured :86:Dialekt ING Belgia: linia informacyjna :86: jest podzielona na podpola ?00 ?20 ?30 zamiast wolnego tekstu. To najczęstsze źródło błędów parsowania MT940. | Prawidłowy | |
| MT940 — Commerzbank, one-decimal amountDialekt Commerzbank: kwota z jednym miejscem dziesiętnym (1234,5 oznacza 1 234,50), typ transakcji NMSC i niemieckie konto podane jako BLZ + numer, a nie IBAN. | Prawidłowy | |
| MT940 — two statements in one fileDwa wyciągi w jednym pliku MT940 oraz tag salda dostępnego :64:. Plik to nie jeden wyciąg — parser, który tak zakłada, po cichu zgubi drugi. | Prawidłowy | |
| MT940 — reversal (RC) and intermediate balancesPrzypadek ABN AMRO: storno RC (uznanie odwrócone w obciążenie), salda pośrednie 60M/62M zamiast F oraz :86: rozłożone na dwie linie. Storna odwracają znak — pomyłka tutaj oznacza saldo, które nigdy się nie uzgodni. | Prawidłowy | |
| MT940 — overdrawn account (debit balances)Rachunek na debecie: salda otwarcia i zamknięcia mają znacznik D (debet). W MT940 saldo ujemne to nie liczba ujemna, tylko flaga znaku — kod, który ją ignoruje, pokaże debet jako środki dodatnie. | Prawidłowy | |
| MT940 — closing balance does not reconcileWyciąg, w którym saldo zamknięcia nie wynika z otwarcia ± obrotów. Celowo jest to ostrzeżenie, a nie błąd blokujący: plik pozostaje czytelny, a człowiek musi rozstrzygnąć, czy zawinił bank, czy eksport. | Prawidłowy | |
| MT940 — 500 transactions (load test)Pięćset transakcji w jednym wyciągu, zbilansowanych co do centa. Sprawdź nim, czy Twój parser pozostaje dokładny — i szybki — przy realnym wolumenie, a nie tylko na trzywierszowym pliku zabawce. | Prawidłowy | |
| MT940 — statement split over two pages (62M / 60M)Jeden wyciąg, jeden dzień, dwie strony: sekwencja 00147/00001 zamyka się saldem POŚREDNIM :62M:, a sekwencja 00147/00002 otwiera się tagiem :60M: z dokładnie tą kwotą i dopiero potem zamyka końcowym :62F:. M to nie F — biorąc saldo pośrednie za końcowe, zaraportujesz 37 500,00, choć rachunek zakończył dzień na 44 249,25. | Prawidłowy | |
| MT940 — USD account with an RD reversalWyciąg w dolarach — MT940 to nie format wyłącznie euro — w którym przelew wychodzący na 35 000,00 wraca nazajutrz przez storno RD: STORNOWANE OBCIĄŻENIE to pieniądze, które WRACAJĄ. Znaczniki RC/RD odwracają ekonomiczny kierunek linii :61:, a parser czytający tylko D z „RD” zaksięguje zwrot ponownie jako płatność i nigdy nie uzgodni salda. | Prawidłowy |
Wyciąg BAI2 (USA / Kanada) (6)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)Wzorcowy plik BAI2: jeden rachunek, saldo otwarcia 010 i zamknięcia 015 oraz dziesięć operacji, których kierunek wynika wyłącznie z type code — 115 wpłata lockbox, 165 uznanie ACH, 195 przelew przychodzący, 475 zrealizowany czek, 451 obciążenie ACH, 495 przelew wychodzący, 698 opłaty. BAI2 nie ma znacznika Wn/Ma: 100–399 to wpływ, 400–699 wypływ. | Prawidłowy | |
| BAI2 — several accounts in one groupDwa rekordy rachunku 03 w jednej grupie 02 — rachunek bieżący i rachunek płacowy, każdy zamknięty własnym trailerem 49. BAI2 jest hierarchiczny (01 plik / 02 grupa / 03 rachunek / 16 operacja / trailery 49-98-99): kto zakłada jeden rachunek na plik, po cichu gubi drugi. | Prawidłowy | |
| BAI2 — 88 continuation recordsRekord kontynuacji 88 w dwóch zupełnie różnych rolach: niesie dodatkowe krotki sald dla rekordu rachunku 03 (tu saldo zamknięcia 015 i dostępne 045) oraz zawinięty tekst swobodny dla operacji 16 (trzy linie fizyczne, jeden opis). Scalenie obu tak samo oznacza czytanie sald jako tekstu — albo tekstu jako sald. | Prawidłowy | |
| BAI2 — CAD and JPY: minor units scale with the currencyKwoty BAI2 nie mają separatora dziesiętnego: to jednostki podrzędne, a liczba domyślnych miejsc po przecinku zależy od waluty. Tutaj „2500000” to 25 000,00 CAD na rachunku CAD (2 miejsca) i ¥2 500 000 na rachunku JPY (0 miejsc). Rachunek CAD dodatkowo zostawia pole waluty puste i dziedziczy ją z nagłówka grupy 02. Zakodowane na sztywno dzielenie przez 100 psuje rachunek w jenach o dwa rzędy wielkości — a saldo i tak się zgadza, bo wszystkie trzy liczby są błędne o ten sam czynnik. | Prawidłowy | |
| BAI2 — closing balance does not reconcileSaldo zamknięcia 015 nie wynika z salda otwarcia 010 powiększonego o operacje 16 — 50 000,00 + 10 000,00 − 2 500,00 daje 57 500,00, a plik deklaruje 59 000,00. Trailery wciąż się zgadzają: zdradza to wyłącznie arytmetyka. Celowo ostrzeżenie, a nie błąd blokujący: plik pozostaje czytelny, a człowiek musi rozstrzygnąć, czy zawinił bank, czy eksport. | Prawidłowy | |
| BAI2 — bad trailer totals and an out-of-range type codeTrzy usterki naraz. Trailer rachunku 49 deklaruje sumę kontrolną i liczbę rekordów, z których żadna nie zgadza się z rekordami powyżej — trailery są własną kontrolą integralności pliku, a kto je pomija, nie zauważy obcięcia. Do tego operacja 16 nosi type code 720 z zakresu kredytów 700–799: to ani uznanie (100–399), ani obciążenie (400–699), więc kierunku nie da się wywnioskować i rekord zostaje pominięty zamiast zgadnięty — dlatego saldo również przestaje się zgadzać. | Prawidłowy |
Factur-X / ZUGFeRD (PDF) (2)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoicePrawidłowa faktura Factur-X w profilu EN 16931: PDF/A-3 z osadzonym XML-em CII. Jeden dokument, który człowiek czyta, a maszyna parsuje — na tym polega sens formatu hybrydowego. | Prawidłowy | |
| Factur-X EN 16931 — BR-CO-15 violationFaktura Factur-X naruszająca regułę EN 16931 BR-CO-15: kwota brutto to 130,00, podczas gdy netto plus VAT daje 120,00. PDF otwiera się i wygląda całkiem normalnie — zdradza go dopiero osadzony XML. | Nieprawidłowy |
Faktura KSeF (FA(3)) (7)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)Zgodna faktura ustrukturyzowana FA(3) — przykład nr 4 opublikowany przez Ministerstwo Finansów, odtworzony bez zmian. Trzy pozycje, 64 279,92 zł brutto przy stawce 23%. Wzorzec tego, co KSeF przyjmuje. | Prawidłowy | |
| KSeF — invoice still using the retired FA(2) schemaNajczęstszy błąd migracji do KSeF: poprawnie zbudowana faktura, która wciąż deklaruje przestrzeń nazw FA(2), wycofaną 1 lutego 2026 r. Nic nie wygląda źle, dopóki KSeF jej nie odrzuci. Zwróć uwagę na to, co doszło w FA(3), a czego tu brakuje: Podmiot2 wymaga teraz JST i GV. | Nieprawidłowy | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Strukturalnie bez zarzutu względem oficjalnego schematu, a mimo to NIP sprzedawcy nie przechodzi sumy kontrolnej mod-11, a P_15 nie zgadza się z sumą rozbicia VAT. ValidateFin zgłasza oba jako ostrzeżenia, nie błędy — żadna z tych reguł nie jest normatywna, a przykład nr 1 samego Ministerstwa też różni się o grosz. | Prawidłowy | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)Faktura korygująca (RodzajFaktury = KOR) — najczęściej poszukiwany i najczęściej źle budowany przypadek FA(3). Kwoty w polach P_13_1, P_14_1 i P_15 są ujemne, bo niosą RÓŻNICĘ, a nie fakturę po korekcie. Pojawiają się PrzyczynaKorekty, TypKorekty oraz DaneFaKorygowanej ze wskazaniem faktury korygowanej. Wiersze występują parami: ten ze StanPrzed to stan sprzed korekty. | Prawidłowy | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)Faktura zaliczkowa (RodzajFaktury = ZAL): dokumentuje zaliczkę na poczet zamówienia, które nie zostało jeszcze zrealizowane. Dlatego nie zawiera ŻADNEGO wiersza FaWiersz — towary i usługi opisuje blok Zamowienie z własnymi polami P_7Z / P_11NettoZ / P_11VatZ — a P_15 wykazuje wyłącznie zaliczkę 12 300,00 zł przy wartości zamówienia 61 500,00 zł. | Prawidłowy | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)Faktura FA(3) bez jednego elementu obowiązkowego: P_2, czyli numeru faktury. Na oko wszystko jest w porządku — poprawny XML, właściwa przestrzeń nazw, wiarygodne rozbicie VAT — a wykrywa to dopiero oficjalny XSD Ministerstwa Finansów: „Element P_6: this element is not expected. Expected is P_2”. KSeF odrzuca taki plik od razu. | Nieprawidłowy | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)NIP nabywcy to 1111111112 — dziesięć cyfr, więc oficjalny schemat, który sprawdza NIP wyłącznie wzorcem, przyjmuje go bez słowa. Suma kontrolna mod-11 się jednak nie zgadza: taki NIP nie może istnieć, a faktura trafia donikąd. ValidateFin zgłasza ostrzeżenie, nigdy błąd — Ministerstwo nie publikuje takiej reguły walidacji. | Prawidłowy |
Faktura FatturaPA (Włochy, SdI) (4)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyFatturaPA, którą SdI by przyjął: poprawna arytmetyka VAT (dwie pozycje po 22 % dające 1 100 €, 242 € podatku, 1 342 € razem), identyfikatory podatkowe z prawidłową cyfrą kontrolną i 7-znakowy CodiceDestinatario, jakiego wymaga odbiorca prywatny. To punkt odniesienia: każdy inny przykład to ten plik, zepsuty w jeden konkretny sposób. | Prawidłowy | |
| FatturaPA — signed CAdES (.p7m) envelopeTa sama zgodna faktura, zamknięta w kopercie podpisu CAdES (.p7m) — tak krąży większość prawdziwych włoskich faktur i tak MUSI wyglądać każda faktura do administracji publicznej. W edytorze tekstu to tylko binarny szum. Walidator otwiera kopertę i sprawdza zawarty w niej XML; samego podpisu nie weryfikuje i mówi o tym wprost. | Prawidłowy | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)Ta faktura jest POPRAWNA względem oficjalnego XSD, a SdI i tak by ją odrzucił — właśnie dlatego sama kontrola schematu nie wystarcza. Trzy wady: podstawa opodatkowania deklaruje 1 150 € przy pozycjach sumujących się do 1 100 € (kontrola 00422, której tolerancja wynosi jedno EURO, a nie jeden cent); podatek deklaruje 250 €, choć 22 % z 1 150 € daje 253 € (00421); a kod Natura to gołe N3, wycofane 1 stycznia 2021 r. na rzecz podkodów (00445) — mimo że nadal figuruje w wyliczeniu schematu. | Nieprawidłowy | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)Najczęstszy powód odbicia faktury skierowanej do włoskiej administracji: CodiceDestinatario. Dla PA (FormatoTrasmissione = FPA12) musi to być SZEŚCIOznakowy kod urzędu IPA — forma siedmioznakowa należy do odbiorców prywatnych. XSD dopuszcza 6 LUB 7 dla obu, więc schemat tego nie widzi; widzi to wyłącznie kontrola SdI 00427. Numer faktury, «FATTURA», nie zawiera przy tym żadnej cyfry (00425). | Nieprawidłowy |
Faktura RO e-Factura (Rumunia, ANAF) (6)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)Faktura, którą ANAF przyjmuje — jej własny walidator offline odpowiada « este valid ». To przykład opublikowany przez Ministerstwo, naprawiony w dwóch punktach, na których wersja opublikowana upada: BT-24 podniesione do CIUS-RO:1.0.1 oraz dwa CUI z naprawdę poprawną cyfrą kontrolną. To punkt odniesienia: każdy zepsuty przykład to ten plik, uszkodzony w jeden konkretny sposób. | Prawidłowy | |
| RO e-Factura — credit note in a foreign currency (FCN)Nota kredytowa (FCN) wystawiona w SEK — a ANAF ją przyjmuje. Pokazuje, czego naprawdę wymaga BR-RO-030: RON musi wystąpić jako waluta faktury (BT-5) ALBO jako waluta rozliczenia VAT (BT-6), niekoniecznie obie. Tu BT-5 to SEK, a BT-6 to RON, co spełnia regułę. Nota nosi też kod typu 381, dozwolony na nocie kredytowej i zakazany na fakturze. | Prawidłowy | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)Najczęstsze rumuńskie odrzucenie i jedyna wada tego pliku: BT-24 nadal podaje CIUS-RO:1.0.0, wartość wycofaną 29 grudnia 2022 r. (rozporządzenie OMF 4092/2022). Poza tym faktura jest bez zarzutu i przechodzi XSD. Oba przykłady, które Ministerstwo wciąż publikuje, mają tę wadę — a jego własny walidator je odrzuca. | Nieprawidłowy | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)Sprzedawca w Bukareszcie, którego miasto (BT-37) zapisano jako „Sector 1” — dokładnie tak, jak zapisuje je samo rozporządzenie ministra. Schematron, który ANAF faktycznie uruchamia, wymaga SECTOR1: wielkimi literami, bez spacji. Gdy tekst prawa i implementacja się rozchodzą, to implementacja odrzuca fakturę. | Nieprawidłowy | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)Przykład, który obnaża martwe pole każdego walidatora uruchamiającego wyłącznie Schematron. CUI nabywcy (RO987456123) ma błędną cyfrę kontrolną — a ŻADNA reguła Schematronu na nią nie patrzy. Ten plik przechodzi XSD, przechodzi cały zbiór reguł CIUS-RO, a ANAF i tak go odrzuca, własnym kodem: ERRIdentif, « CUI cumparator incorect ». | Nieprawidłowy | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)Faktura B2C, w której nabywcą jest osoba prywatna, identyfikowana anonimowym CNP złożonym z trzynastu zer — w produkcji od 16 grudnia 2024 r. Jest poprawna, a walidator traktujący ją jak zniekształcony numer osobowy zepsułby całe fakturowanie konsumenckie w Rumunii: ten numer nie spełnia żadnej reguły formalnej CNP (jego pierwsza cyfra, 0, jest wszędzie indziej odrzucana), bo jest wartością zastrzeżoną, a nie CNP. | Prawidłowy |
Rekord fakturowy Verifactu (Hiszpania, AEAT) (3)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosPrzesyłka, którą AEAT by przyjął: dwa poprawnie połączone łańcuchem rekordy fakturowe. Pierwszy deklaruje się początkiem łańcucha i liczy odcisk z pustym polem poprzednika; drugi łączy odcisk pierwszego. Oba odciski są prawdziwymi wartościami SHA-256 obliczonymi na dokładnym ciągu wskazanym przez AEAT — nie są zmyślone. | Prawidłowy | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)Drugi rekord deklaruje odcisk, który NIE odpowiada jego treści: łańcuch jest zerwany. Plik jest POPRAWNY względem oficjalnego XSD AEAT — walidator patrzący tylko na schemat go przepuszcza. Wykrywa to dopiero ponowne policzenie łańcuchowego SHA-256. I uwaga: AEAT go NIE odrzuca — oznacza jako „Aceptado con errores” (kod 2000) i mimo to rejestruje. | Prawidłowy | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)Faktura uproszczona (F2) zawierająca blok Destinatarios — zabroniony, kod 1190 — oraz CuotaRepercutida (100 €), która nie zgadza się z podstawą × stawka (1 000 € × 21 % = 210 €), daleko poza tolerancją ±10 € kontroli 1142. Plik PRZECHODZI oficjalny XSD bez jednej uwagi: schemat tego nie widzi, a AEAT to odrzuca. | Nieprawidłowy |
Faktura Facturae (Hiszpania, FACe) (2)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaFaktura Facturae 3.2.2 skierowana do administracji publicznej (z jej centrami administracyjnymi DIR3, jak wymaga FACe), która przechodzi oficjalny XSD facturae.gob.es bez jednej uwagi, ze wszystkimi sumami zgodnymi z formułami samego schematu i obecnym podpisem XAdES. To punkt odniesienia: drugi przykład to ten sam plik, zepsuty w jeden konkretny sposób. Podpis jest przykładowy — jego ważność kryptograficzna nie jest sprawdzana offline. | Prawidłowy | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)Ten sam plik, z jedną zmianą: InvoiceTotal deklaruje 1200,00 € tam, gdzie formuła schematu daje 1210,00 € (podstawa 1000 + VAT 210). Plik jest POPRAWNY względem oficjalnego XSD facturae.gob.es — walidator patrzący tylko na schemat go przepuszcza. Wykrywa to dopiero warstwa spójności, sygnalizując też, że suma partii już się nie zgadza. To nie „oficjalne” odrzucenie: Facturae/FACe nie publikuje weryfikowalnych offline kodów odrzucenia, więc to ostrzeżenie, nie błąd. | Prawidłowy |
Wyciąg CODA (Belgia) (6)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationZwykły belgijski wyciąg: przelew SEPA z poprawnym komunikatem strukturalnym (+++090/9337/55493+++), płatność kartą oraz przelew przychodzący z kontrahentem. Saldo początkowe 1 000,00 − 250,00 − 89,90 + 1 500,00 = saldo końcowe 2 160,10, a sumy z rekordu kontrolnego się zgadzają. | Prawidłowy | |
| CODA — globalised salary run (booked total + its details)Globalizacja: jeden zaksięgowany zbiorczy przelew wynagrodzeń na 3 000,00 (numer szczegółu 0000), a za nim dwie pojedyncze wypłaty (0001, 0002). Księgowana jest tylko suma — parser, który zsumuje także szczegóły, liczy plik podwójnie i wyciąg przestaje się bilansować. Kończy się saldem debetowym 2 000,00. | Prawidłowy | |
| CODA — wrong mod-97 check digits and a statement that does not balanceZepsuty celowo. Komunikat strukturalny kończy się na 94, choć mod 97 wymaga 93 — to najczęstsza przyczyna, dla której belgijska płatność nigdy nie zostaje dopasowana do faktury — a saldo końcowe nie wynika z operacji. Żadne inne darmowe narzędzie CODA nie sprawdza tych cyfr kontrolnych. | Prawidłowy | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedWyciąg CODA z dwoma referencjami strukturalnymi, jakie dopuszcza ten format — każda z własną sumą kontrolną: przelew wychodzący z belgijskim komunikatem strukturalnym +++090/9337/55493+++ (typ 101, mod 97 — reszta 0 zapisywana jest jako 97, nie 00) oraz przelew przychodzący z referencją wierzyciela ISO 11649 RF73INV20260042 (typ 100, mod 97-10). Obie są poprawne, a wyciąg się bilansuje: 1 000,00 − 250,00 + 1 500,00 = 2 250,00. | Prawidłowy | |
| CODA — separate application: balances zeroed by design (§7.2.1)CODA typu „separate application” (pozycje 84-88 nagłówka = 00001): rozliczenie akceptacji kart dostarczone poza wyciągiem rachunku. Febelfin §7.2.1 z definicji zeruje jego saldo początkowe i końcowe, więc tożsamość saldo początkowe ± obroty = saldo końcowe nie może być spełniona — i nie wolno jej sprawdzać. ValidateFin pomija ją tutaj i uznaje plik za czysty; walidator, który tego nie robi, oznacza każdy taki plik jako uszkodzony. | Prawidłowy | |
| CODA — old balance ± movements ≠ new balanceZwykły belgijski wyciąg — bez jednego obrotu. Rekordy 2.1 dają 1 000,00 − 250,00 + 1 500,00 = 2 250,00, ale rekord „8” z saldem końcowym deklaruje 2 200,00: 50,00 zaksięgowanego obrotu nigdy nie trafiło do pliku. To ta kontrola wyłapuje ucięty plik CODA, zgubiony rekord albo źle odczytany znak Wn/Ma — i właśnie dlatego poprzedniej próbki NIE wolno sprawdzać w ten sam sposób. | Prawidłowy |
Wyciąg CFONB 120 (Francja) (5)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsFrancuski wyciąg z kompletem danych SEPA: polecenie zapłaty z referencją mandatu i sekwencją RCUR, nazwa wierzyciela, płatność kartą oraz przelew przychodzący z nazwą płatnika, referencją end-to-end, celem płatności i tytułem — wszystko w rekordach „05”. Saldo początkowe 1 000,00 − 250,00 − 89,90 + 1 500,00 = saldo końcowe 2 160,10. | Prawidłowy | |
| CFONB 120 — amount without its overpunched signZepsuty celowo — i to klasyczny sposób uszkodzenia pliku CFONB: kwota obciążenia kończy się zwykłą cyfrą zamiast znakiem ze wbitym znakiem, więc plik nigdy nie mówi, że to obciążenie. Jest odczytywana jako uznanie — a wychwytuje to tożsamość księgowa wymagana przez CFONB. | Prawidłowy | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYDane SEPA w wyciągu CFONB 120 żyją w rekordach „05”, a każdy kwalifikator inaczej dzieli tę samą 70-znakową strefę (pozycje 49-118): RUM niesie referencję mandatu ORAZ jego typ sekwencji (RCUR), REF referencję paczki ORAZ referencję transakcji, RCN identyfikator end-to-end ORAZ cel płatności, natomiast NBE, NPY i LIB zajmują całą strefę. Odczytana płasko, strefa skleja mandat z typem sekwencji. Plik zawiera polecenie zapłaty SEPA (operacja B1) i przelew przychodzący — łącznie dziesięć różnych kwalifikatorów. | Prawidłowy | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileJeden fizyczny plik CFONB 120, dwa rachunki: każdy tworzy własny blok 01 (saldo początkowe) … 07 (saldo końcowe) i bilansuje się osobno. Drugi otwiera się na DEBECIE — saldo początkowe niesie nadbity znak z rodziny „}”, czyli obciążenie — i wraca do salda kredytowego 179,60. Parser, który prowadzi jedno bieżące saldo dla całego pliku albo czyta znak jako cyfrę, myli się na obu rachunkach. | Prawidłowy | |
| CFONB 120 — the new balance does not equal old balance ± movementsKażda kwota niesie tu poprawny nadbity znak — a wyciąg i tak się nie bilansuje: 1 000,00 − 89,90 + 500,00 = 1 410,10, podczas gdy rekord „07” deklaruje 1 310,10. Reguła 2 z §1 specyfikacji CFONB stawia tę tożsamość jako DEFINICJĘ zgodnego wyciągu — to nie heurystyka: w pliku brakuje 100,00 obrotu. | Prawidłowy |
Komunikat Fedwire ISO 20022 (USA) (6)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferPrzelew klienta z nagłówkiem BAH i hybrydowymi adresami pocztowymi — spełnia już format wymagany od 16 listopada 2026 r. | Prawidłowy | |
| Fedwire pacs.009 — conformant bank-to-bank transferPrzelew między instytucjami finansowymi: odcinek międzybankowy, w którym dłużnik i wierzyciel to banki. | Prawidłowy | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026Adres wierzyciela to trzy wiersze tekstu swobodnego, bez miasta i kraju. Zgodny z XSD, lecz odrzucony przez regułę: od 16 listopada 2026 r. Fedwire usuwa adres w pełni niestrukturalny. | Nieprawidłowy | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overKontrprzykład: dokładnie ten sam niestrukturalny adres, ale rozliczenie 30.06.2026. Jest legalny, więc tylko ostrzega. Wyzwalaczem jest data rozliczenia zapisana w komunikacie, nigdy dzisiejsza data. | Prawidłowy | |
| Fedwire pacs.008 — routing number that cannot existNumer rozliczeniowy banku wierzyciela to 021000088 — jedna cyfra nie ta. Nie przechodzi cyfry kontrolnej ABA 3-7-1, więc taki numer nie może istnieć. XSD widzi dziewięć nienagannych cyfr. | Nieprawidłowy | |
| Fedwire — header announces a different message than it carriesNagłówek BAH deklaruje <MsgDefIdr>pacs.009.001.08</MsgDefIdr>, choć dokument, który poprzedza, to pacs.008. Każda połowa jest zgodna z własnym schematem — wykrywa to dopiero ich zestawienie. | Nieprawidłowy |
Przelew SWIFT MT103 (2)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| MT103 — cross-currency customer credit transferKompletny MT103: pięć bloków SWIFT, UETR, zleceniodawca w opcji K, agenci w opcji A i beneficjent z IBAN-em. Rozliczenie w USD, zlecenie w EUR — pole :36: (kurs wymiany) jest więc wymagane i obecne. | Prawidłowy | |
| MT103 — three defects a plain text viewer would missStrukturalnie doskonale czytelny MT103 — i trzykrotnie błędny: UETR nie jest UUID v4, płatność jest wielowalutowa bez kursu w :36:, a IBAN beneficjenta nie przechodzi mod-97. | Prawidłowy |
Plik płatności CPA-005 / AFT (Kanada) (6)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)Zwykły kanadyjski plik płacowy: jeden rekord „C” zawierający dwie wypłaty bezpośrednie (typ operacji 200) w dwóch z sześciu segmentów. Trailer Z deklaruje 2 uznania na łącznie 3 750,50 i brak obciążeń — i zgadza się. Uwaga: licznik rekordów liczy rekordy FIZYCZNE, a trailer liczy TRANSAKCJE — są trzy rekordy i dwie transakcje. | Prawidłowy | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)Obciążenie „D” na 899,00, po którym następuje rekord „J”, który je zwraca. Zwrot niesie kod 901 (brak środków) w polu TYP OPERACJI — tam, gdzie płatność niosłaby swój typ — podczas gdy pierwotny typ 700 przetrwał w stored transaction type. Oba są księgowane jako obciążenia, stąd 2 obciążenia na 1 798,00 w trailerze. | Prawidłowy | |
| CPA-005 — the error correction folded into the debit totalZepsuty celowo — i to dokładnie tak, jak psują to prawdziwe generatory: plik stornuje uznanie rekordem „E”, a trailer liczy to storno jako obciążenie. Nim nie jest. Norma 005 daje korektom E i F WŁASNĄ parę sum, odrębną od par obciążeń i uznań — połączenie ich sprawia, że plik przestaje się bilansować. To najczęstsza przyczyna odrzucenia ręcznie napisanego generatora CPA-005. | Nieprawidłowy | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedPlik AFT o rekordach 1464 znaków, łączący oba kierunki: rekord „C” z dwiema wypłatami wynagrodzeń (3 750,50) i rekord „D” z dwoma obciążeniami z upoważnienia (1 349,25). C to UZNANIE, a D to OBCIĄŻENIE — wiele publikowanych streszczeń zamienia je miejscami. Trailer Z bilansuje się na czterech parach sum, które definiuje norma 005 (D+J, C+I, E osobno, F osobno) — tutaj z licznikami E i F na zerze. | Prawidłowy | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)Kanadyjskie Notice of Change: instytucja odbiorcy informuje zleceniodawcę, że rachunek się zmienił. To OSOBNY PLIK — rekordy mają 208 znaków, nie 1464, a norma 005 zabrania mieszania jego rekordów U (nagłówek), S (zmiana) i V (trailer) z rekordami AFT. Każdy rekord S niesie nowy numer rozliczeniowy i nowy rachunek obok pierwotnych, a trailer V deklaruje, ile rekordów S zawiera plik. | Prawidłowy | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaPlik płacowy klient→bank, który walidator wyszkolony na regułach amerykańskich odrzuciłby dwukrotnie — i dwukrotnie niesłusznie. Pierwsze uznanie idzie na transit 099999999, który nie niesie żadnej cyfry kontrolnej: kanadyjski DPRN po prostu jej nie ma — norma 005 weryfikuje go przez sprawdzenie w Financial Institutions File, a norma 006 nie definiuje żadnego wzoru. Przeniesienie tu amerykańskiej reguły ABA 3-7-1 odrzuca całkowicie poprawne pliki. Item Trace Number są ponadto wyzerowane, co jest normalne w pliku wysyłanym przez klienta do banku (nadaje je Direct Clearer) — stąd dwa ostrzeżenia i zero błędów. | Prawidłowy |
Plik ACH / NACHA (USA) (10)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)Obciążenie WEB na 123,54, które wraca. Przy zwrocie zmieniają się dokładnie trzy rzeczy: transaction code staje się 26 (kod zwrotu obciążenia rachunku bieżącego — NIE pierwotne 27), bankiem odbierającym staje się ODFI oryginału, a numer trace jest nadawany na nowo. Kwota pozostaje bez zmian — ACH nie zna zwrotu częściowego. Addenda 99 niesie R01 i wskazuje na numer trace pierwotnej pozycji. Paczka nadal jest WEB i nadal mówi TRANSFER: nie istnieje ani opis „RETURN”, ani kod SEC „RET”, cokolwiek twierdzi internet. | Prawidłowy | |
| ACH — a notification of change (C01, corrected account number)Powiadomienie o zmianie — i najważniejsze: to NIE jest odrzucenie. Płatność przeszła. Bank odbiorcy prosi o poprawienie zapisanych danych przed NASTĘPNĄ płatnością: ponowne wysłanie tej zapłaciłoby odbiorcy dwa razy. Dlatego pozycja ma kwotę ZERO, a paczka kod SEC COR. Addenda 98 niesie C01 z poprawionym numerem rachunku na pozycjach 36-52 rekordu. | Prawidłowy | |
| ACH — an international entry (IAT) with its seven mandatory addendaPłatność USD → MXN do Meksyku. Rekord IAT to nie krajowy rekord z innymi etykietami: numer rachunku przenosi się na pozycje 40-74 (35 znaków, by pomieścić rachunek zagraniczny), pozycje 13-16 deklarują liczbę następujących addenda, a nazwisko odbiorcy w ogóle nie znajduje się w rekordzie — mieszka w addenda 10. Siedem addenda (10 do 16) jest obowiązkowych przy każdej pozycji międzynarodowej, bo rekord o długości 94 znaków nie pomieści nazwy, adresu i identyfikacji bankowej obu stron. Odczyt tego pliku z krajowymi przesunięciami zwraca fragment numeru rachunku, jakby był imieniem osoby. | Prawidłowy | |
| ACH — PPD payroll credits, balanced with an offset debitPlik wzorcowy: tak wygląda poprawny plik NACHA. Cztery uznania wynagrodzeń PPD (trzy na rachunek bieżący, kod 22, jedno na rachunek oszczędnościowy, kod 32) i piąta pozycja — obciążenie równoważące (offset), kod 27, na własnym rachunku firmy na dokładną sumę. To właśnie czyni plik „zbilansowanym” i dlatego service class code wynosi 200 (mieszany), a nie 220. Entry hash, sumy Batch Control, sumy File Control i block count zgadzają się co do grosza, a każdy routing number spełnia cyfrę kontrolną ABA 3-7-1. | Prawidłowy | |
| ACH — CCD corporate debits with an addenda 05 remittanceInkaso B2B: dwa obciążenia CCD (service class 225, wyłącznie obciążenia), każde z jednym addenda 05 niosącym rozliczaną fakturę — segmenty RMR i REF, czyli remittance ASC X12, z którym odbiorca korporacyjny uzgadnia księgi. CCD dopuszcza dokładnie JEDNO addenda na pozycję: 80 znaków informacji o płatności, ani znaku więcej. Gdy płatnik potrzebuje więcej miejsca, kod SEC staje się CTX. Zwróć uwagę na addenda record indicator na pozycji 79 pozycji: ma wartość 1 i addenda faktycznie następuje. | Prawidłowy | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Cztery obciążenia WEB — kod SEC płatności autoryzowanej online przez konsumenta. Trzy schodzą z rachunków bieżących (kod 27), jedno z rachunku oszczędnościowego (kod 37): mówi o tym transaction code, a czytanie go inaczej niż jako tabeli to dokładnie ten błąd, który popełniają parsery. Pozycje 77-78 niosą payment type indicator: R dla płatności cyklicznej, S dla jednorazowej. Pozycje WEB nie niosą addenda, więc addenda record indicator pozostaje 0. | Prawidłowy | |
| ACH — CTX with seven addenda 05 carrying an EDI 820Jedno obciążenie CTX na 28 750,00 rozliczające naraz trzy faktury, z awizem remittance ASC X12 820 rozłożonym na siedem rekordów addenda 05. CTX to kod SEC, który parsery mylą najczęściej, bo rekord pozycji nie znaczy tu tego, co wszędzie indziej: pozycje 55-58 to NIE początek nazwy, tylko LICZBA następujących addenda (tutaj 0007), a nazwa firmy odbiorcy zaczyna się dopiero na 59. Odczytany z przesunięciami PPD, nazwa wychodzi jako „0007GLOBEX CORP” — dokładnie to pokazuje nasz własny walidator, bo stosuje układ krajowy. | Prawidłowy | |
| ACH — entry hash mismatch (truncated or tampered file)Plik uznań PPD z błędnym entry hash. Entry hash to suma 8-cyfrowych routing numbers wszystkich pozycji, obcięta do ostatnich dziesięciu cyfr — suma kontrolna, której jedynym zadaniem jest wyłapać plik, który po drodze stracił, zyskał albo miał zmienioną pozycję. Tutaj Batch Control i File Control deklarują 28905251, podczas gdy cztery pozycje sumują się do 27905251. Kwoty nadal się zgadzają — i o to właśnie chodzi: hash jest kontrolą, która odzywa się wtedy, gdy żadna inna tego nie robi. | Nieprawidłowy | |
| ACH — batch control debit total ≠ the sum of its entriesPaczka obciążeń CCD, której Batch Control deklaruje 18 450,00, podczas gdy jej dwie pozycje sumują się do 28 075,00 — klasyczny błąd generatora, który zapisuje trailer, zanim doda ostatnią pozycję. Cała reszta pliku jest poprawna, łącznie z sumami File Control, więc walidator zgłasza dokładnie jeden błąd i wymienia obie liczby. To najczęstsza przyczyna odrzucenia ręcznie zbudowanego pliku ACH przez bank. | Nieprawidłowy | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberPlik obciążeń WEB, w którym jeden bank odbierający ma 026009594 — routing number, który nie przechodzi cyfry kontrolnej ABA 3-7-1 (prawdziwy to 026009593). Błędna jest wyłącznie pozycja 12 rekordu, więc entry hash i wszystkie sumy kontrolne nadal się zgadzają: cyfra kontrolna to jedyna kontrola, która wyłapuje pojedynczą przekręconą cyfrę, a ten plik jest tego dowodem — same sumy jej nie zobaczą. Pozostałe dwie pozycje i wszystkie trailery są poprawne, więc walidator zgłasza dokładnie jeden błąd. | Nieprawidłowy |
Kod QR płatności (EPC / szwajcarski QR-rachunek) (6)
| Pliki przykładowe | Oczekiwany wynik | Pobierz plik |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)Zgodny payload kodu QR EPC (SCT QR) w wersji 002 — tej, w której BIC jest opcjonalny i tutaj go pominięto. Tytułem płatności jest ustrukturyzowana referencja wierzyciela ISO 11649, RF6518539007547034, o poprawnej sumie kontrolnej mod-97: 94 bajty z dozwolonych 331. | Prawidłowy | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageDruga połowa EPC069-12: wersja 001, w której BIC odbiorcy jest obowiązkowy (to jedyna różnica między 001 a 002), z tytułem opisowym zamiast referencji. Referencja ustrukturyzowana i tekst dowolny wykluczają się wzajemnie — kod QR niesie jedno albo drugie, nigdy oba naraz. | Prawidłowy | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capPułapka, którą specyfikacja opisuje wprost, a implementacje i tak w nią wpadają: EPC069-12 ogranicza payload do 331 BAJTÓW, a nie znaków. Ten polski payload ma 312 znaków — z zapasem poniżej każdego limitu znakowego — ale każda litera diakrytyczna kosztuje w UTF-8 dwa bajty: waży 338 bajtów i zostaje odrzucony. | Nieprawidłowy | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)Wzorcowy szwajcarski QR-rachunek: QR-IBAN (identyfikator instytucji 31999, w zakresie 30000-31999) w parze z wymaganą przez niego referencją QRR — 26 cyfr plus cyfra kontrolna w rekurencyjnym modulo 10, a nie mod-97 znany z IBAN-u. Zwróć uwagę na blok „ultimate creditor”: siedem linii, obecnych i całkowicie pustych, dokładnie tak, jak wymagają wytyczne. | Prawidłowy | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceDruga połowa reguły dopasowania: zwykły IBAN (identyfikator instytucji 00791, poza zakresem QR-IID) ZABRANIA referencji QRR i przyjmuje referencję wierzyciela ISO 11649 (SCOR) — RF6518539007547034 — albo żadnej. Ten sam rachunek, inny typ konta, inna referencja: to rozróżnienie decyduje, czy szwajcarska płatność da się zaksięgować. | Prawidłowy | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)Najbardziej brzemienny w skutki błąd formatu szwajcarskiego: QR-IBAN z referencją ISO 11649 (SCOR). Sama referencja jest w pełni poprawna — na tym polega pułapka — ale QR-IBAN wymaga referencji QRR i niczego innego. Bank nie zaksięguje takiej płatności, a werdykt jest taki sam w wytycznych 2.3 i 2.4. | Nieprawidłowy |
Skąd wiemy, że te wyniki są aktualne
Każdy plik w tej bibliotece przechodzi przez walidator serwisu przy każdym buildzie. Oczekiwany wynik podany wyżej potwierdza test automatyczny: gdyby plik przestał odpowiadać temu, co głosi ta strona, build by się wywalił. Dwie odziedziczone fikstury naprawiono w ten sposób przed publikacją: trzy numery IBAN nie przechodziły mod-97, a kilka nazw używało znaków spoza podstawowego zestawu SEPA.