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:

Extra herkenning start niet automatisch na upgrade naar Professional. Zie je na een upgrade een leeg ordernummer, projectnummer, contractnummer of geen factuurregels? Dit is enablement, geen herkenningsdefect. Factuurregelherkenning zet je zelf aan via Mijn Omgeving (organisatie-instellingen). Ordernummer-, project- en contractnummerherkenning vragen een eenmalige support-inrichting (Customer Sample Store) per klant/leverancier, onafhankelijk per ontvangende organisatie; het land van de ontvanger of leverancier speelt hierbij geen rol.

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", "betalingskenmerk als factuurnummer", "bankreferentie als factuurnummer", "banknummer als factuurnummer", "onjuist factuurnummer naar Coda", "onjuist factuurnummer naar ERP", "kort nummer i.p.v. factuurnummer", "verkeerd kort nummer herkend", "factuurnummer prefix niet herkend", "herkenning was goed nu weer fout", "platform-XML Postvak IN", "AFAS-export geen IDR", "factuurnummer nergens op de factuur te vinden", "onzichtbaar factuurnummer", "vreemde herkenning factuurnummer", "factuurnummer met slash ervoor", "leading slash factuurnummer", "/nummer i.p.v. nummer", "extra teken voor factuurnummer", "voorloopteken factuurnummer", "factuurnummer met leading special char", "multi-part factuurnummer", "deel na slash weglaten", "leading slash meegenomen", "IBAN als factuurnummer", "deel van IBAN als factuurnummer", "IBAN gelezen als factuurnummer", "klantnummer als factuurnummer", "klantnummer herkend als factuurnummer", "debiteurnummer als factuurnummer", "debiteurnummer als ID in de lijst", "customer number as invoice number", "XML-factuurnummer is PDF-debiteurnummer".

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, een inkoopordernummer/ordernummer (PO) in plaats van het echte factuurnummer, een klant- of debiteurnummer in plaats van het echte factuurnummer (het XML-factuurnummer komt dan overeen met het debiteurnummer op de PDF; bij meerdere klanten van dezelfde leverancier verhelpt één SampleStore-aanpassing voor die leverancier het probleem voor alle klanten), of een bank-/betalingskenmerk (bijvoorbeeld een bankreferentie, het IBAN of een deel van het IBAN/rekeningnummerfragment) in plaats van het echte factuurnummer, met als downstream-gevolg een onjuist factuurnummer richting Coda of het ERP-systeem. Deze laatste variant speelt ook mee wanneer een creditnota onterecht als dubbele factuur wordt geblokkeerd (zie Hoe wordt een dubbele factuur herkend?). Dit is een veldkeuze-fout van de herkenning en staat los van de correcte herkenning van een betalingskenmerk als apart PaymentID-veld (zie Incasso & G-rekening): daar overschrijft het betalingskenmerk het factuurnummer niet, hier wordt het per ongeluk in de plaats van het factuurnummer 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. Herkenning baseert steeds op geïsoleerde beoordeling van het PDF-document zelf; context van afzender of ontvanger blijft daarbuiten, zodat een aanpassing voor de ene leverancier de herkenning bij andere klanten van diezelfde leverancier niet kan schaden.

Spaties en variabele klantnaam in het factuurnummer. Spaties worden standaard uit het herkende factuurnummer verwijderd (normalisatie) -- dit is verwacht gedrag, geen fout. Bevat het factuurnummerveld van een leverancier daarnaast een variabele klant- of afnemernaam naast een stabiel (doorgaans numeriek) deel, dan leert de SampleStore alleen het stabiele deel aan. De volledige string inclusief klantnaam wordt niet als standaardpad opgenomen: dat zou de herkenning bij andere afnemers van dezelfde leverancier kunnen verstoren.

Kort of ander nummer in plaats van een langer prefix-patroon. Bij een leverancier waarvan de facturen normaal een vast voorvoegsel en een vaste lengte hebben, herkent de IDR soms een korter of ander nummer zonder dat voorvoegsel. Is dat patroon (voorvoegsel, lengte, opbouw) al duidelijk uit de melding, dan is de eerste stap direct de SampleStore of RegEx voor die leverancier bijstellen; een PDF- of XML-voorbeeld is dan bewijsmateriaal, geen verplichte eerste stap. Werkte de herkenning eerder al goed en is deze na verloop van tijd opnieuw fout, dan geldt dezelfde aanpak: de SampleStore voor die leverancier opnieuw controleren en bijstellen, geen aanwijzing voor een productfout.

