camt.053.001.08 — entry with no CdtDbtInd
Drugie 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.
camt.053.001.08 — Nieprawidłowy
Drugie 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.
Co pokazuje ten plik
Drugie 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.
| Transakcje | 3 |
|---|---|
| Data w pliku | 2026-02-28 |
Zawarte wady
- CdtDbtIndÉcriture PL-2026-02-0002 : CdtDbtInd (sens débit/crédit) manquant — impossible de déterminer le sens du montant.
- CLBDAvertissement : le solde de clôture (2000.00) ne correspond pas à l'ouverture ± mouvements comptabilisés (4400.00).
Cytowane dosłownie z walidatora, bez parafrazy.
Wszystkie strony, numery IBAN i kwoty poniżej są fikcyjne. IBAN-y są poprawne strukturalnie — przechodzą test mod-97 — ale nie należą do żadnego rzeczywistego rachunku.
Zawartość pliku
<?xml version="1.0" encoding="UTF-8"?>
<!--
ValidateFin sample file — bank statement, camt.053.001.08, BROKEN ON PURPOSE.
The second entry has NO <CdtDbtInd>. It is a debit of 1200.00 (the closing balance
says so: 3000.00 + 500.00 - 1200.00 - 300.00 = 2000.00), but the file never says it.
Two things break at once, and that is the whole lesson:
* CdtDbtInd is MANDATORY (1..1) on ReportEntry — the official XSD rejects the file;
* a parser that quietly defaults a missing direction to CRDT books +1200.00 instead
of -1200.00 and lands 2400.00 away from the truth. The direction of an amount is
never a default; a camt.053 amount is always unsigned and always needs its sign.
All parties and account numbers are fictitious.
Reference page: https://validatefin.com/en/resources/samples/camt053-missing-cdtdbtind
License: CC-BY-4.0
-->
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<BkToCstmrStmt>
<GrpHdr>
<MsgId>CAMT053-NOIND-20260228</MsgId>
<CreDtTm>2026-02-28T19:00:00</CreDtTm>
</GrpHdr>
<Stmt>
<Id>STMT-PL-2026-02</Id>
<LglSeqNb>2</LglSeqNb>
<CreDtTm>2026-02-28T19:00:00</CreDtTm>
<FrToDt>
<FrDtTm>2026-02-01T00:00:00</FrDtTm>
<ToDtTm>2026-02-28T23:59:59</ToDtTm>
</FrToDt>
<Acct>
<Id>
<IBAN>PL61109010140000071219812874</IBAN>
</Id>
<Ccy>EUR</Ccy>
<Nm>Rachunek biezacy</Nm>
<Ownr>
<Nm>Stolarnia Wisla Sp z oo</Nm>
</Ownr>
<Svcr>
<FinInstnId>
<BICFI>WBKPPLPP</BICFI>
</FinInstnId>
</Svcr>
</Acct>
<Bal>
<Tp>
<CdOrPrtry>
<Cd>OPBD</Cd>
</CdOrPrtry>
</Tp>
<Amt Ccy="EUR">3000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2026-02-01</Dt>
</Dt>
</Bal>
<Bal>
<Tp>
<CdOrPrtry>
<Cd>CLBD</Cd>
</CdOrPrtry>
</Tp>
<Amt Ccy="EUR">2000.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Dt>
<Dt>2026-02-28</Dt>
</Dt>
</Bal>
<!-- 1. Credit, correctement signe -->
<Ntry>
<NtryRef>PL-2026-02-0001</NtryRef>
<Amt Ccy="EUR">500.00</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-02-09</Dt>
</BookgDt>
<ValDt>
<Dt>2026-02-09</Dt>
</ValDt>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>RCDT</Cd>
<SubFmlyCd>ESCT</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<AddtlNtryInf>PRZELEW PRZYCHODZACY</AddtlNtryInf>
</Ntry>
<!-- 2. DEFAUT : aucun CdtDbtInd. C'est un DEBIT de 1200.00, le fichier ne le dit pas. -->
<Ntry>
<NtryRef>PL-2026-02-0002</NtryRef>
<Amt Ccy="EUR">1200.00</Amt>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-02-17</Dt>
</BookgDt>
<ValDt>
<Dt>2026-02-17</Dt>
</ValDt>
<BkTxCd>
<Domn>
<Cd>PMNT</Cd>
<Fmly>
<Cd>ICDT</Cd>
<SubFmlyCd>ESCT</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<AddtlNtryInf>PRZELEW WYCHODZACY DOSTAWCA DREWNA</AddtlNtryInf>
</Ntry>
<!-- 3. Debit, correctement signe -->
<Ntry>
<NtryRef>PL-2026-02-0003</NtryRef>
<Amt Ccy="EUR">300.00</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts>
<Cd>BOOK</Cd>
</Sts>
<BookgDt>
<Dt>2026-02-27</Dt>
</BookgDt>
<ValDt>
<Dt>2026-02-27</Dt>
</ValDt>
<BkTxCd>
<Domn>
<Cd>ACMT</Cd>
<Fmly>
<Cd>MDOP</Cd>
<SubFmlyCd>CHRG</SubFmlyCd>
</Fmly>
</Domn>
</BkTxCd>
<AddtlNtryInf>OPLATY BANKOWE</AddtlNtryInf>
</Ntry>
</Stmt>
</BkToCstmrStmt>
</Document>
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.
Wyciąg bankowy (camt.052 / 053 / 054)
- camt.053.001.02 — valid statement
- camt.053.001.08 — valid statement
- camt.053 — unsupported namespace
- camt.053.001.06 — missing Stmt element
- camt.053.001.11 — valid statement
- camt.053.001.08 — three accounts in one file
- camt.053.001.10 — fully detailed entries
- camt.053.001.08 — closing balance does not reconcile
- camt.052.001.08 — valid intraday report
- camt.054.001.08 — valid debit/credit notification
- camt.053.001.08 — 220 entries, valid