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", "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".
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, of een bank-/betalingskenmerk (bijvoorbeeld een bankreferentie) 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.
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.
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. 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.
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?
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".
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.
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:
Best practice orderreferentie-opmaak op de PDF:
Ordernummer: 420000007 in plaats van PO420000007;Zie ook Foutmeldingen bij insturen bij een geblokkeerde of afgekeurde factuur door een verkeerd herkend ordernummer.
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.
-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