Omgekeerde richting: extra teken of deel te veel meegenomen. Andersom komt ook voor: een voorloopteken zoals een schuine streep vóór het echte nummer, of bij een factuurnummer dat uit meerdere delen bestaat een deel na een schuine streep dat wordt meegenomen terwijl het niet bij het factuurnummer hoort. Ook hier is de eerste stap de SampleStore of RegEx voor die leverancier bijstellen, zodat lengte en welke tekens wel of niet meetellen kloppen; bij een factuurnummer met meerdere delen kan support specificeren welk deel wel en welk deel niet wordt overgenomen. Dit is dezelfde SampleStore-aanpak als bij een afgekapt nummer, maar dan in de omgekeerde foutrichting -- geen productfout, een leverancierspecifieke bijstelling.

Gewenst nummer middenin een aaneengesloten string. Bij een duidelijk scheidingsteken (schuine streep, streepje, spatie of een vast voorvoegsel-patroon) is bijstellen via de SampleStore of RegEx meestal goed te doen. Ontbreekt zo'n scheidingsteken en staat het echte factuurnummer middenin een aaneengesloten label-plus-nummer-string, dan is de eerste stap nog steeds dezelfde SampleStore- of RegEx-bijstelling voor die leverancier, maar zonder betrouwbaar scheidingsteken is het resultaat niet gegarandeerd. Support mag dit zo benoemen: een bijstellingspoging, geen harde toezegging op een sluitende fix.

Spaties en variabele klantnaam in het factuurnummer. Spaties worden bij herkenning van het factuurnummer standaard verwijderd (genormaliseerd); wijkt de PDF-weergave met spaties af van het herkende nummer zonder spaties, dan is dat verwacht gedrag, geen fout. Bevat het factuurnummerveld daarnaast een variabele klant- of afnemernaam naast een stabiel deel (bijvoorbeeld een nummer of jaartal), dan leert de SampleStore alleen dat stabiele deel aan. De naamreeks wordt bewust niet meegenomen: herkenning blijft gebaseerd op de geïsoleerde beoordeling van de PDF, los van wie de ontvanger is, zodat een aanpassing voor één klant de herkenning bij andere klanten van dezelfde leverancier niet verstoort. Een volledige string inclusief klantnaam opnemen in de SampleStore is daarom geen standaardoplossing.

Voor onderzoek is het platform-XML uit Postvak IN het bruikbare bestand: dat bevat het IDR-herkenningsspoor. Een XML die je zelf exporteert via je ERP-systeem (bijvoorbeeld AFAS) nadat het factuurnummer al handmatig is gecorrigeerd, mist doorgaans dat IDR-blok en toont alleen het al gecorrigeerde nummer -- dat bestand is dan niet geschikt om de herkenningsfout te analyseren.

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. Leveren de PDF-tekstlaag en de beeld-OCR allebei een kandidaat-factuurnummer op, dan krijgt de tekstlaag voorrang: 1-op-1 tekst is betrouwbaarder dan OCR uit het beeld. Dit kan de oorzaak zijn wanneer een oud en een nieuw factuurnummer of datum door elkaar heen lopen in de herkenning; klanten melden dit soms als "factuurnummer nergens op de factuur te vinden" of "onzichtbaar factuurnummer", omdat op het scherm geen match zichtbaar is. 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. Bij bevestigde verborgen tekstlagen is een tijdelijke workaround mogelijk: de PDF printen naar een bestand als afbeelding, zodat de lagen worden platgemaakt en alleen de zichtbare inhoud overblijft voor OCR.

Secundair symptoom: onterechte dubbele factuur. Een volgende factuur kan hierdoor onterecht als dubbel worden gemarkeerd, omdat de IDR een verkeerd (verborgen) factuurnummer hergebruikt of matcht. Dit is een gevolg van de onderliggende herkenningsfout, geen apart probleem: eerst de tekstlaag-herkenning corrigeren zoals hierboven beschreven, niet los alleen de dubbeldetectie behandelen (zie Hoe wordt een dubbele factuur herkend?).

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?

1. Open het document in Postvak IN en verzamel het Document-ID van de betrokken conversie(s) plus het factuurnummer zoals dat op de latere pagina staat (minimaal één voorbeeld), of download de originele PDF en bijbehorende XML
2. Meld dit bij support (Feedback PDF-conversion)
3. Op basis van de melding voegt het team een leveranciersspecifieke aanwijzing toe, waarna toekomstige facturen van dat formaat het juiste factuurnummer krijgen. Is de verbetering al via een release doorgevoerd, dan volstaat een korte melding dat dit is meegenomen; er is geen harde garantie op herverwerking van al verwerkte documenten zonder heraanbieding.

