Welke velden de IDR herkent op een PDF-factuur: standaard, Professional en configureerbare referenties.
De IDR (Intelligent Document Recogniser) herkent automatisch de belangrijkste gegevens op een PDF-factuur en zet ze om naar gestructureerde velden in de e-factuur. Welke velden worden herkend, hangt af van je abonnement en de configuratie.
Bij elke PDF-conversie worden de volgende velden automatisch herkend:
Met het Professional-abonnement worden aanvullende velden herkend:
Zoekvarianten: "Meta factuurnummer", "Facebook factuur transactie-id", "factuurnummer Meta niet herkend", "Meta invoice number transaction id", "factuurnummer pagina 2 Meta", "transactie-id als factuurnummer", "KvK als factuurnummer", "KvK-nummer factuurnummer", "factuurnummer is KvK", "verkeerd factuurnummer KvK", "factuurnummer niet juist", "KvK gelezen als factuurnummer", "chamber of commerce as invoice number", "factuurnummer niet goed gelezen", "verkeerd factuurnummer OCR", "factuurnummer met schuine streep", "factuurnummer backslash", "twee delen factuurnummer", "inkoopordernummer als factuurnummer", "ordernummer als factuurnummer", "PO number as invoice number", "onjuist factuurnummer", "foutief factuurnummer", "factuurnummer niet goed overgenomen", "factuurnummer afgekapt", "verkeerd factuurnummer IDR", "SampleStore factuurnummer", "RegEx factuurnummerherkenning", "herkenning verbeteren leverancier", "factuurnummer half herkend", "verkeerde factuurnummer overgenomen", "factuurnummerherkenning verbeterd", "bijlage juist factuurnummer", "onjuist factuurnummer leverancier".
Bij sommige leveranciersformaten kan de IDR een ander veld dan het factuurnummer overnemen, of het herkende factuurnummer wijkt af van het formaat op de PDF (bijvoorbeeld door een schuine streep, backslash of een factuurnummer dat uit twee delen bestaat). Voorbeelden: een transactie-id in plaats van het eigenlijke factuurnummer (bekend bij Meta/Facebook-facturen, waarbij het factuurnummer onderaan een latere pagina staat, typisch pagina 2, en het transactie-id prominenter wordt herkend), het KvK-nummer van de leverancier in plaats van het echte factuurnummer, of een inkoopordernummer/ordernummer (PO) in plaats van het echte factuurnummer. Deze laatste variant speelt ook mee wanneer een creditnota onterecht als dubbele factuur wordt geblokkeerd (zie Hoe wordt een dubbele factuur herkend?).
Dit is voor het betreffende formaat verbeterbaar. De herkenning van het factuurnummer is niet door de klant configureerbaar, maar wordt intern geoptimaliseerd door een supportmedewerker via outlier detection, regex en hints per leverancier of formaat. Er is geen roadmap-aanpassing nodig; het betreft een gerichte optimalisatie van de bestaande functionaliteit.
Hoe werkt de herkenning achter de schermen (SampleStore)? Voor gewone factuurnummerherkenning gebruikt de IDR de SampleStore: een database met herkenningspatronen per leverancier. Het proces verloopt in drie stappen: (1) het systeem zoekt nummers die matchen met een RegEx-patroon in de SampleStore, (2) gevonden nummers worden vergeleken met eerdere voorbeelden van dezelfde leverancier (lengte, opbouw, streepjes, punten, underscores, consistentie), (3) het systeem leert zelf bij op basis van nieuwe facturen. Meld je een afwijkend of onvolledig factuurnummer, dan controleert support de SampleStore voor die leverancier en vult deze aan met voorbeelden en eventueel een RegEx zodat het volledige patroon matcht. Is de fix eenmaal doorgevoerd, dan verwacht je bij toekomstige facturen van die leverancier een betere herkenning.
Verborgen of transparante tekst in de PDF (sjabloon-hergebruik). Sommige leveranciers hergebruiken een oude factuur-PDF als sjabloon voor nieuwe facturen. Daarbij kunnen oude datums of factuurnummers als onzichtbare of transparante resttekst in de PDF-tekstlaag achterblijven. De IDR gebruikt hybride OCR: naast het zichtbare beeld wordt ook de tekstlaag van de PDF gelezen. Op een screenshot of op het scherm zie je alleen de zichtbare regels, maar de herkenning ziet de volledige tekstlaag inclusief verborgen resttekst. Dit kan de oorzaak zijn wanneer een oud en een nieuw factuurnummer of datum door elkaar heen lopen in de herkenning. Vermoed je dit patroon, vraag dan altijd de originele PDF op: een screenshot volstaat niet, omdat daarin de tekstlaag ontbreekt. Kopieer vervolgens de tekst uit het bestand naar een platte-tekstverwerker om de afwijking ten opzichte van de zichtbare weergave te controleren.
Geen handmatige aanpassing op het platform. Naast dat de herkenning zelf niet door de klant is te configureren, kan het factuurnummer op een document in eConnect ook niet handmatig worden overschreven of gewijzigd. Bij spoed: download het document en corrigeer het factuurnummer in het doelsysteem of ERP. Meld de afwijking daarnaast altijd bij support (zie stappen hieronder), zodat de herkenning structureel kan worden verbeterd.
Wat kun je doen?
Zoekvarianten: "valuta niet goed herkend", "valuta verkeerd herkend", "verkeerde valuta IDR", "SEK in plaats van NOK", "SEK i.p.v. NOK", "currency wrong PDF", "currency misread invoice", "valutaherkenning factuur", "PDF valuta fout", "valuta verkeerd gelezen".
De valuta is een standaard herkend veld (zie tabel hierboven) en valt onder dezelfde generieke PDF→XML-herkenningsfouten als factuurnummer of bedrag: de IDR kan de ISO-valutacode verkeerd herkennen ten opzichte van de PDF (bijvoorbeeld SEK in plaats van NOK). Dit is geen aparte functionaliteit en geen op zichzelf staand probleem, maar dezelfde herkenningskwestie als bij andere velden.
Wat kun je doen? Meld de afwijking bij support en lever de originele PDF plus de bijbehorende XML (uit Postvak IN) aan, of het Document-ID van de conversietaak. Op basis daarvan optimaliseert het team de herkenning voor het betreffende leveranciersformaat. Net als bij andere herkenningsfouten geldt hier geen harde doorlooptijd-toezegging.
De IDR herkent datums op PDF-facturen en converteert ze naar het standaard UBL-datumformaat (YYYY-MM-DD). Omdat datumnotaties per land verschillen, bepaalt de IDR aan de hand van het land van de leverancier hoe ambigue datums worden geïnterpreteerd:
MDY (maand-dag-jaar). De datum 03/11 wordt geïnterpreteerd als 11 maart.DMY (dag-maand-jaar). De datum 03/11 wordt geïnterpreteerd als 3 november.Als de automatische landdetectie niet volstaat, kan per leverancier via het hint-mechanisme een specifieke aanwijzing voor de datumopmaak worden toegevoegd.
Tip: verkeerd geïnterpreteerde datums (bijvoorbeeld 03/11 als 11 maart in plaats van 3 november) zijn vrijwel altijd een herkenningskwestie, geen platformprobleem. Het platform toont de datum altijd zoals deze in de UBL staat.
Bij het Professional-abonnement wordt het herkende IBAN vergeleken met de verification store: een database van eerder handmatig gevalideerde IBAN-nummers per leverancier. Als het IBAN op de factuur afwijkt van wat eerder is geverifieerd, wordt dit gesignaleerd. Dit helpt bij het detecteren van spookfacturen of gewijzigde bankgegevens.
Let op: het IBAN op een factuur dient volgens de Europese norm EN16931 primair ter identificatie van de leverancier, niet als betaalinstructie. Een gewijzigd IBAN moet altijd eerst worden gevalideerd in de stamgegevens van je financiële systeem voordat erop wordt betaald.
Naast de standaard referenties (ordernummer, contractnummer, projectnummer) kunnen andere referenties per leverancier specifiek worden geconfigureerd. Denk aan budgetcodes, budgethouderscodes of interne referenties. Dit is maatwerk dat op strippenkaartbasis wordt ingericht.
De herkenning van configureerbare referenties maakt gebruik van een drielaags mechanisme:
Tip: het inkoopordernummer is de meest gebruikte referentie en wordt door de meeste leveranciers op de factuur vermeld. Als een leverancier een bepaald referentieveld niet in zijn software kan invullen, heeft het weinig zin om het te vragen. Gebruik in dat geval het inkoopordernummer als primaire referentie.
Let op: inkoopordernummer, contractnummer en projectnummer zijn Professional-standaardvelden, maar herkenning slaat pas aan na een eenmalige support-inrichting per klant/leverancier (op basis van minimaal 5 voorbeeldfacturen, eventueel aangevuld met een regex). Neem contact op met support en lever bij voorkeur een voorbeeldfactuur aan.
Krijg je via de API de informatieve response Order Reference detection skipped as Sample store is empty of Contract Reference detection skipped as Sample store is empty? Dit is geen verwerkingsfout. De IDR vult deze referenties pas wanneer de Customer Sample Store voor jouw endpoint voorbeeldreferenties bevat om tegen te matchen. Is de store leeg, dan wordt alleen die referentiedetectie overgeslagen; overige velden en features worden gewoon herkend.
Oplossen: lever enkele voorbeeld-ordernummers of contractreferenties aan (minimaal 3 tekens per voorbeeld) zoals ze op de facturen staan, zodat support ze in de Customer Sample Store kan configureren. Daarna geldt eerst een label-match (bijvoorbeeld "Your order number"), met regex als fallback. Voor de inrichting van PO-nummerherkenning is ook een Remote Starter beschikbaar via sales.
-NOTFOUND)Zoekvarianten: "NOTFOUND", "NOTFOUND achter factuurnummer", "factuurnummer NOTFOUND", "wat betekent NOTFOUND", "NOTFOUND inlezen", "surrogaat factuurnummer", "gegenereerd factuurnummer", "geen factuurnummer gevonden PDF", "YYYYMMDDHHmmss-NOTFOUND", "factuurnummer eindigt op NOTFOUND".
Het factuurnummer (UBL-veld cbc:ID, BT-1) is verplicht in EN 16931, UBL BIS Billing 3.0 en NLCIUS voor reguliere facturen. De IDR verwerkt echter een gemengde documentstroom: reguliere facturen, creditnota's, declaraties én bonnetjes. Bonnetjes vallen onder het vereenvoudigde factuurregime (transacties tot ca. € 100 inclusief BTW), waarvoor de Belastingdienst geen factuurnummer als wettelijke eis stelt. Afwijzen bij een ontbrekend factuurnummer zou alle bonnetjes en declaraties uit de verwerking halen.
Daarom genereert de IDR-pipeline automatisch een surrogaatnummer wanneer bij herkenning geen factuurnummer uit het document kan worden geëxtraheerd. Het veld cbc:ID (BT-1) wordt dan gevuld met de structuur:
YYYYMMDDHHmmss-NOTFOUND
Het tijdstip is het moment van verwerking door de IDR-pipeline, niet de datum op het document zelf. Voorbeeld: 20240315143022-NOTFOUND. De getoonde waarde is een eConnect-markering, geen leverancier-factuurnummer.
Filtratie is op twee niveaus mogelijk:
cbc:ID) eindigt op -NOTFOUND. Op basis daarvan kan het document worden tegengehouden voor handmatige beoordeling, omgeleid naar een apart postvak, of automatisch afgekeurd.-NOTFOUND in het cbc:ID-veld is voldoende.Zie je een
-NOTFOUND-nummer terwijl je zeker weet dat het factuurnummer wél leesbaar op de PDF stond? Meld dit bij support met de originele PDF en XML, zodat de herkenning kan worden onderzocht.
Met regelherkenning worden ook de individuele factuurregels herkend: omschrijving, stuksprijs, hoeveelheid, regelbedrag en referentievelden per regel. Dit is een aparte feature die je zelf kunt activeren via Mijn Omgeving.
Bij het Professional-abonnement worden aanvullend het inkoopordernummer, contractnummer, projectnummer, buyer reference, G-rekening IBAN en gestructureerde betaalkenmerken (zoals het Belgische OGM) herkend. Deze velden worden bij het standaardabonnement niet automatisch uit de PDF gehaald.
Meld de fout bij support zodat het eConnect-team de herkenning voor deze leverancier kan verbeteren. Elke correctie wordt als trainingsdata teruggevoerd naar de IDR, waardoor vergelijkbare fouten in de toekomst automatisch worden voorkomen. Het systeem leert continu bij.
Ja, naast de standaard referenties kunnen op maatwerkbasis andere referenties per leverancier worden geconfigureerd, zoals budgetcodes of interne referenties. Dit wordt ingericht op strippenkaartbasis door het eConnect-team en maakt gebruik van formaatvalidatie, statistische afwijkingsdetectie en automatische trainingsdata.
Benieuwd hoe de herkenning technisch werkt? Lees Hoe werkt Scan & Herken (IDR/OCR)?.
Bekijk je conversietaken