Document and approval workflows, from arrival to an audit-proof record
A document arrives, someone reads it, someone else approves what it commits the organisation to, and years later an auditor asks who decided and on what basis. This page describes that workflow, shows where the chain breaks, and marks where AI extraction genuinely helps and where a person has to stay in the loop.
Submit a project See the related serviceReviewed by David Nguyen (CEO) · Updated 14 Oct 2026
How the workflow runs today
Documents arrive by every route at once: an email attachment, an upload on a portal, a scan from the office printer, a photograph taken on a phone, a file dropped on a shared drive. Someone opens each one, works out what it is, and retypes the fields that matter into the system that needs them.
The document then needs a decision. That is where the chain leaves the system: the request goes out by email to a manager, who forwards it to a second manager, who replies "fine by me" without quoting what was agreed. The approved document is filed somewhere, usually in more than one place, and the evidence that it was approved exists only as a thread in one person's mailbox.
Where does it break?
-
The approval chain lives in email
Nobody can state the rule, only what usually happens, and the rule changes when someone is on leave.
-
Extraction is retyping
The slowest step is a person reading a PDF and typing numbers into a form, and the error rate of that step is unmeasured.
-
The record cannot be produced on demand
Asked who approved a document in March two years ago, the organisation has to search mailboxes, and sometimes the mailbox is gone.
-
Versions multiply
The signed version, the countersigned version and the version with the handwritten amendment are three files with similar names.
-
Thresholds are advisory
Everyone knows large commitments need a second signature, but nothing enforces it, so the exception is discovered afterwards.
-
Retention is nobody's job
Documents are kept forever because deleting them feels risky, which is its own compliance problem.
The target flow
-
One intake point
Every route lands in the same queue with the same metadata: when it arrived, from whom, through which channel, and the original file kept unaltered.
-
Classification before extraction
What kind of document it is decides which fields matter and which approval rule applies.
-
Extraction with a confidence score per field
Fields are proposed, not asserted, and each carries a link to where in the document it came from.
-
Review sized by risk
High-confidence, low-impact fields pass; anything else reaches a person in a queue built for seconds, not minutes.
-
Approval as a rule, not a message
Thresholds, sequence and delegation are configuration. Each step records who, when, on what version, and on what they saw.
-
One record with a retention rule
The document, its extracted fields, its approval history and its version chain are one object with a defined lifetime and a defined deletion.
Where AI fits, and where a person must stay
Extraction is the part of this workflow where AI earns its place. A model reads a scan, a photograph or a badly generated PDF and proposes structured fields, which is work no rule-based template survived for long. Netbase has delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines, and works with commercial and open-source AI models chosen per project.
Where a person must stay is not a matter of taste:
The review step is a designed component with its own thresholds, queue and escalation path, set out in human in the loop AI workflows. Build it in the first milestone: a review step added later is a review step nobody does. Whether a document type needs a model at all is worked through in the business workflow transformation guide; an AI Workflow Blueprint settles it for one type before a build.
-
Anything that commits the organisation
Approving spend, accepting terms or granting access is a decision with a consequence and an accountable name behind it. A model can prepare it; it cannot be the one who decided.
-
Low-confidence or unusual documents
A field below threshold, a layout never seen before, or a total that does not add up goes to a person by design rather than by exception.
-
Anything a regulator or a court may examine
The defensible record is one where a named person accepted a value, with the source visible beside it.
System boundary
A project of this shape owns intake, classification, extraction with confidence, the review queue, the approval rules and their audit trail, the version chain and the retention schedule.
It does not own the decision itself, the policy behind the thresholds, or the systems of record downstream. Where the approved document becomes a purchase order or a receipt in an operational system, that is ERP and back-office operations; where it becomes an invoice matched to a settlement, that is order and payment operations.
Records, retention and integrations
The objects to design are the document with its original bytes, the extracted field with its confidence and its source location, the version, the approval event, the case that groups them, and the retention rule. Store the original unaltered: an extraction can be rerun, a lost original cannot.
The usual connections are mail and the scanner, an identity directory so approvers are real people with current roles, the operational systems that consume the fields, and storage with the right residency. Agree who owns each and what happens when it fails.
Document workflows carry personal data and often contractual confidentiality. Residency, access, retention and what may be sent to an external model are decisions to take before the architecture, not after a pilot.
Delivery modules
- Intake across channels, with the original preserved and the arrival recorded.
- Classification and a document-type catalogue with its owners.
- Extraction with per-field confidence, source highlighting and an evaluation set.
- Review workbench: queue, thresholds, keyboard-fast correction, and correction feedback.
- Approval engine: rules, sequence, delegation, and an audit trail nobody can edit.
- Version chain and retention, including defensible deletion.
- Integration adapters to the systems that consume the fields, with retry and alerting.
- Search and reporting across cases, ages and exceptions.
These are built as AI Workflow Automation milestones with written acceptance criteria; other engagement shapes are under services.
Rollout
Start with one document type and one approval rule, chosen because volume is high and the consequence of an error is contained. Run extraction in shadow mode first: the model proposes, a person works as before, and the two are compared. Within a few weeks you have a measured accuracy per field on your own documents, which is the only accuracy number worth planning against.
Then move that document type to review-and-accept, keep sampling, and only raise a threshold when the sample supports it. Widen by document type, never by lowering the review bar across all of them at once.
Milestone acceptance is on the project delivery page.
Risks
-
The approval rule does not exist yet
It has to be written and agreed before it can be configured, and that is a discovery task with a named owner.
-
Extraction accuracy is quoted from somewhere else
Vendor figures are measured on other documents. Yours is measured on yours.
-
The review queue is slower than retyping
If correcting a field takes more clicks than typing it, people abandon the tool.
-
Scans are worse than the sample
The pilot set is always the clean one. Ask for the batch nobody wanted to show you.
-
Retention is deferred
Retrofitting defensible deletion across a version chain is expensive.
How is success measured?
Baseline first, then track: documents handled per person per day; extraction accuracy per field on a sampled set; documents passing without a correction; time from arrival to decision; approvals completed outside the rule; the age of the review queue; and how long it takes to produce a complete approval history for one named document.
That last measure is the one an auditor cares about, and usually the one nobody has timed. How evidence is labelled is on the methodology page.
Where this workflow holds
It holds wherever documents carry commitments: supplier invoices and contracts, insurance claims, loan and grant files, HR records, permits and inspection reports, customs and delivery paperwork, and case files in professional services. Proof-of-delivery paperwork in particular sits between this workflow and dispatch and delivery tracking; seller identity documents checked before a listing goes live belong to marketplace and classifieds operations; the other workflows written up this way are under solutions.
It does not hold where the volume is small enough that a person reads everything comfortably, where the real problem is that the upstream party sends the wrong thing, or where a regulator mandates a specific system you do not choose.
Proof from delivery
The delivered part of this page's argument is the document AI component in the registered statement quoted in the AI section above. Those records are anonymised, without a client, sector, volume or result attached.
Related approval machinery appears in the custom fields and configurable workflows in the first phase, from 2020 to 2023, of the multi-tenant cloud ERP platform Netbase has worked on since 2020 as offshore development and managing partner for a client that is not named. That platform's later retail phase was planned work and is not presented as delivered.
An end-to-end approval and records platform is scoped the same way. The approval engine, the audit trail and the retention schedule are ordinary engineering that Netbase scopes, builds and proves milestone by milestone.
Since 2020, Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP that a US software company offers as SaaS to small and mid-sized businesses.
Keep ReadingCommon questions
No. It proposes fields and flags what it is unsure about. A named person approves anything that commits the organisation, and the record shows who and when.
Nobody can answer that before seeing your documents. The shadow run in the first milestone produces the number, measured on your own scans, and the thresholds are set from it.
You do. Custom development creates intellectual property the client owns; a Netbase productized module, where one is proposed, is licensed, not transferred, and named before the build.
Usually yes. They become the integrations; the project owns intake, review, approval and the audit trail on top.
Yes. Every service on this site is delivered remotely from Hanoi, and Netbase has worked with clients in 80 countries. Delivery communication is in English, with weekly reviews and a named project manager.
Netbase takes on projects in any industry where the work can be delivered remotely and accepted by milestones. The industry pages describe the approach sector by sector, and the Work records show delivered projects.
Payment is by bank transfer to the company account of Netbase JSC or through PayPal Business. The payee is always Netbase JSC, the company that operates OutsourcingVN.
Talk to Huy Nguyen (David), Founder and CEO of Netbase JSC: message him on WhatsApp at +84 937 869 689 or email project@netbasejsc.com. You can also send your brief through the project request form. Say which workflow or system the project concerns and what has to stay unchanged; the first step is a discovery conversation, and scope and milestones are agreed after it.
Services behind this solution
AI workflow automation with evaluation and human control
One operating workflow automated, with an agreed way to judge it and a person on uncertain cases.
Learn More
Scope this workflow
Bring one document type, a hundred real examples including the ugly ones, the approval rule as people actually apply it, and the retention obligation you are under. Then submit a project brief naming the part you want automated first. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.