Zoekvarianten: "ander KvK-nummer in de XML", "KvK-nummer factuur vs XML", "sender KvK wijkt af", "afzender KvK verkeerd in XML", "leverancier KvK XML anders dan factuur", "party-id afzender XML PDF", "AccountingSupplierParty KvK".

Soms wijkt het KvK-nummer (of een ander party-id, zoals BTW-nummer) van de leverancier in het afzenderblok van de XML af van wat er op de originele PDF staat, of matcht de herkenning met de verkeerde leverancier. Dit is een veldherkenningsfout op de leverancier-identifier, net als bij bedragen, valuta of factuurnummer.

Let op — niet hetzelfde als "KvK gelezen als factuurnummer". Bij die laatste casus (zie hierboven) wordt het KvK-nummer per ongeluk in het factuurnummer-veld herkend. Hier gaat het om het party-id in het afzenderblok zelf, dat niet overeenkomt met de PDF. Beide zijn losse herkenningskwesties.

Wat kun je doen? Er is geen zelf-service-optie om de XML aan te passen. Verzamel de originele PDF en de bijbehorende XML (te downloaden bij het document in Postvak IN) en/of het Document-ID van de conversietaak, en meld dit bij support (Feedback PDF-conversion). Het team past op basis daarvan de herkenning of de leveranciersmatch aan. Net als bij andere herkenningsfouten geldt hier geen harde doorlooptijd- of fix-garantie.

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", "munteenheid", "foute munteenheid", "munteenheid verkeerd herkend", "munteenheid OCR", "OCR munteenheid", "OCR valuta", "CZK", "Kč", "Koruna", "Tsjechische koruna", "EUR i.p.v. CZK", "EUR in plaats van Kč", "EUR i.p.v. Koruna".

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 EUR in plaats van Kč/CZK, of SEK in plaats van NOK). Dit is geen aparte functionaliteit en geen op zichzelf staand probleem, maar dezelfde herkenningskwestie als bij andere velden. Klantterm "OCR" is hierbij een zoekwoord voor documentherkenning/IDR; de productnaam blijft IDR/PDF-herkenning.

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.

Zoekvarianten: "Amerikaanse datum", "Amerikaanse datum factuurdatum", "US leverancier datum", "USA factuurdatum", "MDY factuurdatum", "MDY i.p.v. DMY", "datumformaat Verenigde Staten", "factuurdatum niet goed herkend Amerikaanse leverancier", "American date format invoice date", "US supplier date format MDY".

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:

• Verenigde Staten: MDY (maand-dag-jaar). De datum 03/11 wordt geïnterpreteerd als 11 maart.
• Alle overige landen: DMY (dag-maand-jaar). De datum 03/11 wordt geïnterpreteerd als 3 november.

Zie je bij een leverancier uit de Verenigde Staten een factuurdatum die volgens jou verkeerd is herkend? Controleer eerst deze landregel voordat je dit als een veldherkenningsfout meldt: bij een Amerikaanse leverancier is 03/11 bijvoorbeeld 11 maart, niet 3 november. Als de datumnotatie niet de verklaring is, gaat het om een andere herkenningskwestie (zie hierboven).

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:

1. Regex: formaatvalidatie om te garanderen dat de geëxtraheerde referentie exact voldoet aan het verwachte formaat
2. Outlier detection: statistische afwijkingsdetectie die onwaarschijnlijke waarden afvangt
3. Hints: automatisch gegenereerde trainingsdata op basis van correcties door het QC-team

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.

Zoekvarianten: "inkoopordernummerrange", "prefix inkoopnummer", "langer ordernummer herkenning", "PO prefix", "reeks niet herkend", "herkenning bijwerken formaatwijziging".

Bestaande PDF/IDR-inkoopordernummerherkenning is gebonden aan het ingerichte patroon (Customer Sample Store + eventueel regex/reeks). Krijgt het ordernummer bij een leverancier een vast prefix en/of wordt het langer, dan volgt de bestaande herkenning dat niet vanzelf. Support werkt het patroon bij; er is geen selfservice-optie in het portaal om dit zelf aan te passen.

Lever vóór de inrichting aan:

• het exacte nieuwe formaat: prefix vast aan de rest van het nummer of met een scheidingsteken, de lengte, en eventuele startcijfers of reeksen;
• voorbeeld-PDF's van het nieuwe formaat.

