Validation rules

Validation rules are the business logic checks applied to data once it has been pulled out of a document, deciding whether that data is plausible, complete, and consistent before it moves downstream. They range from simple format checks (a date must be a real calendar date) to cross-field logic (line items must sum to the invoice total) and lookups against external systems (a VAT number must exist in a registry). In an IDP pipeline, validation rules are what turn raw extraction into data you can trust enough to act on.

How it works

Validation rules sit after extraction and before the data is written to a downstream system. They typically fall into a few categories. Format rules check that a field matches an expected pattern: an IBAN has the right length, a postcode matches a country's format. Range and type rules check that a quantity is a positive number, or a delivery date isn't in the past. Cross-field rules check internal consistency, such as subtotal plus tax equalling the total, or a policy start date preceding its end date. Referential rules check data against an external source, like confirming a supplier's tax ID against a national registry or a customer against a KYC watchlist.

Each rule usually returns a pass, a fail, or a flag for review, and failures are often tied to a confidence score from the extraction step. A low-confidence field that also fails a validation rule is a strong candidate for human review, while a high-confidence field that passes every rule can go straight through.

Good validation rule design is specific to the document type and the business process behind it. An insurance claim has different rules than a construction invoice. Rules should be versioned and testable, because business logic changes (new VAT rates, new regulatory formats) and rules that aren't maintained quietly become wrong.

Why it matters for document processing

Extraction models, whether OCR-based or VLM-based, will occasionally read a number wrong, misplace a decimal, or miss a discount line. Validation rules are the safety net that catches these errors before they cause a bad payment, a wrong policy premium, or a rejected regulatory filing. They're also what makes straight-through processing possible: without rules to separate trustworthy extractions from risky ones, every document would need a human check, defeating the purpose of automation.

Validation rules also encode institutional knowledge that a model doesn't have on its own, like which supplier codes are valid or what tax rates apply this quarter. In regulated flows such as e-invoicing or KYC onboarding, they're often the difference between passing an audit and not. Treat them as a first-class part of the pipeline, not an afterthought bolted on at the end.

Related terms

• Confidence score
• Human-in-the-loop (HITL)
• Straight-through processing (STP)
• Data extraction
• KYC onboarding

FAQ

Are validation rules the same as confidence scores?

No. A confidence score measures how sure the model is that it read a field correctly. A validation rule checks whether that field makes business sense, regardless of the model's certainty. A high-confidence extraction can still fail a validation rule, for example a correctly-read total that doesn't match the sum of line items.

Who should define validation rules, IT or the business team?

The business team should own the logic (what counts as a valid VAT number, an acceptable date range, a required field), while IT or the IDP vendor implements it reliably and keeps it versioned. Rules built without business input tend to be technically correct but operationally wrong, missing edge cases the business already knows about.