Intelligent document processing that turns invoices, forms and contracts into checked data

OCR converts an image of text into characters, while intelligent document processing turns a document into checked, structured data. IDP uses OCR as one step, then adds layout analysis to understand tables and fields, classification to recognise the document type, language models to map content to your schema, validation against your rules and records, and human review for uncertain values. OCR alone gives you text; IDP gives you data a system can act on.

Yes, modern IDP reads invoices by understanding their content rather than relying on a fixed template for each supplier. Language models and layout analysis locate the invoice number, totals and line items wherever they sit on the page. New layouts are still worth watching, so we track accuracy by supplier and add supplier-specific rules where a format repeatedly causes errors, rather than building templates up front for every sender.

Accuracy depends on your documents, so we measure it on your own samples before committing to a scope rather than quoting a general figure. PDFs generated by accounting systems are the easiest case, while dense tables that run across pages and low-quality images are harder. We score accuracy field by field against a ground-truth set, then set review thresholds so that values the system is unsure about are always checked by a person before they are used.

Partly, and we test it on your own samples before agreeing scope. Printed text on reasonable scans is read reliably, and clear handwriting in boxed form fields can often be captured. Joined-up handwriting, faint carbon copies, stamps over text and low-resolution phone photos are harder, so those fields get stricter confidence thresholds and usually go to a reviewer. Where you control intake, scanning guidance or an upload screen that rejects blurred images improves results before extraction starts.

Three-way matching compares each supplier invoice with its purchase order and the goods received record before it is approved for payment. The pipeline extracts invoice lines, retrieves the order and receipt from your ERP and checks supplier, quantities, unit prices and totals within the tolerances you set. Fully matched invoices proceed automatically, and mismatches go to accounts payable with the differing lines highlighted, so staff resolve the problem instead of searching for it.

Yes, trade documents are a strong fit because they follow recognisable structures but vary widely between carriers and shippers. We extract shipper, consignee, notify party, ports, container and seal numbers, package counts, weights and goods descriptions, then cross-check them against the commercial invoice, packing list and your booking records. Discrepancies are flagged before documents are submitted or goods are released, when they are cheapest to correct.

Yes, IDP can capture parties, dates, renewal and notice periods, payment terms, liability caps and other clauses you specify into a structured contract register. Each value links back to the clause it came from, so legal or procurement staff can verify it in one click. Because contract language varies, we treat extracted terms as a draft for review and measure accuracy clause type by clause type on your own agreements.

Documents go to review when any field falls below its confidence threshold or any validation check fails. Thresholds are set per field and document type with the process owner, so bank details and totals are held to a stricter standard than a reference number. Reviewers see the page beside the extracted data with the problem highlighted, and their corrections are logged and reused to improve rules and evaluation sets.

Yes, once a document passes validation or review, the data can be posted through your ERP or accounting system's API, a supported import format or an integration service we build. We match records against existing suppliers, customers and cost codes before posting, use idempotent writes so a retry does not create a duplicate, and log each transaction. Where a system has no usable API, we agree a controlled file-based import instead.

Documents are encrypted in transit and at rest, stored in the cloud account and region you choose and visible only to roles that need them. Review screens can mask bank account and identity numbers for reviewers who do not need to see them, and fields a step does not use can be removed before a model call. Model providers are used under enterprise terms that exclude training on your data. Retention rules delete source files on your schedule, and every view and change is logged.

Yes, both are standard validation checks in an accounts payable pipeline. Each invoice is compared with those already processed on supplier, invoice number, date and amount, including near matches where a number was retyped slightly differently. Bank details on the invoice are compared with the supplier master record, and any difference holds the invoice and alerts finance, because changed payment details are a common sign of invoice fraud. A genuine change is then confirmed through your own call-back procedure.

Buy a packaged product if your documents are common types, your volumes are steady and its built-in connectors reach your systems. A custom pipeline makes sense when documents are unusual or multilingual, validation depends on your own data and rules, review must fit an existing workflow, or per-page licence fees grow too fast with volume. We compare both options against your real documents during discovery and recommend the cheaper one that meets the requirement.

Timelines depend on the number of document types, how varied and clean your samples are, the validation rules required and the systems the data must reach. A first release covering one high-volume document type, such as supplier invoices into one ERP, is a sensible starting point and gives measurable results early. Further document types are added in stages, each with its own evaluation set and review settings.

Build cost depends on scope, and we give a fixed quote after a discovery phase in which we test extraction on your sample documents. The main drivers are the number of document types, validation complexity, review screen requirements and integrations. Running costs come from OCR and model processing per page, hosting and storage, and we estimate them from your monthly volumes so you can compare them with the cost of manual handling.