Published on 03/10/2026
From email attachment to business system: avoid entering data twice
A supplier sends an order confirmation as a PDF. Somebody opens it, types the reference, delivery date and amount into a list, then enters the same details in the business system. The document also goes into a folder. When a corrected version arrives, the search begins: which version is valid, and has it already been recorded?
Automation should do more than speed up this route. It must keep visible which original produced a record, what was uncertain and who approved it. Let us follow one explicitly fictional order confirmation.
The current route
In this example, a fictional business receives AB-8472.pdf. It contains equally fictional values: purchase reference B-1048, delivery date 16 October 2026 and total EUR 1,248.60. An employee saves the PDF, transfers three fields to a spreadsheet and later enters them again in the job system.
| Step | Before | Typical gap |
|---|---|---|
| Receipt | attachment in a personal inbox | cover cannot see it |
| Capture | values typed into a spreadsheet | typing errors, inconsistent format |
| Review | glance at PDF | no record of the check |
| Approval | verbal message or email | status remains unclear |
| Transfer | values entered again | duplicate effort and discrepancies |
This table is not evidence of real savings. It is a fictional workflow used to explain the design.
1. Record receipt consistently
The automated route starts in a designated inbox, not through personal forwarding rules. On arrival, the message receives an internal case ID. The system records sender, receipt time, subject and a technical fingerprint of the file. The original remains unchanged.
Duplicate handling begins here. If the same fingerprint already exists, the workflow does not create a second record. The same purchase reference with a different file is not automatically a duplicate: it may be a correction. That case needs a visible warning and review.
2. Extract values as proposals
The workflow proposes the reference, date and amount. Fixed rules may be enough for a consistent layout; document recognition can help with variable layouts. In either case, every proposed value remains connected to its location and original file.
Unreadable or ambiguous fields must not be silently completed. If the system reads 16 October 2026, it can validate format and plausibility. If it finds both 1,248.60 and a conflicting total, it marks the amount as uncertain. The case waits instead of continuing with a guess.
3. Validate against existing data
Next, the proposed values are checked against structured records:
- Does
B-1048exist in the purchase list? - Does the identified supplier match that purchase?
- Is the date technically valid?
- Do currency and numeric format match accepted inputs?
- Is there already a document with the same reference and version?
These checks do not decide whether a document is commercially or legally correct. They identify discrepancies for a person to assess. This article makes no claim about invoice, retention or tax requirements.
4. Present an understandable approval
The reviewer does not need another crowded spreadsheet. They see the original beside the proposed values and clear warnings. In the fictional example, reference and supplier match and the date is plausible, but the amount is uncertain. The reviewer corrects it from the original and approves the case.
A useful approval records time, responsible person and changes. Rejecting, postponing and requesting clarification are as important as "Approve". Without those options, difficult cases disappear outside the system.
5. Transfer once to the destination
Only after approval does the integration send confirmed data. It includes the case ID. After a timeout, it must not simply create a new record. It first checks whether the destination already processed the case, or safely repeats the same uniquely identified request.
| After | Automatic action | Human action |
|---|---|---|
| Receipt | retain original and case ID | none |
| Extraction | propose three fields | inspect uncertainty only |
| Validation | check master data and duplicates | decide discrepancies |
| Approval | log status and edits | approve explicitly |
| Transfer | send confirmed values once | resolve failed cases |
The important gain is not "no person touches a document". It is a clear division of labor: software handles repeatable steps; people handle uncertainty and exceptions. Duplicate entry can disappear without removing control.
Begin with a controlled trial
Run the new route alongside existing handling first, without writing to the destination. For a defined number of documents, compare every proposed value with the original and manual entry. Record correct fields as well as missing documents, corrections, duplicates and review time.
Move to a limited transfer only after the business understands common exceptions. Enable one supplier and one document type, for example. After each transfer day, reconcile counts and case IDs across intake, review list and destination. A simple reconciliation might show twelve arrivals, one duplicate, two cases waiting for review and nine transferred records. The total must be explainable.
Agree a fallback route. If the interface fails, employees may process a case manually, but must record the same case ID. Otherwise a later retry creates the duplicate that the workflow was meant to prevent.
Start with one document type, one receipt channel and one destination. Gather normal examples, corrections, missing references and genuine duplicates before building. To define and implement this route for your business, a DevSeal automation pilot can establish the first controlled workflow.