Sjabloonregels in Proces Sjablonen

Status: 01.08.2026 • Leestijd: ~8 minuten

Sjabloonregels zijn een manier om bedrijfslogica te definiëren die tijdens de documentverwerking wordt uitgevoerd. Zodra een document is vastgelegd en velden waarden bevatten (van OCR, import of mapping), kunnen regels die waarden evalueren en erop reageren. Dit geeft je een gecontroleerde laag tussen “gegevens zijn vastgelegd” en “gegevens zijn geaccepteerd”, zodat je consistentie kunt afdwingen, uitzonderingen vroeg kunt detecteren en handmatige correcties kunt verminderen.

Een regel heeft doorgaans drie ingrediënten: het kijkt naar één waarde (of een waarde afgeleid van andere waarden), evalueert een voorwaarde en—als aan de voorwaarde is voldaan—triggert een reactie zoals het creëren van een opmerking of het bijwerken van een of meer velden.

Omdat regels in een gedefinieerde volgorde kunnen worden uitgevoerd, kun je gestructureerde logica opbouwen: normaliseer eerst waarden, bereken vervolgens afgeleide waarden en valideer het eindresultaat daarna.

Wat je kunt doen met Sjabloonregels

Valideer volledigheid en basisplausibiliteit

Regels kunnen ervoor zorgen dat de belangrijkste velden aanwezig en redelijk zijn. Bijvoorbeeld, je kunt ontbrekende factuurdata, ontbrekende leveranciersreferenties of totalen die nul zijn wanneer ze dat niet zouden moeten zijn, detecteren. Dit is vaak de eerste controle: als de basis ontbreekt, heeft het geen zin om verder te gaan met meer geavanceerde controles.

In plaats van alles te blokkeren, kun je het gedrag kiezen dat past bij je workflow. Sommige klanten markeren ontbrekende essentiële zaken als fouten (stop met verwerken totdat het is opgelost), terwijl andere controles waarschuwingen kunnen zijn (verwerk maar dwing een herziening af).

