IDR (Intelligent Document Recogniser) automaticky rozpoznává klíčové údaje na PDF faktuře a převádí je na strukturovaná pole v e-faktuře. Která pole se rozpoznávají, závisí na vašem předplatném a konfiguraci.

Při každé konverzi PDF se automaticky rozpoznávají tato pole:

Některé formáty dodavatelů mohou způsobit, že IDR zachytí jiné pole než číslo faktury, například ID transakce místo skutečného čísla faktury. Dobře známým příkladem jsou faktury Meta (Facebook), kde číslo faktury se nachází v dolní části pozdější stránky PDF a ID transakce je rozpoznáno prominentněji. Stejný vzor platí, když IDR místo čísla faktury pÅ™evezme IÄŒO dodavatele nebo číslo objednávky/PO.

To lze pro daný formát dodavatele zlepšit. Rozpoznávání čísla faktury není zákazníkem konfigurovatelné, ale je interně optimalizováno členem týmu podpory prostřednictvím detekce odlehlých hodnot, regulárních výrazů a nápověd pro konkrétního dodavatele nebo formát. Žádná změna roadmapy není nutná; jedná se o cílenou optimalizaci stávající funkcionality. Nahlaste takový případ podpoře — na základě hlášení tým přidá nápovědu specifickou pro dodavatele, aby budoucí faktury v tomto formátu obdržely správné číslo faktury.

S předplatným Professional se rozpoznávají další pole:

IDR rozpoznává data na PDF fakturách a převádí je do standardního formátu data UBL (YYYY-MM-DD). Protože zápisy data se v zemích liší, IDR podle země dodavatele určuje, jak interpretovat nejednoznačná data:

• Spojené státy: MDY (měsíc-den-rok). Datum 03/11 se interpretuje jako 11. březen.
• Všechny ostatní země: DMY (den-měsíc-rok). Datum 03/11 se interpretuje jako 3. listopad.

Pokud automatická detekce země nestačí, lze pro dodavatele přidat konkrétní nápovědu k formátu data prostřednictvím mechanismu hints.

Tip: nesprávně interpretovaná data (například 03/11 jako 11. březen místo 3. listopadu) jsou téměř vždy otázkou rozpoznávání, ne platformy. Platforma vždy zobrazuje datum tak, jak je v UBL.

S předplatným Professional se rozpoznaný IBAN porovnává s verification store: databází dříve ručně ověřených čísel IBAN na dodavatele. Pokud se IBAN na faktuře liší od dříve ověřeného, je to signalizováno. Pomáhá to odhalovat fiktivní faktury nebo změněné bankovní údaje.

Poznámka: podle evropské normy EN16931 slouží IBAN na faktuře především k identifikaci dodavatele, ne jako platební instrukce. Změněný IBAN musí být vždy nejdříve ověřen v master datech vašeho finančního systému před platbou.

Kromě standardních referencí (číslo objednávky, číslo smlouvy, číslo projektu) lze další reference konfigurovat specificky pro dodavatele, například rozpočtové kódy, kódy rozpočtových odpovědných nebo interní reference. Jde o práci na míru nastavenou na bázi pruhových karet.

Rozpoznávání konfigurovatelných referencí používá třívrstvý mechanismus:

1. Regex: validace formátu, aby extrahovaná reference přesně odpovídala očekávanému formátu
2. Outlier detection: statistická detekce odchylek pro nepravděpodobné hodnoty
3. Hints: automaticky generovaná trénovací data na základě oprav týmu QC

Tip: číslo objednávky je nejčastěji používaná reference a většina dodavatelů ho uvádí na faktuře. Pokud dodavatel nemůže vyplnit určité referenční pole ve svém softwaru, málo smyslu ho požadovat. V tom případě použijte číslo objednávky jako primární referenci.

Podle evropské normy EN16931 je reference (buyer reference) povinná na elektronické faktuře; často jde o číslo objednávky nebo jinou referenci příjemce. Odesílatel může do tohoto pole umístit neprávní hodnotu.

eConnect standardně neodhazuje fakturu na základě reference. Faktura nesplňuje základní pravidla evropské normy pouze tehdy, když není přítomna žádná reference. To, zda je faktura odmítnuta z důvodu neznámé nebo neprávní reference, závisí na konfiguraci příjemce: v konkrétní konfiguraci příjemce může být faktura odmítnuta, pokud je reference neznámá. Jde tedy o vlastnost přijímací konfigurace, nikoli standardního zpracování eConnect.

Tip: pokud chcete odmítat faktury s chybějícími nebo neznámými referencemi, nakonfigurujte to přes RBE (Rule Based Enrichment) na přijímacím endpointu.

Číslo faktury (UBL pole cbc:ID, BT-1) je povinné v EN 16931, UBL BIS Billing 3.0 a NLCIUS pro běžné faktury. IDR však zpracovává smísený tok dokumentů: běžné faktury, dobropi-sy, účtenky výdajů a příjetky. Příjetky spadají pod zjednodušený režim fakturace (transakce do ca. 100 Kč včetně DPH), pro který finanční úřad nestanoví číslo faktury jako zákonný požadavek. Odmítnutí kvůli chybějícímu číslu faktury by vylouvalo všechny příjetky a účtenky výdajů ze zpracování.

Proto IDR pipeline automaticky generuje náhradní číslo, když při rozpoznávání nelze z dokumentu extrahovat žádné číslo faktury. Pole cbc:ID (BT-1) je pak vyplněno strukturou:

YYYYMMDDHHmmss-NOTFOUND

Časový razítko je okamžik zpracování pipeline IDR, nikoli datum na dokumentu. Příklad: 20240315143022-NOTFOUND.

Filtraci je možné provádět na dvou úrovních:

1. RBE (Rule Based Enrichment): nakonfigurujte pravidlo, které kontroluje, zda BT-1 (cbc:ID) končí -NOTFOUND. Na základě toho lze dokument zadržet pro ruční kontrolu, přesměrovat do samostatné schránky nebo automaticky odmítnout.
2. Vlastní systémy (ERP/účetní software): přímé vyhledávání řetězce nebo regulární výraz na -NOTFOUND v poli cbc:ID postačí.

S rozpoznáváním řádků se rozpoznávají i jednotlivé řádky faktury: popis, jednotková cena, množství, částka řádku a referenční pole na řádek. Jde o samostatnou funkci, kterou můžete aktivovat sami v Mém prostředí.

Chcete vědět, jak rozpoznávání funguje technicky? Přečtěte si Jak funguje Scan & Rozpoznávání (IDR/OCR)?.