Everything looks convincing at the meeting.
An invoice is uploaded. A few seconds later, the supplier, company details, line items, and total appear on screen. One more step, and the data is ready for the accounting system.
It seems manual data entry can be removed from the process.
Then you upload your company's documents. One is a scan, another contains a table spanning several pages, and a third is resent by the supplier with a corrected price.
A row goes missing. A quantity is interpreted incorrectly. The updated document is treated as a new one.
An employee opens the original file and starts checking everything again.
A demo shows that a solution can complete a task under the conditions demonstrated. Before deciding to deploy it, you need to find out how it handles your document flow and how much work it leaves to people.
This article explains how to test that before a major integration. You will come away with a framework for a test dataset, an error assessment table, and questions to ask your vendor.
Why a successful demo does not prove operational readiness
A short presentation usually uses a clear scenario. That is reasonable: there is limited time to explain how the solution works.
But everyday work involves more than successful recognition.
The system must identify the document, extract the required data, notice missing information, handle repeated submissions, and pass the result onward. Sometimes it will need to stop and request a review.
Consider a hypothetical company that wants to transfer line items from supplier invoices into its accounting system automatically.
The demo uses one PDF with a clear table. Actual work includes:
- scans with stamps covering text;
- photographs with cropped edges;
- documents using different units of measure;
- tables that continue on the next page;
- revised versions of previously received invoices;
- files with incomplete company details;
- password-protected documents.
Successfully processing the first PDF says nothing about performance on the other cases. They need separate testing.
What exactly can go wrong
“The AI read the document incorrectly” is too vague. The business needs to know where the error occurred and which action followed it.
Document processing errors and checks| What happened | Why it matters | What to check |
|---|
| A table row was omitted | The order or system record will be incomplete | Whether line items are checked against the source |
|---|
| Individual units and packs were confused | The actual order quantity may change | How units of measure are handled |
|---|
| An amount was read incorrectly | Approval or payment data will be wrong | Whether arithmetic checks exist |
|---|
| A repeated file was treated as new | A duplicate record may be created | How repeated submissions are detected |
|---|
| A revision was not linked to its previous version | Outdated terms may remain in use | How document versions are handled |
|---|
| A missing field was filled with a guess | An employee may mistake invented data for source information | What happens when information is missing |
|---|
| Data was extracted but not transferred onward | An employee still has to enter it manually | How completion of the entire operation is verified |
|---|
Not all these problems are directly related to the AI model. Some concern validation rules, data matching, and integration.
Acceptance testing should therefore cover the entire workflow, from receiving the file to producing the correct result in the target system.
Start with the result your employee needs
Before testing, define what should be available after the document is processed.
“Recognize an invoice” is not specific enough.
A more useful requirement is:
Extract the supplier, invoice number and date, line items, quantities, units, and amounts. Check mandatory fields and arithmetic. Prepare a draft record in the accounting system. Send ambiguous values to an employee with a reference to the original fragment.
Now there is something concrete to test.
Separately define which actions the system may perform independently. Preparing a draft and creating a final record require different levels of control. Financially significant actions may need additional approvals.
A good requirement describes both successful processing and what the system should do when it cannot produce a reliable result.
How to build a document test set
Do not limit testing to a few tidy files that are easy for a person to read.
Start with documents from a typical working period. Review the formats and suppliers, where employees correct data, and which files are returned for clarification.
Build three groups.
1. Ordinary documents
These represent the bulk of the flow: typical invoices, requests, completion certificates, or other documents the solution is designed to process.
Include common layout variations. If the company works with several major suppliers, testing one template does not replace testing the others.
2. Difficult but realistic documents
Include files the team actually encounters:
- lower-quality scans;
- multipage tables;
- merged cells;
- notes containing important terms;
- different currencies and units of measure;
- multiple documents in a single file.
This group should test real difficulties in your process. A random unreadable file that never occurs in your work will contribute little to the assessment.
3. Exceptions
Add a repeated submission, a corrected version, an unsupported document type, an inaccessible file, and a document missing mandatory data.
The correct outcome may be to stop processing and give the employee a clear notification.
The number of files depends on the variety and volume of your flow. A small selection can reveal initial problems, but it cannot substantiate a promised accuracy rate across the company's entire workload.
Use some documents for configuration and reserve others for independent testing afterward.
Prepare the correct answers before running the test
Record the expected result in advance so the assessment does not become an argument about impressions.
For each test document, list the required fields and correct values. If the source is ambiguous, mark it as needing clarification.
Do not require the reviewer to invent an answer that the document does not contain.
Use a table like this to record results:
Pilot evaluation table| Test field | What to record |
|---|
| Document and scenario | Type, source, ordinary case or exception |
|---|
| Expected result | Correct values and required action |
|---|
| System result | What was extracted and where it was transferred |
|---|
| Error | Which field or action was wrong |
|---|
| Consequence | Correction, a stop, or reprocessing required |
|---|
| Employee time | Time spent reviewing and correcting |
|---|
| Outcome | Accepted, sent for clarification, or rejected |
|---|
This gives you a basis for deciding what works, what needs improvement, and which errors prevent launch.
Why “98% accuracy” needs an explanation
Before evaluating an impressive percentage, ask what was counted.
Is it the share of correctly recognized characters, correctly populated fields, or documents without any significant errors?
Consider a hypothetical invoice with 50 fields to check. One field is incorrect. Field-level accuracy is 98%.
But if that error is in the bank details or product quantity, accepting the document without review is not appropriate.
Assess these separately:
- correctness of critical fields;
- share of documents ready for the next step without corrections;
- share of cases sent for human review;
- errors the system failed to flag;
- time spent reviewing and correcting.
The review rate also needs context. If the system confidently misses errors, a low review rate is not an advantage. If it sends almost every document to a person, the expected time savings may not materialize.
Count the work that remains after AI
Producing a result quickly is not enough. An employee must be able to use it.
Suppose manual document processing takes ten minutes.
The system extracts the data in 20 seconds, but the employee then spends seven minutes checking and another two making corrections. Human work has decreased by only one minute in this scenario.
This is an illustrative example. It shows why model speed should not be presented as labor time saved.
Compare the full process:
File preparation + processing + review + corrections + transfer to the working system.
Track active employee time separately from total document turnaround time. An automated operation may run in the background while someone does other work.
Also test how easy corrections are. If one disputed value requires reopening a multipage file and locating the right row, interface usability will directly affect the value of the implementation.
Agree on acceptance criteria before integration
Define criteria with the process owner and the employees who will use the system.
There is no universal acceptable error rate. Requirements depend on consequences: an incorrect internal document category and incorrect payment details create different risks.
Record:
- Which documents are included in the first phase.
- Which fields are mandatory.
- Which errors prevent automatic continuation.
- When the system must request review.
- Who handles exceptions.
- How much manual work should remain.
- Which results justify expanding the rollout.
You also need a procedure for technical failures. If the accounting system is unavailable, the document must not silently disappear from the queue. Retrying a transfer must not create a duplicate.
These workflow behaviors should be tested before the system handles the full volume.
What to ask the vendor at the next demo
Instead of the general question “How accurate is your AI?”, ask them to walk through specific situations.
- Can we test the solution on documents that were not used during configuration?
- What happens if a mandatory value is missing?
- How will an employee see the source of a disputed field?
- What happens when the same document is submitted again?
- How are corrected versions handled?
- How long does human review take?
- What happens if the downstream system is unavailable?
- Which materials and activities are included in the pilot price?
The answers will clarify the solution's limits and the scope of work. An honestly stated limitation is more useful than a promise to process every document without errors.
How to start without a large project
Choose one document type and one outcome, such as preparing a draft invoice record for an employee to review.
Collect real files, record the expected values, and measure current effort. After configuration, test the solution on the reserved dataset and compare the entire process, including corrections.
Human confirmation can remain in place during the first phase. Expand independent system actions based on the results of testing specific scenarios.
At Futureinapps, we implement AI document and data processing. For an initial discussion, prepare a few anonymized files, an example of the required output, and a description of what happens after a document arrives.
This will help define the pilot's scope, validation requirements, and potential integration.
A pilot should produce an informed decision: deploy, improve, or stop. The sooner you reach that decision using your own documents, the less time and budget you will spend on an unsuitable solution.
