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, číslo objednávky/PO nebo bankovní/platební referenci (například bankovní referenci, IBAN nebo část IBAN/čísla účtu), což vede k nesprávnému číslu faktury směrem do Coda nebo ERP systému. Tato poslední varianta může také způsobit, že dobropis je nesprávně blokován jako duplicitní faktura (viz Duplicitní faktura). Jde o chybu výběru pole v rozpoznávání, odlišnou od správného rozpoznání platební reference jako samostatného pole PaymentID (viz Inkaso a účet G): tam platební reference nepřepisuje číslo faktury, zde je omylem rozpoznána na jeho místě.

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.

Jak funguje rozpoznávání v pozadí (SampleStore)? IDR k tomu používá SampleStore: databázi vzorů rozpoznávání pro každého dodavatele. Proces probíhá ve třech krocích: (1) hledání čísel odpovídajících vzoru RegEx v SampleStore, (2) porovnání s předchozími příklady stejného dodavatele (délka, struktura, pomlčky, tečky, podtržítka, konzistence), (3) samoučící se úprava na základě nových faktur. Podpora po hlášení doplní SampleStore o příklady a případně RegEx.

Krátké nebo jiné číslo místo delšího vzoru s předponou. Pokud faktury dodavatele mají obvykle pevnou předponu a pevnou délku, IDR někdy rozpozná kratší nebo jiné číslo bez této předpony. Je-li vzor (předpona, délka, struktura) z hlášení již jasný, prvním krokem je přímá úprava SampleStore nebo RegEx pro tohoto dodavatele; příklad PDF nebo XML pak slouží jako důkaz, ne jako povinný první krok. Pokud rozpoznávání dříve fungovalo správně a časem se opět stalo chybným, platí stejný přístup: zkontrolovat a upravit SampleStore pro tohoto dodavatele, což není příznak chyby produktu.

Pro šetření je XML z platformy z doručené pošty vhodný soubor: obsahuje stopu rozpoznávání IDR. XML, které si sami exportujete ze svého ERP systému (např. AFAS) poté, co bylo číslo faktury již ručně opraveno, obvykle postrádá tento IDR blok a zobrazuje pouze již opravené číslo — tento soubor pak není vhodný pro analýzu chyby rozpoznávání.

Skrytý nebo průhledný text v PDF (opakované použití šablony). Někteří dodavatelé znovu používají starý PDF faktury jako šablonu pro nové faktury. Stará data nebo čísla faktur mohou zůstat jako neviditelný nebo průhledný zbytkový text ve vrstvě textu PDF. IDR používá hybridní OCR: vedle viditelného obrazu se čte i textová vrstva PDF. Na snímku obrazovky nebo na monitoru vidíte pouze viditelné řádky, ale rozpoznávání vidí celou textovou vrstvu včetně skrytého zbytkového textu. To může být příčinou, když se staré a nové číslo faktury nebo datum v rozpoznávání pletou. Pokud podezříváte tento vzor, vždy si vyžádejte originální PDF: snímek obrazovky nestačí, protože postrádá textovou vrstvu. Poté zkopírujte text ze souboru do editoru prostého textu a zkontrolujte odchylku oproti viditelnému zobrazení.

Vedlejší příznak: faktura chybně označená jako duplikát. Následná faktura může být chybně označena jako duplikát, protože IDR znovu použije nebo porovná nesprávné (skryté) číslo faktury. Jde o důsledek základní chyby rozpoznávání, nikoliv o samostatný problém: nejprve opravte rozpoznávání textové vrstvy, jak je popsáno výše, namísto toho, abyste řešili detekci duplikátů izolovaně (viz Duplicitní faktura).

Varianty vyhledávání: „jiné IČO v XML", „IČO faktura vs XML", „IČO odesílatele se liší", „IČO dodavatele nesprávné v XML", „IČO dodavatele XML jiné než faktura", „ID subjektu odesílatele XML PDF", „AccountingSupplierParty IČO".

Někdy se IČO dodavatele (nebo jiné ID subjektu, jako DIČ) v bloku odesílatele XML liší od toho, co je uvedeno na originálním PDF, nebo rozpoznávání přiřadí fakturu ke špatnému dodavateli. Jde o chybu rozpoznávání pole na identifikátoru dodavatele, stejně jako u částek, měny nebo čísla faktury.

Pozor — není to totéž jako „IČO přečtené jako číslo faktury". V tomto jiném případě (viz výše) je IČO omylem rozpoznáno v poli čísla faktury. Zde jde o ID subjektu přímo v bloku odesílatele, které neodpovídá PDF. Jde o dvě samostatné otázky rozpoznávání.

Co můžete udělat? Neexistuje možnost samoobslužné úpravy XML. Shromážděte originální PDF a přidružené XML (ke stažení u dokumentu v doručené poště) a/nebo ID dokumentu konverzního úkolu a nahlaste to podpoře. Na tomto základě tým upraví rozpoznávání nebo shodu dodavatele. Stejně jako u jiných chyb rozpoznávání se zde neuplatňuje žádná pevná lhůta.

Varianty vyhledávání: „měna nebyla správně rozpoznána", „měna byla nesprávně rozpoznána", „špatná měna IDR", „SEK místo NOK", „currency wrong PDF", „rozpoznávání měny faktura", „PDF měna chyba", „měna přečtena chybně".

