Document Processing

Document Processing is the intelligent document processing (IDP) module of Nashua 360. It takes the unstructured paper and digital documents that enter an enterprise every day, invoices, purchase orders, delivery notes, application forms, contracts, statements and correspondence, and turns them into clean, validated, structured data that the rest of the suite can act on without re-keying. It owns the problem of the document backlog: the manual reading, sorting, transcription and filing that sits between a document arriving and a business process being able to use it.

The module combines high-accuracy optical character recognition, layout-aware AI extraction, automatic classification, confidence scoring and human-in-the-loop review into a single governed pipeline. It sits at the front door of the suite, feeding trusted data into finance, procurement, contracts and operations, and it works hand in hand with the AI Workers who read, verify and route documents alongside people.

What the module does

Document Processing ingests documents from every practical channel: a monitored mailbox, a scanner or multifunction device, a mobile capture, a watched folder, an API drop or a direct upload. It handles the full spread of formats, from clean digital PDFs to photographed, skewed, low-contrast and multi-page scans, applying deskew, denoise, rotation and page-splitting before recognition. Optical character recognition renders every page as searchable text with positional coordinates, and handwriting, stamps, barcodes, QR codes and checkboxes are read alongside machine print.

On top of recognition sits classification and extraction. Each document is identified by type and routed to the matching extraction model, which pulls the fields that matter for that type: supplier and buyer identities, document and reference numbers, dates, line items, quantities, unit prices, tax lines and totals, contract parties, terms and signatures. Every extracted value carries a confidence score and a link back to the exact region of the page it came from. Validation rules, lookups against master data and arithmetic checks run automatically, so that documents which reconcile cleanly pass straight through, while those with low confidence or failed checks are held for review. The result is a steady flow of clean, structured, audit-linked data ready for downstream use.

The domain and the data model

At the centre of the module is the idea of a document as it travels from a raw captured image to a trusted record. Every arriving item is treated as a distinct object with its own origin, its own pages and its own history, so that the same invoice photographed twice, or a batch scanned as one file, resolves into the individual documents a business actually cares about.

Each document is understood through three related notions. First, its type, which says what kind of thing it is and therefore what is expected of it: an invoice expects a supplier, totals and tax; a contract expects parties and terms. Type drives everything that follows. Second, its extracted content, held as a set of named fields and, where relevant, repeating lines, each value bound to the position on the page where it was found and to the confidence the system holds in it. This binding is what makes every figure traceable back to the source rather than asserted in isolation. Third, its state, the point it has reached on the journey from captured, through classified and extracted, to reviewed and released, together with who or what acted at each step.

Around these sit the reference points that give extraction meaning: the suppliers, customers, accounts and catalogue entries a value is matched against, and the extraction profiles that describe how a given type from a given source should be read. Relationships are simple and business-legible: a document is of a type, contains fields and lines, is matched to known parties, and leaves an unbroken trail of the hands and decisions that shaped it.

CaptureClassifyExtract andvalidateReview andrelease
How a document moves from raw capture to trusted, released data.

The principal workflows

The everyday workflow is straight-through processing. A document arrives, is classified, extracted, validated and, if every check is satisfied, released to the receiving process with no human touch. The measure of the module is how large a share of volume clears this path safely, and the controls exist to keep that share high without letting a wrong document through.

The second workflow is exception review. When confidence on a field falls below its threshold, a validation rule fails, or a total does not reconcile, the document is queued to a reviewer. The review surface places the extracted values beside the original image, highlights the exact region each value came from, flags the specific fields in doubt and lets a person confirm or correct in a few keystrokes. Corrections are captured as feedback, sharpening extraction for similar documents thereafter. A third workflow handles classification uncertainty, where a document that does not clearly match a known type is triaged, labelled and, if it represents a recurring new form, taught to the system. Batch capture, splitting of combined files, re-processing of amended documents and bulk approval round out the operational picture, and every path is governed by role-based queues, service-level timers and full status visibility so nothing stalls unseen.

Functional depth that matters

Extraction quality rests on layout-aware models that read a page as a structured object, understanding tables, columns, key-value pairs and multi-page continuations, rather than as a flat stream of characters. This is what allows line items to be captured as coherent rows and totals to be tied to their components. Confidence is calibrated per field, so thresholds can be set tightly on the values that carry financial or legal weight and loosely on those that do not, letting the module route work precisely rather than reviewing everything or nothing.

Validation is where correctness is enforced. The module runs arithmetic reconciliation on documents that carry line items and totals, checking that quantities, unit prices, subtotals, discounts, tax and grand total agree. It validates tax treatment against expected rates and registration identifiers, verifies party details against master records, detects duplicates by content rather than filename, and applies format and range rules to dates, currencies and references. Extracted data is normalised into consistent units, date formats, currency codes and party identifiers so downstream systems receive uniform values regardless of how the source expressed them. Every document retains an immutable record of its original image, each extracted value, each automated check and each human decision, with data handled under strict access controls and retention policies. That combination of reconciliation, normalisation, duplicate detection and an unbroken audit trail is what lets the business trust the data enough to post, pay or contract against it.

How it fits the Nashua 360 suite

Document Processing is the capture layer for much of the suite, and its value comes from what it feeds. Extracted supplier invoices flow directly into Accounts Payable and the wider Finance ledger, arriving as matched, coded, reconciled entries ready for three-way matching against the orders and receipts held in Procurement. Captured contracts and their extracted parties, dates and terms populate Contract Management, so obligations and renewal dates are tracked from the moment a signed document lands. Customer forms and correspondence are attached to the relevant records in the CRM, and released documents are filed into Document Management as the system of record with their metadata already populated.

Because extraction resolves parties and catalogue items against shared master data, the structured output lands against the same suppliers, customers, accounts and products the rest of Nashua 360 already uses, with no reconciliation gap. Approvals and exceptions raised here surface through the common workflow and notification fabric that runs across the suite, and every released document keeps its link back to source so that any downstream record can be traced to the page it came from.

How AI Workers operate inside it

AI Workers are first-class participants in Document Processing, not an add-on. They perform the reading and reasoning that classification and extraction depend on, and they act on the results. A worker can be asked in plain language to query the module directly, to report how many invoices from a given supplier are awaiting review, which documents failed reconciliation this week, or where a particular reference appears, and it answers from live module data with links to the underlying pages.

Workers execute actions as well as answer. They classify incoming documents, extract and normalise fields, resolve parties against master data, and release clean documents to their destination processes without human involvement where confidence and checks allow. They watch continuously for anomalies and exceptions, flagging duplicate submissions, totals that do not reconcile, unexpected tax treatments, out-of-pattern values and documents that do not match a known type, and they raise these to the right person with the evidence attached. Where a value is ambiguous, a worker offers decision support, proposing the most likely reading with its reasoning and the source region for a human to confirm. And a worker can stand as an approval or review node in a workflow, verifying a document against policy and either passing it forward, holding it, or escalating to a named reviewer, so that people spend their attention only on the judgements that genuinely need them.