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:
Bij sommige inkomende facturen ontbreekt de klant-BTW-code G (geen btw / 0%), terwijl een andere factuur met een ogenschijnlijk vergelijkbare BTW-verdeling deze code wel toont. Dit is meestal geen herkenningsfout.
Belangrijk onderscheid: de Peppol/UNCL5305-categorie G (export buiten de EU) is niet hetzelfde als een klant-BTW-code zoals G, H of A1. Klant-BTW-codes zijn boekhoud- of mappingcodes van de ontvanger, ingericht in het eigen systeem van de klant. De IDR herkent het BTW-percentage en de -categorie op basis van wat daadwerkelijk op de PDF staat. Staat er bijvoorbeeld 21% (code A1) en geen aantoonbare 0%-component op de factuur, dan vult het systeem geen G/0% in. Verschillen tussen leveranciersformaten of ontbrekende 0%-informatie op de bron-PDF verklaren dit soort afwijkingen vaak, niet een fout van de herkenning.
Zoekvarianten: "onjuist factuurnummer", "inkoopordernummer als factuurnummer", "PO number as invoice number", "ordernummer als factuurnummer", "Meta factuurnummer", "KvK als 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", "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. Voorbeelden: een transactie-id in plaats van het eigenlijke factuurnummer (bekend bij Meta/Facebook-facturen, waarbij het factuurnummer onderaan een latere pagina staat), het KvK-nummer van de leverancier, 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. 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. Meld zo’n geval bij support — op basis van de melding voegt het team een leveranciersspecifieke aanwijzing toe waarna toekomstige facturen van dat formaat het juiste factuurnummer krijgen.
Hoe werkt de herkenning achter de schermen (SampleStore)? De IDR gebruikt hiervoor de SampleStore: een database met herkenningspatronen per leverancier. Het proces verloopt in drie stappen: (1) zoeken naar nummers die matchen met een RegEx-patroon in de SampleStore, (2) vergelijken met eerdere voorbeelden van dezelfde leverancier (lengte, opbouw, streepjes, punten, underscores, consistentie), (3) zelflerend bijstellen op basis van nieuwe facturen. Support vult de SampleStore aan met voorbeelden en eventueel een RegEx na een melding.
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?).
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.
Met het Professional-abonnement worden aanvullende velden herkend:
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.
Volgens de Europese norm EN16931 is een referentie (buyer reference / koperreferentie) verplicht op een e-factuur; dit is vaak een ordernummer of een andere referentie van de ontvanger. Een verzender kan in dit veld een onjuiste waarde plaatsen.
eConnect keurt een factuur standaard niet af op de referentie. Een factuur voldoet alleen niet aan de basisregels van de Europese norm als er in het geheel geen referentie aanwezig is. Of een factuur alsnog wordt afgekeurd vanwege een onbekende of onjuiste referentie hangt af van de inrichting van de ontvanger: in een specifieke ontvanger-inrichting kan een factuur worden afgekeurd als de referentie onbekend is. Dit is dus een eigenschap van de ontvangende configuratie, niet van de standaard eConnect-verwerking.
Tip: als je facturen wil afkeuren op ontbrekende of onbekende referenties, configureer dit via RBE (Rule Based Enrichment) op het ontvangende eindpunt.
-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.
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