Valideer formaten en patronen (bijv. factuurnummers, ID's)

Veel zakelijke velden moeten een gestructureerd formaat volgen: factuurnummers, inkoopordernummers, BTW-ID's, IBAN's, interne referenties. Regels kunnen valideren of een veld voldoet aan de verwachte structuur en een opmerking genereren wanneer dat niet het geval is.

Dit is vooral nuttig wanneer OCR tekens onjuist leest (O vs 0, I vs 1), of wanneer leveranciers verschillende nummeringsschema's gebruiken en je “ongewone” waarden vroeg wilt detecteren.

Vergelijk waarden op consistentie

Regels kunnen twee waarden vergelijken en evalueren of ze overeenkomen of verschillen. Dit kan zo eenvoudig zijn als controleren of twee geëxtraheerde referenties zijn uitgelijnd, of meer zakelijke controles zoals ervoor zorgen dat de valuta overeenkomt met de verwachte valuta van de leverancier.

Een veelvoorkomende aanpak is om een geëxtraheerde waarde te vergelijken met een ander vastgelegd veld, of met een waarde afgeleid van masterdata. Het doel is niet om elke kleine afwijking te vangen, maar om tegenstrijdigheden te identificeren die aangeven dat het document aandacht nodig heeft.

Voer numerieke controles uit, inclusief drempels en toleranties

Numerieke vergelijkingen zijn een van de sterkste functies in de verwerking van echte facturen. Je kunt hoge bedragen markeren voor handmatige goedkeuring, negatieve waarden detecteren waar ze niet zouden moeten voorkomen, en verdachte verschillen benadrukken.

Waar gelijkheid vereist is, is tolerantie belangrijk omdat gescande documenten vaak kleine afwijkingen introduceren door afronding (vooral met BTW). In plaats van “118,99 vs 119,00” als een mislukking te beschouwen, kun je een kleine afwijkingsband toestaan en alleen een uitzondering aanroepen wanneer het verschil je gedefinieerde tolerantie overschrijdt.

Dit is ook hoe typische controles voor financiële integriteit worden uitgedrukt—zoals het verifiëren van totalen en belastingen zonder te veel valse positieven te creëren.

Valideer totalen zoals Netto / BTW / Bruto

Een van de meest gevraagde controles is ervoor zorgen dat totalen correct optellen. Een typische bedrijfsregel is: Bruto moet gelijk zijn aan Netto plus BTW, mogelijk binnen een tolerantie. Wanneer de relatie niet klopt, kun je een opmerking genereren die expliciet om herziening vraagt.

Deze controles kunnen op headerniveau (documenttotalen) worden toegepast en—afhankelijk van je sjabloonstructuur—ook op lijnniveau (bijv. lijnbedrag = hoeveelheid × eenheidsprijs, of lijn totalen optellen tot header totalen). Zelfs wanneer je geen strikte blokkering afdwingt, biedt dit sterke operationele controle en vermindert het boekingsfouten.

Controleer masterdata-resolutie (record bestaan)

Een veld kan een waarde bevatten en toch verkeerd zijn omdat het niet naar een geldig record verwijst. Regels kunnen dit soort problemen detecteren door te controleren of er een overeenkomstig masterdata-record bestaat. Typische voorbeelden zijn leveranciers-/klantresolutie, artikelnummer op lijnen, of andere gerefereerde entiteiten.

Dit is een van de belangrijkste regeltypes omdat downstream verrijking ervan afhankelijk is. Als een leveranciersrecord niet kan worden opgelost, kunnen velden zoals betalingsvoorwaarden, goedkeuringslogica of boekingsinstellingen onbetrouwbaar zijn. In die zin fungeren “record bestaat” controles vaak als poorten: als de resolutie mislukt, wordt het document gemarkeerd voor correctie voordat het verder kan gaan.

Gebruik masterdata als onderdeel van de logica (verrijking en controle)

Zodra een record is opgelost, kunnen regels informatie uit dat record gebruiken als input voor verdere evaluatie of om documentvelden in te vullen. Dit maakt leveranciersspecifieke logica en consistent gedrag mogelijk.

Bijvoorbeeld, je wilt misschien een opmerking genereren wanneer de leverancier geblokkeerd is, de standaardvaluta van de leverancier toepassen wanneer de valuta ontbreekt, of de betalingsvoorwaarden van de leverancier gebruiken om een vervaldatum af te leiden. Dit vermindert handmatig werk en houdt de documentverwerking in lijn met masterdata.

Afleiden en berekenen van waarden

In veel processen zijn de waarden die je wilt valideren niet direct vastgelegd maar kunnen ze worden afgeleid. Regels kunnen berekende resultaten ondersteunen, zoals verwachte totalen of verschillen. Dit helpt je om controles uit te drukken zoals “vergelijk vastgelegde bruto met berekende bruto” of “bereken de delta en markeer deze wanneer deze de tolerantie overschrijdt”.

Berekende waarden zijn ook nuttig voor het opbouwen van consistente, verklaarbare logica waarbij validatie niet afhankelijk is van een enkel geëxtraheerd veld, maar van relaties tussen velden.

Omgaan met data en vervaldatumlogica

Datumcontroles zijn een veelvoorkomende vereiste omdat datums velden de boekings- en betalingsprocessen beïnvloeden. Regels kunnen controleren op onrealistische data (ver in de toekomst, of eerder dan verwacht), relaties afdwingen (vervaldatum niet eerder dan factuurdatum), en datums afleiden van andere waarden.

Een klassiek voorbeeld is de berekening van de vervaldatum op basis van betalingsvoorwaarden. Wanneer de vervaldatum consistent wordt afgeleid, verminder je handmatige bewerkingen en voorkom je dat documenten met onjuiste betalingsdata worden geboekt.

Wat er gebeurt wanneer een regel wordt voldaan

Opmerkingen: communiceer duidelijk naar de gebruiker

Opmerkingen zijn de “menselijke” uitkomst van regels. Ze bieden duidelijke richtlijnen: wat is gedetecteerd, waarom het belangrijk is, en wat te doen. Opmerkingen kunnen informatief, waarschuwingen of fouten zijn, afhankelijk van hoe strikt het proces moet zijn.

Goede opmerkingstekst is specifiek en actiegericht. “Totalen komen niet overeen” is nuttig; “regel mislukt” is dat niet. De beste regelsets voelen als een checklist die zichzelf automatisch uitlegt aan de beoordelaar.

Veldvervanging: automatische correcties en standaardisatie

Regels kunnen ook velden automatisch bijwerken. Dit is gepast wanneer de wijziging veilig en deterministisch is: normaliseren van getalformaten, invullen van standaardwaarden, kopiëren van waarden tussen velden, of toepassen van waarden afgeleid van masterdata.

Het vervangen van waarden hoeft geen problemen te verbergen. Veel klanten combineren beide benaderingen: ze normaliseren waarden automatisch, maar creëren nog steeds een opmerking wanneer het document oorspronkelijk iets verdachts bevatte. Op die manier wordt het document verwerkbaar terwijl het nog steeds transparant blijft.

Typische uitkomsten die klanten implementeren

Klanten implementeren vaak een regelset die resultaten oplevert zoals:

“Markeer facturen wanneer totalen niet optellen (netto + BTW vs bruto), terwijl een kleine tolerantie voor afronding is toegestaan.”
“Verhoog waarschuwingen wanneer factuurtotalen goedkeuringsdrempels overschrijden.”
“Stop met verwerken wanneer een leverancier niet kan worden opgelost of wanneer verplichte velden ontbreken.”
“Detecteer ongeldige formaten voor factuurnummers, BTW-ID's of IBAN's.”
“Afleiden van vervaldatums op basis van factuurdata en betalingsvoorwaarden zodat gebruikers ze niet handmatig hoeven te berekenen.”
“Normaliseer vastgelegde waarden zodat vergelijkingen en boekingen consistent verlopen.”
“Pas leveranciersspecifieke controles toe, bijvoorbeeld geblokkeerde leveranciers, valutamismatch of ontbrekende referenties.”