Měna je standardně rozpoznávané pole (viz tabulka výše) a spadá pod stejné generické chyby rozpoznávání PDF→XML jako číslo faktury nebo částka: IDR může nesprávně rozpoznat kód měny ISO ve srovnání s PDF (například SEK místo NOK). Nejde o samostatnou funkci ani o izolovaný problém, ale o stejnou otázku rozpoznávání jako u jiných polí.

Co můžete udělat? Nahlaste odchylku podpoře a doložte originální PDF spolu s přidruženým XML (z doručené pošty) nebo ID dokumentu konverzního úkolu. Na tomto základě tým optimalizuje rozpoznávání pro daný formát dodavatele. Stejně jako u jiných chyb rozpoznávání se zde neuplatňuje žádná pevná lhůta.

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

Varianty vyhledávání: "americké datum", "americké datum faktury", "datum dodavatele z USA", "datum faktury USA", "datum faktury MDY", "MDY místo DMY", "formát data Spojené státy", "datum faktury nesprávně rozpoznáno americký dodavatel", "American date format invoice date", "US supplier date format MDY".

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.

Vidíte u dodavatele ze Spojených států datum faktury, které bylo podle vás rozpoznáno nesprávně? Nejprve zkontrolujte toto pravidlo pro danou zemi, než to nahlásíte jako chybu rozpoznávání pole: u amerického dodavatele je 03/11 například 11. březen, ne 3. listopad. Pokud zápis data není vysvětlením, jde o jinou otázku rozpoznávání (viz výše).

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.

Upozornění: číslo objednávky, číslo smlouvy a číslo projektu jsou standardní pole Professional, ale rozpoznávání se aktivuje až po jednorázovém nastavení podporou pro klienta/dodavatele (na základě alespoň 5 vzorových faktur, případně doplněném o regex). Kontaktujte podporu a poskytněte nejlépe vzorovou faktur i.

Získáváte přes API informativní odpověď Order Reference detection skipped as Sample store is empty nebo Contract Reference detection skipped as Sample store is empty? Nejde o chybu zpracování. IDR vyplní tyto reference až když Customer Sample Store pro váš endpoint obsahuje vzorové reference k porovnání. Je-li store prázdný, přeskocí se pouze toto rozpoznávání reference; ostatní pole a funkce se rozpoznávají normálně.

Řešení: poskytněte několik vzorových čísel objednávek nebo referencí smluv (alespoň 3 znaky na vzorek) přesně tak, jak se objevují na fakturách, aby je podpora mohla nakonfigurovat v Customer Sample Store. Poté platí nejprve shoda podle popisku (např. „Your order number“), s regexem jako zálohou. Pro nastavení rozpoznávání PO čísla je též k dispozici Remote Starter přes obchodní tým.

Ne, ne přímo na platformě. Customer Sample Store, formátovací pravidla nebo RegEx pro rozpoznávání čísla objednávky si nespravujete sami; to nastavuje podpora eConnect.

Nepřímo však můžete:

• nechat dodavatele fakturovat s jasným, jednotným formátem referenčního čísla objednávky (viz osvědčený postup níže);
• podělit se o znalost formátu (prefix, pevná délka, struktura) s podporou;
• po neúspěšném rozpoznání poskytnout originální PDF nebo ID dokumentu spolu se správným číslem objednávky, aby podpora mohla aktualizovat Sample Store.

Osvědčený postup pro formát referenčního čísla objednávky na PDF:

• uveďte referenční číslo objednávky pokud možno jednou na faktuře, ne opakovaně na více místech;
• použijte běžný popisek, například Číslo objednávky, PO number, Číslo obj. nebo Your order number;
• oddělte popisek a číslo mezerou nebo interpunkčním znaménkem, například Číslo objednávky: 420000007 místo PO420000007;
• udržujte pevnou strukturu a pokud možno pevné umístění na faktuře.

Viz také Chyby odeslání při blokované nebo zamítnuté faktuře v důsledku nesprávně rozpoznávaného čísla objednávky.

Varianty vyhledávání: "více čísel PO", "více čísel objednávky jedna faktura", "více referencí objednávky PDF", "OrderReference hlavička", "PO na řádku faktury", "rozpoznávání řádků PO", "rozpoznávání více čísel PO".

• Úroveň hlavičky: maximálně jedno číslo objednávky (OrderReference) na hlavičce faktury. Více čísel PO na jednom PDF automaticky nevyplňuje více referencí objednávky hlavičky.
• Úroveň řádku jako text: další čísla PO na PDF mohou skončit v popisu řádku (textový fragment) prostřednictvím rozpoznávání řádků — to samo o sobě není strukturovaná reference řádku objednávky.
• Skutečná reference objednávky na úrovni řádku: pouze pokud má příjemce nastavení na úrovni řádku; není to standardní "více PO → více referencí objednávky".

Neočekávejte automatické spojení více čísel PO s více referencemi objednávky hlavičky. U layoutu s více PO nejprve zkontrolujte nastavení Professional a Sample Store pro jedno PO hlavičky; další čísla PO skončí jako text řádku, ne jako samostatná reference řádku objednávky, pokud si to příjemce sam nenastavil. Viz také Rozpoznávání řádků pro referenční pole na řádek.

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)?.