At first, the validation looked good enough. The model returned something, a few checks passed, and if the numbers roughly matched, the export moved on.Na prvních testech jsem měl pocit, že validace funguje dobře. Model něco vrátil, pár kontrol proběhlo a pokud čísla přibližně seděla, export pokračoval dál.
But the more real documents you see, the more obvious it becomes that the accounting world works very differently from an AI conference demo.Jenže čím víc reálných dokumentů člověk vidí, tím víc mu dochází, že účetní svět funguje úplně jinak než AI demo na konferenci.
In accounting, there is no such thing as almost correct. It either matches exactly, to the cent, ideally to the smallest currency unit, or it is a problem.V účetnictví totiž neexistuje skoro správně. Buď to sedí úplně, na korunu, ideálně na haléř, nebo je problém.
Why one validation layer is not enoughProč nestačí jedna validační vrstva
That is where one important lesson appeared. If the validation logic uses the same assumptions and the same calculation base as the original output, the system can easily make a mistake twice and then congratulate itself for being consistent.A právě tehdy mi došlo něco důležitého. Pokud validační logika používá stejný základ jako původní výpočet, systém může velmi snadno udělat chybu dvakrát a pak se sám pochválit, že je konzistentní.
- The calculation makes an error.Výpočet udělá chybu.
- The validation repeats the same error.Validace zopakuje stejnou chybu.
- The system reports: "Everything matches."Systém oznámí: "Všechno sedí."
Except it does not.Jenže nesedí.
So a second control layer was added, built to work independently from the first one. The goal is not only to verify the result, but to verify it in a different way.A tak vznikla druhá vrstva kontrol, která funguje úplně nezávisle na té první. Neověřuji pouze výsledek. Ověřuji ho jiným způsobem.
Once both layers reach the same conclusion independently, the chance that the data actually makes sense in production grows much more.Ve chvíli, kdy obě vrstvy dojdou ke stejnému výsledku nezávisle na sobě, výrazně roste šance, že data dávají smysl i v reálném provozu.
How LLM validation works on VAT and financial documentsJak vypadá validace LLM u DPH a finančních dokumentů
The same principle gradually extended to LLM outputs. If the model returns a price without VAT, a price with VAT, and a VAT rate, I do not assume the tuple is correct just because the model produced all three fields.To samé začalo postupně vznikat i kolem LLM výstupů. Pokud model vrátí cenu bez DPH, cenu s DPH a sazbu DPH, nespoléhám na to, že je výsledek automaticky správně jen proto, že model vrátil všechna tři pole.
Instead, the system starts recomputing missing values, checking subtotals, verifying VAT rates, testing field relationships, and looking for contradictions across the full document.Naopak. Systém začne dopočítávat chybějící hodnoty, porovnávat mezisoučty, kontrolovat sazby DPH, ověřovat vztahy mezi poli a hledat rozpory napříč celým dokumentem.
That is the point where LLM validation stops being a schema check and becomes real document logic. The output must not only look structured. It must satisfy financial rules.Právě tam se z validace LLM přestává stávat jen kontrola schématu a začíná skutečná dokumentová logika. Výstup nestačí jen strukturovat. Musí projít finančními pravidly.
Rounding, cents, and hidden accounting mathZaokrouhlování, haléře a skrytá matematika účetních systémů
Sometimes the difference is tiny, for example -0.01 to +0.01.V některých případech rozdíl vyjde třeba -1 až +1 haléř.
Then another problem starts. Is it an error or just rounding? And if it is rounding, where exactly was it introduced: on a single line item, in the VAT subtotal, or only at the final aggregation?A teď přichází další problém. Je to chyba? Nebo jen zaokrouhlení? A pokud zaokrouhlení, vzniklo na položce, v součtu DPH, nebo až v celkové agregaci?
At that point you are no longer just processing a document. You are debugging the math of someone else's accounting software.Najednou člověk nezpracovává jen dokument. Začíná debugovat matematiku cizích účetních systémů.
This is one reason why invoice AI and accounting automation need explicit tolerance logic, traceable calculations, and a clear explanation of why a value was accepted, adjusted, or blocked.I proto potřebuje AI nad fakturami a automatizace účetnictví explicitní toleranční logiku, dohledatelné výpočty a jasné vysvětlení, proč byla hodnota přijata, upravena nebo zablokována.
Why total amount is not enoughProč nestačí, že sedí celková částka
Another layer came with line-item validation. It is not enough to say: "the total matches."Další vrstva přišla u validace položek. Nestačí totiž jen říct: "sedí celková částka."
A robust production system also needs line items, VAT rates, subtotals, quantities, unit prices, field dependencies, and ideally the whole document to match across several independent checks.Produkční systém potřebuje, aby seděly jednotlivé položky, sazby DPH, mezisoučty, množství, ceny, vazby mezi poli a ideálně i celý dokument křížem přes několik různých kontrol.
Only once all of that passes can the export continue. If something does not match, the output is blocked and the issue gets handled explicitly.Teprve když všechno projde, může export pokračovat dál. Pokud něco nesedí, výstup se zablokuje a řeší se chyba.
That is a critical difference between demo AI and a production AI system: production must know when not to continue.A právě tam člověk začne chápat rozdíl mezi AI demem a produkčním AI systémem: produkce musí vědět, kdy dál nepokračovat.
Demo AI versus production AIRozdíl mezi AI demem a produkčním AI systémem
A demo needs to return something. A production system needs a high level of confidence that the output actually makes sense.Demo potřebuje něco vrátit. Produkční systém potřebuje mít vysokou jistotu, že výstup skutečně dává smysl.
Once AI starts generating accounting entries, VAT outputs, control reports, summary reports, or financial exports, the problem is no longer just prompting.Ve chvíli, kdy AI začne generovat účetnictví, DPH, kontrolní hlášení, souhrnná hlášení nebo finanční exporty, už nejde jen o prompting.
- Deterministic validationDeterministic validation
- Cross-checks between independent calculationsCross-checky mezi nezávislými výpočty
- Blocking rules when confidence dropsBlocking rules při poklesu jistoty
- Auditability of every decisionAuditovatelnost každého rozhodnutí
- Defense in depth logic across the whole workflowDefense-in-depth logika napříč celým workflow
That is where many AI projects begin discovering that reality is much less elegant than the first LinkedIn demo.A upřímně? Právě tam podle mě většina AI projektů začíná zjišťovat, že realita bývá výrazně méně elegantní než první demo na LinkedInu.
Production AI needs certainty, not just a nice answerProdukční AI potřebuje jistotu, ne jen hezký výstup
As long as AI only returns something that looks plausible, the whole system appears simple. The moment the output must survive accounting, VAT, and financial operations, you realize that the key factor is not only model quality. It is validation quality.Dokud AI jen něco hezky vrací, vypadá všechno jednoduše. Jakmile ale má výstup obstát v účetnictví, DPH a finančním provozu, začne být jasné, že klíčem není jen kvalita modelu, ale hlavně kvalita validace.
Because with financial data, it is not enough for the answer to look good. It has to be correct, explainable, and ideally verified in several independent ways before production trusts it.Protože u finančních dat nestačí, že AI odpověď vypadá dobře. Musí být správně, ověřitelně a ideálně potvrzená několika nezávislými způsoby, než jí produkce začne věřit.