Dit geldt voor IDR/PDF-herkenning. De native e-factuur OrderReference (rechtstreeks in de UBL, zonder IDR-conversie) is een apart spoor.

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.

Nee, niet direct in het platform. Je beheert de Customer Sample Store, de opmaakregels of de RegEx voor ordernummerherkenning niet zelf; dit richt eConnect-support in.

Wel indirect, door:

• leveranciers te laten factureren met een duidelijke, uniforme orderreferentie-opmaak (zie best practice hieronder);
• formatkennis (prefix, vaste lengte, structuur) met support te delen;
• bij een mislukte herkenning de originele PDF of het Document-ID plus het juiste ordernummer aan te leveren, zodat support de Sample Store kan bijwerken.

Best practice orderreferentie-opmaak op de PDF:

• vermeld de orderreferentie bij voorkeur éénmaal op de factuur, niet herhaald op meerdere plekken;
• gebruik een gebruikelijk label, bijvoorbeeld Ordernummer, PO-nummer, Inkoopordernummer of Your order number;
• scheid label en nummer met een spatie of leesteken, bijvoorbeeld Ordernummer: 420000007 in plaats van PO420000007;
• houd een vaste structuur en bij voorkeur een vaste plek op de factuur aan.

Zie ook Foutmeldingen bij insturen bij een geblokkeerde of afgekeurde factuur door een verkeerd herkend ordernummer.

Zoekvarianten: "meerdere PO-nummers", "meerdere inkoopordernummers één factuur", "meerdere orderreferenties PDF", "OrderReferentieNummer kop", "PO op factuurregel", "regelherkenning PO", "meerdere PO-nummers herkenning".

• Kopniveau: maximaal één inkoopordernummer (OrderReference) op de factuurkop. Meerdere PO-nummers op één PDF vullen niet automatisch meerdere kop-orderreferenties.
• Regelniveau als tekst: extra PO-nummers op de PDF kunnen via regelherkenning in de regelomschrijving (tekstfragment) terechtkomen — dat is geen gestructureerde orderregel-referentie op zich.
• Echte orderreferentie op regelniveau: alleen als de ontvanger regelniveau-inrichting heeft; niet standaard "meerdere PO's → meerdere orderreferenties".

Verwacht geen automatische koppeling van meerdere PO-nummers aan meerdere kop-orderreferenties. Controleer bij een multi-PO-layout eerst de Professional- en SampleStore-inrichting voor de ene kop-PO; extra PO-nummers landen als regeltekst, niet als aparte orderregel-referentie, tenzij de ontvanger dat zelf heeft ingericht. Zie ook Regelherkenning voor referentievelden per regel.

Zoekvarianten: "Uw kenmerk", "Ons kenmerk", "Referentie label anker", "label naar BuyerReference", "SampleStore signaalwoorden", "labels vs SampleStore", "BuyerReference herkenning label", "herkenningsregel label SampleStore".

De SampleStore bevat voorbeelden en RegEx-opmaak van de referentienummers zelf, geen catalogus van labels of signaalwoorden die je als aparte ankerregel opslaat. Labels zoals "Uw referentie", "Referentie", "Kenmerk" of "Your order number" gebruikt de IDR wel: ze krijgen prioriteit boven een pure RegEx-fallback. Alleen de waarde die na het label volgt telt mee, en dan alleen als die waarde ook past bij de SampleStore-voorbeelden of -opmaak voor dat referentietype. De opmaak van het nummer is dus leidend, niet het PDF-label: een onduidelijk label met een juiste nummeropmaak in de store kan wel matchen, maar een herkenbaar label zonder store-match is onvoldoende (zie de melding over een lege Sample Store hierboven).

Staan zowel een OrderReference als een BuyerReference op de factuur, dan prevaleert de OrderReference. Labels of ankerregels beheer je niet zelf in het standaardplatform; support richt de voorbeelden en RegEx per referentietype in.

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:

1. RBE (Rule Based Enrichment): configureer een regel die controleert of BT-1 (cbc:ID) eindigt op -NOTFOUND. Op basis daarvan kan het document worden tegengehouden voor handmatige beoordeling, omgeleid naar een apart postvak, of automatisch afgekeurd.
2. Eigen systemen (ERP/boekhoudpakket): een directe string-match of reguliere expressie op -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.

Benieuwd hoe de herkenning technisch werkt? Lees Hoe werkt Scan & Herken (IDR/OCR)?.